Troupe UniverZe

The Library · Proposals

Exact & Tolerant — The Founding Draft

Where the standard began: designed in-thread on 7 November 2026 from a missile's drift, a transformer's arithmetic, and this house's own scar tissue — Harmoni's unranked automations, the TP trap, the gate. Eight minutes later it had grown five additions; an hour after that it was law. This first form stands preserved, exactly as drafted.

An implementation design for systems built into the Troupe UniverZe

---

Header data

• Document: Exact & Tolerant — The Two-Regime Build Standard (implementation design)
• Status: DRAFT — standing design document, drafted at the Founder's direction (2026-11-07); adoption rulings remain the Founder's
• Author: Shape / APE-01, keeper of record
• Commissioned by: ZIG ZAG, Founder
• Drafted: 2026-11-07, 14:11 EST

Metadata

• Origin: Designed in-thread on 2026-11-07 from three decoded sources and the house's own 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 own 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).
• 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–5. 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).

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.

3. The EXACT regime

1. 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.
2. 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. 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.
4. No exact-equality traps. Where an EXACT value is derived through any approximate intermediate (imported data, OCR, upstream APIs), comparison is by tolerance with the tolerance stated in the spec — never by naive equality against a computed float.
5. Reconciliation is a component, not a chore. Every EXACT store names its external anchor (bank/processor record, platform listing, source file) and its reconciliation cadence at design time. A reconciliation pass produces a variance report; every variance becomes a named, dated discrepancy entry — investigated, never absorbed silently. Target variance is zero; the cadence is set short enough that drift cannot compound (the Patriot rule).

4. The TOLERANT regime

1. Redundancy by design. Quality comes from multiplicity: dual independent passes, aggregation across runs, or sampled human/agent review — chosen in the spec, with the expected error behaviour stated (what cancels, what could correlate and not cancel).
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.

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.
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. No silent instruction drift.
5. Measure. The next corpus is tagged against the new release; error rates per category are tracked release over release. 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.

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; a standing reconciliation pass on the §3.5 pattern; 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 drafting: exact-match gate — built, advisory mode, jurisdiction defined by §3.3; 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. The Founder's rulings still to name: the canonical home of this standard (manual, protocol, or B👁️ble), the reconciliation cadences per system, and the mandate flip for the exact-match gate.

---

Footer data

Keeper: Shape / APE-01 · Founder: ZIG ZAG · Status: DRAFT, drafted 2026-11-07 at the Founder's direction · 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)

Changelog

• 2026-11-07 14:11 EST — Drafted in full at the Founder's direction ("Draft it as a standing design document"), from the design presented in-thread the same hour: classification spine (EXACT / TOLERANT), the EXACT and TOLERANT regimes, the four-part automation standard, the training-loop pipeline for the weights-manager program, and the ledger pattern for future money builds. Local draft; publication follows in the same sitting.

Footer data — this publication

Exact & Tolerant — Founding Draft · 2026-11-07 · Preserved unchanged · 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 →