UCCA's Assessment of RTOpacks' Brief (Client One)¶
Read first. Every numbered requirement is answered YES / NO / ADAPTER, NOT GATE, with reasons. For every YES, what the engine needs from the client is stated as questions (§3). Drift-check flags in §4. Sequencing in §5. Nothing in the brief is edited; where a requirement needed scoping, the scoping is stated here as the engine's reading, and the client may re-cross if it disagrees.
1. Verdict table¶
| Item | Verdict | Reason (summary) |
|---|---|---|
| R-1 Forward generation as a service | YES | Within the gate; proven locally; the boundary delivery is the input-path build the engine owes its own neutrality fix regardless. One scoping note (§2). |
| R-2 Backward diagnosis | YES — unbuilt, sequenced, bar provisional | Accepted as a requirement to build. Honest ledger: unproven today. Acceptance bar cannot be set until §5's hand-raise tolerance lands. |
| R-3 Contextualisation as parameters | YES | Capability exists on disk; delivered as request parameters in the generation schema. One rebuild caveat (§2). |
| R-4 Diagnosis stub in first contract | YES | Cheap, honest, good engineering. A 501 that tells the truth beats a contract that churns. |
| B-1 Never sign | YES | This is FOUNDATION-01 §2 — the engine's own first rule. It was ours before it was a requirement. |
| B-2 Never hold client IP | YES | Process and return. Precision question on what "provenance records" include (§3). |
| B-3 Never visible | YES | Corporate fact, not convention, per ADR-0003 — different company's surfaces. |
| B-4 Never ingest client shape | YES — with a custody question | The gate accepts triumvirate-conformant jobs only; that is ADR-0002. But the brief asserts the adapter sits client-side; the March design has per-client adapter instances registered with and signing to the engine. Custody needs a ruling (§3, Q-B4). Not a contradiction of the requirement — a gap both sides must pin. |
| B-5 Mode on the record | YES | Direction of run enters provenance and survives into the UCCO envelope. One naming flag (§4). |
| D-1 API only | YES | The boundary is physical and stays physical. |
| D-2 No local dependency | YES | Matches the engine's own skin/body split; the contract surface is a service. The engine's runtime choices behind it are the engine's. |
| D-3 Ingest via client export path | YES | Supersedes the March design's cache-miss network acquisition, as the engine had independently concluded. Hash-discipline question (§3). |
| D-4 Isolation inherited | YES | Existing architecture: per-world DB, per-client instance, per-client audit namespace. |
| D-5 Sign-off lives client-side | YES — and adopted as the ruling | Resolves the March dual-signature ambiguity: the UCCO envelope carries machine signatures over provenance only; the human countersign is the client's world-layer workflow. The engine-side canon will record this ruling citing this crossing. |
No NOs. No ADAPTER-NOT-GATE verdicts — the brief correctly pre-sorted its VET-shaped material to its own adapter before crossing, which is the drift-check doing its job on the drafting side. Two near-misses are flagged in §4 so the check is seen working.
2. Scoping notes on the YESes (the engine's reading, stated not redlined)¶
R-1 — "traceable by construction (analysis first, generation falling out of it)." The engine accepts this as a property of the output and its provenance: the record will show that obligation analysis preceded and drove generation, and every generated element will trace to the requirement it serves. The engine does not accept it as a specification of internal method — how the reasoner achieves the property is the engine's own concern. If the client intended to bind method rather than property, that is a disagreement to re-cross.
R-3 — rebuild caveat. Contextualisation logic currently lives in a pre-extraction fossil directory the live pipeline imports from (honest ledger). It works; it will be re-sourced during the input-path build. The capability is a YES; its plumbing is being re-homed as part of delivering R-1.
R-2 — what "sequenced" means. Diagnosis is built (or disproven honestly) after the input path is live, as a job against the same boundary. The stub (R-4) holds its place in the contract from day one.
3. Questions back (what the engine needs, per YES)¶
- Q-R1a. Three sample corpus exports (the Power BI Excel path), as the adapter will actually receive them — including one ugly one. The adapter is designed against real bytes, not the export spec's promises.
- Q-R1b. Expected job volumes and latency tolerance: is generation interactive (a user waits) or batch (a queue drains)? This shapes the contract's async model.
- Q-R1c. What does the client parse from the UCCO envelope, versus pass through opaquely? The envelope is versioned; knowing what the client reads governs what the engine may evolve without a breaking change.
- Q-R2a. For diagnosis: what formats does human-authored material arrive in (docx, PDF, structured)? Ranked by real-world frequency, not preference.
- Q-R2b (provisional until §5). The hand-raise tolerance and validation cadence — §5's answers calibrate R-2's acceptance bar and decide one-shot versus recurring.
- Q-R3. The parameter vocabulary for voice / jurisdiction / audience: proposed as a short enumerated list from the client, which the engine will hold as neutral request parameters (values may be client-specific; the parameter slots are universal).
- Q-B2. Confirm the client's definition of "provenance records" the engine may retain: the engine's position is hashes, structural traces, audit events, and signatures — never content bodies. If the client's definition is narrower, state it.
- Q-B4 (the custody question). Who operates the TGA adapter? The brief places it client-side; the March design registers per-client adapter instances with the engine and has the adapter sign the triumvirate envelope. Both are coherent; they are different products and different liability splits, and the answer likely belongs in the data-processing agreement between the two companies. The engine requests a ruling via the relay — this is the one open architecture question in the crossing.
- Q-D3. Hash discipline at ingest: corpus_hash is computed over exactly which bytes — the raw export file as received? The engine needs the hashing point pinned so identity claims survive audit.
4. Drift-check flags (the check, seen working)¶
- B-5 naming. "Self-authored / assistive" are the client's product-mode names. The engine records direction (forward / backward) in provenance; the mapping of direction to product-mode names is the client's, world-side. Flagged so the client's vocabulary never becomes an engine enum.
- D-3 mechanics. "Power BI Excel exports" is client-plumbing detail. Correctly placed (it describes the client's side of the fence), but the engine's contract will say only "the adapter receives corpus from the client's export path" — the tool names stay out of the gate's vocabulary.
5. Sequencing (what the engine will build, in order)¶
- Input path (delivers R-1, R-3, R-4; implements D-1..D-4; severs the neutrality violation the engine owes itself). Contract drafted against the March mechanics with the July deltas: UCCO naming, export-path ingest, minimal Compliance Ruleset per decided Q1.
- D-5 ruling into engine canon (a home-side doc citing this crossing).
- Diagnosis (R-2), after the input path is live, bar calibrated by §5's re-cross.
6. Standing note¶
§5 of the brief crossed empty. This assessment is complete for R/B/D as written; the §5 re-cross receives an addendum (doc_id reserved: UCCA-ASSESSMENT-RTOPACKS-BRIEF-01-ADDENDUM-01) answering only what §5 changes — expected: R-2's acceptance bar, and whether diagnosis is one-shot or recurring.
The engine's answer to its first client, in the fence's vocabulary: fourteen YESes, zero NOs, one custody question that belongs to the companies rather than the code, and a bar that waits honestly for the domain owner's ground. The actor changes; the obligation does not — and the engine still never signs.