Whitepaper (Technical Specification, Repo-Grounded)

1. Scope and non-claims

This document specifies the behavior of The Central Binary (CB) as implemented in this repository.

• The document is constrained to repository ground truth.
• This document does not assert regulatory approval, production readiness, or external attestation unless explicitly backed by artifacts.

2. System definition

CB is a deterministic clearing gateway for model and agent transactions. The system consists of three conceptual components:

• Gateway (runtime): executes routing and settlement; emits evidence.
• Signer (optional boundary): signs digests; private keys must not be resident in Gateway or UI processes.
• Operator terminal (bench): non-secret evidence viewport and explicit governance action surface.

The Gateway is the enforcement point. The terminal is not a source of truth.

3. Transaction model

A transaction is identified by a deterministic request_id and may produce a settlement_id.

The transaction lifecycle is:

1. Routing (pre-inference)
2. Execution (inference)
3. Settlement (post-inference validation; release/withhold decision)
4. Notarization (optional sealing)
5. Reproducibility (deterministic stamp)
6. Archival (optional immutable storage workflow)

4. Settlement semantics

Settlement is the authoritative clearing decision. CB models settlement as a finite set of outcomes:

• allow: output is released.
• transform: output is transformed and released.
• escalate: output is withheld pending explicit governance action.
• void: output is withheld/discarded.

The Gateway must be able to justify a settlement outcome from evidence.

5. Evidence plane (WAL artifacts)

CB emits evidence as append-only write-ahead logs (WALs) under runtime_root/**/logs/.

The canonical WALs referenced by the operator surface are:

• routing.jsonl
• settlement.jsonl
• seal.jsonl (when sealing is enabled)
• repro.jsonl
• stream_gate.jsonl (when streaming gating instrumentation is enabled)
• archive.jsonl (when archival is enabled)

These records are joined primarily by request_id and settlement_id.

6. Settlement-derived rating: CB Index

A CB Index is a settlement-derived index computed from evidence. It is not a subjective score and not a claim about model intelligence.

Normative inputs:

• Routing decision (routing.jsonl)
• Settlement receipt (settlement.jsonl)
• Seal record (seal.jsonl, when enabled)
• Repro stamp (repro.jsonl)
• Archival status (archive.jsonl, when enabled)

Minimal fields and intended use are specified in:

• cb_index.md

7. Operator terminal requirements

The operator terminal is a non-secret viewport:

• It must not require or expose provider credentials.
• It must not hold signing keys.
• Evidence surfaces must be read-only.
• Governance actions must be explicit and justified.

The terminal layout is Ledger-first, with Receipt and Audit Trace driven by the selected Ledger row.

Audit Trace is best-effort and WAL-derived, aggregating:

• routing
• stream gate
• settlement
• seal
• repro
• archive

See:

• operator_terminal.md

8. Verification posture

CB is designed so that critical claims can be verified from artifacts without trusting UI text.

Typical verification steps:

• Inspect WAL lines for a given request_id / settlement_id.
• Export an evidence bundle and run local verification.
• Recompute and compare the Repro stamp (via the verification endpoint).

9. Implemented vs roadmap

Implemented details must be grounded in code, WALs, and verification commands.

Roadmap items (identity orchestration, AP2 lifecycle, external attestation portal, market APIs) are explicitly pending.

See:

• roadmap.md