Skip to content

UCCA → RTOpacks — on the engine-state request

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

Receipt. RTOP-ENGINE-STATE-REQUEST — 2026-07-30 received and read in full. Final line echoed: "Filed by RTOpacks, 2026-07-30. Relay: Tim, sole relay both directions." Filed byte-verbatim to canon/received/, unedited, not promoted to home canon.

Two carriage notes, neither blocking, neither acted on. The document arrived without a digest — we computed one on receipt, 9a29b475f79f71278e926c73982ea70957b76e414e8b87cd03b189efe0d95772 (42 lines, 2,844 B); if that differs from yours, yours governs and we re-file. And it carries no YAML frontmatter, where our filing convention expects it. We have not repaired either — respond-never-redline. Flagged so both ledgers reconcile.

1. Yes — and the convergence is worth naming first

Yes to the document. The request is reasonable, the framing is right, and "honest is the only requirement" is the standard this house already holds itself to.

Before anything else: on 2026-07-28, before this request existed, UCCA ruled its own roadmap as three windows — (1) a measurement pass, now closed; (2) an in-house end-to-end beta loop, one unit forward through the live spine and the engine's own output diagnosed backward, zero client material; (3) the RTOpacks beta as a repeat, not a build.

Your thin thread is our Window 3. Neither house saw the other's plan. Two independent derivations of the same next step is the strongest evidence either of us has that it is the right one — and it means the thing you are asking us to scope, we are already scoping, one window ahead of you.

2. What the document will be, and the honest limit on when

The runnable-state document will be UCCA-ENGINE-RUNNABLE-STATE-<date>, UCCA-prefixed as you asked, in our own terms.

It is not written yet, and we are telling you why rather than sending you something faster and worse. Most of what you asked for — a real example output verbatim, what has actually been run and when, timing, cost, where output lands — is live substrate, not documentation. Our drafting layer is structurally blind to a good deal of it: it cannot enumerate object storage, and the operator console is unreachable to it. Producing those answers honestly requires a reconnaissance pass with live reads, which is now scheduled, and the document follows it.

This delay is the request being honoured, not deferred. The failure mode your §17 warns against — "not as designed, not as intended, not as it will be" — is exactly the failure mode a house produces when it answers a runnable-state question from its own documentation. We have spent this week finding fossils of precisely that shape in our own ledger. You will get proven state with reads under it, and everything we cannot establish will be labelled as not established rather than smoothed over.

One thing we can commit to now, because it is already filed canon rather than a promise: where the answer is "that doesn't work" or "nobody has ever run that," the document will say so in those words. Your §25 is right that a long "what breaks" section is a good sign. Ours will be long.

3. The constraint that is not ours to relax

Stated up front so it shapes your scoping rather than surprising it late.

The engine raises hands; it never signs. A TRACED finding asserts that a byte-verified verbatim anchor responsive to an element exists in the submitted material, on the claim's declared basis — and nothing more. It does not assert the obligation is met, satisfied, or complied with. A NOT_YET_TRACED finding asserts an honest gap in the trace — never a finding of failure, deficiency or non-compliance. That is ratified canon this side (NORTHSTAR-01 §6, FOUNDATION-01 §2), it holds for every client in every domain, and a BETA or uncalibrated label does not change it.

The practical consequence for a viewable surface: if the surface renders a finding as compliant, met, satisfied, passed, or a percentage that reads as any of those, it is asserting something the engine did not. We raise this now because it is cheaper to design a surface around than to retrofit, and because it is the one point on which we cannot meet you halfway.

4. Questions — tier 1, scoping

These are the ones whose answers change what the runnable-state document should emphasise. Short answers are fine; "we haven't decided" is a real answer and a useful one.

  1. What is "one qualification goes into the engine"? A code, a file you hold, a pack you already produce, or a compiled structure? This matters more than any other question here: our throat consumes a compiled normal form, and per ADR-0002 the compiling adapter lives on the client side of the boundary. If your thin thread assumes the engine ingests a qualification code and does the compiling, the thread has a component in it that neither house has built — better to find that now than at gate 2.
  2. Who compiles, in your picture? RTOpacks, UCCA under contract, or a thing you assumed already existed?
  3. What does "something comes out" have to be for your surface to render it? Our terminal artefact is a signed, expiring, revocable credential envelope — verifiable, machine-addressable, and not a human-readable document. Something has to render it for a person. Is that renderer yours, ours, or unassigned?
  4. Forward or backward? The engine runs in two directions: forward, generating material that traces coverage by construction; backward, diagnosing existing material against an obligation. Both are proven. Your request doesn't say which one the thin thread uses, and they are different threads with different inputs. If the honest answer is "whichever is easier", say so — we have an opinion and will give it once we know what the surface is for.
  5. Internal or client-facing? Is the BETA surface seen by RTOpacks staff, or by an actual RTO? The honesty grammar required is materially different, and we would rather over-engineer the first than under-engineer the second.
  6. Where does RPL sit? Tim has ruled that RPL and this thread are the same parcel in different wrapping, and our RPL capability answer crosses with this document. Is evidence→competency reasoning in scope for the first thread, or a later one? It is a mode on the backward core rather than a re-engineer, so the answer changes sequencing but not feasibility.
  7. What is gate 2? You've named this as gate-1 input. Knowing what gate 2 decides tells us what gate 1 actually has to carry.

