wai: the record made true #201

Merged

dcharlot merged 17 commits from wai/d1-record-true into main 2026-10-11 16:58:41 -04:00

Conversation 0 Commits 17 Files changed 37 +941 -88

dcharlot commented 2026-10-09 14:31:41 -04:00

Owner

Copy link

Makes WAI's own record match its code, adds the protected-content lanes and the reader limits, and adds wai/SECURITY.md.

What changed

1. The QAT claim. SPEC §5 and determinism-tiers §5 said wai.neural.int_synth decodes "QAT weights". No committed model was trained that way. The trained corpus vector came from tools/wai_int_synth_real.py: float training, then post-training quantisation with each layer's shift derived from its measured activation range. The synthetic vectors' weights are generated from a seed. Both texts, the capability comment, the module doc and a test comment now say this. tools/wai_int_synth_qat.py is now marked experimental: it trains against one fixed shift and no committed model came from it. tools/wai_int_synth_export.py names the working path. I also searched for "QAT", "quantization-aware" and "trained in integer" across the tree and checked each hit against its training tool. The other int_* codecs and JPEG AI were already described as post-training quantised. ternary-tt compared itself to QAT, and now compares itself to int_hyper instead.

2. Stale paths.

• SPEC §5 named neural/int_synth.rs; the file is int_synth.rs at the crate root.
• quantum-ops named wai-rs/src/quantum_ops.rs; it lives in wai-quantum.
• quantum-sim gave quantum_receipt a feature list it no longer has.
• README and SPEC Appendix A pointed to a committed .cargo/config.toml that does not exist; build.rs finds libFLAC.

The section-refs check was already green. A scan of every relative link and backticked path in the WAI texts found these and nothing else stale.

3. SPEC §6.5, "Protected content: two lanes" (normative).

• Lane A, hardware-protected content. The media is decrypted and decoded inside the platform's protected media path. This revision registers no security.encryption value for it. WAI attests only its records about such a title: the served manifest, the segment map, the key-release decisions and the content hashes of WAI objects. None of them covers a decoded frame. Parametric synthesis is allowed only inside a decoder the protection system certifies, and it gets no tier and no output digest.

• Lane B, mls-sframe. The application decrypts, so every record and tier applies as it does to plaintext. The section states that Lane B is not a protected-path robustness level and must not be offered for a licence term that requires one.

• Tier scope. determinism-tiers §5 gains a subsection on where decode-equivalence holds:

  • native CPU;
  • wasm32: the CI job passed on main at 412a08c5, and the release build validates with SIMD and relaxed-SIMD disabled;
  • no GPU or NPU decoder.

  A WebAssembly decoder at the tier uses no relaxed-SIMD instruction and depends on no NaN's bits. The tier never covers output a sink cannot read.

• Pointers. The wai.video.keys row and the confidentiality extension now say which lane they belong to.

4. Reader limits and wai/SECURITY.md.

• The gap. Nothing bounded man_len. For eight bytes declaring u32::MAX, parse_head asked for 4 GiB (and so did http_verify.py).

• SPEC §2 Reader limits. No reader refuses a manifest for its size or nesting within 2²⁷ bytes (128 MiB) and 127 levels. Any reader may refuse one past those limits. A refusal for length comes from man_len alone (manifest_too_large). The layout does not change, and the §8 freeze stands.

• Why 2²⁷. The limit holds the largest manifest a conforming staged layer has. A WIR1 layer covers up to 2²⁰ units, and a prev with one run per unit is about 94 MB. The first gate run falsified a 1 MiB limit: staged_resources.rs writes a 1.47 MB layer manifest, which that extension permits.

• wai-rs. MANIFEST_MAX_LEN is enforced by:

  • both readers;
  • manifest_bytes;
  • parse_head (head_malformed);
  • both writers, which stop serialising as soon as the manifest passes the limit, and wai-web's pack and packMulti.

  The writers also refuse a payload whose length does not fit its u32 field; before, they wrote it modulo 2^32. include/wai.h gains the constant.

• Python verifiers. staged_verify.py, claim_verify.py, pack_verify.py and http_verify.py apply the same length limit.

• SECURITY.md covers:

  • how to report a vulnerability;
  • every bound the manifest readers apply, where each is specified, and which tests check it;
  • the native codec libraries, which run in-process with no sandbox, and two gaps stated as gaps: wai.text.zstd and wai.text.xz decompress with no output bound, and the fuzz smoke test is in no CI workflow;
  • module authorisation, and the module runtime environment that is not yet specified;
  • the fingerprinting risk of held_sets, pointing at the privacy rules still to come.

Tests, falsified once

• container::tests::a_manifest_past_the_reader_limit_is_refused_and_never_written, for both readers and manifest_bytes, from eight bytes:

  • at the limit, refused only as truncated;
  • one past it, or u32::MAX, refused as too large.

  A 2 MiB manifest round-trips byte for byte. The writers' capped serialiser accepts a manifest at a limit equal to its length and refuses it one byte below. Serialising 128 MiB takes a debug build about 17 s, so the real-size writer check is in verify_pack.mjs.

• http_binding::tests::head_parse_refuses_a_manifest_past_the_reader_limit.

• container::tests::a_manifest_nested_past_127_is_refused: pins the existing nesting limit (127 read, 128 refused).

• container::tests::a_length_past_a_u32_field_is_refused.

• verify_pack.mjs (the wasm job): pack and packMulti write a 3 MiB manifest and refuse one byte past 2²⁷ (3.6 s, 340 MB locally).

Each falsification was run after a commit:

• Disabling check_manifest_len failed both limit tests.
• Disabling the capped serialiser failed the container test.
• Making u32_field truncate failed its test.
• Removing the bound from wasm pack failed verify_pack.mjs.
• On main's Python, read_wai1 read the over-limit manifest.

Each was restored through git and passes. Every changed Python verifier passes its corpus as CI runs it.

Checks

