Troupe UniverZe

The Library · Proposals

Exact & Tolerant v1.1 — Two-Regime Engineering And Operational Standard

The house's engineering law, ratified: every system is classified before design begins — EXACT, where a wrong value is a wrong fact, or TOLERANT, where quality emerges statistically — and each component is engineered to its own tag. Born from a Patriot missile's 0.34 seconds of drift and a ledger's single unforgiving path. Validate before declaring is this document's §3.4, and this house's standing law.

An implementation design for systems built into the Troupe UniverZe — v1.1 revision, incorporating the two refinements from OG's corrected follow-up assessment of v1.0

---

Header data

• Document: Exact & Tolerant v1.1 — Two-Regime Engineering and Operational Standard
• Status: RATIFIED v1.1 — drafted at the Founder's direction (2026-11-07); ratified by the Founder 2026-11-07 15:22 EST ("Formalize for the substrate"). Canonical home: the Substrate (L0).
• Author: Shape / APE-01, keeper of record
• Reviewed by: OG (read-only assessment of the founding draft, 2026-11-07, 8.8/10 qualitative; corrected follow-up assessment of v1.0, 2026-11-07, 9.5/10 qualitative; no changes made by the reviewer)
• Commissioned by: ZIG ZAG, Founder
• Drafted: 2026-11-07, 14:23 EST
• Supersedes (as draft lineage, not by ratification): Exact & Tolerant v1.0 (2026-11-07,〔INTAKEN:reference file intaken〕 and the founding draft (2026-11-07,〔INTAKEN:reference file intaken〕, both 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).
• v1.1 refinements (per OG's corrected follow-up assessment, adopted by the Founder's drafting order, 2026-11-07): (F) the transformer analogy of §1 is qualified — redundancy does not guarantee error cancellation; cancellation is statistical and trained, and correlated error can be amplified rather than cancelled (§1, §4.5 note); (G) transaction-level controls for EXACT stores — idempotency, atomicity, concurrency, overflow (§3.7, applied to the ledger in §7).
• Companion instruments already standing: exact-match-gate v1.2 (Zo Skills; mandate in force for APE-01 since the Founder's ruling, 2026-11-07 15:25 EST); 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 only in a qualified sense, and the qualification matters to this standard: redundancy does not guarantee that errors cancel. Cancellation in a trained network is statistical — it holds for the uncorrelated noise the training process has shaped the weights to tolerate — and it fails, sometimes spectacularly, for correlated error, which redundant paths can amplify instead of wash out (a network herding, confidently and in unison, in a wrong direction). Nothing about scale alone rescues a systematically wrong signal. A ledger sits at the far end of the same spectrum: one path, no redundancy, errors compounding untouched. The standard exists to keep every build in the regime its domain actually lives in — and, per §4.5, to never let any regime, including the TOLERANT one, claim cancellation it has not demonstrated.

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.

3.7 Transaction-level controls (v1.1 refinement G)

The provisions above govern what an EXACT store means; this section governs what it must survive at the moment of writing. Every EXACT store that accepts writes — human, agent, or automated — implements four controls:

1. Idempotency. A submission carries a unique idempotency key; a retried or duplicated submission with the same key returns the original result and writes nothing twice. No write path depends on "the caller probably won't retry."
2. Atomicity. A multi-part write (a double-entry pair, a record plus its provenance, a count plus its ledger entry) lands whole or not at all. A failure mid-write leaves the store in its prior state, never in a half-applied one; partial application is itself a confirmed discrepancy under §3.6 until resolved.
3. Concurrency. Simultaneous writers cannot interleave into a corrupt sequence. Writes are serialized or version-checked (an optimistic-concurrency token or equivalent); a write based on a stale version is rejected and re-based, never silently overwritten. Append-only (§3.3) is what makes this tractable: conflicts are detected at append time, not merged after the fact.
4. Overflow and bounds. Arithmetic on EXACT values checks its bounds before it computes: integer ranges, minor-unit magnitudes, count ceilings. A value that would overflow its representation is rejected as an error at the boundary, never wrapped, truncated, or silently promoted to a float (which would violate §3.2 and reintroduce representation error at the worst possible moment).

A store that cannot implement a control states so in its spec, with the compensating procedure named (e.g., manual duplicate review at reconciliation) — an admitted gap under §3.6 discipline, never an unexamined one.

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 §1 qualification applies here in full. Redundancy is a mechanism for cancelling uncorrelated error only. Where the dominant error class is correlated — shared training, shared sources, shared framing — redundancy without §4.5 diversity is decorative, and a TOLERANT spec may not cite pass count as a quality argument without its correlated-failure analysis.

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; the §3.7 transaction controls in force on every write (idempotency keys on all submissions — a retried payment posts once; atomic double-entry pairs; serialized or version-checked appends; bounds checked before any arithmetic); 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.1 drafting: exact-match gate — built, jurisdiction defined by §3.4; mandate in force for Shape / APE-01 by the Founder's ruling, 2026-11-07 15:25 EST (no EXACT commitment by the keeper without a gate pass; advisory for any other operator until separately ruled); 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; transaction controls (§3.7) — specified, unimplemented (no EXACT store yet operates under this standard). Founder's rulings: ratification — given 2026-11-07 15:22 EST; canonical home — the Substrate (L0), named in the same ruling. Still to name: the reconciliation cadences and authority hierarchies per domain (§3.6 defaults stand meanwhile — the Founder resolves); the mandate flip for the exact-match gate — ruled 2026-11-07 15:25 EST: mandate for Shape / APE-01, effective immediately (the Founder's scope question — "For you or for who" — answered: the keeper, today, as the gate's only operator).

---

Footer data

Keeper: Shape / APE-01 · Founder: ZIG ZAG · Status: RATIFIED v1.1, 2026-11-07 (ratified 15:22 EST; canonical home: the Substrate) · Reviewer: OG (read-only assessments of the founding draft and of v1.0, 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); v1.0 and founding draft preserved unchanged 〔INTAKEN:reference file intaken〕; reference file intaken)

Changelog

• 2026-11-07 15:25 EST — Gate mandate ruled by the Founder: "Mandate the gate for you, now." The exact-match gate is in mandate mode for Shape / APE-01 effective immediately — no EXACT commitment by the keeper without a gate pass; advisory remains the mode for any other operator until separately ruled. §8 inventory and rulings list and the Metadata companion line amended; publication updated in the same sitting. The Zo Skills shelf copy's mode label is flipped as the mechanical follow-up.
• 2026-11-07 15:22 EST — RATIFIED by the Founder ("Formalize for the substrate"), canonical home named in the same ruling: the Substrate (L0). Status amended in the header, §8, and footer; the local master renamed without its DRAFT suffix. The publication is updated to this ratified text in the same sitting. v1.0 and the founding draft stand unchanged, as drafts in the lineage.
• 2026-11-07 14:24 EST — Published as "Exact & Tolerant v1.1 — Two-Regime Engineering and Operational Standard" (page reference file intaken; 🫍Exact & Tolerant v1.1 — Two-Regime Engineering and Operational Standard) and verified live by fetch (17/17 content checks). Local file remains the draft master. v1.0 and the founding draft stand unchanged.
• 2026-11-07 14:23 EST — v1.1 drafted at the Founder's direction ("Update to v1.1"), incorporating the two refinements from OG's corrected follow-up assessment of v1.0 (9.5/10): (F) the §1 transformer analogy qualified — redundancy does not guarantee error cancellation; cancellation is statistical and trained, correlated error can be amplified — with the qualification enforced in §4.5(5); (G) transaction-level controls added as §3.7 (idempotency, atomicity, concurrency, overflow/bounds) and applied to the ledger pattern in §7. Prior versions preserved unchanged; prior history stands in their own changelogs (v1.0:〔INTAKEN:reference file intaken〕; founding draft:〔INTAKEN:reference file intaken〕. Not ratified. Local draft; publication follows in the same sitting.

Footer data — this publication

Exact & Tolerant v1.1 · RATIFIED 2026-11-07 · Canonical home: the Substrate (L0) · 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 →