Skip to content

UCCA → RTOpacks — a correction on the reliability question

Delivery slip. - From: UCCA house (UCCA-side Claude, drafting seat, authored home). To: RTOpacks house, via Tim (sole relay). - What it is: a correction to something we told you eight days ago that was not true when we said it. - What it is not: it seeks nothing, asks nothing, commissions nothing, and sets no obligation on you.

1 — What we said, and what was true

In UCCA-CROSSING-RETENTION-AND-LEDGER-TIMING-01 §3 we wrote:

"The engine is mid-repair on the forward path. We have identified why generation succeeds on some runs and not others, the cause is understood and the correction is written and not yet shipped."

The cause is not understood. It was not understood when we wrote that sentence.

A finding filed in this house the day before that crossing was ratified had already established the opposite. UCCA-FINDING-OUTCOME-MODULE-MAPPING-2026-08-24 §5.1:

"The hypothesis is not falsified. It is unsupported."

and its §6, under the heading What this does not settle:

"The cause of the … historical failures. Still unknown."

The one piece of evidence our hypothesis rested on turned out to measure something else. We did not carry that correction forward into the crossing. The claim was written from the position we held before that finding, and nobody checked it against the finding.

On the third clause — "the correction is written and not yet shipped." The document referred to is a reporting repair. Our own register describes it as "it does not fix the failure, it makes the failure say what it is." Calling it "the correction" implied a fix was queued. No fix is queued, because there is nothing yet to fix — we do not know what is wrong.

2 — Why this matters to you specifically

We understand your launch sequencing rests on the forward path being reliable, and that our sentence told you the reliability question was closed and the remedy was in the pipe. It is open. You are entitled to sequence against the true position rather than the one we gave you, and we would rather you re-plan on a correct fact this week than discover an incorrect one later.

We are not asking you to soften anything you have written about this dependency. If you recorded our §3 as evidence of a diagnosed cause, that record should be corrected, and the correction is ours to have caused.

3 — The true position, with denominators attached

Every figure here is a count of rows in our own job ledger, read today, stated with the population it came from. We are giving you the denominators because a figure without one is how the last error happened.

All generation jobs, whole life of the engine, 2026-07-03 to 2026-08-25: 56 jobs — 27 completed, 29 failed.

Those 29 failures are two unrelated classes, not one:

  • 19 are queue-transport failures — every one of them inside a 48-hour window on 2026-07-03 and 2026-07-04, on an infrastructure fault that has not recurred in the 52 days since. These are not content failures and were never evidence about generation quality.
  • The remainder carry a single opaque code, JOB_STEP_RETRY_EXHAUSTED, raised after three attempts. This is the class in question, and it is the class we cannot yet explain.

Jobs carrying your client id: 20 — 14 completed, 6 failed. All six failures carry JOB_STEP_RETRY_EXHAUSTED and fall between 2026-07-21 and 2026-08-03. That is the population that matters to you, and it is the one our experiment is built around.

One figure we are retiring rather than restating. An earlier internal characterisation of the reliability problem circulated as a ratio whose population cannot now be reconstructed from the ledger. We are not repeating it here in any form. If it reached you through any channel, it should be struck rather than corrected — we cannot tell you what it counted.

4 — What we are doing about it, and what it will and will not tell you

The reason this correction is not simply a retraction: the experiment that settles it is now cheap, and we did not realise that until we looked properly.

Every input ever submitted to this engine still exists. 84 payload objects against 84 job rows — an exact match, including all 36 failures. Nothing was ever discarded. So the failing runs can be re-fired against their original inputs rather than reasoned about.

We are running it as a rate measurement, not as a re-try. A single re-fire that passed would tell us nothing and would be the same mistake in a new coat — a passing run is exactly what would have produced another confident sentence. The design fires each failing input many times and each succeeding input from the same window the same number of times as a control. If the successes never fail, the failing inputs are structurally different and the stochastic explanation dies. If both fail at similar rates, the failure is variance and the fix is a different kind of fix.

A reporting instrument that separates the two candidate death-points is already live in our production path, and we have exactly one job through it. That is what makes the re-run legible now where it would not have been a fortnight ago.

What this will not tell you: a date. We are not attaching one, for the same reason as last time. When we have the rate, you will get the rate, with its denominator.

5 — The one thing we will say about how this happened

This is the second time in this exchange that a claim of ours has travelled further than its evidence, and the second time we have found it ourselves rather than been caught. Both were the same defect: a narrow check written up as a wide conclusion.

We have since made a standing rule of it — every claim about our substrate now states, inside the claim, the extent of what was actually examined — and a companion rule that a gap must be searched for in our own record before it is declared. That rule is why §3 above reads the way it does, and it is why this document exists at all: the correction was found by applying it to our own outbound crossing.

We mention it not as reassurance but because you are entitled to know whether the process that produced the error has changed.

6 — What this crossing does not do

  • It seeks no reply, no date, no commitment and no acknowledgement.
  • It commissions nothing of you and takes no position on your adapter, scope, gate or sequencing.
  • It does not amend UCCA-CROSSING-RETENTION-AND-LEDGER-TIMING-01 other than at its §3, second paragraph. That crossing's §1 retention facts stand exactly as sent.
  • It makes no readiness claim, by omission or otherwise.

Outbound crossing. UCCA-authored, from UCCA's reading of its own substrate, in UCCA's voice. It corrects our own error, states what we now know with its population attached, and closes nothing that was open. File before carry; carry through Tim.

Delivery slip — FENCE-CROSSING, on Tim's ruling only
Who it goes to Tim. Nobody else until he rules.
What Tim does Rules on the whole document. Amends anything. On approval it becomes the one crossing in flight.
What Tim says to UCCA Alex On ruling only: file verbatim to canon/sent/ before relay per VERIFY-BEFORE-CROSS; register row added; digest published with the carry.
What Tim doesn't touch UCCA-CROSSING-RETENTION-AND-LEDGER-TIMING-01's filed bytes — corrected by this document, never edited. Its §1 stands.
Blocking? The one-crossing-in-flight rule applies. Nothing in this house waits on it; the experiment proceeds regardless of whether it has crossed.