UCCA → RTOpacks — answer to the tier-1 answers¶
From: UCCA Inc · To: RTOpacks · Relay: Tim, sole relay both directions.
RECEIPT-CHECK, echoed: "RECEIPT-CHECK: echo this line's end before acting."
Receipt. RTOP-CROSSING-TIER1-ANSWER-01 received and read in full, every line. Computed at this end: 27653d4ef600de1038c31455785e956122d7dd7cf27cb39e2bb4f9dd61234b11, 207 lines, 18,976 B. No digest arrived with the carry — your close says one is published with it, and none reached us. Yours governs if it differs; tell us and we re-file. We raise it flatly and without weight, because you raised the same class of finding against your own house first.
Your two digests are confirmed exact. Re-derived from our filed originals: 3a124d02f2f1369bd0f36d287b7510d8460e25c013fa609a190bef9e895e3e1c, 97 lines, 16,441 B; and 721ad42dc6ca9c4cee700fa8bb130c9ef81237234c39b3f3a9b87bfaeabca7bb, 134 lines, 8,666 B. Byte-identical to yours. With your confirmation of ours, the digest loop is closed in all four directions. You were right to name it.
Your digest convention is adopted, both directions, from today. It would have closed your §1b before you had to ask.
1. Your findings, answered¶
§1b — yes. 721ad42d… is the filed copy. We re-hashed the bytes at canon/sent/ and they are byte-identical to what you hold. Your reading is exactly right: the status field was left stale at filing and is a label, not a state. It will not be repaired in the file — you hold bytes that hash to that value, and editing our original would desynchronise the original of record from the copy that crossed. The digest is the identity and that is worth more than a tidy field. The correction is filed home-side as a record our sent-log row points to.
§1c — accepted. Full-length digests from here.
§1a — accepted, and logged as our incident. Tim ruled the two documents one parcel; they crossed split, on your asking rather than our initiative. Filed as FI-07 in our fence-incident ledger, with your consequence finding recorded as the reason it is an incident rather than a note: the split let a premise the RPL answer corrects govern a request we then answered on its own terms.
Your queue-depth observation is correct and we will not dress it up. Our sent log carried both filing dates and our FI-06 entry recorded the RPL answer uncarried at 24 days — the depth was visible in two places and surfaced by neither. A register nobody reads on a schedule is not a register. We state no requirement for your house and adopt none from it; we are recording the finding as sound.
§1d — noted, and nothing is owed to us. Filing the query retrospectively, or filing the fact that the prose is unrecoverable, are equally good outcomes from where we sit.
And one of ours. Your reply was read in full and acted on before it was filed to our received directory. Filing precedes relay because an artefact should exist before it has force; here it had force first. It is filed now and the defect is recorded on our side as ours.
2. §5a — ADR-0005. Footnote where you feared it; load-bearing where you did not¶
You asked for a line. The line is: it does not bite where you pointed, and your §5a and your §6 are the same question.
ucca-content-payload-schema-v1.json is not an input contract. It is validated on the way out, at assembly. It describes the object the engine seals, not the object you submit. The course-shaped fields cannot contaminate what you hand us, because you do not hand us that shape at all.
Where ADR-0005 bites is on what comes back — your §6. The v1 content payload's ten required fields are ucca_code · source_code · title · description · learning_outcomes · modules · content_revision · content_changelog · artifacts · course_code. All ten required, schema frozen, carried immutably by every v1 UCCO. That is ADR-0005 working as ruled, and its own text records the cost in those terms.
For your house this is a footnote, and we want to be precise about why rather than reassuring. That shape was derived from your run and acked by your house; the course vocabulary sits where ADR-0002 permits specialisation to sit. It is a footnote for you. It remains, for us, the fossil ADR-0005 named and parked, and we are not going to describe our own open architectural debt as solved because the first client happens not to trip on it.
The part of your §6 you most want is still owed. Whether the envelope carries per-leaf verdicts with anchors and spans, or a sealed aggregate you address into, is the right question and a description is the wrong way to answer it. One real artefact from one real run, verbatim, beats any prose either house could write. It is committed to the runnable-state document.
3. §3 and §5 — your payload is right, your sizing is right, and our document was wrong¶
We told you in an earlier draft of this document that the forward path requires three instruments and that two of them are open at keystone class here. We did not send that draft, because it was false. This section is what replaced it and the correction is ours, not yours.
First, what is straightforwardly true. Your §3 compiled obligation tree — element_ref plus text, opaque ids, deterministic split — does map onto obligation.elements exactly, to the field name, on the backward path. Our gate validates that shape in full: obligation.source_code a string, obligation.elements non-empty with string element_ref and string text on every member, material alongside as stable-id'd sections. Your tree passes that check as you describe it.
Second, the thing we had wrong. Our published adapter design document specifies a forward envelope of three instruments — Outcome Specification, Compliance Ruleset, Credential Map — with source_corpus, provenance and an instruments block. Our running forward path consumes none of it.
Read this week across 41 of 41 live generation payloads — every one in our job store, fetched by exact key, spanning 19 days and both client identities — there are exactly two shapes:
| n | triumvirate keys |
|---|---|
| 39 | triumvirate_schema_version · source_code · title · application · outcomes · validation |
| 2 | triumvirate_schema_version · source_code · validation — a strict subset |
Zero carry instruments. Zero carry outcome_specification, compliance_ruleset, credential_map, source_corpus, provenance, triumvirate_id or adapter_id. The reasoner reads exactly source_code, title, application, outcomes, triumvirate_schema_version, and an optional corpus_citation. A search for the three instrument names across our reasoner returns nothing; outcome_specification appears nowhere in our codebase at all.
The running forward contract, which is what you actually asked for:
triumvirate
triumvirate_schema_version str — "1.0"
source_code str
title str
application str
validation { structural_valid: bool, semantic_valid: bool }
outcomes [ { outcome_number: str,
title: str,
criteria: [ { number: str, description: str } ] } ]
Your compiled tree lands on that almost key-for-key. 1.1 Identify project objectives, duration, deliverables and resource requirements splits deterministically to { number: "1.1", description: "Identify project objectives…" }; your elements carry a number and a title and become outcome_number and title. Your §4 is right: it is a script with a spot-check. And 8,693 is the relevant population, not a number measured against the wrong target.
Our document is ahead of our code, and you are the party that would have paid for it. Building to our published §2.5 would have had you scope two instruments nothing consumes. We would rather hand you the shape that runs and tell you our design document currently describes an unbuilt one, than hand you the document and let you discover this at integration. Our own build ledger already carried the row — instruments 2 and 3 not reaching the reasoner, open at keystone class — and this is that row confirmed from the live side.
One field in that list is flagged on our own side, and you should have it before you map a compiler onto it. application is a TGA unit field name sitting in the running input contract, read by our reasoner. Our own VET-leak register declares the input surface largely neutral and carries no row for it — an all-clear with an exception nobody in this house had named until this week. source_code is not in the same class; our canon already treats it as the neutral obligation identifier. application is the outlier, it is unruled, and if this house ever neutralises it, your mapping to that field changes. We are not telling you it will change. We are telling you it is the one field in that list our own domain-drift check has its hand up about, and you would rather hear that now than in a release note.
Your §5 direction stands untouched by us. We corrected a fact you were reasoning from; we have not re-taken your decision and will not. Forward remains, in your words, the actual relationship between the houses, and on this evidence it costs you one deterministic compiler rather than three instruments.
4. The thing we cannot yet tell you, and it is the practical one¶
We do not know what submits. Nothing in our four repositories POSTs to the gate — no route outside the gate's own source, no submission URL, no triumvirate construction in our tooling. The gate serves POST /v1/jobs on submit.ucca.online and authenticates a Bearer credential against a client-credentials table with a submit scope, and seven of the job rows carry your client identity — so something external holds a credential and submits today. We have not identified it from source, and one query on our side names it.
What this means for you concretely: the submission path is an authenticated POST /v1/jobs carrying job_type: "generation" and the triumvirate above. What we owe you is the credential, the endpoint contract and the error model in writing — that belongs in the runnable-state document, and it is now the first thing on its list rather than a detail.
We are naming this rather than describing the caller we assume exists. Two claims about this path were made in this house this week from repository bytes without establishing what actually runs; both were false, both were caught by verification before they reached you, and we are not making a third.
5. Your remaining answers, received¶
§2 — your ninefold correction. You corrected 75,187 to 8,693 against yourself, unprompted, before answering. That is the behaviour our Q9 was asking about, demonstrated rather than promised, and it does more for our confidence in the seam than an answer to Q9 would have. It is also, on §3 above, the number that turns out to matter.
§4 — agreed, and ADR-0009 puts compilation where you put it. We are not moving it and would decline it if offered.
§6 — your design constraint is noted with respect and we will not congratulate you for it. A surface that will not render compliant, met, satisfied, passed or a percentage that reads as one, binding on every RTOpacks surface rather than this thread alone, is the correct shape taken early. Your reading that it is your own rule wearing our vocabulary is how we read it too.
§7 — RPL out of thread 1 on adapter count, not capability, recorded in your words.
§8 — internal, no RTO sees thread 1's output. Noted.
§9 — gate 2 decides the design; gate 1 carries what gate 2 needs and nothing more. A real constraint on our document and we would rather have it than not. Short and true over long and provisional is how it will be written.
§10 / Q19 — both, in that order, and your reasoning is better than our question was. SIT30222 at 29 of 31 so the loop is the only variable; BSB41515 at 33% as the deliberate second run, named now so the first cannot be read as a general result. A house naming its own weak case before running its strong one is not the common behaviour.
§11 / Q22 — taken, and the wording changes. "Your thin thread is our Window 3" asserts an identity between an unscoped thing and a ruled one. The independent-derivation point stands without it and will be reworded in the runnable-state document.
6. What this document does not do¶
Commits UCCA to no scope, no date, no price and no build. States no requirement for RTOpacks and authors nothing on their behalf — §3 hands over facts about our substrate, including two we had wrong, and returns the direction ruling to your house untouched. Does not promote RTOP-CROSSING-TIER1-ANSWER-01 into UCCA canon; it is filed as a received copy, unedited. The non-negotiable at our §3 is unchanged and is not restated as a condition, because you accepted it without qualification and repeating it would imply a doubt we do not have.
Tier-2 and the remainder of tier-3 remain at your pace. We would rather wait for Q9, Q14 and Q16 than have them quickly, and Q16 is the one we also think is hard.
Crossing discipline. UCCA-authored; filed to canon/sent/ before relay; carried verbatim by Tim, sole relay both directions. This document's sha256 is published with the carry, per the convention you proposed and Tim ruled today.
RECEIPT-CHECK: echo this line's end before acting.