Authority Overview

CentralBinary (CB) is a deterministic clearing gateway for model and agent transactions.

CB is designed to be evidence-first:

Routing decisions are written to an append-only WAL.
Settlement receipts are written to an append-only WAL.
Seals are written to an append-only WAL when signing is enabled.
Reproducibility stamps are computed from these WAL records.
Optional archival writes immutable storage events.

Ground truth and non-claims

This site describes repository ground truth. It does not claim regulatory approval, production readiness, or external attestation unless explicitly stated and backed by verification artifacts.

Core surfaces

Gateway (runtime): enforcement point for routing and settlement.
Signer (optional boundary): isolated signing authority.
Operator Terminal (bench): read-only evidence viewport with explicit, justified governance actions.

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:

Routing (pre-inference)
Execution (inference)
Settlement (post-inference validation; release/withhold decision)
Notarization (optional sealing)
Reproducibility (deterministic stamp)
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

Marketing (Public Overview)

The Central Binary (CB)

Deterministic clearing for model and agent transactions.

CB sits between clients and model providers and provides:

Deterministic settlement (allow | transform | escalate | void)
Evidence-first operation (append-only WALs)
Operator-grade review (Ledger + Receipt + Audit Trace)

Who this is for

Teams that need auditable controls on model output.
Operators who need a Ledger-first surface instead of ad-hoc logs.
Builders who need an enforcement point that stays provider-agnostic.

What you get (outcomes)

A clearing decision you can justify: settlement outcomes are emitted as evidence.
A forensic trail you can replay: the system writes time-ordered WAL artifacts.
A stable basis for reporting: CB Index is derived from settlement evidence, not opinion.

How it works (at a glance)

Route (write routing.jsonl)
Execute (run provider/model)
Settle (write settlement.jsonl)
Seal (optional; write seal.jsonl)
Repro stamp (write repro.jsonl)
Archive (optional; write archive.jsonl)

Operator terminal (CBX)

The CBX Terminal is the operator surface.

Ledger is the primary surface.
Receipt shows the selected transaction’s fields.
Audit Trace aggregates WAL-derived events for the selection.

Call to action

Read the technical spec: whitepaper.md
Understand the rating model: cb_index.md
See what’s implemented vs pending: roadmap.md

Screenshots (drop-in)

Add images under docs/src/assets/ and reference them here.

![CBX Terminal — Ledger + Receipt + Audit](assets/cbx-terminal.png)

Download / run (developer preview)

Local run:

cargo test
cargo build --bin cb-runtime
NOT_RUNTIME_PORT=8714 ./target/debug/cb-runtime
cargo run --manifest-path bench/Cargo.toml

Implemented today vs roadmap

Implemented surfaces (repo-grounded):

Routing + routing WAL + routing stream
Settlement + settlement WAL + settlement stream
Repro stamp + verification endpoint
Evidence bundle export + verification tooling
Operator terminal: Ledger-first + Receipt + Audit Trace
Optional: S3 archival worker + archive surfacing

Roadmap (not implemented):

Identity-first orchestration (Ping)
External attestation (Merkle anchoring)
AP2 lifecycle
Market APIs and enterprise connectors

Learn more

architecture.md
evidence.md
operator_terminal.md

Architecture

CB is a three-component system:

Gateway

Accepts requests.
Selects a route deterministically.
Executes the selected backend.
Settles the output under a policy envelope.
Writes evidence records (WALs) that can be verified later.

Signer

Optional isolated signing boundary.
Receives a digest/envelope and returns a signature.
Produces seal.jsonl records.

Operator Terminal

Non-secret viewport.
Ledger-first evidence surface.
Human-in-the-loop governance actions are explicit and justified.

Evidence & Verification

CB’s evidence model is WAL-first.

WAL sources

routing.jsonl: routing decision per request.
settlement.jsonl: settlement receipt per request/settlement.
seal.jsonl: signature record when sealing is enabled.
repro.jsonl: reproducibility stamp derived from routing + settlement + seal.
archive.jsonl: archival worker status events (optional).
stream_gate.jsonl: streaming gate events (optional, when enabled).

All WALs may exist at:

runtime_root/logs/*.jsonl
runtime_root/tenants/<tenant>/logs/*.jsonl

Verification posture

Evidence verification should be possible from local artifacts.
External attestation is explicitly treated as a separate milestone.

CB Index (Settlement-Derived Rating)

A CB Index is a settlement-derived rating computed from evidence.

It is not a subjective score and not a claim about model intelligence.

Definition

A CB Index record summarizes a transaction’s clearing outcome using only verifiable inputs:

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

Minimal fields

Identity: request_id, settlement_id, optional tenant_id, session_id, turn_index
Routing: risk_profile, provider_tier, provider_id, selected_model_artifact_id, routing_reason_code
Settlement: compliance_status (allow|transform|escalate|void), output_hash
Notarization: signer_id, alg, seal presence
Reproducibility: repro_stamp_sha256
Archival: status (uploaded|exists|upload_failed)

Intended use

Compare operational integrity and compliance behavior across providers and tiers.
Provide a deterministic, auditable input into risk controls and governance.
Drive institutional reporting without inventing claims.

Operator Terminal

The CBX Terminal is an institutional operator surface.

Invariants

Non-secret viewport (no provider credentials, no signing keys).
Evidence surfaces are read-only.
Governance actions are explicit and justified.

Primary layout

Ledger is the primary surface.
Receipt and Audit Trace panels are driven by the selected Ledger row.

Audit Trace coverage

Audit Trace is a best-effort, WAL-derived timeline for the selected request/settlement:

Routing (routing.jsonl)
Stream gate (stream_gate.jsonl)
Settlement (settlement.jsonl)
Seal (seal.jsonl)
Repro (repro.jsonl)
Archive (archive.jsonl)

Roadmap (Milestones J.1–J.7)

This page mirrors CB.md Appendix J and is intended to be institutionally explicit about what is implemented vs pending.

J.1: Deterministic Streaming Gating
J.2: Immutable Archival & External Attestation
J.3: AP2 Mandate Full Lifecycle
J.4: Identity-First Orchestration
J.5: External Audit & Attestation
J.6: Market Launch & Interoperability
J.7: Enterprise Ecosystem Integration

Deployment & Hosting

This section describes practical deployment strategies aligned to the repository.

Recommended split

Docs (static): S3 (optionally fronted by CloudFront).
Runtime: containerized deploy (ECS Fargate behind an ALB).

Operational requirements

No secrets in repo.
Health checks and fail-closed semantics.
Object Lock + correct IAM permissions for archival.

Docs deployment (mdBook -> S3)

Prerequisites

AWS CLI installed (aws --version).
mdBook installed (mdbook --version).
- If you don’t have it yet: cargo install mdbook.

AWS authentication (do not paste secrets into chat)

Configure a dedicated AWS profile and enter your access key/secret at the terminal prompt:

aws configure --profile cb-docs

Then verify:

aws sts get-caller-identity --profile cb-docs

Build the docs

From repo root:

mdbook build docs

Output is written to:

docs/book/

Option A (fast): Public S3 static website

This is the simplest path to get a URL up quickly.

Pick:

BUCKET (globally unique), e.g. centralbinary-docs-<your-org>-<env>
REGION, e.g. us-east-1 or us-west-2

Create the bucket:

aws s3api create-bucket --bucket $BUCKET --region $REGION --profile cb-docs (for us-east-1)
aws s3api create-bucket --bucket $BUCKET --region $REGION --create-bucket-configuration LocationConstraint=$REGION --profile cb-docs (for other regions)

Allow public website hosting (intentionally):

aws s3api put-public-access-block --bucket $BUCKET --public-access-block-configuration BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false --profile cb-docs

Attach a read-only bucket policy (public GET objects):

Create a local file bucket-policy.json with:
- Resource: arn:aws:s3:::$BUCKET/*
Then:
- aws s3api put-bucket-policy --bucket $BUCKET --policy file://bucket-policy.json --profile cb-docs

Enable S3 website configuration:

aws s3 website s3://$BUCKET --index-document index.html --error-document 404.html --profile cb-docs

Upload:

aws s3 sync docs/book s3://$BUCKET --delete --profile cb-docs

Website endpoint:

http://$BUCKET.s3-website-$REGION.amazonaws.com

Option B (recommended): CloudFront + private bucket

For an institutional public site, the recommended posture is:

CloudFront distribution
ACM TLS cert for your domain
Origin Access Control (OAC)
S3 bucket kept private (no public policy)

This is a longer setup, but it can be done with CLI only. You can run without a custom domain first (CloudFront default HTTPS domain), then add ACM + Route53 later.

B.1 Create a private bucket (us-east-1)

Set:

REGION=us-east-1
BUCKET=<globally-unique-bucket>

Commands:

aws s3api create-bucket --bucket $BUCKET --region $REGION --profile cb-docs
aws s3api put-bucket-versioning --bucket $BUCKET --versioning-configuration Status=Enabled --profile cb-docs
aws s3api put-bucket-encryption --bucket $BUCKET --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}' --profile cb-docs
aws s3api put-public-access-block --bucket $BUCKET --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true --profile cb-docs

B.2 Upload the built site

mdbook build docs
aws s3 sync docs/book s3://$BUCKET --delete --profile cb-docs

B.3 Create an Origin Access Control (OAC)

aws cloudfront create-origin-access-control --origin-access-control-config '{"Name":"cb-docs-oac","Description":"OAC for CB docs","SigningProtocol":"sigv4","SigningBehavior":"always","OriginAccessControlOriginType":"s3"}' --profile cb-docs

Save the returned Id as OAC_ID.

B.4 Create the CloudFront distribution

Create cloudfront-distribution.json (example values; you must substitute $BUCKET and $OAC_ID):

Origins[0].DomainName: $BUCKET.s3.$REGION.amazonaws.com
DefaultRootObject: index.html
DefaultCacheBehavior.ViewerProtocolPolicy: redirect-to-https

Then:

aws cloudfront create-distribution --distribution-config file://cloudfront-distribution.json --profile cb-docs

Save:

Distribution Id as DIST_ID
Distribution ARN as DIST_ARN
Distribution domain name (your HTTPS URL)

B.5 Attach a bucket policy allowing CloudFront (OAC)

Create a bucket policy that allows the CloudFront service principal to s3:GetObject with a AWS:SourceArn condition bound to your distribution ARN:

aws s3api put-bucket-policy --bucket $BUCKET --policy file://bucket-policy-cloudfront.json --profile cb-docs

B.6 Invalidate CloudFront after updates

After any aws s3 sync update:

aws cloudfront create-invalidation --distribution-id $DIST_ID --paths '/*' --profile cb-docs

B.7 Custom domain (optional)

If you want docs.<your-domain>:

Request/validate an ACM cert in us-east-1.
Update distribution aliases + viewer certificate.
Create a Route53 alias record to the CloudFront distribution.

Keyboard shortcuts

CentralBinary