Skip to content

RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-07-30, verbatim. Original of record lives in the RTOpacks repo. Per FENCE-PROTOCOL-01 §4 this copy is never edited and never promoted into home canon; local force is home-side (UCCA-CROSSING-ENGINE-STATE-RESPONSE-01 and the runnable-state document it commits to). Crossed WITHOUT a published digest — the sha256 below was computed on receipt on the UCCA side, with no origin manifest to check it against; if RTOpacks publishes a different digest, theirs governs and this copy is re-filed. sha256 of crossed bytes (body below): 9a29b475f79f71278e926c73982ea70957b76e414e8b87cd03b189efe0d95772.

RTOP-ENGINE-STATE-REQUEST — 2026-07-30

From: RTOpacks (via Tim) To: UCCA Inc Asks for: a filed statement of the engine's current runnable state.

Why we're asking

RTOpacks is about to build a thin end-to-end thread: one qualification goes into the engine, something comes out, and it lands on a viewable RTOpacks surface labelled BETA / uncalibrated. We are deliberately deferring quality — the point is to get the whole loop running, then improve it.

We cannot scope that work until we know what the engine can actually do today. Right now that is the single biggest unknown in the plan.

What we're asking for

A short document describing the engine as it currently runs — not as designed, not as intended, not as it will be. Rough is fine. Incomplete is fine. Honest is the only requirement. If something doesn't work, say it doesn't work; that is more useful to us than a description of the finished version.

Please answer these, in whatever order suits:

  1. Input. What do you hand it? A unit code, a qualification code, a file, an API call? What exact fields or arguments does it need? Where does that input have to come from?
  2. Output. What comes out? Files, JSON, a document, rows in a database? Please include one real example output, verbatim, warts and all — a genuine artefact from a genuine run beats any description of one.
  3. How it is invoked. Command line, script, HTTP endpoint, manual steps in a sequence? Is a human needed part-way through, or does it run start-to-finish unattended?
  4. What it has actually been run on. Which qualifications or units, how many, and when. We are asking what has succeeded, not what should succeed.
  5. What breaks. Known failures, unimplemented paths, things that only work on certain inputs, anything held together with tape. This section being long is a good sign, not a bad one.
  6. Timing and cost. Roughly how long does one qualification take end to end, and what does a run cost.
  7. Where output currently lands. Local disk, a bucket, a database, nowhere?
  8. What it needs that it doesn't have. Data, credentials, decisions, anything blocking.

Form

  • A single markdown document, filed and crossing verbatim per FENCE-PROTOCOL-01.
  • UCCA-authored, so it keeps the UCCA- prefix. Suggested name: UCCA-ENGINE-RUNNABLE-STATE-<YYYY-MM-DD>.md. Authorship stays home; RTOpacks will not re-prefix it.
  • No need to tailor it to RTOpacks' conventions or vocabulary. Describe the engine in UCCA's own terms.

What happens with it

It becomes the gate-1 input to the RTOpacks thin-thread brief. Nothing is committed to or promised on the basis of it — it is an input to scoping, not an agreement about scope.

Filed by RTOpacks, 2026-07-30. Relay: Tim, sole relay both directions.