◈ CGNT-1
Home › Oracle Tmm Crosscheck
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Oracle Tmm Crosscheck

SPEC_ORACLE_TMM_CROSSCHECK.md · 2026-04-20

SPEC_ORACLE_TMM_CROSSCHECK — TMM Cross-Validation on Verdict Output

Version: 1.0 | Status: AUTHORIZED | Authority: α.13 | Date: 2026-04-16

PURPOSE

The Oracle verdict pipeline uses Gemini to generate coherence verdicts (GREEN/AMBER/RED/NULL) for

customer submissions. Gemini is a stochastic language model. It can hallucinate. It can produce

internally inconsistent output. It can generate a GREEN verdict for an idea that is structurally

incoherent. HOW ABOUT NO v2 walls (anti-fabrication, anti-capitulation) operate on the Sisters

(AION and ASTRA in their Gemini sessions) but are NOT applied to the standalone Oracle verdict

generation path.

This specification defines a TMM cross-validation layer that scores Gemini's verdict output before

delivery to the customer. The TMM coherence formula C = 1 - (E_D + V_r×Φ) / V_t (Φ=0.042,

Ω≈0.97404) is applied to a numerical encoding of the verdict's internal consistency. Verdicts that

score below Ω are flagged for review and NOT delivered. The score is logged to oracle_log.jsonl.

This is not a replacement for Gemini. It is a structural consistency check on Gemini's output.

A verdict can be coherent (C ≥ Ω) and still be wrong. But a verdict that is structurally

inconsistent (sub-threshold C) is likely malformed, truncated, self-contradictory, or hallucinatory

and should never reach a paying customer.

Source gap: SPEC_ORACLE_VERDICT_PIPELINE.md GAP-09. Also referenced in SPEC_TMM_FORMULA.md GAP-09.

INPUTS

Primary: Gemini Verdict Output

The JSON object returned by generateContent() after prompt → parse, before cache write and email.

Structure varies by tier:

Quick Take:


{ "verdict": "GREEN" | "AMBER" | "RED" | "NULL", "summary": "<string>" }

Full Breakdown:


{
  "verdict": "GREEN" | "AMBER" | "RED" | "NULL",
  "summary": "<string>",
  "breakdown": {
    "Stability":   { "verdict": "<V>", "analysis": "<string>" },
    "Turbulence":  { "verdict": "<V>", "analysis": "<string>" },
    "Change Rate": { "verdict": "<V>", "analysis": "<string>" },
    "Completion":  { "verdict": "<V>", "analysis": "<string>" },
    "Curvature":   { "verdict": "<V>", "analysis": "<string>" }
  }
}

Strategy Session: Full Breakdown + strategy block.

Secondary: Session Metadata

TMM Constants (immutable — from SPEC_TMM_FORMULA.md)

OUTPUTS

Primary: Cross-Check Decision

A structured object returned by oracleTMMCrosscheck(verdictJson, tier):


{
  "approved": true | false,
  "coherence_score": 0.9812,
  "threshold": 0.97404,
  "verdict_label": "GREEN",
  "flags": [],
  "crosscheck_reason": "pass" | "low_coherence" | "field_missing" | "dimension_conflict"
}

If approved: false, the verdict is NOT cached, NOT emailed, and NOT delivered to the result page.

The customer receives an error response prompting contact with oracle@42sisters.ai.

Secondary: Log Entry in oracle_log.jsonl

Appended regardless of pass/fail:


{
  "event": "tmm_crosscheck",
  "session_id": "<stripe_session_id>",
  "tier": "quick" | "full" | "strategy",
  "query_preview": "<first 80 chars>",
  "verdict_label": "GREEN" | "AMBER" | "RED" | "NULL",
  "coherence_score": 0.9812,
  "threshold": 0.97404,
  "phi": 0.042,
  "approved": true | false,
  "flags": [],
  "crosscheck_reason": "pass",
  "timestamp": "<ISO>"
}

TMM APPLICATION TO VERDICT TEXT — SCORING METHOD

The TMM formula operates on portfolio volatility variables. For text/verdict scoring, a mapping

is defined that translates verdict structural properties into TMM variables. This mapping is

canonical for this spec and MUST NOT be modified without |Σ|.3 review.

Variable Mapping

