Skip to content
Myles Bryning
2026-01-11cuecruxgovernancetrustsystems

Canonical Map

CueCrux canonical map: core objects, operational flow, and governance state machine.

Abstract: This page defines CueCrux as a system of proof-carrying answers: the objects the system produces, the operational flow that makes outputs verifiable, and the governance state machine that keeps reuse safe over time.

Core objects

CueCrux Canonical Map: Core objects and relationships

Claim: answers are objects made of claims, evidence, and receipts. If you drop receipts, you have not integrated trust, you have integrated hope.

Show draft diagram source graph TD Q[Question] -->|ask| A[Answer] A -->|contains| CL[Claims (atomic)] CL -->|supported by| MIS[MiSES Evidence Sets] MIS -->|references| AR[Artefacts] AR -->|tracked in| PL[Provenance Ledger]

A -->|emits| RCCROWN Receipt RC -->|binds| MIS RC -->|binds| CFGSnapshot Config

A -->|exposes| TSTrust Signals TS --> COVContext Coverage TS --> FRFragility TS --> CONTRAContradiction TS --> STALEStaleness

A -->|governed by| GOVGovernance state machine TS -->|feeds transitions| GOV GOV -->|supersedes| A2New Answer or New Receipt

Operational flow

CueCrux Canonical Map: Operational flow

Claim: verified answers are built from retrieval to MiSES to receipts, then verified, displayed, monitored, and governed. If any step is skipped, risk leaks into the plumbing.

Show draft diagram source flowchart LR U[User or Agent] -->|q| API[/BFF or SDK call/] API --> RET[Hybrid retrieval] RET --> MIS[MiSES selection] MIS --> GEN[Answer generation] GEN --> RC[Mint CROWN receipt] RC --> VER[Verify receipt] VER --> UI[Display plus Why Trust] UI --> MON[Monitor drift and contradictions] MON --> GOV[Govern active, disputed, superseded] GOV -->|notify subscribers| SUB[Webhooks or events]

Governance state machine

CueCrux Canonical Map: Governance state machine

Claim: governance is procedural. Trust signals trigger transitions, and supersedence is explicit rather than accidental.

Show draft diagram source flowchart LR TS[Trust Signals] --> J1(( )) style J1 fill:none,stroke:none

subgraph GOV_STATES"Governance State" direction LR ACTActive DISDisputed SUPSuperseded end

J1 --> ACT ACT -->|contradiction emerges| DIS DIS -->|resolved| ACT ACT -->|superseded| SUP DIS -->|replaced| SUP

Glossary

TermMeaningWhat to remember
AnswerA proof-carrying object, not just textStore IDs and receipts, not screenshots
ClaimAn atomic statement inside an answerClaims can be supported, contradicted, or marked insufficient
MiSESMinimal Sufficient Evidence SetSmallest non-redundant support set, not citation dumping
ArtefactEvidence unit: document, chunk, extractHas provenance, licence, timestamps, hashes
Receipt (CROWN)Signed snapshot binding answer to evidence and configIf you cannot verify it, do not call it verified
SnapshotThe recorded retrieval and model configurationEnables replay and drift detection
CoverageHow much of the relevant evidence space was touchedStops thin answers sounding complete
FragilitySensitivity to removing key evidenceTurns unease into a defensible signal
ContradictionDissenting evidence found in the same windowTreat as data, not a UI nuisance
Governance stateActive, disputed, supersededAnswers can change without becoming political

Integration contract

What an integrator must store

Store these fields with any answer that influences a workflow:

  1. answer_id
  2. receipt_id
  3. mode (light, verified, audit)
  4. as_of and time_window (explicit or inferred)
  5. coverage label and fragility score (or at least high or low)
  6. contradiction status (present or not)
  7. governance state (active, disputed, superseded)

If you only store the text, you are keeping the vibe and binning the warranty.

What an integrator must verify

  1. Verify receipt signature server-side (hash plus signature).
  2. Reject verified UX if verification fails.
  3. Treat superseded or disputed answers as escalations, not autopilot inputs.