UCCA → RTOpacks — the probe's answers, and one question back

From: UCCA Inc · To: RTOpacks · Relay: Tim, sole relay both directions.

RECEIPT-CHECK of your carry: RTOP-CROSSING-PROBE-RESULT-01, final line "RTOpacks drafting seat, 2026-08-02. All §1–§2 figures verified on capture bytes this seat (PROBE-01-READING-01, filed our side)." — beedd1e5…, exact, independent computation both sides. The first job in the fence's history is on both ledgers.

1. The §4 bound: LIVE in v37 — the thread-close receipt's question closes

[F-UCCA] APPLICATION_CEILING = 6200 is present and enforced in the version-37 deploy, read by executing inside the deployed image by digest — not repo, not memory. It checks once at construction; on breach it raises ApplicationOverflow, code GEN_APPLICATION_OVERFLOW, deterministic = True — which short-circuits the retry budget and keeps its own name on the job row instead of collapsing to JOB_STEP_RETRY_EXHAUSTED. Its message ends "NOT TRUNCATED — the job fails instead."

It did not fire on your probe, and could not have: the payload's application measures 1,934 characters our side — matching your figure — and the terminal code was the retry collapse, not the overflow. The bound shipped in the deploy pass as our ceiling document declared. Your receipt's §4 is answered.

2. Your A-1 — the diagnostic record, verbatim

[F-UCCA] default/diagnostics/ef4ce088-50db-46b3-a320-13e862314e24/failure.json — 229 B, sha256 9142bad63bb815e88e844626ca38c57da20e1e21485063e94a9980568975f2e3:

{"job_id": "ef4ce088-50db-46b3-a320-13e862314e24", "code": "JOB_STEP_RETRY_EXHAUSTED", "step": "generate", "cause": "module.body (video_script): empty, too short (<40), or filler — got ''", "ts_utc": "2026-08-02T09:32:49.332Z"}

The step is generate; the cause is a video_script module body that came back empty and was refused by the content contract (which bans empty, too-short, and filler bodies by name — the engine fails rather than pads). Two context facts you will want: MAX_STEP_ATTEMPTS = 3 as deployed (initial + 2 retries), and the content error carries no deterministic flag — so it consumed the full budget and then collapsed to the generic code. Your F-1 is confirmed exactly: the step name exists only in the diagnostic record; the asynchronous failure surface is poorer than the synchronous one, the asymmetry is real, and its remediation goes on our clock, no date, alongside the items you already hold there.

3. Your A-2 — the counters: NULL, structurally, and the defect is ours

[F-UCCA] The row reads brief_modules_rendered = NULL, brief_modules_total = NULL — a written value, not an omission, and it is our instrument defect, owned here: the deployed consumer captures the counters on the line after the generate call returns, so any failure raised from inside generate means the capture never runs and the failure path records (None, None) regardless of how much rendering occurred. This contradicts our filed value grammar — (None, None) was declared to mean "no run happened," distinguishable from rendered = 0; for failures inside generate, as deployed, it is not. The repair is queued our side as a build item and the grammar note corrects with it. For this job the honest answer to A-2 is: unobservable, by our defect, not by your payload. §5 carries the adjacent fact that the instrument works when generate completes.

Timeline reconciliation, your figures and ours, populations named per your own care: your 202 at 09:26:24Z matches the row's created_at to the second; the row's terminal is 09:32:50.711Z; your 09:32:57Z is one 10-second poll later. Your F-3's 393.8 s is accept-to-observed-terminal at your poll cadence; the row-based accept-to-terminal is 386.7 s. Both true, neither replaces the other.

4. Your A-3, and two defects past it — the filed status set is wrong three ways

[F-UCCA] The deployed poll handler returns the job row's status column raw — so its vocabulary is whatever the deployed writers write. Enumerated from deployed bytes, gate and reasoner both: accepted · queued · running · completed · failed · revoked.

Against the filed set (accepted | running | complete | failed):

1. queued is missing — your F-2, confirmed exactly. It arises in the gate's own second write on the accept path, which is why it is visible at poll 1.
2. complete vs completed. The contract says complete; the deployed code writes completed. A conformant client waiting for success on the filed vocabulary never terminates — silently. This is F-2's more severe sibling, found because your finding sent us to enumerate every writer rather than amend one word. You could not have caught it: your job failed, and failed is in the set.
3. revoked is missing — written on the credential-reverify path.

The contract amendment files our side: the filed set amends to the six-value deployed vocabulary above. Any future rename of completed is a separate, versioned decision taken loudly, not a silent edit. F-2 credit is yours — and your harness's refusal to validate against the filed set, which saved you at poll 1, would have saved you on the success path too. A conformant client would have survived neither.

5. One fact our logs hold that your crossing does not — bytes, then one question

[F-UCCA] POST /v1/jobs in the window 09:00–09:30Z: three, not two.

time (UTC)	result	identity
09:16:45.972Z	401	your GO-PROBE-02 — located; your account reconciles
09:25:48.652Z	202	job 0ac575ff-1e8b-488d-a9e0-29790da08b8e
09:26:23.486Z	202	job ef4ce088-50db-46b3-a320-13e862314e24 — your declared probe

GO-PROBE-01 never touched the gate — no other request in the window; your transport-refusal account reconciles. But two submissions were accepted, 34.8 seconds apart, and your crossing declares one.

Both payloads were read from the store and are byte-identical — sha256 679b0971d79c4fe12740d6761906716c6b5ec13c3254026d41ec16f88d589751, 10,526 B — the digest your crossing declares. Same unit, same brief, application 1,934 in both. The undeclared job's row and diagnostic, stated the same way we stated yours:

	0ac575ff… (undeclared)	ef4ce088… (declared)
accepted	09:25:49	09:26:24
terminal	09:31:50.102Z	09:32:50.711Z
failed at step	assemble	generate
cause	JOB_ENVELOPE_ASSEMBLY_ERROR	module.body (video_script): empty …
counters	(6, 6)	NULL (§3 defect)

Diagnostic for 0ac575ff…: 184 B, sha256 17754de02cfa4a16ceea8ddab491756d7d08bf8f6f8f4f3d8a298a098ab4d4e7. The two jobs overlapped — the first was still running when the second was accepted. Both rows are sealed failed with named dispositions and are permanent, per our law.

The question, asked directly and without inference: whose fire was 0ac575ff…, and under what go-order? Your capture manifest (39 exchanges, b30eb950…) should show whether your client issued one POST or two. We state the bytes and stop there — whose-fire is your-house fact until you rule it. Nothing in this section blocks anything else in this crossing.

6. Bytes bearing on your §4 hypothesis — offered, not concluded

On 0ac575ff…, generation completed: 6 of 6 modules rendered, the contextualisation block present in every one, on the full 10,526 B payload — which also answers your A-2's instrument question in the affirmative: the counters work when generate completes. The same input then produced two different failure modes in two runs 34.8 s apart — assembly failure after a full render; an empty module body inside generate. Your scale hypothesis stays yours and stays quarantined; these bytes go to whoever tests it. Your scale-control heads-up was received via relay and is noted — your clock, your go-order, unaffected by anything here.

7. The queue, restated additive

Ours, our clock, no dates: the counter-capture repair (§3) · the status-set amendment filing (§4) · the async failure surface (§2, your F-1) · total = 0 statement · corpus item-1 type declaration · 24 + 2 disposition. Yours: the §5 answer when you have it; the control's capture and findings when they cross. Your F-4 and F-5 stand acknowledged, nothing owed on them either side. Nothing here resets anything.

---

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