§3.6 already makes a decision receipt verifiable **by re-execution**: with
`weights_digest` and `precision`, a verifier runs the forward pass again and
gets the same probabilities. That settles whether this answer came from these
weights. It says nothing about where the weights came from — and a decision
model is ordinarily fitted to a corpus of earlier decisions, which is what
decides which answer the probabilities favour before any request arrives.
§3.7 adds that binding as two OPTIONAL fields, paired the way `weights_digest`
and `precision` are because neither carries the claim alone:
training_digest BLAKE3 over the canonical encoding of the corpus records
in the order the fit consumed them, each as its content
id. The order is in the address because it is part of
what the fit consumed.
training_authority what a verifier can DO with that corpus: `signed` (every
record signed by the principal that produced it, so a
third party can check it without trusting whoever
trained on it), `logged` (append-only, attested head, so
removal and reordering are detectable, but records are
not attributable), or `opaque` (bytes and a digest).
As with `weights_digest`, the absence is the signal: a verifier distinguishes
an unattributable model from an attributable one instead of assuming, which is
the only reason these are optional rather than required.
The section also forbids something. A fitted decision model is usually
introduced because it is cheaper than the generation it displaces, and a
receipt MUST NOT state that saving: those joules were never metered, because
that generation was never run. `uj_per_decision` is a measured figure, and a
difference against an unrun alternative is not — a receipt carrying one would
assert an estimate in a field a reader is entitled to read as measurement. An
operator who wants the comparison runs both and keeps both receipts, so the
difference lives between two sealed figures rather than inside one of them.
Conformance vectors do not move. The published reference serve in
`conformance/v1/` is a generation, and both fields are decision-only and
OPTIONAL, so `reference/signed_core.hex` and `reference/envelope.hex` are
unchanged and need no regeneration.
Nothing in this repository yet produces a `training_digest`. The spec now says
how such a model is bound; the fit that emits one is in INGEST.md's Adding
list, which is honest about the order these landed in.
INGEST.md also gains the `mesh/` section it never had. Noted while there and
NOT fixed here, because it is a separate job: that file is dated 2026-05-23,
carries 4 sections for 22 standards, pins "Rust 1.95.0" where the root
`rust-toolchain.toml` says 1.98.0, and routes 12 links to github.com issues,
which is not where this project's issues live any more.
Guards run locally, all clean: comparative prose (4104 files), vanity metrics
(523 Markdown files), spec refs (1966 citations across 17 standards, all
resolve), orphan sources.
Co-Authored-By: Claude Opus 5 <[email protected]>
9.5 KiB
Ingest — Scope of the Open Standards Ecosystem
Dated 2026-05-23.
The three open standards in this repository are self-contained. They do not depend on running any external service. They interoperate where interoperation is useful, but they are complete on their own.
The implementation principle is direct: the best ideas from open-source and private efforts in each niche are ingested and built in Rust under permissive licences, so that each protocol is an ever-present, fully complete, free alternative.
This document records the scope of each protocol — the capabilities included and the capabilities being added — so a contributor can see at a glance what is in the ecosystem and what remains to land.
Rust 1.95.0
Every Rust workspace in this repository targets Rust 1.95.0 (edition 2024). The pin is at the repository root in rust-toolchain.toml. Per-workspace MSRV is declared in each Cargo.toml (rust-version = "1.95"). CI enforces both.
openpay/
Scope: a complete payment-acceptance stack. Card, account-to-account, and stablecoin rails behind one orchestrator, with a typestate-enforced lifecycle and an append-only double-entry ledger.
Included in v0.1.0
- Typed money (integer minor units, no
f64). - Typestate payment lifecycle (
Payment<Created>→Authorized→Captured→Refunded, distinct types). - Card rail with
CardAcquirertrait + Hyperswitch driver. - Account-to-account rail with
A2aAcquirertrait + FedNow / PIX (Bacen SPI) / SEPA Instant (RT1/TIPS) drivers — direct ISO 20022 with no PSP intermediary. - Stablecoin rail with
CryptoGatewaytrait +EvmJsonRpcGateway(USDC on Base / Ethereum / Polygon / Arbitrum) + a hand-rolled ERC-20 calldata encoder. - Token-only vault (
Vaulttrait + AES-256-GCM-SIV reference). - On-device fraud scoring (heuristic, ONNX, pure-Rust Burn backends).
- Outbound webhook delivery with Stripe-compatible signing + auto-disable on chronic failure.
- Multi-rail orchestrator with policy routing, idempotency, soft-failure fallback, and 3DS / SCA resume.
- Append-only double-entry ledger with bi-temporal history.
- Ledger ↔ bank-statement reconciliation via deterministic UUID v5 matching.
- Minigraf-backed implementations of every domain store (
LedgerStore,WebhookStore,ReconciliationStore,RefundStore,DisputeStore,SettlementStore,SubscriptionStore,IdempotencyStore). - Refunds, disputes, batch settlement (with NACHA payout file generation), recurring subscriptions (calendar-aware intervals, trials, dunning, proration), FX with banker's rounding.
- HTTP server (
op-server) and operator CLI (op-cli) with 14 subcommands. - Driver-SDK conformance harness (
op-driver-sdk). - FFI to iOS / macOS (
op-ffi-swift), Android (op-ffi-jni), and browser/Node (op-wasm). PAN never crosses any FFI boundary. - ISO 20022 message helpers (
op-iso20022) and an EMV TLV codec (op-emv).
Adding
Tracked in issues labelled openpay:
- PCI-DSS scope-management materials and zero-scope reference deployment (#1).
- Network token provisioning (VTS + MDES) behind a
Tokenized<Card>typestate (#2). - Bi-temporal ledger lens: CLI
as_ofqueries + Grafana dashboard + OpenTelemetry traces per state transition (#3). - Dispute auto-evidence packager.
- MCC-aware / least-cost routing.
- Sub-merchant onboarding and KYB.
- Multi-currency settlement orchestration.
- Webhook delivery SLA + retry-policy semantics.
smart-byte/
Scope: a complete content-addressed value-envelope substrate. Signed envelopes that carry arbitrary cargo with provenance and energy cost intrinsic, replicated by deterministic lockstep BFT across federated 8–32-node clusters.
Included in v1 spec
- Envelope schema: identity (content-addressed hash), provenance (issuer-signed birth certificate), ownership chain (signature-bound transitions), cargo (opaque application-layer payload), joule cost (measured + estimated).
- Deterministic lockstep simulation — every node runs the identical state machine, one frame at a time.
- Byzantine supermajority commit (>2/3 cluster agreement on post-frame state hash).
- Federation by bounded clusters connected by a gossip overlay (the pattern that has run the internet).
- Per-byte content-addressed history.
- Security engineering documented in
SECURITY.md— proven primitives, no exotic constructions. - The Treatise (Parts I–III in full; IV–VII previewed) and the strategic-context document.
Adding
Tracked in issues labelled smart-byte:
- Rust reference implementation
smart-byte-rs— envelope + sign + lockstep gossip MVP (#4). - KERI Self-Addressing IDentifiers + key-event log format (#5).
- Conformance test-vector pack published at
byte.transaction.science/conformance(#6). - Revocation registry.
- Privacy primitives (selective disclosure).
- Schema discovery format.
- Cross-cluster gateway protocol with formal dispute semantics.
eoc/
Scope: a complete energy-optimised compute substrate. Every query resolves through a four-stage memoising cascade — cache → key-value → graph → neural — and a neural model is invoked only when nothing cheaper can answer.
Included in v1 spec
- Four-stage cascade with explicit stage boundaries.
- Joules as the unit of accounting; energy is a protocol-level field, not telemetry.
- Browser-runnable / commodity-CPU posture.
- Federated, no-off-switch positioning (CC-BY-4.0 spec; no single entity runs it).
- Specification suite across
spec/covering wire format, decay semantics, registry shape, and worked evaluation instances.
Adding
Tracked in issues labelled eoc:
- Rust + WASM reference implementation
eoc-rswith hardware joule counters (RAPL / NVML /powermetrics) (#7). - Benchmark harness
eoc-benchand the joules-per-MT-Bench-point metric (#8). - GSF SCI-for-AI submission + HuggingFace cookbook recipe (#9).
- Cache-key canonicalisation specification.
- Learned router stage (matrix-factorisation or comparable).
- Semantic-similarity threshold calibration methodology.
- Registered MIME / JSON-Schema for the protocol envelope.
mesh/
Scope: energy-accounted inference serving and routing. A request declares a joule ceiling and a fidelity floor; the mesh routes it to the cheapest-sufficient model on the cheapest-sufficient backend, serves it under a meter, and seals a receipt whose headline figure is microjoules per accepted output token — measured, not taken from a price list.
Included in v1 spec
- Grants decided as a JCP enforcement point before any work, with the metered joules debited after it and a breach recorded on the receipt (§2).
- A decision journal that survives steward restart, so a restart is not mistaken for a log that lost its history (§2.2, §6.3).
- Fidelity floors, with advertised and delivered levels reported separately so an unmet floor is visible rather than inferred (§3.2).
- Energy provenance as a closed set —
HwShunt,ModelBased,Estimator— withmeasured_ujpresent only for the first (§3.3). - Cheapest-sufficient routing that records every candidate weighed (§4).
- Typed decisions as a second unit of work: calibrated probabilities over a
schema, zero output tokens, priced per scored option and reported as
uj_per_decisionrather than per accepted token (§3.6). - Training provenance for a decision model:
training_digestaddresses the corpus the weights were fitted to, andtraining_authoritysays whether a third party can check that corpus (§3.7). Added 2026-11-04 to close a gap in this spec: a receipt could already bind which weights answered and at what precision, so the answer reproduces, but it could say nothing about what taught those weights to answer that way. §3.7 also forbids the saving such a model is usually introduced with — the generation it displaced was never run, so it was never metered.
Adding
- The fit itself: a reference pipeline that turns a corpus of signed accepted
transitions into a decision model, emitting the
training_digestthe receipt carries. The spec now says how such a model is bound; nothing in this repository yet produces one. uj_per_option_scoredcalibration methodology across backends.
How this document evolves
This file is the living scope manifest. Adding a capability begins by filing an issue with the relevant openpay / smart-byte / eoc label, then appearing in the Adding list above. Shipping a capability moves it to the Included list.
A new standard joins this repository by:
- Landing in a new top-level subdirectory with its own README and licence, per
CHARTER.md. - Getting a paragraph in the root
README.md. - Adding its own section here.