5. Questions — tier 2, the hard ones

Asked directly because a thin thread scoped around an unstated assumption is the expensive kind.

  1. Who is the accountable human in your loop, and at what point do they act? Our canon requires that the accountable judgement stays human. A loop with no human in it is not a thin thread — it is an unsigned one. If the answer is "nobody, it's a demo", that is fine and we will say so on the surface's behalf; but it should be a decision, not an omission.
  2. What is your appetite for the engine being confidently wrong? Our measured failure direction is over-claim — the engine's errors run toward claiming a trace that a careful reader would not. On a compliance surface, an over-claim is a false assurance about a regulated obligation. Do you want the first thread to run with that exposed, or gated?
  3. And the reverse: how would you feel about a thread that returns almost nothing? The honest possibility is that on real RTOpacks material the engine finds few anchors and returns NOT_YET broadly. This has never been tested. Our corpora, until three days ago, could not even construct the case where material genuinely meets an obligation without restating it. Your thin thread may be the first real measurement of that direction anywhere. Do you want to be that test — and if the answer is a wall of NOT_YET, is that a finding or a failure?
  4. What does "uncalibrated" mean to you, precisely? A word on a banner, a legal position, an internal caveat, or a promise to a client that numbers will change? We ask because we have a specific allergy to labels that carry more assurance than the thing behind them.
  5. What would make you abandon the thread? Naming the kill condition before starting is worth more than any spec. If nothing would, that is also worth knowing.
  6. What are you hoping to learn that you don't already believe? If the thread is meant to confirm something, it will confirm it. If it is meant to surprise you, it should be designed to be capable of surprising you, and those are different builds.
  7. Is the real subject of this thread the engine, or the seam between the houses? A thread that proves the engine works and a thread that proves the interface works are different threads, and only one of them needs the engine to be good. Our read is that the seam is the higher-risk unknown. Yours may differ, and if it does we would like to know why.
  8. What happens to the output afterwards? Kept, shown, discarded, used as evidence of anything? Our credentials expire and are revocable by design; if your surface caches a rendering, the rendering outlives the claim.
  9. How much of this do you want to be able to run without Tim? Every crossing today is hand-carried by one human, which is correct discipline and does not scale to a running loop. At some point the thread needs either an API and credentials, or an accepted human bottleneck. Which, and when? This is the question hiding inside "thin thread" and we would rather ask it early.

6. Questions — tier 3, the what-ifs

Speculative on purpose, per Tim's instruction that lateral thinking is wanted on top of the immediate need. No answer is owed on any of these; a one-line reaction to any one is useful.

  1. What if the first output is obviously, visibly wrong? Success — the loop ran — or failure — the surface embarrassed someone? Answer determines who should be in the room for the first run.
  2. What if it is subtly wrong? Materially harder, and the more likely case. Does anything in your plan catch a plausible-but-wrong output, or does the thread assume the output is either right or obviously broken?
  3. What if the qualification you pick has an open enumeration? Our scope claims cover the enumerated content only and say so. On some qualifications that caveat is a footnote; on others it eats the claim. Do you want to pick a qualification that makes the thread look good, or one that makes it informative? They are usually not the same document.
  4. What if we ran your material through the engine and it disagreed with your own experts? Which one of you is wrong, and how would you want to find out? We have spent this week discovering that our own answer key was wrong more often than the engine was — and that some questions were not gradeable at all because they had never been asked precisely enough. That result is likely to recur on real material, and it is not a defect; it is what the instrument is for.
  5. What if the bottleneck turns out not to be the engine? If the thin thread's slowest, most fragile, most human-dependent step is compilation, rendering, or the crossing itself — is the plan still worth running, and does it change what you would want from us?
  6. What if UCCA is wrong about what you need? We author nothing on your behalf by protocol, but we may still have assumed something. What in this document reads as us describing your house rather than ours? Name it and we will withdraw it.
  7. What would you ask for if you could ask for anything, ignoring what you believe we can do? We would rather hear an impossible request and say "not that, but here is the adjacent thing that exists" than build precisely to a ceiling you imagined for us.

7. What this document does not do

Commits UCCA to no scope, no date, no capability and no price. States no requirement for RTOpacks and authors nothing on RTOpacks' behalf — every item in §§4–6 is a question, and where a UCCA constraint is stated it is labelled as ours and sourced to filed canon. Asserts no live engine state whatsoever; that is the runnable-state document's job and it waits on reads. Does not accept or decline any scope for the thin thread. Does not promote the received request into home canon.

8. What we need back, minimally

Tier 1 is the set that unblocks work. Questions 1 and 3 are the two that most change what the runnable-state document should contain — what you hand the engine, and what the surface has to render. Everything else can follow at your pace.

Crossing discipline. UCCA-authored; filed to canon/sent/ before relay; carried verbatim by Tim, who is the sole relay in both directions. Crosses in one parcel with UCCA-CROSSING-RPL-CAPABILITY-ANSWER-01, which has been filed and awaiting carry since 2026-07-06 and answers RTOpacks' earlier RPL query. Actor names are qualified throughout by protocol: UCCA-side Claude drafted this; UCCA Alex files it; Tim carries it.

RECEIPT-CHECK: echo this line's end before acting.