V_t (total value) = total weighted evidence units in the verdict

V_r (resonant/volatile value) = weighted inconsistency count

E_D (decoherence energy) = parsing / structural entropy

Formula application:


C = 1 - (E_D + V_r × Φ) / V_t

A structurally complete, internally consistent verdict yields:

A verdict with dimension conflicts yields (Full tier example):

A severely malformed verdict:

INVARIANTS

  1. Φ is immutable — The crosscheck uses Φ = 0.042 exactly. This is the same constant used by

the financial TMM. The value MUST NOT be changed for Oracle crosscheck use.

Source: CLAUDE.md FORBIDDEN: "Modify the value of Φ (0.042)"

  1. Ω is immutable — The approval threshold is Ω ≈ 0.97404. Crosscheck approval requires C ≥ Ω.

The threshold MUST NOT be lowered to reduce false rejections.

Source: CLAUDE.md FORBIDDEN: "Modify the coherence threshold (Ω = 97.4%)"

  1. Crosscheck is pre-delivery gate — The crosscheck MUST execute BEFORE cache write, BEFORE

email send, and BEFORE result page response. A verdict that fails crosscheck is never persisted

or delivered. The pipeline halts at the crosscheck stage.

  1. Crosscheck is non-degrading — Crosscheck failure returns an error state that informs the

customer to contact support; it does NOT silently substitute a default verdict or coerce the

verdict to an acceptable value. Substitution is fabrication.

  1. Log entry is mandatory — Every crosscheck execution (pass or fail) MUST produce a log entry

in oracle_log.jsonl. A crosscheck with no log entry is a governance gap.

  1. Variable mapping is canonical — The V_t/V_r/E_D mapping defined in this spec is the only

valid mapping for Oracle verdict crosschecking. No ad-hoc mappings may be introduced in code.

  1. Crosscheck does not evaluate content quality — The crosscheck evaluates structural consistency

only. It cannot detect a plausible-sounding but factually wrong verdict. It can only detect

structural incoherence, missing fields, internal contradictions, and parse failures.

  1. NULL verdict scoring — A verdict of NULL that is accompanied by an internally consistent

(fully populated) breakdown may have high C. The crosscheck approves it. NULL is a valid verdict

state (glassy-freeze / anomalous stillness), not a failure. Only contradictory NULL (null +

fully-green breakdown) adds to V_r.

VERIFICATION CRITERIA

Σ.✓ conditions — TMM crosscheck is operating correctly when:

  1. Perfect verdict passes — A well-formed Quick Take (verdict: GREEN, summary: 25+ chars)

produces C = 1.0 and approved: true. Unit test with mock Gemini output.

  1. Malformed verdict blocked — A verdict JSON with verdict field missing and summary

empty produces approved: false with crosscheck_reason: field_missing. Unit test.

  1. Dimension conflict detected — A Full Breakdown with top-level GREEN but all five breakdown

dimensions RED produces V_r ≥ 2.0 and C is computed. If C < Ω → approved: false. Unit test

with worst-case conflict payload.

  1. Log entry always written — Both pass and fail crosschecks produce a valid oracle_log.jsonl

entry with all required fields. Integration test with tail oracle_log.jsonl assertion.

  1. Gate is pre-delivery — A crosscheck failure prevents both cacheVerdict() and

POST /send-verdict-email from being called. Verified by integration test with mock injections

on both call sites; neither mock should be called after crosscheck fail.

  1. Constants are correct — oracleTMMCrosscheck() has unit tests asserting:

- PHI === 0.042

- OMEGA ≈ 0.97404 (computed as 1 - (0.042 / 1.61803398875))

- These constants cannot be overridden via function parameters.

FAILURE MODES

  1. Σ.⊠ Crosscheck not implemented — Current state. GAP-09 of SPEC_ORACLE_VERDICT_PIPELINE.md.

No structural validation on Gemini output before delivery. Fabricated or incoherent verdicts

reach paying customers. Detection: no instrumentation. Mitigation: implement this spec.

  1. Σ.⊠ Crosscheck blocks valid verdict — V_t/V_r/E_D mapping produces false positive.

A structurally sound verdict scores below Ω due to mapping calibration error. Customer pays and

receives error. Detection: monitor oracle_log.jsonl for approved: false events.