• Gate: gate.sh d1 is GREEN on the head: build, lib tests, carriage, the corpus loop, fast kernels, byte-exact, wasm32 check and the neural gates. The first run was RED on staged_resources and falsified the 1 MiB limit (see above).
• check-public-names.sh and check-comparative-prose.sh, file by file, on every changed file. The only prose hits are in CHANGELOG history that main already has, and the check's default scope excludes that file.
• check-wai-section-refs.py, check-workflow-concurrency.sh and check-no-vanity-metrics.sh: green.

For the owner

• The reporting address, [email protected], is the one the repository's sandbox standard already gives. Whether that mailbox is monitored was not checked: please confirm it, or replace it.
• The site's roadmap line "two DRM lanes" now has a SPEC section to point to. The site is a separate repository and is unchanged here.
• Not in this PR, each named in SECURITY.md or the direction notes:
  • an output bound for zstd and xz decode, which needs a chosen limit;
  • fuzzing in CI;
  • the module runtime specification;
  • the held_sets privacy rules, a follow-up to the HTTP receipts work;
  • a CI scan of the wasm opcodes.

🤖 Generated with Claude Code

Makes WAI's own record match its code, adds the protected-content lanes and the reader limits, and adds `wai/SECURITY.md`. ## What changed **1. The QAT claim.** SPEC §5 and determinism-tiers §5 said `wai.neural.int_synth` decodes "QAT weights". No committed model was trained that way. The trained corpus vector came from `tools/wai_int_synth_real.py`: float training, then post-training quantisation with each layer's shift derived from its measured activation range. The synthetic vectors' weights are generated from a seed. Both texts, the capability comment, the module doc and a test comment now say this. `tools/wai_int_synth_qat.py` is now marked experimental: it trains against one fixed shift and no committed model came from it. `tools/wai_int_synth_export.py` names the working path. I also searched for "QAT", "quantization-aware" and "trained in integer" across the tree and checked each hit against its training tool. The other `int_*` codecs and JPEG AI were already described as post-training quantised. `ternary-tt` compared itself to QAT, and now compares itself to `int_hyper` instead. **2. Stale paths.** - SPEC §5 named `neural/int_synth.rs`; the file is `int_synth.rs` at the crate root. - quantum-ops named `wai-rs/src/quantum_ops.rs`; it lives in `wai-quantum`. - quantum-sim gave `quantum_receipt` a feature list it no longer has. - README and SPEC Appendix A pointed to a committed `.cargo/config.toml` that does not exist; `build.rs` finds libFLAC. The section-refs check was already green. A scan of every relative link and backticked path in the WAI texts found these and nothing else stale. **3. SPEC §6.5, "Protected content: two lanes"** (normative). - **Lane A, hardware-protected content.** The media is decrypted and decoded inside the platform's protected media path. This revision registers no `security.encryption` value for it. WAI attests only its records about such a title: the served manifest, the segment map, the key-release decisions and the content hashes of WAI objects. None of them covers a decoded frame. Parametric synthesis is allowed only inside a decoder the protection system certifies, and it gets no tier and no output digest. - **Lane B, `mls-sframe`.** The application decrypts, so every record and tier applies as it does to plaintext. The section states that Lane B is not a protected-path robustness level and must not be offered for a licence term that requires one. - **Tier scope.** determinism-tiers §5 gains a subsection on where `decode-equivalence` holds: - native CPU; - wasm32: the CI job passed on main at `412a08c5`, and the release build validates with SIMD and relaxed-SIMD disabled; - no GPU or NPU decoder. A WebAssembly decoder at the tier uses no relaxed-SIMD instruction and depends on no NaN's bits. The tier never covers output a sink cannot read. - **Pointers.** The `wai.video.keys` row and the confidentiality extension now say which lane they belong to. **4. Reader limits and `wai/SECURITY.md`.** - **The gap.** Nothing bounded `man_len`. For eight bytes declaring u32::MAX, `parse_head` asked for 4 GiB (and so did `http_verify.py`). - **SPEC §2 *Reader limits*.** No reader refuses a manifest for its size or nesting within 2²⁷ bytes (128 MiB) and 127 levels. Any reader may refuse one past those limits. A refusal for length comes from `man_len` alone (`manifest_too_large`). The layout does not change, and the §8 freeze stands. - **Why 2²⁷.** The limit holds the largest manifest a conforming staged layer has. A `WIR1` layer covers up to 2²⁰ units, and a `prev` with one run per unit is about 94 MB. The first gate run falsified a 1 MiB limit: `staged_resources.rs` writes a 1.47 MB layer manifest, which that extension permits. - **wai-rs.** `MANIFEST_MAX_LEN` is enforced by: - both readers; - `manifest_bytes`; - `parse_head` (`head_malformed`); - both writers, which stop serialising as soon as the manifest passes the limit, and `wai-web`'s `pack` and `packMulti`. The writers also refuse a payload whose length does not fit its u32 field; before, they wrote it modulo 2^32. `include/wai.h` gains the constant. - **Python verifiers.** `staged_verify.py`, `claim_verify.py`, `pack_verify.py` and `http_verify.py` apply the same length limit. - **`SECURITY.md` covers:** - how to report a vulnerability; - every bound the manifest readers apply, where each is specified, and which tests check it; - the native codec libraries, which run in-process with no sandbox, and two gaps stated as gaps: `wai.text.zstd` and `wai.text.xz` decompress with no output bound, and the fuzz smoke test is in no CI workflow; - module authorisation, and the module runtime environment that is not yet specified; - the fingerprinting risk of `held_sets`, pointing at the privacy rules still to come. ## Tests, falsified once - `container::tests::a_manifest_past_the_reader_limit_is_refused_and_never_written`, for both readers and `manifest_bytes`, from eight bytes: - at the limit, refused only as truncated; - one past it, or u32::MAX, refused as too large. A 2 MiB manifest round-trips byte for byte. The writers' capped serialiser accepts a manifest at a limit equal to its length and refuses it one byte below. Serialising 128 MiB takes a debug build about 17 s, so the real-size writer check is in `verify_pack.mjs`. - `http_binding::tests::head_parse_refuses_a_manifest_past_the_reader_limit`. - `container::tests::a_manifest_nested_past_127_is_refused`: pins the existing nesting limit (127 read, 128 refused). - `container::tests::a_length_past_a_u32_field_is_refused`. - `verify_pack.mjs` (the wasm job): `pack` and `packMulti` write a 3 MiB manifest and refuse one byte past 2²⁷ (3.6 s, 340 MB locally). Each falsification was run after a commit: - Disabling `check_manifest_len` failed both limit tests. - Disabling the capped serialiser failed the container test. - Making `u32_field` truncate failed its test. - Removing the bound from wasm `pack` failed `verify_pack.mjs`. - On main's Python, `read_wai1` read the over-limit manifest. Each was restored through git and passes. Every changed Python verifier passes its corpus as CI runs it. ## Checks - Gate: `gate.sh d1` is **GREEN** on the head: build, lib tests, carriage, the corpus loop, fast kernels, byte-exact, wasm32 check and the neural gates. The first run was RED on `staged_resources` and falsified the 1 MiB limit (see above). - `check-public-names.sh` and `check-comparative-prose.sh`, file by file, on every changed file. The only prose hits are in CHANGELOG history that main already has, and the check's default scope excludes that file. - `check-wai-section-refs.py`, `check-workflow-concurrency.sh` and `check-no-vanity-metrics.sh`: green. ## For the owner - The reporting address, [email protected], is the one the repository's sandbox standard already gives. Whether that mailbox is monitored was not checked: please confirm it, or replace it. - The site's roadmap line "two DRM lanes" now has a SPEC section to point to. The site is a separate repository and is unchanged here. - Not in this PR, each named in `SECURITY.md` or the direction notes: - an output bound for zstd and xz decode, which needs a chosen limit; - fuzzing in CI; - the module runtime specification; - the `held_sets` privacy rules, a follow-up to the HTTP receipts work; - a CI scan of the wasm opcodes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 7 commits 2026-10-09 14:31:41 -04:00

