open-standards/INGEST.md
Transaction Science 9c04dca002 op-rails-x402: auth-capture and batch-settlement, and an honest account of where the wire stands
The rail refused two of the wire's four schemes. Both are implemented.

**`auth-capture`.** Under `escrow` the client's settle places a hold before the
work, and the server finalizes afterwards with a payload it authors itself,
naming the operation as `payload.type`: a capture of what the work cost, or a
void when it cost nothing. `accept` walks that, and refuses a capture over the
hold before it is relayed. Later operations go through the same `/settle`, so
`lifecycle_payload` builds them around the network binding's own fields — the
facilitator is handed the payment rather than left to reconstruct it.

`AuthCapturePayment` is the server's book of one payment: held, captured,
refunded, and the two deadlines. The escrow enforces these on chain, so the
book is not where safety comes from. It is where a doomed operation is refused
*before* it costs a failed settle and, for an asynchronous server, a payment
its own records misdescribe: a capture over the hold or past the capture
deadline, a void with nothing left to release, a refund over what was captured
and not yet refunded or past the refund deadline, a fee outside the bounds the
client authorized. A requirement with no capture deadline is refused rather
than booked — a hold that can never be reclaimed is not one to place.

**`batch-settlement`.** The commitment is verified, the work runs, and the
charge is stored rather than moved, so the result carries an empty
`transaction` and reports the request's price in `extra.chargedAmount`. That is
success, not a missing hash. The charge is bounded where it is reported, since
under this scheme there is no transfer to fail instead.

The settle-time amount rule is now one type, `MeteredCharge`, for every scheme
whose settled figure may differ from the authorized one; `UptoCharge` stays as
its name for the `upto` case.

And the capability document is corrected. It claimed partial settlement as
ground the wire did not cover. The wire's reservation lifecycle is as complete
as ours, and the document now says so and maps all three metered schemes onto
it. What that narrows our contribution there to is exactly two things, stated
without decoration: nothing on that wire bounds the energy the paid work burns,
and none of the three schemes carries a measurement — the figure the buyer pays
is a number the seller produced, bounded above and otherwise unexplained.

Co-Authored-By: Claude <[email protected]>
2026-11-10 15:24:37 -05:00