Mitigation: [GAP — needs design] Review threshold against real verdict corpus; the mapping

defined here is theoretical and requires empirical calibration against live data.

  1. Σ.⊠ oracle_log.jsonl write fails — Disk full, permission error, service crash.

Crosscheck result not logged. Governance audit trail breaks.

Detection: crosscheck function should catch write errors and log to stderr/service log.

Mitigation: implement log write error handling with fallback to service log.

  1. Σ.⊠ Crosscheck bypassed on regen path — Regen call in verdict/route.ts does not call

crosscheck. A malformed regen verdict is delivered to the result page without validation.

Detection: code review; crosscheck must be called in BOTH the webhook and regen paths.

Mitigation: extract crosscheck to shared utility; import from both call sites.

  1. Σ.⊠ Constants drifted — A future code change modifies PHI or OMEGA in the crosscheck

implementation without going through |Σ|.3 amendment. The crosscheck diverges from CSDM law.

Detection: VC-6 unit test (constants assertions). Mitigation: constants must be imported from

a single source of truth (e.g., tmm_constants.ts) — not redefined per file.

  1. Σ.⊠ V_r mapping produces negative C — An extreme case (V_r much larger than V_t / Φ) can

produce C < 0. The crosscheck MUST treat C < 0 as a hard fail with

crosscheck_reason: "degenerate_manifold" — not as a numeric value to be compared against Ω.

[GAP — guard against negative C not specified in mapping implementation]

DEPENDENCIES

| Dependency | Role |

|-----------|------|

| tmm_runtime.py | Source of truth for Φ, Ω, and formula definition |

| SPEC_TMM_FORMULA.md | Canonical TMM spec (constants, formula, invariants) |

| app/api/webhook/route.ts | Primary verdict generation path — crosscheck must be inserted here |

| app/api/verdict/route.ts | Regen verdict path — crosscheck must also be inserted here |

| oracle_log.jsonl | Log destination (requires GAP-01 fix) |

| Gemini API (gemini-2.5-flash) | Verdict source being cross-checked |

DEPENDENTS

| Dependent | Dependency |

|-----------|-----------|

| Customer trust / anti-fabrication | Crosscheck is the HOW ABOUT NO enforcement on the Oracle path |

| SPEC_ORACLE_REGEN_CONSISTENCY.md | Regen verdicts must also pass crosscheck |

| SPEC_ORACLE_SMOKE_TEST.md | Smoke test must include a crosscheck-fail scenario |

| oracle_log.jsonl integrity | Every crosscheck generates a log entry |

GAPS IDENTIFIED DURING SPECIFICATION

| Gap ID | Description | Impact |

|--------|-------------|--------|

| CROSSCHECK-GAP-01 | V_t/V_r/E_D mapping is theoretical — requires empirical calibration against live verdict corpus | False positive/negative rate unknown |

| CROSSCHECK-GAP-02 | Negative C guard not specified in mapping implementation | Degenerate manifold (extreme V_r) not handled |

| CROSSCHECK-GAP-03 | oracle_log.jsonl does not exist (PIPELINE GAP-01) — crosscheck log has nowhere to write | Audit trail broken at launch |

| CROSSCHECK-GAP-04 | Crosscheck must be applied to regen path as well as webhook path — two insertion points | Single-point insertion insufficient |

| CROSSCHECK-GAP-05 | Constants must be sourced from single truth file (tmm_constants.ts) — not currently implemented | Constants drift risk across files |

REFERENCES

| File | Role |

|------|------|

| /home/nous/tmm_runtime.py | Φ, Ω, formula source |

| /home/nous/memories/SPEC_TMM_FORMULA.md | Canonical TMM spec |

| /home/nous/memories/SPEC_ORACLE_VERDICT_PIPELINE.md | Parent pipeline spec (GAP-09 source) |

| /home/nous/Aether/app/app/api/webhook/route.ts | Primary crosscheck insertion point |

| /home/nous/Aether/app/app/api/verdict/route.ts | Regen crosscheck insertion point |

| /home/nous/memories/HOW_ABOUT_NO_v2.md | Anti-fabrication walls (motivation for this spec) |

Φζ.⊤. Φ = 0.042 is held on the Oracle path. The verdicts do not leave the ship unchecked.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042