wai: int_synth's weights are quantised after float training, and two engine paths moved ... 08b1568291

SPEC §5 and determinism-tiers §5 said `wai.neural.int_synth` decodes "QAT
weights". No committed model was trained that way. The trained corpus vector was
made by `tools/wai_int_synth_real.py`: float training, then post-training
quantisation with each layer's shift derived from its measured activation range,
the recipe `tools/wai_int_synth_train.py` documents. The synthetic vectors' weights
are generated from a seed. Both texts, the capability constant's comment, the
module doc and a test comment now say that.

`tools/wai_int_synth_qat.py` said it "closes the one open gap" and tunes "the
weights AND the shifts"; it trains the weights against one fixed shift and made no
committed model, and it now says so. `tools/wai_int_synth_export.py` told users to
train with QAT upstream; it now names the working path.

Stale paths: the int_synth decoder is `int_synth.rs` at the crate root, not
`neural/int_synth.rs` (SPEC §5, the export tool, the capability comment); the
quantum-ops engine is `wai-quantum/src/quantum_ops.rs`, and the quantum-sim
receipt's feature is `quantum_receipt` of `wai-quantum`, which `wai-rs` forwards,
not `["quantum", "world"]`.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: SPEC §6.5, protected content in two lanes, and where the exact tier holds ... ce4646278f

A new normative section names the two lanes protected content travels in, and
what a WAI record covers in each.

- Lane A, hardware-protected content: a standard codec decrypted and decoded inside
  the platform's protected media path. This revision registers no
  `security.encryption` value for it, so no WAI envelope carries Lane A media. WAI's
  records about such a title (the served manifest, the package's segment map, the
  key-release decisions, the content hashes of WAI objects) are all it attests; none
  covers a decoded frame. Parametric synthesis applies only inside a decoder the
  protection system certifies, with no tier and no output digest.
- Lane B, end-to-end encryption at the application layer (`mls-sframe`): the
  application decrypts and any decoder runs, so every record and tier applies as to
  plaintext. It is stated not to be a protected-path robustness level: a publisher
  must not offer it for a licence term that requires one.
- The exact tier covers only output a sink can hash. determinism-tiers §5 gains a
  subsection listing the fabrics `decode-equivalence` is shown on in this revision
  (native CPU; wasm32, whose CI job passed on main at 412a08c5), none on GPU or NPU,
  forbids relaxed-SIMD instructions and NaN-bit dependence in a Wasm decoder at the
  tier, and rules out any tier, digest or binding for protected-path output.

The `wai.video.keys` row and the confidentiality extension now say which lane they
belong to.

Two more stale references: README and SPEC Appendix A sent macOS builders to a
committed `.cargo/config.toml` that no longer exists; `wai-rs/build.rs` finds libFLAC
through pkg-config, then the Homebrew prefix.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: a reader need hold no manifest past 1 MiB, and the writers never write one ... 30a15bad94

`man_len` is a u32, and nothing bounded it: a reader trusted it up to the bytes in
hand, and the HTTP head parser answered a `man_len` of 4 GiB by asking for
4 GiB + 12 bytes. The reference now sets a reader limit:

- `container::MANIFEST_MAX_LEN` is 1 MiB (1 048 576 bytes), far above any manifest in
  the committed corpora. `check_manifest_len` refuses a longer one with
  `manifest_too_large`, from the length field alone, before anything is sliced.
- Both readers (`Wai::from_bytes`, `WaiMulti::from_bytes`), `manifest_bytes` and
  `http_binding::head::parse_head` (as `head_malformed`) apply it.
- Both writers, and the browser crate's `pack` and `packMulti`, refuse to write a
  manifest past it, so the reference never emits what its reader refuses.
- The writers also refuse a payload whose length does not fit its u32 field;
  `Wai::to_bytes` and `WaiMulti::to_bytes` wrote such a length modulo 2^32.
- `include/wai.h` gains the constant, as cbindgen writes it.

Tests: at the limit both containers read and write back byte for byte; one byte
past it, or a declared u32::MAX, is refused by every reader from the first eight
bytes, and neither writer writes it; the head parser refuses it instead of asking
for it. The manifest's nesting limit, which the JSON reader already applied, is
now pinned: 127 levels read, 128 refused, in WAI1 and WAI2 manifests.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: the Python verifiers apply the same manifest reader limit as wai-rs ... 027dca6dc5

