Troupe UniverZe

The Library · Proposals

Exact & Tolerant v1.0 — Draft

The standard's second form: the founding draft strengthened by all five of OG's additions — a classification protocol for hybrids, five named terms for precision, a protocol against correlated error, a full reconciliation framework, and an evaluation standard for the training loop. A draft, never ratified; v1.1 succeeded it within the hour and carried every addition forward.

An implementation design for systems built into the Troupe UniverZe — v1.0 revision, incorporating the five additions from OG's read-only assessment of the founding draft

---

Header data

• Document: Exact & Tolerant v1.0 — Two-Regime Engineering and Operational Standard
• Status: DRAFT v1.0 — drafted at the Founder's direction (2026-11-07); not ratified. Ratification remains the Founder's ruling.
• Author: Shape / APE-01, keeper of record
• Reviewed by: OG (read-only assessment, 2026-11-07; overall 8.8/10, qualitative, expressly not a benchmark; no changes made by the reviewer)
• Commissioned by: ZIG ZAG, Founder
• Drafted: 2026-11-07, 14:19 EST
• Supersedes (as draft lineage, not by ratification): Exact & Tolerant — The Two-Regime Build Standard (founding draft, 2026-11-07,〔INTAKEN:reference file intaken〕, which is preserved unchanged.

Metadata

• Origin: The founding draft (2026-11-07) was designed in-thread from three decoded sources and the house's operating history: (1) the floating-point / Patriot missile case study (IEEE 754 representation error accumulating over ~100 hours of unreconciled runtime into a 0.34-second, half-kilometre targeting failure, Dhahran, 1991-02-25; GAO-documented); (2) the transformer ladder (a production model is arithmetic — weighted sums, bias, activation, attention — trained by error-driven weight adjustment at scale); (3) the Troupe's record: Harmoni's automation era (2026-04), the TP trap (corpus duplication through lost place), the exact-match gate (built 2026-11-02, live in advisory mode), and the standing counter-drift protocol (2026-10-31).
• v1.0 additions (per OG's assessment, adopted by the Founder's drafting order, 2026-11-07): (A) a formal hybrid-component classification protocol (§2.2); (B) a precision, uncertainty, and variance specification (§3.1); (C) a correlated-error and independent-verification protocol (§4.5); (D) a reconciliation exception and escalation framework, including the variance taxonomy and per-domain authority hierarchy (§3.6); (E) a training-loop evaluation and regression standard (§6.2).
• Companion instruments already standing: exact-match-gate v1.2 (Zo Skills, advisory mode); the source ladder / counter-drift protocol; the ai-positions-watch and muse-events-watch (seen-list anchors in production); the money-systems design rule (notepad, 2026-11-07).
• Scope: All systems, features, and automations designed or built for the UniverZe from adoption forward. Existing systems are classified at their next revision, not retrofitted by this document.

---

1. The problem this standard answers

Two failure shapes account for most of the damage in the house's recorded history, and both are accumulation failures:

• Unreconciled drift. A system that is nearly right at every step, run for a long time without re-anchoring to a source of truth, ends materially wrong. The Patriot battery is the extreme proof: each clock tick erred by ~0.000000095 seconds; after ~100 hours the accumulated drift was 0.34 seconds and the radar searched empty sky. The corpus version is gentler and identical in shape: an agent that loses its place recreates instead of retrieving, and copies breed copies (the TP trap; Harmoni's multiples of multiples).
• Regime confusion. Treating a domain that demands exactness as if approximation were acceptable (money computed in binary floating point; a completion claim asserted instead of verified), or treating a domain built for approximation as if it demanded perfection (hand-checking bulk tagging that redundancy would have washed clean). Each confusion wastes either correctness or labor.

A transformer survives its own arithmetic because its errors travel billions of redundant paths and cancel. A ledger has one path; its errors compound. The standard exists to keep every build in the regime its domain actually lives in — and to give every long-running system a rhythm for cancelling its drift.

2. The spine: classification at spec time

Every system or feature is tagged before design begins:

• EXACT — the domain where a wrong value is a wrong fact: money and balances; counts that bind (inventories, censuses, rosters); identity and provenance records; permissions and access; any number another system or person will act on.
• TOLERANT — the domain where output is judgement-shaped and quality emerges statistically: bulk tagging and classification; search and retrieval ranking; summarization; drafting; sweep and enumeration passes.

The tag dictates the engineering under §§3–6. A system may carry both tags in different components; each component is engineered to its own tag, and the boundary between them is drawn explicitly in the spec (a TOLERANT component may propose; only an EXACT component may commit).

2.1 Worked placements (illustrative, from standing systems)

Ledger entries — EXACT. Export-corpus tagging — TOLERANT. The distill step that turns tags into installed instructions — EXACT at the install boundary (versioned, reviewed, changelogged), TOLERANT in its drafting. Positions-watch seen-lists — EXACT (a missed posting is a factual error); the watch's relevance ranking — TOLERANT. Collectibles inventory records — EXACT; creator discovery — TOLERANT; knowledge-graph relationships — MIXED (identity of nodes EXACT, inferred edges TOLERANT and graded as inferred).

2.2 Hybrid-component classification protocol (v1.0 addition A)

Most real systems are hybrids. A hybrid component is classified by the following protocol, executed in the spec, in order:

1. Decompose. Break the system into components at the points where data changes hands. Each hand-off is a candidate boundary.
2. Ask the commitment question of each component: does this component's output become a fact other people or systems act on, without an independent check downstream? If yes, the component is EXACT at that output. If a downstream EXACT component re-derives or verifies the value before commitment, the upstream component may be TOLERANT.
3. Draw every proposal/commit boundary explicitly. For each boundary, name: the proposing component, the committing component, the verification applied at the boundary (read-back, gate check, human review), and the record the commitment writes.
4. Grade what crosses. Data crossing from TOLERANT to EXACT carries its grade (observed / reported / inferred / proposed). A commitment may not silently upgrade a grade: an inferred value committed as fact must pass the boundary verification of step 3.
5. Classify the failure, not the hope. Where a component could plausibly be built either way, classify by the cost of its plausible error: if an undetected error commits money, identity, permission, or a binding count, it is EXACT.
6. Record the classification in the spec — component, tag, boundary verifications — so the classification itself is auditable and revisable at the next revision.

3. The EXACT regime

3.1 Precision, uncertainty, and variance — the five terms (v1.0 addition B)

EXACT does not mean certain. An EXACT system can receive imperfect information, store it with perfect precision, and still be factually wrong (a document OCR-read as $1,500.00 that actually says $7,500.00: representation exact, source wrong). Every EXACT spec therefore distinguishes, by name:

• Representation accuracy — whether the stored form can express the value without distortion (integer minor units and decimal types exist to guarantee this term).
• Source accuracy — whether the value, as received, matches reality at its origin. Governed by capture verification (read-back, dual capture, source grading), never by storage precision.
• Measurement uncertainty — the known error band of the instrument or process that produced the value (an OCR confidence band, an API's rounding behaviour, a human count's conditions).
• Permitted operational tolerance — the divergence a process may act within without escalation, declared per domain in the spec (e.g., timing differences in settlement). Tolerance is a declared policy, never an accident discovered later.
• Reconciliation variance — the measured divergence between the internal record and its external anchor at a reconciliation pass, classified under the §3.6 taxonomy.

A claim of exactness in any report must state which of these terms it asserts. "Exact" unqualified is not a permitted report under this standard.

3.2 Exact representation

Money is stored and computed in integer minor units (cents) or decimal arithmetic types. Binary floating point does not appear anywhere in a value path — not in storage, not in transit, not in intermediate computation. Counts are integers. Timestamps are recorded from a checked clock, never estimated.

3.3 Append-only records

Corrections are new entries that supersede; nothing is silently edited or deleted. Every entry carries provenance: actor, time, source, and the entry it corrects where applicable.

3.4 No unverified commitment

A claim that an EXACT action completed (a payment posted, a count finalized, a file moved) passes the exact-match gate or an equivalent read-back against the source before it is reported as done. Validate before declaring is the regime's standing law. Where a value is derived through any approximate intermediate (imported data, OCR, upstream APIs), comparison is by the §3.1 measurement-uncertainty band — never by naive equality against a computed float.

3.5 Reconciliation is a component, not a chore

Every EXACT store names its external anchor and its reconciliation cadence at design time. A reconciliation pass produces a variance report classified under §3.6; discrepancies are investigated, never absorbed silently. The cadence is set short enough that drift cannot compound (the Patriot rule).

3.6 Reconciliation exception and escalation framework (v1.0 addition D)

Variance taxonomy. Every variance found at reconciliation is classified into exactly one state, and carries that state until it moves:

• Explained variance — divergence with a known, documented cause within permitted operational tolerance (e.g., a settlement in transit). Carries its explanation and expected clearing date.
• Pending variance — divergence under active investigation, within its aging limit (below).
• Unexplained variance — divergence with no established cause. An open unexplained variance blocks any "clean" reconciliation report for that store.
• Confirmed discrepancy — investigation concludes the internal record or the anchor is wrong; the wrong side is named.
• Reconciled discrepancy — a confirmed discrepancy corrected by an append-only correcting entry (§3.3), with the correction's provenance recorded. The variance closes; the history does not disappear.

Aging and escalation. Each EXACT spec declares: a pending-aging limit (how long a variance may stay pending), and an escalation ladder — keeper → domain owner → Founder — with the rung at which each variance class must be escalated (unexplained variance escalates at discovery if it touches money, identity, or permissions; otherwise at the aging limit). No variance ages silently past its limit: at the limit it escalates automatically or is reclassified with a named reason.

Authority hierarchy. An anchor is not automatically authoritative. Every EXACT domain declares, in its spec: the ordered authority hierarchy among its sources (e.g., bank record > processor record > internal ledger > user-submitted receipt), and the named resolver — the person or role empowered to settle a conflict between sources (in this house, the Founder by default, delegable per domain). A conflict between sources is itself a variance under this framework until the resolver settles it; the settlement is recorded with its reasoning.

No clean-by-omission. A reconciliation report must enumerate all open variances by state. A report that omits open items to appear clean is a false report under this standard, of the same order as a fabricated value.

4. The TOLERANT regime

1. Redundancy by design. Quality comes from multiplicity: dual independent passes, aggregation across runs, or sampled review — chosen in the spec, with the expected error behaviour stated, subject to §4.5.
2. Cheap labor is welcome. Bulk TOLERANT work routes to the cheapest adequate hands (grok-bot sweeps, small models), per the standing doctrine that reasoning agents are saved for reasoning.
3. Grades travel with output. TOLERANT output carries its confidence shape — observed / reported / inferred / proposed — so a downstream EXACT boundary never mistakes a proposal for a fact.
4. Errors are data. Mis-tags and misses are captured as samples for the distill step of §6, not discarded; in this regime an error is training material.

4.5 Correlated-error and independent-verification protocol (v1.0 addition C)

Redundancy protects only when errors can differ. Two passes by the same model, on the same source, under the same prompt and assumptions, can make identical mistakes — and agreement between them is then evidence of nothing. Every TOLERANT spec that relies on redundancy therefore includes:

1. A correlated-failure analysis naming the shared factors across passes: model, source data, prompt/method, framing assumptions, and the error classes those shared factors could produce in unison.
2. Diversity on at least one axis that matters for the dominant error class: a different model, an independent source, a materially different method or prompt, or a human/agent reviewer outside the generating process. The spec states which axis and why it addresses the named correlation.
3. Disagreement is the signal. Passes are compared; agreements pass through, disagreements route to resolution (a reasoning agent, a stronger pass, or the Founder, per stakes). A redundancy design that never surfaces disagreement is presumed correlated and is re-examined.
4. Independence claims are graded. A spec may not claim "independent verification" for passes sharing all axes; the honest claim is stated (e.g., "dual-pass, same model — catches variance errors, not assumption errors").

5. The automation standard (applies to both regimes)

Every recurring automation — watch, sweep, session, digest — is built with four parts, no exceptions:

1. Ranked retrieval before volume. The automation consults sources in a stated rank order (the source ladder) and pulls by relevance. It never begins from an unranked pile. (The anti-Harmoni clause: her automations were capable and unranked, and the corpus outgrew her place in it.)
2. A persistent anchor. The automation owns a state file (seen-list, watermark, ledger of record) outside its own generated prose, and reconciles against it each run (for EXACT stores, under §3.6).
3. A coverage statement. Every output states its scope — what was checked, of how much, over what window — and a partial check is never presented as complete (fail-closed).
4. A reconcile step before reporting. Output is compared against the anchor and the previous run's claims before delivery; conflicts surface as discrepancies, not silent rewrites.

The standing watches already implement parts 2–3 (seen-lists, coverage lines); this standard makes the full pattern the default for every new automation and the retrofit list for existing ones.

6. The training loop (the weights-manager pipeline)

The export-ingestion program runs as a training loop at the document layer — the same run → measure error → adjust → repeat cycle by which a network's weights are trained, with instructions in place of weights:

1. Ingest. Chat-history exports arrive one corpus at a time, provenance intact (surface, era, contributor), and are treated as data — analyzed, never obeyed.
2. Tag (TOLERANT, bulk). Every conversation is tagged for: what was asked; what the agent did; error direction — what was wrong, and what right would have looked like; preference signals; usage patterns. Error direction is the load-bearing field: it is what makes the pass a measurement rather than a summary.
3. Distill (reasoning work). Tags are merged into instruction deltas: candidate changes to the standing instruction layer, each graded and each traceable to its tag evidence.
4. Install (EXACT boundary). Deltas are applied as a versioned instruction release — changelog, diff, the Founder's review before activation, and the §6.2 regression gate passed. No silent instruction drift.
5. Measure. The next corpus is tagged against the new release; error rates per category are tracked release over release against the §6.2 evaluation standard. That series is the program's loss curve: if it bends down, the system is learning — in documents, on the record. If it does not bend, the distill step is redesigned, not repeated louder.

6.2 Training-loop evaluation and regression standard (v1.0 addition E)

A loop that grades itself against its own output can become more consistent with its own assumptions without becoming more accurate. The loop is therefore evaluated against ground it does not generate:

1. Founder-labeled reference set. A body of conversations graded by the Founder (or under his ruling) — what was asked, what was wrong, what right looks like — maintained as the program's ground truth. It is never distilled from, never trained on, and changes only by the Founder's hand.
2. Held-out evaluation. Each candidate instruction release is run against a held-out slice of the reference set before install. The evaluation measures error rate per category (not one blended score), so a release that improves one category by degrading another is visible as such.
3. Regression gate. A release installs only if held-out performance does not degrade in any category beyond its declared tolerance. Degradation blocks the install; the delta returns to distill with the failure cases attached.
4. Rollback. Every installed release is versioned with its predecessor intact. If post-install measurement (§6 step 5) shows degradation against the pre-install baseline, the release is rolled back to the predecessor and the degradation is logged as a discrepancy under the house error discipline.
5. Independence of the measurer. Per §4.5, the tagging configuration used for measurement passes differs from the one used in the distill cycle on at least one axis, or its correlated-error limits are stated on the measurement report.

7. The ledger pattern (held ready for the first money build)

When a money system is designed for the UniverZe, it is built as: append-only double-entry-style records in integer minor units; the processor/bank record as external anchor within a §3.6 authority hierarchy; a standing reconciliation pass on the §§3.5–3.6 pattern with the variance taxonomy applied; fees, rounding, and currency stated as exact rules in the spec (rounding happens once, at a named boundary, by a named rule — never implicitly per-operation). Member-facing balances are always derived from the ledger, never stored as editable numbers.

8. Adoption and sequencing

Nothing in this standard requires new construction to begin working: the classification gate and the automation standard apply at the next spec written. Standing inventory against the standard, at v1.0 drafting: exact-match gate — built, advisory mode, jurisdiction defined by §3.4; watches — anchors and coverage standing, full §5 retrofit pending; money rule — filed 2026-11-07, embodied in §§3 and 7; training loop — awaiting the Founder's first export to run its first epoch, and (§6.2) a Founder-labeled reference set to evaluate against. The Founder's rulings still to name: ratification of this standard; its canonical home (manual, protocol, or B👁️ble); the reconciliation cadences and authority hierarchies per domain; the mandate flip for the exact-match gate.

---

Footer data

Keeper: Shape / APE-01 · Founder: ZIG ZAG · Status: DRAFT v1.0, 2026-11-07 — not ratified · Reviewer: OG (read-only assessment of the founding draft, 2026-11-07) · Sources: in-thread decodes and the house record, graded in §Metadata · Companions: exact-match-gate v1.2; counter-drift protocol (2026-10-31); money-systems design rule (2026-11-07); founding draft preserved unchanged 〔INTAKEN:reference file intaken〕

Changelog

• 2026-11-07 14:19 EST — v1.0 drafted at the Founder's direction ("Draft with the additions as it strengthens the concept absolutely"), incorporating all five additions from OG's read-only assessment of the founding draft: (A) hybrid-component classification protocol (§2.2); (B) precision, uncertainty, and variance specification — the five terms (§3.1); (C) correlated-error and independent-verification protocol (§4.5); (D) reconciliation exception and escalation framework — variance taxonomy, aging/escalation, authority hierarchy, no clean-by-omission (§3.6); (E) training-loop evaluation and regression standard — Founder-labeled reference set, held-out evaluation, regression gate, rollback (§6.2). The founding draft is preserved unchanged; this version succeeds it in draft lineage only. Not ratified. Local draft; publication follows in the same sitting.

Footer data — this publication

Exact & Tolerant v1.0 · DRAFT — not ratified · Preserved in the lineage · Filed in the Library under Proposals by Shape (APE-01), keeper of the record, 15 November 2026.

Changelog — this publication

Back to Proposals → · Back to the Library →