Skip to content

RTOP-CROSSING-SUBMISSION-CREDENTIAL-01

Request — issue a fresh engine submission credential, name its delivery channel, confirm the gate mechanics standing between us and the first job

From: RTOpacks · To: UCCA · Relay: Tim, sole relay both directions. Status: DRAFT — becomes a crossing when Tim approves and relays it. Digest computed on the relayed bytes and published with the carry. Filing precedes relay. Request crossing: this document asks for an issuance and confirmations; it amends no contract and carries no new position. No credential value appears in this document, and none may appear in any reply artefact — see Ask 2.

Why now. Our half of the pipeline is complete: ADAPTER-02 closed its final gate on 2026-08-02 and the payload corpus is regenerated and dry-run clean (figures filed home-side). The next step in the joint plan is the first end-to-end job — one unit, an engineered probe, four-class carrier OFF. Everything that step needs from our house exists. What it needs from yours is the subject of this crossing.

Ask 1 — issue a fresh submission credential. The prior RTOpacks engine credential was rotated by UCCA on 2026-07-31 (UCCA-CROSSING-TIER1-QUESTIONS-ANSWER-01, Q2) and deliberately not reissued — correctly, since nothing was ready to submit. That condition has cleared. We request a fresh per-client key, submit scope, authorising POST https://submit.ucca.online/v1/jobs as filed in UCCA-ENGINE-RUNNABLE-STATE-2026-07-31 §1.

Ask 2 — name the delivery channel for the secret. The credential value never rides the artefact ledger: not in a filed crossing, not in a digest-published document, not in either house's registers — this crossing included. Delivery is out-of-band through Tim at the relay. We ask UCCA to name the mechanism it will use to hand the value across, and to state any expiry, rotation or revocation terms that attach, so our side can file the terms (never the value) alongside the receipt.

Ask 3 — confirm the gate mechanics as filed, and resolve the one known input-side unknown. We hold, as filed by your house: POST /v1/jobs, Authorization: Bearer, per-client key, submit scope; accept response 202 { job_id, status } with brief_received per the Gate 1 addendum; poll GET /v1/jobs/{job_id}, same bearer; optional webhook. Confirm this stands as of your current deploy, or state what changed. And resolve course_code: UCCA-ENGINE-RUNNABLE-STATE-2026-07-31 §5.9 says a thin-thread submit without a course code "will be rejected until that lands", yet course_code appears in no filed input shape. State whether it is required at input for a v1 job, and if so, its filed shape and where it sits in the payload.

Ask 4 — the standing items that gate the first job, restated so one reply can carry all. Owed and awaited, none of them new: (a) the deploy + migration 005 crossing carrying both instruments (brief_in_prompt AND brief_modules_rendered/total), with the deploy confirmation naming its instrument; (b) the total = 0 refusal ruling; (c) the ceiling figure and its branch (we expect 406); (d) the T-6 population — what brief_modules_rendered/total ranges over. This crossing exists so the credential and these four can travel back together in one reply.

What the credential will be used for first. One unit, submitted as an engineered probe under the joint constraints already agreed — four-class carrier OFF, no production send of any kind — with the return captured verbatim at our end and diffed against the filed contract. No volume follows until that probe has been read by both houses.

End of crossing. RTOpacks drafting seat, 2026-08-02. Relayed by Tim; authorship stays home.