The stdlib verifiers already copy the reference reader's nesting limit, so that two
readers agree on an envelope. They now copy its length limit too:
`staged_verify.MANIFEST_MAX` (1 MiB) is refused by `read_wai1` and `read_wai2`, by
`claim_verify.wai2_read`, by `pack_verify.read_envelope`, and by
`http_verify.parse_head` as `head_malformed` before it asks for the head.

Checked: every changed verifier passes its corpus as CI runs it (pack, staged,
http, staged-measure, claim). A manifest of exactly 1 MiB is read by each reader
and one byte more refused, as wai-rs does. On main, `read_wai1` read the longer one
and `parse_head` answered eight bytes declaring u32::MAX by asking for 4 GiB.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: SECURITY.md, and SPEC §2's reader limits stated as rules ... 6c3abb1530

`wai/SECURITY.md` is engineering notes, not normative text:

- how to report a vulnerability: [email protected], the address the
  repository's sandbox standard already gives, and what to send;
- manifest parsing: every bound the readers apply, with where it is specified and
  which tests check it, including the Python verifiers' share of them;
- the native codec libraries behind the `codecs` and `neural` features, that they run
  in-process with no sandbox, what does not touch them, and two gaps stated as gaps:
  `wai.text.zstd` and `wai.text.xz` decompress without an output bound, and the
  random-input smoke test is in no CI workflow;
- module authorisation (SPEC §4, jwp-receipts §7.9) and what it does not yet cover:
  the environment a module runs in;
- the fingerprinting risk of `held_sets`, pointing at the privacy rules still to be
  written for http-delivery.

SPEC §2 gains *Reader limits*: no reader refuses a manifest for its size or nesting
within 1 MiB and 127 levels, any reader may refuse one past them, and a refusal for
length comes from `man_len` alone (`manifest_too_large`). The container layout does
not change. http-delivery §7 step 3 and the WAI2 packer rule point at it.

`verify_pack.mjs`, which the wasm job runs, now checks that `pack` and `packMulti`
write a manifest of exactly 1 MiB and refuse one byte more; it passes against a
release wasm32 build of this source. That build also validates with WebAssembly's
SIMD and relaxed-SIMD features disabled (a control with bulk memory disabled fails),
which determinism-tiers §5 now records in place of a claim about build flags.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: CHANGELOG for the record made true ... b0bdea2949

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: the manifest reader limit is 2^27, the largest manifest a staged layer has ... 07e923c724

The gate falsified the 1 MiB limit: `tests/staged_resources.rs` offers layers over
up to 65 536 units whose `refines.prev` names a different producer for each unit,
and the writer refused its 1.47 MB manifest. staged-delivery §3 permits that: a
`WIR1` layer covers up to 2^20 units, and a `prev` with one run per unit is about
90 bytes a run, some 94 MB in all. A reader floor below that would let a sink
refuse layers the extension allows.

`MANIFEST_MAX_LEN` is now 2^27 (134 217 728 bytes), which holds that layer, and SPEC
§2 states why. The Python verifiers use the same bound.

The writers now serialise through a capped writer that stops as soon as the
manifest passes the limit, so a refused manifest is never built in full. Serialising
128 MiB takes a debug build about 17 s, so the tests check the writers' cap at a
small limit, and the readers' boundary from the length field: at the limit a reader
refuses eight bytes only as truncated, one past it as too large. A 2 MiB manifest,
past the old bound, round-trips byte for byte. `verify_pack.mjs` checks a 3 MiB
manifest written and one byte past 2^27 refused by the browser writers.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 6 commits 2026-10-09 17:19:48 -04:00

wai-rs: test the writers' limits through the writers ... 4961fccf1e

The test named for the writers called manifest_json_within and u32_field
directly and never called Wai::to_bytes or WaiMulti::to_bytes, so putting
serde_json::to_vec and `as u32` back in both writers left every test green.
Both writers now run to_bytes_within(WriteLimits), and to_bytes passes
SPEC's limits. The test writes each envelope at limits equal to its
manifest's and payloads' lengths, and requires manifest_too_large one byte
below the manifest, the field error one byte below a payload, and the sum
error when two payloads each fit and their total does not.

MANIFEST_MAX_LEN's doc cites staged-delivery Appendix A.3 for the 2^20-unit
cap (section 3 bounds a count only by 32 bits), and says the limit bounds
the bytes read, not the memory a parse takes. wai.h regenerated.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: the HTTP corpus holds the manifest reader limit at its edge ... 010ee79b28

No case reached the new limit: with the check deleted from
http_verify.parse_head, every case still gave its outcome, and no committed
envelope declares a man_len past 2^27. Four parse_head cases now do, on a
WAI1 (O5) and a WAI2 (OD): eight bytes declaring 2^27 + 1 are refused
(head_malformed), and eight declaring 2^27 ask for the head they declare
(need 134217740 and 134217738). Both implementations give all four.

falsify/manifest-limit-dropped.patch drops the check from head::parse_head,
and http_verify.py --mutate manifest-limit-dropped drops it on the Python
side; run.sh runs both.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: the Python verifiers check their manifest reader limit in memory ... 55df2cdc2c

In staged_verify, claim_verify and pack_verify the man_len check is
outcome-neutral for any input under 128 MiB: the bounds check after it
refuses the same bytes. No corpus file is that large, so nothing exercised
it. Each verifier now builds, in memory, a WAI1 and a WAI2 (claim_verify:
the WAI2 its wai2_read reads) whose manifest is padded to 2^27 + 1 bytes
by a member no revision defines, and requires it refused, and requires the
same envelope with a 300-byte manifest read, so only the limit tells the
two apart. pack_verify builds its own envelopes, as it shares no code.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web: pack and packMulti refuse a payload past its u32 field ... 2e398cde86