203 lines
15 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Ingest — Scope of the Open Standards Ecosystem
*Dated 2026-05-23. Reconciled 2026-11-04.*
The 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 file **indexes** the ecosystem and records the repository-wide facts. It does not duplicate each standard's scope: that lives in the standard's own `README.md` and `SPEC.md`, which are the source of truth and cannot drift from the code the way a second copy here did. Four standards also carry an Included / Adding breakdown below, because theirs has content worth keeping; the rest are indexed and link to their own documents.
---
## One toolchain pin, no MSRV floor
Every Rust workspace in this repository targets the toolchain pinned at the repository root in [`rust-toolchain.toml`](rust-toolchain.toml) — currently **1.99.1 (edition 2024)**. That pin is the only statement of the version, and bumping it is a change to every workspace at once. CI installs that exact version on every runner, so the pin is what the code is held to.
**No first-party crate declares `rust-version`, deliberately.** This project tracks latest stable rather than supporting a floor, and a per-crate MSRV would be a second, quieter version statement that drifts from the pin. Two things in the tree mention it and neither is a second toolchain. [`wai/wai-verify/Cargo.toml`](wai/wai-verify/Cargo.toml) records that it declines an MSRV on purpose: the model checker runs the proof harnesses under a toolchain it brings itself, and an MSRV above that one makes cargo refuse to build them — note the crate carries **no `rust-toolchain.toml`**, so nothing in this repository pins a second version. And `joule-code/joule-code-rs/vendor/wtransport/Cargo.toml` declares `1.88`, which is vendored third-party code stating its own floor.
*This section previously claimed the pin was 1.95.0 and that "per-workspace MSRV is declared in each `Cargo.toml`". Both were wrong at the time of reading — hence the reconciliation date above.*
---
## The standards
Twenty-two, each with its own documents. A standard's scope, conformance and status are stated there, not here.
| Standard | Documents |
|---|---|
| `aac/` | [README](aac/README.md) · [SPEC](aac/SPEC.md) |
| `arl/` | [README](arl/README.md) |
| `eoc/` | [README](eoc/README.md) · Included / Adding below |
| `jcp/` | [README](jcp/README.md) · [SPEC](jcp/SPEC.md) |
| `joule-code/` | [README](joule-code/README.md) · [SPEC](joule-code/SPEC.md) |
| `joule-os/` | [README](joule-os/README.md) |
| `joule-ui/` | [README](joule-ui/README.md) · [SPEC](joule-ui/SPEC.md) |
| `jouleclaw/` | [README](jouleclaw/README.md) · [SPEC](jouleclaw/SPEC.md) |
| `joulecontract/` | [README](joulecontract/README.md) · [SPEC](joulecontract/SPEC.md) |
| `jouledesk/` | [README](jouledesk/README.md) · [SPEC](jouledesk/SPEC.md) |
| `joulehook/` | [README](joulehook/README.md) · [SPEC](joulehook/SPEC.md) |
| `joulespec/` | [README](joulespec/README.md) · [SPEC](joulespec/SPEC.md) |
| `jouletable/` | [README](jouletable/README.md) · [SPEC](jouletable/SPEC.md) |
| `map/` | [README](map/README.md) · [SPEC](map/SPEC.md) |
| `mesh/` | [README](mesh/README.md) · [SPEC](mesh/SPEC.md) · Included / Adding below |
| `openpay/` | [README](openpay/README.md) · Included / Adding below |
| `pool/` | [README](pool/README.md) · [SPEC](pool/SPEC.md) |
| `proof/` | [README](proof/README.md) · [SPEC](proof/SPEC.md) |
| `sandbox/` | [README](sandbox/README.md) · [SPEC](sandbox/SPEC.md) |
| `sense/` | [README](sense/README.md) · [SPEC](sense/SPEC.md) |
| `smart-byte/` | [README](smart-byte/README.md) · Included / Adding below |
| `wai/` | [README](wai/README.md) · [SPEC](wai/SPEC.md) |
---
## 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 `CardAcquirer` trait + Hyperswitch driver.
- Account-to-account rail with `A2aAcquirer` trait + FedNow / PIX (Bacen SPI) / SEPA Instant (RT1/TIPS) drivers — direct ISO 20022 with no PSP intermediary.
- Stablecoin rail with `CryptoGateway` trait + `EvmJsonRpcGateway` (USDC on Base / Ethereum / Polygon / Arbitrum) + a hand-rolled ERC-20 calldata encoder.
- Token-only vault (`Vault` trait + 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`).
- Machine / agent payment acceptance on the HTTP `402` rail (`op-rails-x402`), speaking **both** live wire versions: v1 (`X-PAYMENT`, `maxAmountRequired`) and v2 (`PAYMENT-REQUIRED` / `PAYMENT-SIGNATURE` / `PAYMENT-RESPONSE`, CAIP-2 networks, all four schemes — `exact`, `upto`, `auth-capture` with its capture / void / refund lifecycle and deadlines, and `batch-settlement` with its reported per-request charge — the `authorization` / `upfront` / `escrow` orderings, the facilitator split into `/verify` + `/settle` + `/supported`, and `/discovery/resources`). A scheme this build does not know is refused, not gated as `exact`.
- Agentic mandate acceptance (`op-agentic`): an AP2 SD-JWT presentation parsed and its selective disclosures resolved — a withheld value is never read as an empty one — a closed checkout mandate's hash binding checked over the merchant-signed checkout (the UCP Checkout object), and the `checkout.allowed_merchants` and `checkout.line_items` constraints evaluated as specified, including the maximal-flow matching rule. All eight **payment**-mandate constraints are evaluated too: allowed payees, instruments and initiation providers, amount range, budget, recurrence, execution window, and the reference binding a payment to its checkout. Decimal amounts convert to integer minor units by decimal string arithmetic, never through a float, and an amount with more precision than its currency is refused rather than rounded. A constraint type that is not evaluated is refused rather than skipped, and a budget or recurrence limit evaluated without the history of prior presentations is refused rather than passed. Signatures stay behind a `MandateVerifier` seam.
- Agentic mandate **creation** (`op-agentic::create`): build an open or closed mandate of either family, make any claim selectively disclosable, and emit the compact SD-JWT presentation the acceptance path reads — so the stack issues the credential as well as reading it. Salts must carry the 128 bits of entropy the format requires, since the digest is published whether its value is disclosed or not; a shorter one is refused rather than quietly used. Signing goes through a `MandateSigner` seam. The round trip (create → present → accept) is tested, and so is the case that matters more: a presentation that withholds a claim, which must be refused rather than read as permitting everything — asserted over randomised disclosure subsets, so no subset can accept a checkout the complete mandate refuses.
### Adding
Not in a tracker today — see the note at the end of this file. This list is the record:
- PCI-DSS scope-management materials and zero-scope reference deployment.
- Network token provisioning (VTS + MDES) behind a `Tokenized<Card>` typestate.
- Bi-temporal ledger lens: CLI `as_of` queries + Grafana dashboard + OpenTelemetry traces per state transition.
- 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
Not in a tracker today — see the note at the end of this file. This list is the record:
- Rust reference implementation `smart-byte-rs` — envelope + sign + lockstep gossip MVP.
- KERI Self-Addressing IDentifiers + key-event log format.
- Conformance test-vector pack published at `byte.transaction.science/conformance`.
- 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
Not in a tracker today — see the note at the end of this file. This list is the record:
- Rust + WASM reference implementation `eoc-rs` with hardware joule counters (RAPL / NVML / `powermetrics`).
- Benchmark harness `eoc-bench` and the joules-per-MT-Bench-point metric.
- GSF SCI-for-AI submission + HuggingFace cookbook recipe.
- 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` — with
`measured_uj` present 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_decision` rather than per accepted token (§3.6).
- Training provenance for a decision model: `training_digest` addresses the
corpus the weights were fitted to, and `training_authority` says 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_digest` the receipt
carries. The spec now says how such a model is bound; nothing in this
repository yet produces one.
- `uj_per_option_scored` calibration methodology across backends.
---
---
## How this document evolves
This file is the index and the repository-wide record. Adding a capability begins by filing an issue on the forge under the relevant label; where a standard keeps an Included / Adding breakdown here, the capability appears in **Adding** and moves to **Included** when it ships.
A new standard joins this repository by:
1. Landing in a new top-level subdirectory with its own README and licence, per [`CHARTER.md`](CHARTER.md).
2. Getting a paragraph in the root [`README.md`](README.md).
3. Adding a row to **The standards** above. A section of its own is optional and worth writing only when there is more to say than its README already says.
**On the links this file used to carry, and why the Adding lists now link nowhere.** It pointed 12 times at `github.com` issues. That is not where this project's git lives any more, and more to the point **there is nothing on the other side**: the forge repository has its issue tracker enabled and **empty** — `open_issues_count` is 0 — because the migration carried code and pull requests, not issues. So the nine per-item numbers could not be repointed; a pre-migration `#7` has no counterpart, and Forgejo numbers issues and pull requests from one counter, so guessing would also have been unsafe. They were removed, and the three "tracked in issues labelled X" lines were replaced with the truth, which is that these lists are themselves the record.
Filing them as forge issues would be the better state and is not something the credentials here can do — `/issues` is 403 for both of them. Until then, an item moves from **Adding** to **Included** by being shipped and edited here, and this file is the tracker.