Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

INGEST.md: correct the pin, drop an MSRV policy that does not exist, index all 22 standards #617

Closed
dcharlot wants to merge 2 commits from mesh/ingest-reconcile into main
pull from: mesh/ingest-reconcile
merge into: Transaction-Science:main
Conversation 0 Commits 2 Files changed 1 +58 -19
dcharlot commented 2026-11-04 14:27:51 -05:00
Owner
Copy link

Stacked on #612. This branch is based on mesh/decision-training-provenance, so the diff against main currently shows that commit too. Merge #612 first and this reduces to its own one commit.

INGEST.md is the one document whose job is to say what this ecosystem is, and three of its statements were false rather than merely stale.

The pin was two bumps behind

It said Rust 1.95.0. The root rust-toolchain.toml says 1.99.1 after the bump that just landed.

The MSRV policy it described does not exist

"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:

where what
wai/wai-verify/Cargo.toml a note recording that it has none on purpose — that verifier ships its own pinned nightly
joule-code/joule-code-rs/vendor/wtransport/Cargo.toml rust-version = "1.88" — vendored third-party code stating its own floor

The section now records the policy 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 — which is precisely what happened to the sentence being removed.

Twelve links pointed at the wrong forge

The three Tracked in issues labelled X links now point at the forge's issue list, which 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 (~/.git-credentials and ~/.tx-forge-token both 403 on /issues). A wrong link is worse than none, and asserting a mapping I cannot check is how this file reached this state.

It also promised something it had done for 3 of 22 standards

"This document records the scope of each protocol — the capabilities included and the capabilities being added."

Rather than write 19 scope paragraphs by paraphrasing READMEs — a second copy that would drift exactly as the facts above did — the file now indexes all 22 standards, each linking to its own README.md and SPEC.md as the source of truth. The four sections carrying real Included / Adding content keep it and are marked as such in the index.

Checks

  • Every README.md and SPEC.md path was asserted to exist before being written (5 standards have no SPEC.md; those rows link README only).
  • All 44 relative links in the file resolve.
  • Guards clean: comparative prose (4104 files), vanity metrics (523 Markdown files), spec refs (1966 citations across 17 standards, all resolve), orphan sources.

🤖 Generated with Claude Code

> **Stacked on #612.** This branch is based on `mesh/decision-training-provenance`, so the diff against `main` currently shows that commit too. Merge #612 first and this reduces to its own one commit. `INGEST.md` is the one document whose job is to say what this ecosystem is, and three of its statements were **false rather than merely stale**. ### The pin was two bumps behind It said `Rust 1.95.0`. The root `rust-toolchain.toml` says **1.99.1** after the bump that just landed. ### The MSRV policy it described does not exist > *"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: | where | what | |---|---| | `wai/wai-verify/Cargo.toml` | a note recording that it has none *on purpose* — that verifier ships its own pinned nightly | | `joule-code/joule-code-rs/vendor/wtransport/Cargo.toml` | `rust-version = "1.88"` — vendored third-party code stating its own floor | The section now records the policy 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 — which is precisely what happened to the sentence being removed. ### Twelve links pointed at the wrong forge The three `Tracked in issues labelled X` links now point at the forge's issue list, which 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 (`~/.git-credentials` and `~/.tx-forge-token` both 403 on `/issues`). A wrong link is worse than none, and asserting a mapping I cannot check is how this file reached this state. ### It also promised something it had done for 3 of 22 standards > *"This document records the scope of each protocol — the capabilities included and the capabilities being added."* Rather than write 19 scope paragraphs by paraphrasing READMEs — a second copy that would drift exactly as the facts above did — the file now **indexes** all 22 standards, each linking to its own `README.md` and `SPEC.md` as the source of truth. The four sections carrying real Included / Adding content keep it and are marked as such in the index. ### Checks - Every `README.md` and `SPEC.md` path was asserted to exist *before* being written (5 standards have no `SPEC.md`; those rows link README only). - All **44 relative links** in the file resolve. - Guards clean: comparative prose (4104 files), vanity metrics (523 Markdown files), spec refs (1966 citations across 17 standards, all resolve), orphan sources. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
mesh/1 can bind what taught the weights, not only which weights answered
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 7s
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
Details
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 53s
Details
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m7s
Details
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m41s
Details
1c8cac9e7d 
§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]>
INGEST.md said 1.95.0, an MSRV policy that does not exist, and 12 links to the wrong forge
Some checks failed
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m16s
Details
standards workspaces build + test / which workspaces this change touches (pull_request) Has been cancelled
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been cancelled
Details
638189cae6 
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 <[email protected]>
The links had nothing on the other side, and wai-verify pins no toolchain
All checks were successful
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m43s
Details
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
Details
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m29s
Details
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 44s
Details
2aa14ab337 
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 <[email protected]>
dcharlot closed this pull request 2026-11-04 21:20:51 -05:00
All checks were successful
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m43s
Details
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
Details
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
Details
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m29s
Details
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 44s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!617
No description provided.