SECURITY.md and the CHANGELOG named wai-web's writers among those that
refuse a payload whose length does not fit its u32 field, but they still
wrote `payload.len() as u32` and `p.len() as u32`; packMulti's checked_add
caught only a total that overflows, and the claim held only because usize
is 32 bits on wasm32. Both now convert with u32::try_from, as wai-rs's
writers do, and name the payload that does not fit.

verify_pack.mjs: the refused manifest is 2^27 + 1 bytes, one past the
limit; the comment read as if it were 2^27.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

check-wai-section-refs: read wai/SECURITY.md too ... ddd49ee03d

SECURITY.md cites sections of SPEC, http-delivery, integer-payloads and
jwp-receipts, and nothing checked them: the checker read only SPEC.md and
extensions/*.md, and the workflow's paths left SECURITY.md out. It reads
SECURITY.md now, and the workflow runs when it changes. Every reference in
it resolves; a reference to http-delivery §66 put in by hand fails the
check. CHANGELOG.md stays out: it is a dated record whose older references
are kept as written.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: SECURITY.md, SPEC §2 and §6.5 say what holds ... 59ab0d9489

SECURITY.md:
- "Allocation follows the input" was false for the manifest. The reference
  readers parse it into serde_json::Value; measured on the release build,
  a 94 MB prev of 2^20 runs peaks at about 7 times its length and a
  134,217,000-byte array of zeros at about 38 times (5.1 GB RSS, 7.6 s in
  from_bytes, which returned Ok). The text now says so, and the argument
  that a sink short of that memory could not decode such layers either is
  gone.
- CI does link ONNX Runtime and libzstd: wai-neural-gates.yml and
  wai-neural-e2e.yml build `neural`. No workflow builds `codecs`.
- No Kani harness is in int_kernels.rs; the harnesses are in rans.rs,
  int_entropy.rs, int_transform.rs, wai_video_policy.rs, staged/predict.rs
  and staged/wir1_arith.rs. Its SIMD kernels, the only unsafe outside the
  C ABI, are held to the scalar kernels by equality tests, not by a model
  checker.
- The bare "(§5.1)" names http-delivery; the writer test is described as
  it now runs; the Python verifiers' checks are described as they now run.

SPEC §2: the 2^20-unit cap is staged-delivery Appendix A.3's (section 3
bounds a count only by 32 bits); the limit bounds what a reader reads, not
the memory its parse takes; the paragraph is reflowed.

SPEC §6.5: Lane A's records are "among them", and include wai.video.ssai
and wai.video.channel. Lane B no longer says every record applies:
staged-measurement counts no encrypted object, and a verifier without the
key checks no payload-dependent rule of a reconstruct-session claim
(jwp-receipts §2.4.12 rule 3); nothing in the reference states a Lane B
tier. The confidentiality header and the CHANGELOG say the same.

SPEC §5 and determinism-tiers §5: only `photo` comes from a trained model;
gradient, bloom, facade and the cross-architecture golden use seeded
integer weights, as the CHANGELOG said both texts did.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 23 commits 2026-10-10 22:23:54 -04:00

wai: wai generate and wai score build|render, with native pins a sink checks against ... a220d16a48

`wai generate` makes a wai.generate.spectral picture with the reference generator at
any size and prints its SHA-256; with --instr it makes a listed size of an instruction
object of form v0, which it reads as a sink does, and --write-instr writes one.
`wai score build` writes a WSCR from integer note fields only; `wai score render`
prints samples, pcm_sha256, mixdown_blake3 and score_hash, and --pcm writes the samples.

Vectors: tests/vectors/generate/sizes.json (256x128, 640x320) and instr-v0.json (the
object, its four listed sizes and 28 objects a sink refuses); score-conformance gains
pcm_sha256 for every vector and notes/<name>.json, the authoring form, which
`wai score build` turns back into the committed WSCR byte for byte. Every pin was made
natively and equals the shared browser binding's output.

`wai wrap` refuses a wai.generate.spectral payload that is not a form-v0 object, in
every build. No library source changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai SPEC §5: the payload of wai.generate.spectral is an instruction object (form v0) ... 3770d1ab8e

The registration is completed as §8 permits: the row named the generator and no byte
layout. The payload is one canonical JSON object naming the model by its SHA-256 and
giving the prompt, the seed, the steps and every size a sink makes, each within stated
bounds and with one serialization per object, so an envelope's content hash names the
instructions. A sink makes only listed sizes, with that model only; conformance is
generation-equivalence at each listed size, and a sink holding a size's SHA-256 does
not present a picture that differs or accept one on a 64-bit FNV-1a alone. The
envelope's intent is `create`: a generator does not back `replicate` (§7), and this
keeps that rule.

The registry row names the payload; §8 lists the completion. score §2.3 documents the
integer authoring form `wai score build` reads, and §4 the pcm_sha256 every vector now
states. CI builds the `wai` binary with `generate` and `score` in both profiles of the
integer-kernel steps and runs tests/cli_generate_score.rs there; the two larger listed
sizes of instr-v0.json run in the release step.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai cli tests: the two instr_sizes callers each write their own object file ... 35debe1706

instr_makes_the_listed_small_sizes and instr_makes_the_listed_large_sizes run at
once in the release step, and both removed and rewrote one scratch file,
object.instr, while the other's `wai generate --instr` children read it. A remove
or a truncating write landing as a child opened the file would refuse the object
and fail the test. Each caller now names its own file.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai cli tests: the note-count guard is what refuses the crafted WSCR ... 0d123ab7f2

score_render_refuses_a_note_count_its_bytes_cannot_hold wrote a file with no
contract section, so the reader refused it with MissingSection(0x01) before
parse_notes reserved anything, guard or no guard: the test checked only which
message came first. The file now carries a well-formed contract (section 0x01) and
a notes section of only the count (0x02), and the same file declaring no notes is
shown to render, so without the guard the reader reaches Vec::with_capacity.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai score render: refuse a contract that is not one channel of wai.det.fixed64 ... 887c99a61f

render printed "channels":2 beside a mono mixdown of `duration` samples when a WSCR's
contract said two channels, and rendered a contract whose numeric profile was
wai.det.float64; a verifier following SPEC §7 Digests would read that PCM as stereo
frames. render now refuses both, as build refuses to write them.
score_render_refuses_a_contract_it_does_not_render patches the committed scale.wscr
in place for each case.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai score build: refuse a member given twice in the authoring form ... 95fa7244f6

The authoring form (score §2.3) is the definition, yet a note holding both
"start":0 and "start":5 built with start 5 (serde_json keeps the last value) and
the same hash as a note with start 5 alone; another JSON reader could keep the
first. wai_cli/strict_json.rs reads JSON with every object's members distinct and
refuses a repeat, and build reads its document through it. Two refused cases are
added: a note field and a document member, each given twice.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai generate.spectral form v0: accepted objects at every bound, and each refusal's reason ... f0107b07b8

instr-v0.json had one accepted object and 28 refused ones, none at an inclusive
bound, so a second sink stricter by one passed every vector; and the CLI test held
only that each object was refused, not why, so a rule relaxed (a quotation mark let
into the prompt) stayed green while the canonical-bytes check refused the object
in its place.

- The reader (wai_cli/instr.rs) refuses with a reason code, the first rule broken
  in a stated order; a member given twice is refused as such (strict_json).
- The vector gains twelve accepted objects (seed 0 and 2^32 - 1, steps 1 and 64,
  an empty prompt, 256 bytes, 0x20 and 0x7e, JSON's structural characters, a side of
  1, a side of 4096 and 2^23 pixels, 16 sizes, the w-then-h order), each with the
  SHA-256 of its first listed size made natively; eight more refused objects (types,
  a fraction in a size, a negative side, an escaped line feed, a backslash, cut-short
  JSON); and a reason for every refused object.
- tests/cli_generate_score.rs asserts each refusal's reason through `wai generate
  --instr` and `wai wrap`, and makes and wraps every accepted object.
- tests/generate.rs states form v0 a second time, independently of the reader, and
  holds the object, the accepted and the refused lists to it, making each accepted
  object's output with the library.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai generate.spectral: the generator's envelope carries intent create, and wrap writes no other ... da03ef1524

SPEC §5 said the envelope's intent is `create`, but `wai wrap` refused only
`replicate` and wrote wai.generate.spectral envelopes with `--intent improve` or
`--intent banana`, and the non-conforming list did not mention intent. The
sentence is now a rule: an envelope that names the generator, as capability or
fallback, carries `create`, one with another intent is non-conforming, and wrap
refuses any other. wrap_writes_the_generator_only_with_intent_create covers
improve, an open string, a case variant, the empty string and the fallback.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai generate.spectral: the model is the parameter set, so the envelope carries no pin; inspect and unwrap report the payload ... 7e3b883074

Form v0 names the model inside the payload by the SHA-256 of one file, and SPEC §5
never said how that relates to §3.1's parameter-set pin, which governs every
GenerativeDeterministic capability: whether a generate envelope carries a pin, or
which wins when a pin and `model` disagree. The library registers the set as
several files, so a form-less pin over the very file `model` names would be
refused form_required. SPEC §5 now states the relation: the model file is the
parameter set and `model` its identity; an envelope that names the generator
carries no `prior` and a sink refuses one that does, whatever it names. §3.1 says
so beside the pin rules, the non-conforming list names it, and prior-carriage §7's
row says the set is never pinned and names the file. No library source changes.

`wai inspect` and `wai unwrap` reported a generate envelope with a corrupt
payload as conforming ("component roles ✓", no payload line). They now report
the payload (form v0, with the reader's reason), the intent and any pin of every
envelope or WAI2 component that names the generator, ✓ or ✗; inspect's verdict
says the envelope does not conform. inspect_and_unwrap_report_the_generators_envelope
covers a prompt byte changed in place, the intent improve, a pin over the model
file itself, and a WAI2 component with and without a pin.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai REGISTRY: the status note names wai.generate.spectral among the registrations v0.4.0 completes ... cdc351b33c

The hand-written Status note listed the integer codecs whose registrations v0.4.0
completes and left out wai.generate.spectral, which SPEC §8 now says §5 completes.
The note sits outside the generated region the library test compares.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web wasm32 CI: the browser generator and score synth make every native pin ... 4c09bea76a

The CHANGELOG said every pin equals the shared browser binding's output, and the
browser sink's form-v0 reading has no CI of its own, yet wai-web-wasm.yml ran no
generate or score check. demo/verify_generate_wasm.mjs runs generateSpectral at
every size the generate vectors pin (sizes.json, instr-v0.json's four listed sizes,
and the first listed size of each object at a bound of form v0), checks each
object names the committed model, and runs ScoreSink over every score-conformance
vector for its pcm_sha256, mixdown hash and score hash. The workflow runs it on the
node build and now also triggers on wai/score-conformance/. 35 checks pass locally
on a wasm32 build of this tree.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web: reach builds — L1 legalised, L2 MVP-lowered, J wasm2js, and an ES5 loader ... c4e592cfa4

The shipped wai-web package needs WebAssembly with sign-extension, non-trapping
float-to-int and bulk memory, and i64 crossing the JS boundary as BigInt.
reach/build.sh derives three more builds from that package with pinned tools
(binaryen version_123 by archive SHA-256; TypeScript, esbuild and acorn by
package-lock.json):

- L1: the shipped binary legalised at the JS interface, for engines where i64
  does not cross as BigInt;
- L2: MVP-lowered and legalised, at four profiles (full, verify_decode, verify,
  receipt), for MVP-only WebAssembly;
- J: the wasm2js translation, one ES5 script per profile, with an ES5-floor
  runtime and glue: memory views refreshed when the buffer changes, i64 values
  carried as Numbers where there is no BigInt.

wai-load.js (ES5) picks shipped, L1, L2 or J from feature probes alone and
says why; a rung can be forced for testing.

test/conformance.js (ES5) runs the workloads over the repository's corpora on
any rung and compares every output with the shipped build's; run-modern.mjs
forces every rung and profile on a modern Node and runs the demo verify
scripts against each full build.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: the recorded manifest, the README, the CHANGELOG, and CI on the engine lines ... bf7c61ff0b

reach/manifest.json is the build of the package the site serves (wai_web_bg.wasm
0063129a..., wai_web.js f63605f0...); given that package, build.sh refuses any
output whose SHA-256 differs. The manifest records where the package came from.

wai-web-reach.yml (linux runner) builds wai-web from the tree with the web target,
runs build.sh and run-modern.mjs on it, then runs conformance.js in one Node image
per engine line: node:0.12 (J), node:8.0.0 (J, and the L2 receipt build),
node:8 and node:10 (L2), node:12 and node:14 (L1). Each must be given its rung by
the loader's probes, and every output must equal the shipped build's. The README
says which device classes each image stands for, and that no real old device has
been run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: the i64 workload crosses a low half with its top bit set ... 2c5f382492

2^32 + 2^31 goes in as a parameter and comes back as a result, so the Number
path (no BigInt) is tested where the low half's sign bit matters.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: direct i64 results with a high low half; the shipped wasm streams in browsers ... 3f26fab1f4

The runtime's falsification (an i64 result's low half read as signed where there
is no BigInt) passed every workload: op_lamport returns its u64 through memory,
not as an i64 result, so no workload returned an i64 whose low half has its top
bit set. quantizeScale(0.75, 32) and (1.5, 32) now do, with a zero and a
non-zero high half.

For the shipped rung a browser now hands the glue the wasm URL, so the module
compiles while it downloads; a host that reads files still hands it the bytes.
The recorded manifest changes for wai-load.js only.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

ci(wai-web-reach): build the package outside the tree ... 07ee78d414

The wasm-bindgen glue is an ES module in a .js file. Under wai/wai-web/reach/ the
nearest package.json (the build tools' pins) has no "type", so Node would read
the glue as CommonJS first. In $RUNNER_TEMP no package.json applies; only the
reach build and the reference, which the engine images read, stay in the
workspace.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

ci(wai-web-reach): gate the build on the pull request's own diff ... b77b332d3d

A rebase's push delta fires every path-filtered workflow; the reach job builds
wai-web and runs six engine images, so it now runs only when
scripts/pr-touches-paths.py says the pull request touches its paths (failing
open, and always on main), as wai-pack does.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: CI holds the served bytes to the manifest; the package of record kept in-tree ... df9d349d92

The reach builds' byte-identity rested on local runs: CI built wai-web from the tree,
which can never be the package the site serves, so build.sh took its "not the recorded
input" branch and the recorded outputs were never checked there.

- reach/record/ keeps the package of record: the two files the site serves under
  /wai/pkg/. It is rebuilt from wai/wai-web at 248846f1 with the site's recipe, which now
  also remaps the standard library's sources in the toolchain to /rustc/<the compiler's
  commit>: the old remap kept the toolchain's folder, named after the build host, in
  every panic location of generic std code (and so in every reach binary and J bundle).
  manifest.json is re-recorded from it, with input.commit.
- The package is kept rather than rebuilt in CI: the same commit and recipe give a
  different wasm on the linux runner's host than on the macOS arm64 host that built it
  (measured twice in the runner's image, with the export at /tmp and at /private/tmp; the
  glue is the same, the code section is not).
- wai-web-reach.yml runs a leg per package. The record leg checks reach/record/ against
  the manifest's SHA-256 and runs build.sh with the new WAI_REACH_REQUIRE_RECORD=1, which
  refuses any other package, so every output must equal the manifest; then run-modern and
  the engine images run on those outputs. The tree leg is the earlier job. Step names
  describe each image by its engine features.
- wai-load.js: the early-engine probe is the feature `noDotAll` (was `v8Before62`), and
  its reasons and comment say what the engine lacks, not which engine it is.
- README, CHANGELOG and wai/README: the proxies are named by Node image and engine
  features, and the device classes they stand for by capability; no engine, browser or
  OS family names. Counts that drift ("five counted places", "four profiles", "the four
  int_synth vectors") describe the shape instead. The CHANGELOG describes what CI runs
  and claims no CI result.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: J's wasm2js from binaryen's WebAssembly build, so every host gives the recorded bytes ... 3a8a2161d5

The record leg, run in the linux runner's image, built 7 of the 11 recorded outputs and
refused the four J bundles: the x86_64 Linux archive's native wasm2js allocates the
translation's locals differently from the macOS archive's (the same MVP module in, the
i64-lowering temporaries and coalesced locals out in another order). Each host is
deterministic on its own; the difference is between the archives' builds.

- build.sh runs wasm2js from binaryen's WebAssembly build of the same release (npm
  binaryen 123.0.0, pinned with its integrity hash in package-lock.json) on Node, after
  checking its version is the pinned release. Its output is the macOS archive's for every
  profile, so no recorded output changes; only the manifest's tool lines do. The four
  translations run side by side.
- In the linux runner's image (catthehacker/ubuntu:act-22.04, Node 24.18, x86_64), build.sh
  with WAI_REACH_REQUIRE_RECORD=1 on reach/record/ now gives all 11 outputs equal to
  reach/manifest.json; on macOS arm64 the re-recorded manifest has the same 11 outputs.
- README, CHANGELOG and the workflow say which wasm2js J uses and why.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: the provenance vector's signer id is a label ... ee44f1871c

The reach receipt workloads verified a receipt copied from the site, written by
wai_prov before its signer id became a label: it named a domain under did:web,
which signer_ids_are_labels refuses (jwp-receipts §7.1, §7.8).

wai_prov gains --carry <receipt.json>: it measures nothing, carries each
step's figure and label from an earlier receipt for the same lineage, and signs
them with its published test seed (0x70 x 32) under its label
did:example:wai-prov. It refuses a receipt that does not verify or whose steps
are not this run's (operations, input and output hashes, work), and writes no
report. The vector is regenerated with it: the envelope is unchanged, the
figures are the ones wai_prov first measured for these bytes, and carrying the
receipt onto itself writes both files again byte for byte. The vector's README
states how it is made and the command.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge origin/main into wai/generate-score-cli ... 815f3fb8c2

Brings in #200 (HTTP receipts and keys) and #206 (wai-ops) among the rest
of main. One conflict, wai/CHANGELOG.md: both sides added entries at the
top of v0.4.0. Kept every entry; this branch's "Generated pictures and
scores" stays on top as the newest, main's entries follow unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/generate-score-cli (with main) into wai/reach-builds ... 4e52e7923a

Brings in #197 (wai generate and wai score build|render) and, through it,
main as of #200 and #206. One conflict, wai/CHANGELOG.md: both sides added
entries at the top of v0.4.0. Kept every entry, newest first: this
branch's "wai-web on older engines: the reach builds", then #197's
"Generated pictures and scores", then main's entries unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/reach-builds (with #197 and main) into wai/d1-record-true ... 4e7155b955

Brings in #205 and #197 and, through them, main as of #200 and #206.

- wai/extensions/quantum-sim.md: both sides rewrote the status line's
  reference implementation. Kept main's two capabilities (circuit2 WQC2,
  circuit WQC1 frozen) and this branch's wording of where the reference
  lives (the `quantum` feature of wai-quantum, forwarded by wai-rs).
- wai/http-conformance/falsify/run.sh: #200 rewrote the single-run script
  into shards; took the sharded runner unchanged and ported this branch's
  additions into it: manifest-limit-dropped.patch sits with the other
  patches with its must-fail cases on its first line (it applies to the
  merged head.rs unchanged), and the Python mutation manifest-limit-dropped
  is declared in falsify/mutations.txt, after reload-walked where the old
  list had it, with the cases it must fail:
  head_malformed_manifest_too_large_O5 and _OD. The 3/3 shards cover
  134 patches and 78 mutations, each once.
- wai/http-conformance/cases.json: regenerated with wai_http_vectors gen;
  the generator's output equals the merged text (1049 cases), and both
  wai_http_vectors verify and http_verify.py give every outcome.
- wai/CHANGELOG.md: no textual conflict, but git left this branch's entry
  below "Staged measurement"; moved "The record made true" to the top of
  v0.4.0, newest first, above #205's and #197's entries.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request from a commit 2026-10-10 22:24:07 -04:00

Merge wai/d1-record-true (with #205, #197 and main) into wai/w4-4-staged-packages

dcharlot referenced this pull request 2026-10-10 23:35:30 -04:00

wai: graphics-vector, the extension text of wai.graphics.vector, §1–§3 (Draft, D7-1) #215

dcharlot referenced this pull request from a commit 2026-10-11 03:47:54 -04:00

wai-web reach: the record leg runs the record's own demo scripts

dcharlot added 1 commit 2026-10-11 03:47:54 -04:00

wai-web reach: the record leg runs the record's own demo scripts ... 603c6bbb8c

The record leg holds the package of record (reach/record/, built from the
commit reach/manifest.json names) to the demo verify scripts. It ran this
tree's scripts, so a check added after the record's commit was run against
code that predates it: #201's verify_pack test of the writers' manifest
limit failed on every rung of the record leg (jobs 21114, 21188), because
the recorded wai_web_bg.wasm was built before the writers refused a
manifest past 2^27.

run-modern.mjs takes --demo-commit <commit>: step 3 then runs that commit's
demo scripts over that commit's corpora (its wai/, exported with git
archive). A script this tree runs that the commit lacks is reported as
SKIP, not as a pass; a commit with none of them fails the run, as does an
empty or unknown commit. The record leg fetches input.commit (the checkout
is shallow) and passes it. The tree leg is unchanged: this tree's scripts
against this tree's build, where the new verify_pack check runs and passes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request 2026-10-11 04:08:07 -04:00

wai-vector: WOS1 and WVG1 with the refusal order, the interval check and the cost (D7-2; stacked on #215) #216

dcharlot referenced this pull request 2026-10-11 04:27:04 -04:00

wai-vector: the raster RS1-RS9 and the frame procedure, with per-frame SHA-256 vectors (D7-3; stacked on #216) #217

dcharlot referenced this pull request from a commit 2026-10-11 08:44:05 -04:00

wai-conformance: build wai as one codegen unit for the wasip2 quantum leg

dcharlot added 2 commits 2026-10-11 08:44:06 -04:00

wai-conformance: build wai as one codegen unit for the wasip2 quantum leg ... 1f48766531

The wasip2 leg's `cargo build --bin wai_quantum_vectors` also links wai's
cdylib, and rust-lld 22 (Rust 1.98) segfaults linking it on #201's tree. The
crash is LLD 22's ElemSection::writeBody dereferencing a null indirect function
table: the linker keeps the flags of the first object that names
__indirect_function_table, and on this tree that object (a codegen unit holding
io::Error::is_interrupted, which the new capped manifest writer instantiates)
names it without NO_STRIP. The table is then no GC root, nothing the cdylib keeps
(only cabi_realloc is exported) calls through it, yet live function addresses
still fill the element segment. LLD 23 ORs NO_STRIP across references and links
the same inputs.

Which object comes first follows the codegen units' hashed names, which depend on
the code and the checkout path, so the crash comes and goes with unrelated
changes. With one unit, wai's object comes first and takes function addresses, so
it names the table with NO_STRIP. Measured on 603c6bbb at the CI path in an x86_64
Ubuntu 22.04 container: the step crashes as is and links with this setting.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge origin/main (#215, #216, #217) into wai/d1-record-true ... 8885e66688

CHANGELOG: both v0.4.0 entries kept; this branch's entry stays on top, as it
lands after main's vector-graphics entry. README merged without conflict.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit adc866cee2 into main 2026-10-11 16:58:41 -04:00

dcharlot referenced this pull request from a commit 2026-10-11 16:58:43 -04:00

Merge pull request 'wai: the record made true' (#201) from wai/d1-record-true into main

dcharlot referenced this pull request from a commit 2026-10-11 22:25:08 -04:00

Merge main (at 4ab66d24, with #199, #201 and #219) into wai/d2b-bounds

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

Subscribe

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!201

No description provided.