From 724673cabf6c124a07769f7edfc41de92992f8d3 Mon Sep 17 00:00:00 2001 From: Transaction Science Date: Wed, 4 Nov 2026 14:27:28 -0500 Subject: [PATCH 1/2] INGEST.md said 1.95.0, an MSRV policy that does not exist, and 12 links to the wrong forge MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three things in this file were false rather than merely stale, which is worse in the one document whose job is to say what the ecosystem is. **The pin.** It said "Rust 1.95.0". The root `rust-toolchain.toml` says 1.99.1 after the bump that just landed, so the file was two bumps behind. **The MSRV policy.** It said "Per-workspace MSRV is declared in each `Cargo.toml` (`rust-version = \"1.95\"`). CI enforces both." No first-party crate declares `rust-version` at all. The only two mentions in the tree are `wai/wai-verify/Cargo.toml`, carrying a note that it deliberately has none because that verifier ships its own pinned nightly, and a vendored `wtransport` manifest declaring 1.88, which is third-party code stating its own floor. The section now records the policy that is actually in force: one pin at the root, no MSRV floor, because a per-crate floor is a second and quieter version statement that drifts from the pin. **The tracker.** Twelve links pointed at `github.com` issues. The three "Tracked in issues labelled X" links now point at the forge, whose issue list answers 200 anonymously. The nine per-item numbers were **dropped rather than translated**: Forgejo numbers issues and pull requests from one counter, so a pre-migration `#7` is not necessarily today's `#7`, and neither credential available here can read issues to confirm a mapping — both 403. A wrong link is worse than none, and asserting a mapping I cannot check is how this file got into this state. It also claimed to record "the scope of each protocol", having done so for 3 of 22. Rather than write 19 scope paragraphs by paraphrasing READMEs — a second copy that would drift exactly as these facts did — the file now **indexes** the 22 standards and links each to its own README and SPEC, which are the source of truth. The four sections that carry real Included / Adding content keep it and are marked in the index. Every one of the 44 relative links was checked to resolve, and every README and SPEC path asserted to exist before being written. Guards clean: comparative prose (4104 files), vanity metrics (523 Markdown files), spec refs (1966 citations across 17 standards), orphan sources. Stacked on mesh/decision-training-provenance (#612), which adds the `mesh/` section this index marks as detailed. Co-Authored-By: Claude Opus 5 --- INGEST.md | 75 ++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 55 insertions(+), 20 deletions(-) diff --git a/INGEST.md b/INGEST.md index c9ac3229b..d32504233 100644 --- a/INGEST.md +++ b/INGEST.md @@ -1,20 +1,53 @@ # Ingest — Scope of the Open Standards Ecosystem -*Dated 2026-05-23.* +*Dated 2026-05-23. Reconciled 2026-11-04.* -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 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. +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. --- -## Rust +## One toolchain pin, no MSRV floor -Every Rust workspace in this repository is built with the toolchain pinned at the repository root in [`rust-toolchain.toml`](rust-toolchain.toml), which tracks the latest stable release (edition 2024). CI installs that exact version on every runner, so the pin is what the code is held to. +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. -There is no minimum-supported-version floor below the pin. The `rust-version` key in each `Cargo.toml` is a cargo convenience -- it turns an older toolchain into a clear message instead of a compile error -- and is not a support promise. +**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 an exception to the policy: [`wai/wai-verify/Cargo.toml`](wai/wai-verify/Cargo.toml) carries a note recording that it has none on purpose, because that verifier ships its own pinned nightly; 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) | --- @@ -44,11 +77,11 @@ There is no minimum-supported-version floor below the pin. The `rust-version` ke ### Adding -Tracked in [issues labelled `openpay`](https://github.com/Transaction-Science/open-standards/issues?q=is%3Aissue+label%3Aopenpay): +Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Science/open-standards/issues) under the `openpay` label: -- PCI-DSS scope-management materials and zero-scope reference deployment ([#1](https://github.com/Transaction-Science/open-standards/issues/1)). -- Network token provisioning (VTS + MDES) behind a `Tokenized` typestate ([#2](https://github.com/Transaction-Science/open-standards/issues/2)). -- Bi-temporal ledger lens: CLI `as_of` queries + Grafana dashboard + OpenTelemetry traces per state transition ([#3](https://github.com/Transaction-Science/open-standards/issues/3)). +- PCI-DSS scope-management materials and zero-scope reference deployment. +- Network token provisioning (VTS + MDES) behind a `Tokenized` 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. @@ -73,11 +106,11 @@ Tracked in [issues labelled `openpay`](https://github.com/Transaction-Science/op ### Adding -Tracked in [issues labelled `smart-byte`](https://github.com/Transaction-Science/open-standards/issues?q=is%3Aissue+label%3Asmart-byte): +Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Science/open-standards/issues) under the `smart-byte` label: -- Rust reference implementation `smart-byte-rs` — envelope + sign + lockstep gossip MVP ([#4](https://github.com/Transaction-Science/open-standards/issues/4)). -- KERI Self-Addressing IDentifiers + key-event log format ([#5](https://github.com/Transaction-Science/open-standards/issues/5)). -- Conformance test-vector pack published at `byte.transaction.science/conformance` ([#6](https://github.com/Transaction-Science/open-standards/issues/6)). +- 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. @@ -99,11 +132,11 @@ Tracked in [issues labelled `smart-byte`](https://github.com/Transaction-Science ### Adding -Tracked in [issues labelled `eoc`](https://github.com/Transaction-Science/open-standards/issues?q=is%3Aissue+label%3Aeoc): +Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Science/open-standards/issues) under the `eoc` label: -- Rust + WASM reference implementation `eoc-rs` with hardware joule counters (RAPL / NVML / `powermetrics`) ([#7](https://github.com/Transaction-Science/open-standards/issues/7)). -- Benchmark harness `eoc-bench` and the joules-per-MT-Bench-point metric ([#8](https://github.com/Transaction-Science/open-standards/issues/8)). -- GSF SCI-for-AI submission + HuggingFace cookbook recipe ([#9](https://github.com/Transaction-Science/open-standards/issues/9)). +- 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. @@ -154,10 +187,12 @@ measured, not taken from a price list. ## 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. +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 its own section here. +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.** It pointed 12 times at `github.com` issues, which is not where this project's issues live. The tracker links now point at the forge. The per-item numbers from those links were **dropped rather than translated**: Forgejo numbers issues and pull requests from one counter, so a pre-migration `#7` is not necessarily today's `#7`, and no credential available here can read issues to confirm a mapping. A wrong link is worse than none. -- 2.54.0 (Apple Git-157) From 2e0c56fe6b26afde06372a9d0d57e832d71af105 Mon Sep 17 00:00:00 2001 From: Transaction Science Date: Wed, 4 Nov 2026 14:33:28 -0500 Subject: [PATCH 2/2] The links had nothing on the other side, and wai-verify pins no toolchain MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two corrections to the reconciliation, both from checking rather than reasoning. **The Adding lists were not tracked anywhere.** I had repointed the three "Tracked in issues labelled X" links at the forge's issue list and dropped the nine per-item numbers for want of a verifiable mapping. The real reason is simpler and worth stating: 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. There was never a `#7` to point at. So the three lines now say what is true, which is that these lists are themselves the record, and the closing note carries the evidence and the consequence: filing them as forge issues would be the better state, and `/issues` is 403 for both credentials available here, so it is not something this change can do. **`wai-verify` pins no toolchain.** The note I wrote repeated the crate's own comment, that it "ships its own pinned nightly". It does not: there is no `rust-toolchain.toml` in that crate. The nightly belongs to the model checker, which brings its own toolchain for the proof harnesses; the crate only declines to state an MSRV that would outrank it. The distinction matters for the policy one line above it — **nothing in this repository pins a second version**, and the corrected text says so. Confirmed while here: both pins on `main` are 1.99.1 after #606, and 1.99.1 is what `channel-rust-stable.toml` currently publishes, so the repository is on latest stable with one pin and no floor. Guards clean. 43 relative links, 0 broken. The one remaining `github.com` is inside the prose explaining the removal. Co-Authored-By: Claude Opus 5 --- INGEST.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/INGEST.md b/INGEST.md index d32504233..878b8cbca 100644 --- a/INGEST.md +++ b/INGEST.md @@ -14,7 +14,7 @@ This file **indexes** the ecosystem and records the repository-wide facts. It do 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 an exception to the policy: [`wai/wai-verify/Cargo.toml`](wai/wai-verify/Cargo.toml) carries a note recording that it has none on purpose, because that verifier ships its own pinned nightly; and `joule-code/joule-code-rs/vendor/wtransport/Cargo.toml` declares `1.88`, which is vendored third-party code stating its own floor. +**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.* @@ -77,7 +77,7 @@ Twenty-two, each with its own documents. A standard's scope, conformance and sta ### Adding -Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Science/open-standards/issues) under the `openpay` label: +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` typestate. @@ -106,7 +106,7 @@ Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Sc ### Adding -Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Science/open-standards/issues) under the `smart-byte` label: +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. @@ -132,7 +132,7 @@ Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Sc ### Adding -Tracked on the forge, in [issues](https://git.transaction.science/Transaction-Science/open-standards/issues) under the `eoc` label: +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. @@ -195,4 +195,6 @@ A new standard joins this repository by: 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.** It pointed 12 times at `github.com` issues, which is not where this project's issues live. The tracker links now point at the forge. The per-item numbers from those links were **dropped rather than translated**: Forgejo numbers issues and pull requests from one counter, so a pre-migration `#7` is not necessarily today's `#7`, and no credential available here can read issues to confirm a mapping. A wrong link is worse than none. +**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. -- 2.54.0 (Apple Git-157)