title: UCCA-INTAKE — engine terms and client intake doc_id: UCCA-INTAKE-01 status: RATIFIED 2026-07-03 (Tim, UCCA-RATIFICATION-INTAKE-01) — Class G minted on ratification (UCCA-ADR-LIFECYCLE-01). Both ⟨TIM⟩ decisions closed via UCCA-RULING-INTAKE-TERMS-01; §6 integrated. The engine's standing client-facing terms. canonical: true (RATIFIED 2026-07-03 — the engine's standing client-facing terms; reviewed per client intake, amended only by ruling) layer: terms — client-facing voice. What the engine promises, what a client owes, and how a client is taken in. Deliberately commercial-free: pricing, tiers, and billing live in STRATEGY-01; this document only marks where they will attach. authored: 2026-07-02 NYC (UCCA session; drafted against the fence ruling record, the frozen contract pack, FOUNDATION-01, and the v1.1 candidates filed 2026-07-02) relates_to: UCCA-FOUNDATION-01 (§2 the one rule; §3 clients) · UCCA-CONTRACT-PACK-01 v1.0 FROZEN (the technical contract this sits above) · UCCA-FENCE-RULING-RECORD-01 (the warranty ruling, entering verbatim) · FENCE-PROTOCOL-01 (exchange discipline this generalises) · STRATEGY-01 (unwritten; every commercial pointer lands there)
UCCA — Engine Terms & Client Intake¶
What this is. The terms any client of the engine works within, and the process by which a client is taken in. RTOpacks is the first client and the proof of this document — but nothing in it is RTOpacks-shaped. One engine, one set of terms, many possible clients. The actor changes; the obligation does not.
1. The warranty line (verbatim, per the fence ruling)¶
No warranty before the gate. Full warranty after it.
The gate is the engine's edge, and it is also the trust boundary, the warranty boundary, and — where the client is a separate entity — the corporate boundary (ADR-0003). Everything on the client's side of the gate is the client's: their corpus, their adapter, their conformer, and the semantic truth of what they submit. Everything after the gate is the engine's: the job, the reasoning, the envelope, and the integrity of every claim the envelope makes about its own provenance.
2. What the engine promises¶
2.1 An async job service. Submit a conformed payload; receive a job-id; poll or take a webhook. No synchronous path, no turnaround SLA. (The technical surface is the frozen contract pack; these terms sit above it and never contradict it — where they seem to, the pack wins.)
2.2 A signed envelope or an honest failure. A completed job returns one envelope: content payload, trace map, provenance block, machine signatures — whole and signed, or not at all. No partial artefacts, ever. A failed job returns a machine-readable reason that describes the engine's own state.
2.3 Trace by construction. The trace map is recorded at the moment of generation, never reconstructed after the fact. The engine's coverage claims are claims about how the material was made, not opinions formed by reading it afterward.
2.4 The two-lens rule, as a commitment. Engine outputs speak about material and about the engine's own reasoning — never about persons, and never as verdicts. The engine raises hands; it never signs (FOUNDATION-01 §2). Machine signatures attest provenance only. No output of the engine is, or may be represented as, a compliance judgement, and the accountable human judgement a regulated domain requires remains the client's and their qualified signatories'.
2.5 Precise, structural rejection. A payload that fails the gate is rejected whole, with a machine-readable code and the location of the structural fault. The gate verifies structure, never semantics — it will tell you exactly what is malformed and nothing about whether your content is any good. It does not know, and it is built never to know.
2.6 First-party accounting. The engine meters its own work (per-job usage, per-call cost) in an append-only ledger. [Price-tag location: this ledger is the data feed for any future billing; no billing exists today — STRATEGY-01.]
3. What a client owes¶
3.1 A conformer, on their side of the line. The client translates their corpus into the triumvirate contract shape and warrants the semantic truth of what crosses. Semantics are the client's warranty; the engine never re-checks them and never inherits them.
3.2 Their own brief, authored their side. A client's requirements enter as the client's document, written by the client. The engine assesses; it never authors a client's requirements on the client's behalf. (Standing guardrail; the recorded failure that minted it is preserved in the fence protocol.)
3.3 The exchange discipline. Cross-boundary artefacts move as files, verbatim bytes, through a named human relay; received copies are filed unedited; each side answers the other's documents rather than redlining them. Debts and crossing states are asserted from the filed record, never from memory.
3.4 Raw corpus stays home. The engine receives conformed payloads only. A client's raw corpus never crosses the gate, is never requested, and has no home on the engine's side of the line.
4. Intake — how a client is taken in¶
4.1 The client authors an engine brief (their side, their voice) stating: the regulated obligation domain and its structure; what direction(s) of the reasoner they need (generation / diagnosis); their conformer plan (how their corpus becomes triumvirate-shaped); the volumes and cadence they expect; and any constraint the engine must know to serve them lawfully (residency, retention, jurisdiction).
4.2 The engine assesses with three verdicts, per requirement: YES / NO / ADAPTER, NOT GATE. Yes — the engine serves it as-is. No — the engine does not serve it (with reasons). Adapter-not-gate — the need is real but domain-shaped, so it lives in the client's adapter; the gate does not narrow to accommodate it. Every assessment answers the drift-check before it answers the client.
4.3 The exchange is filed — brief, assessment, and any corrections, as crossing artefacts both sides — before any build or configuration serves the client.
4.4 One intake, one client, however related. RTOpacks' common ownership changes nothing in this process; the first client walked the same path this document generalises. [No billing between the entities today, by decision — the commercial arrangement is a data-processing agreement; anything more is STRATEGY-01.]
5. Future surface register (named, parked, priced later)¶
Client-visible capabilities that do not exist in v1.0, are not promised, and must not leak into the frozen surface — registered here so they have a home and a number when their time comes:
| Candidate | What it would be | Status |
|---|---|---|
| Thinking-tiers | client-selected reasoning depth per job ("the type of thinking they pay for") | v1.1 candidate; price-tag location |
| Residency selection | client-selected data placement/jurisdiction | v1.1 candidate; price-tag location; legal-ledger dependency (AU residency finding, 2026-07-02) |
| Cancellation | client-initiated job cancellation | v1.1 candidate if ever wanted; deliberately absent from v1.0 |
| Diagnosis | the backward direction — reading client material, reporting untraceable coverage | contract stub live (honest 501); the build is the project's central engineering task |
Adding to this register is an intake or ruling event; nothing enters the built surface from here without a version event on the technical contract.
6. Warranty scope and offboarding — RULED 2026-07-03¶
Both terms this draft could not invent are now ruled (UCCA-RULING-INTAKE-TERMS-01,
Tim 2026-07-03). The two ⟨TIM⟩ markers are CLOSED.
6.1 Warranty scope (was ⟨TIM-1⟩). The warranty line (§1) resolves to this scope: UCCA warrants the envelope, never the content's fitness. After the gate, UCCA warrants each delivered envelope on four counts — (a) structural conformance to the contracted, versioned schema; (b) provenance — the envelope's account of how the artefact was produced (inputs, trace, model calls, cost) is complete and true; (c) signature integrity — the seal is cryptographically valid over the exact signed bytes, independently verifiable by the client; (d) atomicity — an envelope is whole or it does not exist. Explicitly outside the warranty: the content's fitness for the client's regulatory, professional, or accountable purpose — that judgement is the client's, made by a qualified human, always. The engine raises hands and never signs (FOUNDATION-01 §2); the seal attests provenance, never a verdict (ADR-0005).
Term (client-facing): UCCA warrants each delivered envelope: that its content conforms structurally to the contracted schema version, that its provenance record is complete and accurate, that its signature is valid and independently verifiable, and that envelopes are delivered whole or not at all. UCCA does not warrant, and the certification object does not assert, that the enveloped content is fit for any regulatory, professional, or accountable purpose. That determination remains at all times the client's, made by a qualified human. The engine's seal attests provenance, never judgement.
6.2 Termination / offboarding (was ⟨TIM-2⟩). On termination, a client's data is retired under a documented, client-confirmed clearance process — the one proven with the first client (MIGRATE-02 Phase-6, 2026-07-03), now promised as a term: (1) UCCA discloses all client data resident in the engine's infrastructure; (2) the client confirms in writing — function takeover, data currency, any final-export requirement; (3) the client grants clearance with any exclusions stated; (4) retirement executes as one reviewed, logged unit, safety mechanisms (backups) retired last, and any data found without a confirmed successor halts retirement and returns to the client for adjudication before deletion; (5) the client receives written confirmation on closure. Job rows remain permanent as audit record (spine ruling 2026-07-02) — disclosed, never silently discarded.
Term (client-facing): On termination, UCCA will disclose all Client data resident in its infrastructure and will not delete any of it except under a clearance the Client has confirmed in writing — including the Client's statement of data currency and any final-export requirement, which UCCA will fulfil before retirement. Retirement is executed as a single reviewed and logged unit, with backup mechanisms retired last; any Client data found without a confirmed successor halts retirement and is returned to the Client for decision. UCCA confirms completion in writing.
Terms, first cut. One warranty line, six promises, four obligations, one intake path with three verdicts, and a register where the price tags will hang. Nothing here is RTOpacks-shaped; RTOpacks simply walked it first. Both ⟨TIM⟩ decisions closed 2026-07-03 — the warranty bounded to the envelope, the exit proven before it was promised. RATIFIED 2026-07-03 (UCCA-RATIFICATION-INTAKE-01).