docs(codec): PR-X12 substrate canon resolutions — 18 open items resolved#197
Merged
Merged
Conversation
Companion to pr-x12-substrate-merged-canon.md (master commit bc9da4a). Additive, not a replacement. Resolves every open item raised in the review of PR #196's merged canon. Coverage (citation IDs R-1 through R-13): §3 — 5 affirmations of canon synthesis (M:E-A, M:E-D, M:E-G, M:E-I, M:E-F). §4 — 4 resolutions of items the canon raised in abstraction but did not commit: R-1 — Basis<T> + LinearReduce two-trait signatures (Plan A4-design) R-2 — bit 15 universal / bit 14 consumer-typed via ConsumerProfile R-3 — ≤1500 LoC generic codec + ≤200 LoC per-consumer budget, with current LoC measurements (1838 total, ~600 generic-code) R-4 — 4 threshold pairs for Plan G (video / splat / KV / gradient), each with reference baseline + compression target + quality floor §5 — 3 restorations from session A: R-5 — DCT-II vs GEMM crossover at ~64 blocks (per-architecture matrix) R-6 — SSD reformulation for VNNI block-match ME (~30-50× over SAD) R-7 — CTU partition as tropical-GEMM, O(4^d) → O(d²) (~16× speedup) §6 — 3 restorations from session B: R-8 — Plan G framing: confidence-degradation gate (45/46 debt items degrade perf/correctness; D-STACK-13 alone degrades confidence) R-9 — Codec layer is topology-FREE, not topology-generic; PredictiveSignal contract pins neighbour slots as opaque 4-way categorical R-10 — Sub-1-bit/Gaussian math: 50 B/Gaussian → 4 bit/Gaussian near target (3 factors), 1 bit/Gaussian stretch (3 more factors) §7 — 3 new commitments missing from both originals and from the merge: R-11 — 4K @ 60 fps = 125 ns/CTU budget; SIMD-batched encode promoted from P2 to P1 (~210 ns/CTU achievable, scalar misses by 7.6×) R-12 — Per-CTU flush default (~12 KB buffer); per-bucket override for Plan F; FlushUnit tag in frame header R-13 — Plan F v1 commits per-shard codebook (Option A); Option B/C in Phase 3 exploration §8 — Concrete trait signatures for all four plug-points: PredictiveSignal (consumer), Basis<T> + LinearReduce (basis + reduce), CurveOrder<const N> (curve), RdoMetric (A6 RDO). §9 — Falsifiability matrix: every claim from canon + this doc gets a test, a metric, and a pass condition. 24 rows, each is an audit gate. §10 — Sequencing diagram with Plan G as named blocking gate before A7. §11 — End-state recap + exit conditions per claim. Worst-case fallback: if R-1's LinearReduce shape wrong under bench pressure, recover in Phase 0 (3 days), not after A7 ships (6 weeks). §12 — Compaction-preservation contract: 7 items must survive summarisation. §13 — Single load-bearing paragraph for cold-read cases. Total: 1281 lines. Read order updated in §0: 1. pr-x12-codec-x265-design.md — mechanical spec 2. pr-x12-substrate-merged-canon.md — architectural fusion (THE canon) 3. THIS DOC — resolutions of opens in canon 4. session A original — archeology 5. session B original — archeology No src/ changes. Pure .claude/ addition.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
✅ Files skipped from review due to trivial changes (5)
📝 WalkthroughWalkthroughAdds PR‑X12 documentation: a canonical resolutions document (R-1..R-13), a delta extract, multiple perspective/substrate lens docs (anti‑neural, bgz/jc, cam_pq/sigker/dn_tree, GGUF LLM weights, WoA multi‑arch, x265 BLAS/GEMM, x266 3DGS), small .gitignore additions, and cross-reference/bench/falsifiability material. ChangesCanon Resolutions and Perspective Lenses
🎯 2 (Simple) | ⏱️ ~10 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/knowledge/pr-x12-substrate-canon-resolutions.md:
- Around line 766-771: The doc's CTU math is inconsistent: the value "132,710
CTUs/frame" and references like "4096 cells" and R-12's per-CTU flush numbers
don't match a 64×64 CTU (3840×2160 / 64 = ~2,040 CTUs) but instead match 8×8
blocks (~129,600). Fix by choosing one canonical CTU size and updating all
dependent numbers and text: either change CTU size to 8×8 everywhere (replace
"64×64 CTU" and "4096 cells" references and recompute per-block latency) or keep
64×64 CTU and replace "132,710" with ~2,040 and recompute the per-CTU budget,
"127 ms/frame" and the R-12 flush calculations accordingly; ensure all
occurrences (mentions of "132,710", "4096 cells", "64×64 CTU", and R-12 latency
numbers) are updated to the consistent set.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f05af36b-ae65-491d-93c5-7c134fb66ed8
📒 Files selected for processing (1)
.claude/knowledge/pr-x12-substrate-canon-resolutions.md
AdaWorldAPI
pushed a commit
that referenced
this pull request
May 22, 2026
…nnotations Companion content to PR #197's canon-resolutions doc. Adds: Perspective lens docs (4 reframings + 2 extensions): - pr-x12-x265-blasgraph-gemm.md every HEVC inner loop as a GEMM - pr-x12-x266-3dgs-spacetime-upscaling.md Basis<T> + EWA splat → free res/fps upscaling - pr-x12-woa-multiarch-orchestration.md per-arch dispatch contract for consumers - pr-x12-anti-neural-lookup-inversion.md lookup tables as frozen 1-layer NNs - pr-x12-gguf-llm-weights-encoding.md fifth load: LLM weight tensors Substrate-binding docs (PR-X12 ↔ existing lance-graph/ndarray crates): - pr-x12-bgz-jc-substrate-synergies.md bgz17/bgz-tensor/bgz-hhtl-d/jc already implement most of PR-X12; jd-nd + Cronbach research crate are the named gaps - pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md cam_pq trains all bgz palettes; sigker (arXiv:2006.14794, Hambly-Lyons 2010, CST 2021) is the formal-correctness bedrock for jc Pillar 11; dn_tree + merkle_tree are the R-13 online-update + integrity substrate; 7 wiring gaps (G-1..G-7) catalogued Plus: - pr-x12-canon-resolutions-delta.md smaller derivative of PR #197's resolutions doc for fresh-agent quick-read Inline R-N annotations into the three prior canon docs (merged-canon, mapping, synergies) pointing each load-bearing claim to its R-N formalisation. Total: ~4500 lines added across 8 new docs, 3 docs lightly annotated.
…nnotations Companion content to PR #197's canon-resolutions doc. Adds: Perspective lens docs (4 reframings + 2 extensions): - pr-x12-x265-blasgraph-gemm.md every HEVC inner loop as a GEMM - pr-x12-x266-3dgs-spacetime-upscaling.md Basis<T> + EWA splat → free res/fps upscaling - pr-x12-woa-multiarch-orchestration.md per-arch dispatch contract for consumers - pr-x12-anti-neural-lookup-inversion.md lookup tables as frozen 1-layer NNs - pr-x12-gguf-llm-weights-encoding.md fifth load: LLM weight tensors Substrate-binding docs (PR-X12 ↔ existing lance-graph/ndarray crates): - pr-x12-bgz-jc-substrate-synergies.md bgz17/bgz-tensor/bgz-hhtl-d/jc already implement most of PR-X12; jd-nd + Cronbach research crate are the named gaps - pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md cam_pq trains all bgz palettes; sigker (arXiv:2006.14794, Hambly-Lyons 2010, CST 2021) is the formal-correctness bedrock for jc Pillar 11; dn_tree + merkle_tree are the R-13 online-update + integrity substrate; 7 wiring gaps (G-1..G-7) catalogued Plus: - pr-x12-canon-resolutions-delta.md smaller derivative of PR #197's resolutions doc for fresh-agent quick-read Inline R-N annotations into the three prior canon docs (merged-canon, mapping, synergies) pointing each load-bearing claim to its R-N formalisation. Total: ~4500 lines added across 8 new docs, 3 docs lightly annotated.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (11)
.claude/knowledge/pr-x12-gguf-llm-weights-encoding.md (3)
131-134: ⚡ Quick winClarify Escape mode semantics for domain-agnostic codec.
The document states Escape is a "lossy-fallback path" but then requires it to be lossless for LLM weights. This creates a domain-specific semantic split that appears to conflict with R-3's commitment to keeping the codec body generic. While F-4 (line 330) acknowledges this tension, the resolution there (bypass channel in framing layer) should be referenced here to avoid confusion.
Consider adding a forward reference: "For LLM weights, Escape must preserve full precision (see §10 F-4 for wire-format implications)."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-gguf-llm-weights-encoding.md around lines 131 - 134, Clarify the apparent semantic conflict by adding a forward-reference note after the sentence about Escape + raw f16: state that for LLM weights Escape must be lossless and point readers to the framing-layer resolution (e.g., reference F-4 / §10) that handles the domain-specific bypass so the codec body remains domain-agnostic; mention Escape, LLM.int8(), SmoothQuant and R-3 in that brief note so readers can locate the relevant discussion.
269-269: 💤 Low valueMinor overstatement: phone-class viability claim.
The claim that "A 7B model at PR-X12 is genuinely runnable on a phone-class device" focuses only on weight storage and decode scratch memory. In practice, KV cache (1-2 GB) and activation memory during forward pass are significant additional consumers. While the storage reduction is valuable, the runnable-on-phone claim may oversell the improvement.
Consider softening to: "...brings a 7B model significantly closer to phone-class viability by reducing the weight memory footprint."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-gguf-llm-weights-encoding.md at line 269, The sentence "A 7B model at PR-X12 is genuinely runnable on a phone-class device" overstates the claim by ignoring KV cache and activation memory; replace or soften that sentence (the quoted phrase) to something like "...brings a 7B model significantly closer to phone-class viability by reducing the weight memory footprint" and ensure the revised wording appears where the **Memory savings:** paragraph refers to PR-X12 so the document reflects the caveat about additional runtime memory (KV cache and activations).
336-351: ⚡ Quick winClarify timing of discriminant reservation request.
Section 11 prescribes that PR-X12 should "Reserve an
EncodingDomain::LLMWeightsdiscriminant" (line 348), but the document's status (line 398) marks the LLM-weight work as "post-PR-X12 scope (2-3 months after merge)."If the discriminant reservation should happen in the current PR-X12, state this explicitly. If it's deferred to the future LLM-weight implementation PR, rephrase item 5 as "The future LLM-weight implementation will require reserving..."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-gguf-llm-weights-encoding.md around lines 336 - 351, Item 5 is ambiguous about when to reserve EncodingDomain::LLMWeights; update the text to explicitly state timing: either (A) if the discriminant must be reserved in the current PR-X12, change item 5 to read that PR-X12 will reserve EncodingDomain::LLMWeights in the codec metadata header now (so decoders can be forward-compatible), or (B) if reservation is deferred, rephrase item 5 to say "The future LLM-weight implementation PR will reserve EncodingDomain::LLMWeights" and adjust the status section to match that deferred timeline; be sure to reference EncodingDomain::LLMWeights and the PR-X12 scope/status so readers see the consistent plan..claude/knowledge/pr-x12-woa-multiarch-orchestration.md (1)
136-143: ⚡ Quick winPer-arch constant pattern may not compile as shown.
The code example uses
const DCT_BATCH_CROSSOVER: usize = match Arch::CURRENTto select crossover values per architecture. This pattern requiresArch::CURRENTto be a const-evaluable discriminant, which is non-trivial to implement in Rust without macros.The more idiomatic Rust approach for per-arch constants is cfg-based selection:
#[cfg(all(target_arch = "x86_64", target_feature = "amx"))] const DCT_BATCH_CROSSOVER: usize = 64; #[cfg(all(target_arch = "x86_64", not(target_feature = "amx")))] const DCT_BATCH_CROSSOVER: usize = 32; #[cfg(target_arch = "aarch64")] const DCT_BATCH_CROSSOVER: usize = 128;If the
match Arch::CURRENTpattern is intentional and represents a future abstraction, add a comment explaining howArch::CURRENTachieves const evaluation.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-woa-multiarch-orchestration.md around lines 136 - 143, The per-architecture constant DCT_BATCH_CROSSOVER cannot reliably be defined by evaluating match Arch::CURRENT at compile-time unless Arch::CURRENT is a const-evaluable discriminant; replace the match-based constant with cfg-gated constants (e.g., separate #[cfg(...)] const DCT_BATCH_CROSSOVER declarations for each target/feature) or, if you intentionally keep the Arch::CURRENT approach, add a clear comment on Arch::CURRENT and link to the const-evaluation mechanism (or macro) that guarantees it is compute-time constant so the compiler will accept the const binding..claude/knowledge/pr-x12-anti-neural-lookup-inversion.md (3)
295-307: ⚡ Quick winEnsure enhancement-layer bit reservation coordinates with R-2 header semantics.
The prescription to "reserve a bitstream flag for the enhancement-layer hook" (line 304) is sound, but given the bit 14 conflict noted elsewhere (lines 237-238 vs R-2), ensure this bit reservation is explicitly tracked and doesn't conflict with the ConsumerProfile semantics established in R-2.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-anti-neural-lookup-inversion.md around lines 295 - 307, Ensure the reserved enhancement-layer bit in the 16-bit header explicitly agrees with R-2's ConsumerProfile field: pick a specific unused bit (avoid bit 14 if R-2 or other docs already claim it), add a short normative sentence in the codec spec naming the bit (e.g., "enhancement_layer_flag") and its bit position, and update the ConsumerProfile / header semantic paragraph to reference that symbol so the reservation is tracked and cannot conflict with R-2. Also add a cross-reference note in the same doc pointing to R-2 so reviewers can verify the chosen bit is free.
99-99: 💤 Low valueConsider more precise mathematical phrasing.
The phrase "asymptotically equivalent" typically refers to limiting behavior (n→∞), but both the codebook and MLP have fixed dimensions. Consider "information-theoretically equivalent" or "achieve equivalent compression within a log(K) overhead factor" for precision.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-anti-neural-lookup-inversion.md at line 99, Update the sentence about equivalence to use precise information-theoretic phrasing: replace "asymptotically equivalent" with wording such as "information-theoretically equivalent" or "achieve equivalent compression up to a log(K) overhead" and explicitly mention the symbols R, H(cells), and K=4096 (e.g., "R ≥ H(cells); both the codebook and the neural encoder (MLP) can achieve H(cells) up to a log(K) overhead with K=4096") so the claim is mathematically precise and unambiguous.
101-131: ⚡ Quick winClarify the conditional scope of the GNN-to-tropical-GEMM equivalence.
The claim that "the GNN forward pass on the RDO graph is a tropical-GEMM iteration" (line 117) is true only under specific conditions (max aggregation + identity-on-positive activation). Most production GNNs use sum aggregation with nonlinear activations (ReLU, GeLU), which don't map directly to tropical semiring operations.
Consider hedging: "For GNNs with max-aggregation and identity-positive activation, the forward pass is structurally equivalent to tropical-GEMM. Other GNN variants may require approximation."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-anti-neural-lookup-inversion.md around lines 101 - 131, Clarify that the equivalence to tropical-GEMM applies only under the specific aggregation/activation choices: update the paragraph around the "GNN forward pass on the RDO graph" and the sentence claiming "is a tropical-GEMM iteration" to state that this holds when aggregate == max (or max-pooling) and σ is identity-on-positive (no nonlinearity), and add a hedge sentence such as: "For GNNs using sum aggregation or nonlinear activations (ReLU/GeLU/etc.) the mapping does not hold exactly and may require approximation." Reference the terms "aggregate", "max", "σ", "GNN forward pass", and "tropical-GEMM" so the change is applied to that exact claim..claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md (2)
274-278: 💤 Low valueClarify gap numbering convention across substrate docs.
This doc uses G-8 and G-9 for
jd-ndand Cronbach/ICC gaps (lines 310-312), while the companion docpr-x12-cam-pq-sigker-dn-tree-substrate-bindings.mduses G-1 through G-7 for different gaps. The numbering should either be unified across docs or clearly scoped per-doc.Recommendation: If gaps are meant to be globally numbered across the PR-X12 substrate doc set, renumber to avoid collision. If per-doc, add a clarifying note like "Gaps G-1..G-7 are enumerated in the cam_pq/sigker/dn_tree companion doc."
Also applies to: 310-312
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md around lines 274 - 278, The gap numbering in this doc uses G-8 and G-9 for `jd-nd` and Cronbach/ICC, which collides with the companion doc `pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md` that enumerates G-1..G-7; either unify the global numbering across PR-X12 docs or mark numbering as per-doc by adding a clarifying sentence (e.g., "Gaps G-1..G-7 are enumerated in the cam_pq/sigker/dn_tree companion doc") and renumber or prefix these gaps accordingly (update the `G-8`/`G-9` references and any mentions of `jd-nd`, Cronbach, ICC to match the chosen scheme).
376-421: ⚡ Quick winTrack proposed documentation updates.
Section 8 proposes specific updates to four other PR-X12 docs:
pr-x12-canon-resolutions-delta.md(R-7 path correction, R-13 expansion, optional R-14)pr-x12-gguf-llm-weights-encoding.md(§6 numbers, §7 highheelbgz ref, §9 bench target)pr-x12-anti-neural-lookup-inversion.md(§3.1 empirical anchor)pr-x12-substrate-merged-canon.md(M:E-D dep target, M:H-1 fifth load)These are actionable follow-up edits with specific section targets. Consider opening a tracking issue to ensure these updates are applied consistently.
Would you like me to generate a checklist or tracking issue template for these proposed documentation updates?
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md around lines 376 - 421, Create a tracking-issue/checklist template that lists the four target docs (pr-x12-canon-resolutions-delta.md, pr-x12-gguf-llm-weights-encoding.md, pr-x12-anti-neural-lookup-inversion.md, pr-x12-substrate-merged-canon.md) and enumerates the exact edits: R-7 path correction to lance-graph::bgz17::scalar_sparse::tropical_spmv, R-13 expansion referencing bgz-hhtl-d shared-palette and PretrainedStatic, add optional R-14 pointing to lance-graph/crates/jc proof, update §6/§7/§9 in pr-x12-gguf to cite bgz-hhtl-d measured 343:1 and SpiralAddress (highheelbgz), swap benchmark to Qwen3-TTS-1.7B, anchor §3.1 in pr-x12-anti-neural-lookup-inversion to bgz-tensor’s AttentionSemiring+ComposeTable empirical numbers, and in pr-x12-substrate-merged-canon fix M:E-D dep to lance-graph::bgz17 and add LLM weights as the fifth load noting bgz-tensor 640× compression for M:H-1; include acceptance criteria, owner, ETA, and a step to update citations to lance-graph/crates/bgz17/KNOWLEDGE.md and to prefer lance-graph::bgz17::Palette::nearest_index where applicable..claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md (1)
293-312: 🏗️ Heavy liftValidate gap cost estimates and blocking relationships.
The gap table provides specific cost estimates (days/weeks) and blocking relationships. While subjective, these should be internally consistent:
- G-4 blocks R-14 (1-2 weeks)
- G-6 blocks R-13 SharedClusterWide (2-3 weeks)
- G-7 blocks R-13 integrity (1 week)
Total estimate is 8-12 weeks for G-1..G-7, plus 3-5 weeks for G-8..G-9 = 11-17 weeks. This matches line 313 but is a substantial commitment. Ensure stakeholders are aligned on these estimates.
Consider adding milestone dependencies or phasing to the gap table if certain gaps must be addressed before others (e.g., G-4 before R-14, G-6 before G-7).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md around lines 293 - 312, Reconcile and validate the gap cost totals and blocking relationships by (1) confirming the arithmetic that G-1..G-7 = 8–12 weeks and G-8..G-9 = 3–5 weeks to ensure the document total 11–17 weeks is correct, (2) explicitly documenting the blocking edges for G-4→R-14, G-6→R-13 (SharedClusterWide), and G-7→R-13 (integrity) in the table row notes, and (3) adding a short milestone/phasing column or dependency list so reviewers can see required ordering (e.g., mark G-4 as prerequisite for R-14 and schedule G-6 before G-7 or vice versa as appropriate) and a line invoking stakeholder sign-off to confirm estimates and schedule..claude/knowledge/pr-x12-x266-3dgs-spacetime-upscaling.md (1)
262-269: ⚡ Quick winClarify "landed" terminology in status table.
The table claims several items (R-2, R-3 audit, R-13) are "landed," but this is a docs-only PR that adds the canon resolutions document itself. No src/ changes exist. "Landed" typically implies merged code, but these are documentation commitments.
Consider rephrasing to "committed in canon" or "defined in R-N" to avoid confusion about implementation status.
📝 Proposed terminology clarification
| Requirement | Source | Status | |---|---|---| -| `Basis<T>` trait with parametric `apply` | R-1, M:E-A | landed in concept; implementation in Plan A4 | -| EWA splat rasterizer as `Basis<f16>` impl | Plan E | scheduled | -| Codec body decoupled from specific basis | M:H-NEW-2 LoC envelope | enforced via R-3 audit | -| Header byte stable across basis swaps | R-2, M:E-J bits 0-1 | landed | -| Plan G video lane validates per-arch latency | R-4, R-11 | scheduled | -| Federated codebook policy for scene anchors | R-13 | landed | +| `Basis<T>` trait with parametric `apply` | R-1, M:E-A | committed in canon; impl in Plan A4 | +| EWA splat rasterizer as `Basis<f16>` impl | Plan E | scheduled | +| Codec body decoupled from specific basis | M:H-NEW-2 LoC envelope | committed via R-3 audit rule | +| Header byte stable across basis swaps | R-2, M:E-J bits 0-1 | committed in canon | +| Plan G video lane validates per-arch latency | R-4, R-11 | scheduled | +| Federated codebook policy for scene anchors | R-13 | committed in canon |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-x266-3dgs-spacetime-upscaling.md around lines 262 - 269, Update the status table entries that currently read "landed" (notably the rows referencing R-2, R-3 audit, and R-13) to language that clearly denotes documentation-only commitments—e.g. replace "landed" with "committed in canon" or "defined in R-N" (or similar phrasing) so the table no longer implies merged/implemented source changes; ensure the same wording is applied consistently across the "Requirement | Source | Status" table.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/knowledge/pr-x12-anti-neural-lookup-inversion.md:
- Around line 237-238: The statement claiming the enhancement-layer flag uses
"bit 14" conflicts with R-2/Plan A8; update the PR-X12 text to either remove the
specific "bit 14" claim or replace it with the correct R-2-designated reserved
field/bit, and ensure the text references R-2/Plan A8’s handling of bits 14–15
(leaf_size with ConsumerProfile demux) and the enhancement-flag location
consistently; look for occurrences of "M:E-J bit 14", "leaf_size",
"ConsumerProfile", and "enhancement layer available" in the PR-X12 doc and
adjust the sentence to cite the correct R-2 field or omit the bit number.
In @.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md:
- Line 12: The document's numeric compression claims for bgz-hhtl-d (e.g.,
"343:1", "313:1", "589:1", "110× vs GGUF Q4_K_M") lack in-repo evidence; either
add exact links to the encoder+decoder benchmark harness and raw result outputs
(include the harness name, the metric calculation code or script, and example
output for Qwen3-TTS-1.7B) or change the wording to a non-assertive statement
like "reported in doc" until evidence is committed. Update the mentions in
.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md and any other knowledge
docs that repeat these ratios, and if adding evidence, create the missing
artifact (e.g., BGZ_HHTL_D.md or a benchmark directory with the encoder/decoder,
the compression-ratio computation, and sample outputs) and reference the jc
crate proof harness and the outstanding jd-nd/Cronbach-ICC research crates where
appropriate.
In @.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md:
- Around line 321-336: The PR references new resolution IDs R-14 and R-15 but
the canonical summary document does not contain those headings, causing
broken/unresolved references; update pr-x12-canon-resolutions-delta.md by adding
canonical entries for R-14 (formal-correctness commitment referencing Pillar 11
/ lance-graph/crates/jc and sigker) and R-15 (SignatureBasis:
sigker::SignatureBasis<DEPTH>: Basis<f32>) under the same numbering scheme used
for R-7 and R-13, or alternatively change the PR text to retarget those mentions
to existing IDs; ensure each new entry includes the short title and the
referenced symbols (Pillar 11, lance-graph/crates/jc, sigker::SignatureBasis) so
downstream links resolve.
- Around line 371-377: The markdown lists incorrect absolute source paths and
non-existent repo references; update
`.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md` (section
showing file list) to use the repository-relative paths for the local files
(replace `/home/user/ndarray/src/hpc/cam_pq.rs`,
`/home/user/ndarray/src/hpc/dn_tree.rs`,
`/home/user/ndarray/src/hpc/merkle_tree.rs` with `src/hpc/cam_pq.rs`,
`src/hpc/dn_tree.rs`, `src/hpc/merkle_tree.rs`) and remove or mark as external
any absolute `/home/user/lance-graph/...` entries (e.g.,
`lance-graph/crates/sigker/`, `lance-graph/crates/jc/src/hambly_lyons.rs`) so
the document only references paths that actually exist in this repository or
clearly notes they are external dependencies.
- Around line 136-138: Update the Hambly–Lyons table row to include the full
arXiv identifier: edit the row containing "Hambly-Lyons, 'Uniqueness for the
signature of a path of bounded variation' | 2010" and append
"arXiv:math/0507536" (e.g., after the year or inside the bold theorem column) so
the citation reads with the complete arXiv ID.
- Around line 31-44: Update the bindings doc to match the real Rust signatures:
replace the CamFingerprint struct with the type alias CamFingerprint = [u8;
NUM_SUBSPACES] and change kmeans to accept and return nested vectors using the
signature pub fn kmeans(data: &[Vec<f32>], k: usize, dim: usize, iterations:
usize) -> Vec<Vec<f32>> (instead of &[f32] -> Vec<f32>); for the SigKer section
remove or correct the nonexistent exported types/functions and instead reference
the actual symbols exported in this repo
(ndarray::hpc::pillar::signature::signature_d2_deg3, sigker_hl, prove_pillar_11)
or point readers to the correct external crate/repo if those functions live
elsewhere.
In @.claude/knowledge/pr-x12-substrate-merged-canon.md:
- Around line 281-282: The merged-canon note incorrectly documents bits 14–15 as
a 2-bit leaf_size field; update the text so bits 14–15 match the canonical
R-2/R-8 semantics: make bit15 the universal “has inter-tier reference” flag and
make bit14 a consumer-typed/multiplexed bit (value interpreted via
ConsumerProfile) rather than part of leaf_size, or instead adjust R-2 wording to
explicitly declare leaf_size is not an on-wire 2-bit field; ensure the note
references bits 14–15, leaf_size, ConsumerProfile and the “has inter-tier
reference” semantics so both documents are consistent.
In @.claude/knowledge/pr-x12-x266-3dgs-spacetime-upscaling.md:
- Around line 217-218: The bandwidth formula under the "HEVC: re-encode at
4K/60fps target" line is wrong—replace the incorrect "4 × 4 × 6.25 = 100 MB"
with the correct scaling for resolution × framerate (4× pixels × 2× frames =
8×), i.e. "8 × 6.25 = 50 MB" or explicitly "4 × 2 × 6.25 = 50 MB"; if you
intended 100 MB instead, update the base bitrate/assumptions (the "6.25" factor)
and adjust the explanatory text so the numbers are consistent.
- Around line 163-167: The PR-X12 header docs are ambiguous about the on-wire
semantics of R-2 bits 14–15: the snippet currently defines bits 14-15 as
leaf_size while other canon text assigns them inter-tier/ConsumerProfile
meanings; clarify which interpretation is authoritative on-wire and how the
other interpretation is derived (if at all). Update the x266 section for the
"PR-X12 header (16 bits, R-2)" to explicitly state that bits 14–15 encode
leaf_size on-wire (or alternatively that bit15=UNIVERSAL inter-tier and
bit14=CONSUMER via ConsumerProfile if that is correct), then describe any
mapping/interpretation rules that derive ConsumerProfile/inter-tier semantics
from leaf_size (or note that those are purely causal-tier interpretations and
not transmitted). Reference the symbols "bits 14-15", "leaf_size", "R-2",
"ConsumerProfile", and "inter-tier" so readers can locate and reconcile the
differing canon statements.
---
Nitpick comments:
In @.claude/knowledge/pr-x12-anti-neural-lookup-inversion.md:
- Around line 295-307: Ensure the reserved enhancement-layer bit in the 16-bit
header explicitly agrees with R-2's ConsumerProfile field: pick a specific
unused bit (avoid bit 14 if R-2 or other docs already claim it), add a short
normative sentence in the codec spec naming the bit (e.g.,
"enhancement_layer_flag") and its bit position, and update the ConsumerProfile /
header semantic paragraph to reference that symbol so the reservation is tracked
and cannot conflict with R-2. Also add a cross-reference note in the same doc
pointing to R-2 so reviewers can verify the chosen bit is free.
- Line 99: Update the sentence about equivalence to use precise
information-theoretic phrasing: replace "asymptotically equivalent" with wording
such as "information-theoretically equivalent" or "achieve equivalent
compression up to a log(K) overhead" and explicitly mention the symbols R,
H(cells), and K=4096 (e.g., "R ≥ H(cells); both the codebook and the neural
encoder (MLP) can achieve H(cells) up to a log(K) overhead with K=4096") so the
claim is mathematically precise and unambiguous.
- Around line 101-131: Clarify that the equivalence to tropical-GEMM applies
only under the specific aggregation/activation choices: update the paragraph
around the "GNN forward pass on the RDO graph" and the sentence claiming "is a
tropical-GEMM iteration" to state that this holds when aggregate == max (or
max-pooling) and σ is identity-on-positive (no nonlinearity), and add a hedge
sentence such as: "For GNNs using sum aggregation or nonlinear activations
(ReLU/GeLU/etc.) the mapping does not hold exactly and may require
approximation." Reference the terms "aggregate", "max", "σ", "GNN forward pass",
and "tropical-GEMM" so the change is applied to that exact claim.
In @.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md:
- Around line 274-278: The gap numbering in this doc uses G-8 and G-9 for
`jd-nd` and Cronbach/ICC, which collides with the companion doc
`pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md` that enumerates G-1..G-7;
either unify the global numbering across PR-X12 docs or mark numbering as
per-doc by adding a clarifying sentence (e.g., "Gaps G-1..G-7 are enumerated in
the cam_pq/sigker/dn_tree companion doc") and renumber or prefix these gaps
accordingly (update the `G-8`/`G-9` references and any mentions of `jd-nd`,
Cronbach, ICC to match the chosen scheme).
- Around line 376-421: Create a tracking-issue/checklist template that lists the
four target docs (pr-x12-canon-resolutions-delta.md,
pr-x12-gguf-llm-weights-encoding.md, pr-x12-anti-neural-lookup-inversion.md,
pr-x12-substrate-merged-canon.md) and enumerates the exact edits: R-7 path
correction to lance-graph::bgz17::scalar_sparse::tropical_spmv, R-13 expansion
referencing bgz-hhtl-d shared-palette and PretrainedStatic, add optional R-14
pointing to lance-graph/crates/jc proof, update §6/§7/§9 in pr-x12-gguf to cite
bgz-hhtl-d measured 343:1 and SpiralAddress (highheelbgz), swap benchmark to
Qwen3-TTS-1.7B, anchor §3.1 in pr-x12-anti-neural-lookup-inversion to
bgz-tensor’s AttentionSemiring+ComposeTable empirical numbers, and in
pr-x12-substrate-merged-canon fix M:E-D dep to lance-graph::bgz17 and add LLM
weights as the fifth load noting bgz-tensor 640× compression for M:H-1; include
acceptance criteria, owner, ETA, and a step to update citations to
lance-graph/crates/bgz17/KNOWLEDGE.md and to prefer
lance-graph::bgz17::Palette::nearest_index where applicable.
In @.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md:
- Around line 293-312: Reconcile and validate the gap cost totals and blocking
relationships by (1) confirming the arithmetic that G-1..G-7 = 8–12 weeks and
G-8..G-9 = 3–5 weeks to ensure the document total 11–17 weeks is correct, (2)
explicitly documenting the blocking edges for G-4→R-14, G-6→R-13
(SharedClusterWide), and G-7→R-13 (integrity) in the table row notes, and (3)
adding a short milestone/phasing column or dependency list so reviewers can see
required ordering (e.g., mark G-4 as prerequisite for R-14 and schedule G-6
before G-7 or vice versa as appropriate) and a line invoking stakeholder
sign-off to confirm estimates and schedule.
In @.claude/knowledge/pr-x12-gguf-llm-weights-encoding.md:
- Around line 131-134: Clarify the apparent semantic conflict by adding a
forward-reference note after the sentence about Escape + raw f16: state that for
LLM weights Escape must be lossless and point readers to the framing-layer
resolution (e.g., reference F-4 / §10) that handles the domain-specific bypass
so the codec body remains domain-agnostic; mention Escape, LLM.int8(),
SmoothQuant and R-3 in that brief note so readers can locate the relevant
discussion.
- Line 269: The sentence "A 7B model at PR-X12 is genuinely runnable on a
phone-class device" overstates the claim by ignoring KV cache and activation
memory; replace or soften that sentence (the quoted phrase) to something like
"...brings a 7B model significantly closer to phone-class viability by reducing
the weight memory footprint" and ensure the revised wording appears where the
**Memory savings:** paragraph refers to PR-X12 so the document reflects the
caveat about additional runtime memory (KV cache and activations).
- Around line 336-351: Item 5 is ambiguous about when to reserve
EncodingDomain::LLMWeights; update the text to explicitly state timing: either
(A) if the discriminant must be reserved in the current PR-X12, change item 5 to
read that PR-X12 will reserve EncodingDomain::LLMWeights in the codec metadata
header now (so decoders can be forward-compatible), or (B) if reservation is
deferred, rephrase item 5 to say "The future LLM-weight implementation PR will
reserve EncodingDomain::LLMWeights" and adjust the status section to match that
deferred timeline; be sure to reference EncodingDomain::LLMWeights and the
PR-X12 scope/status so readers see the consistent plan.
In @.claude/knowledge/pr-x12-woa-multiarch-orchestration.md:
- Around line 136-143: The per-architecture constant DCT_BATCH_CROSSOVER cannot
reliably be defined by evaluating match Arch::CURRENT at compile-time unless
Arch::CURRENT is a const-evaluable discriminant; replace the match-based
constant with cfg-gated constants (e.g., separate #[cfg(...)] const
DCT_BATCH_CROSSOVER declarations for each target/feature) or, if you
intentionally keep the Arch::CURRENT approach, add a clear comment on
Arch::CURRENT and link to the const-evaluation mechanism (or macro) that
guarantees it is compute-time constant so the compiler will accept the const
binding.
In @.claude/knowledge/pr-x12-x266-3dgs-spacetime-upscaling.md:
- Around line 262-269: Update the status table entries that currently read
"landed" (notably the rows referencing R-2, R-3 audit, and R-13) to language
that clearly denotes documentation-only commitments—e.g. replace "landed" with
"committed in canon" or "defined in R-N" (or similar phrasing) so the table no
longer implies merged/implemented source changes; ensure the same wording is
applied consistently across the "Requirement | Source | Status" table.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d1385111-5b5f-436c-9d8d-2f9b0f137960
📒 Files selected for processing (11)
.claude/knowledge/pr-x12-anti-neural-lookup-inversion.md.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md.claude/knowledge/pr-x12-canon-resolutions-delta.md.claude/knowledge/pr-x12-codec-cognitive-substrate-mapping.md.claude/knowledge/pr-x12-cross-domain-synergies.md.claude/knowledge/pr-x12-gguf-llm-weights-encoding.md.claude/knowledge/pr-x12-substrate-merged-canon.md.claude/knowledge/pr-x12-woa-multiarch-orchestration.md.claude/knowledge/pr-x12-x265-blasgraph-gemm.md.claude/knowledge/pr-x12-x266-3dgs-spacetime-upscaling.md
✅ Files skipped from review due to trivial changes (2)
- .claude/knowledge/pr-x12-codec-cognitive-substrate-mapping.md
- .claude/knowledge/pr-x12-x265-blasgraph-gemm.md
… + gitignore settings.local.json
After reading bgz17/KNOWLEDGE.md, bgz-tensor/{lib.rs,hhtl_d.rs,BGZ_HHTL_D.md},
highheelbgz/lib.rs, jc/{lib.rs,hambly_lyons.rs,Cargo.toml}, sigker/lib.rs,
ndarray/src/hpc/{cam_pq.rs,dn_tree.rs,merkle_tree.rs}, and
bgz17/src/scalar_sparse.rs in full, corrected the following:
bgz-jc-substrate-synergies.md:
- jc is 12-pillar (not 5) — Cargo.toml description is stale; run_all_pillars()
executes pillars 1, 3, 4, 5, 5b, 7-11. Detailed mapping per pillar added.
- Pillar 11 is ACTIVE under --features hambly-lyons (since 2026-05-07, PR #348),
not DEFERRED. The DEFERRED reading applies only to the default zero-dep build.
- Pillar 10 (Pflug-Pichler nested-distance on Sigma DN-trees) is the formal proof
for CAM-PQ tree quantization correctness — not Pillar 11. Pillar 11 certifies
sigker's Index-regime classification.
- The Hambly-Lyons probe deliberately uses signature_truncated (tensor-algebra),
NOT signature_kernel_pde — the latter has a known math bug (PR #350: diverges
from the true kernel I_0(2*sqrt(<u,v>)) at moderate inner products).
- The literal 4096-entry codebook is bgz-tensor::Codebook4096, a first-class
type. bgz-hhtl-d is a different basin-codebook strategy (4 basin x 16 HIP x
256 TWIG = 16384-cell address space over a shared 256-entry palette per role).
- Examples directory has 10 runnable proofs (not 9).
cam-pq-sigker-dn-tree-substrate-bindings.md:
- Same Pillar 10/11 distinction propagated.
- signature_kernel_pde caveat: known math bug, use signature_truncated for now.
- StaunenType: 6 explicit variants (not 8). MultipleChanges is the catch-all
carrying a Vec<u8> of differing branch indices.
- dn_tree's quaternary fanout is a spatial partition of the prototype-index
range, not a literal per-mode container. The Skip/Merge/Delta/Escape mapping
is structurally suggestive but not load-bearing; the practical wiring is
per-mode counts bundled via the existing GraphHV plastic-bundling primitive.
- train_semantic uses jaccard similarity on label sets + push/pull on centroids
(NOT CLAM archetype clustering as the Explore agent summary said).
- merkle_tree's 1 KB layout, branch indices (0=identity through 7=content),
and xor_diff (panCAKES compression) clarified.
- R-14 split into two clauses: codec-quantization correctness via Pillar 10
(active), path-signature correctness via Pillar 11 (active under feature).
.gitignore:
- Added .claude/settings.local.json so per-user permission overrides survive
branch switches without being committed.
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md (1)
179-183: 💤 Low valueConsider downgrading signature_kernel_pde as a substrate binding until PR
#350lands.Lines 179-183 (and 149-150) document that
sigker::signature_kernel_pdehas a "known math bug" (PR#350: diverges from true kernel at moderate inner products) and recommend usingsignature_truncatedinstead. The document positions sigker as substrate for PR-X12's streaming-decode pattern (line 179) but then caveats that the referenced function is buggy.Either: (a) emphasize
signature_truncatedas the actual substrate binding (since that's what jc Pillar 11 uses), or (b) add a clear statement in §2.1 or the thesis (line 12) that the PDE-form is pending correction and production code must use the tensor-algebra path.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md around lines 179 - 183, The document currently promotes sigker::signature_kernel_pde as a substrate for the streaming-decode pattern while noting a known math bug (PR `#350`); update the text to downgrade that binding: explicitly state that sigker::signature_truncated (and linear_path_kernel_closed_form for the special case) are the recommended production substrate bindings until PR `#350` is merged, and add a short, prominent note in §2.1 / the thesis intro that the PDE form (sigker::signature_kernel_pde) is pending correction and must not be used in production; change the phrasing in the paragraphs referencing sigker::signature_kernel_pde (including the sentence at the current §2.4.2 and the earlier cross-reference) to recommend sigker::signature_truncated/linear_path_kernel_closed_form and cite PR `#350` as the reason.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md:
- Around line 179-183: The document currently promotes
sigker::signature_kernel_pde as a substrate for the streaming-decode pattern
while noting a known math bug (PR `#350`); update the text to downgrade that
binding: explicitly state that sigker::signature_truncated (and
linear_path_kernel_closed_form for the special case) are the recommended
production substrate bindings until PR `#350` is merged, and add a short,
prominent note in §2.1 / the thesis intro that the PDE form
(sigker::signature_kernel_pde) is pending correction and must not be used in
production; change the phrasing in the paragraphs referencing
sigker::signature_kernel_pde (including the sentence at the current §2.4.2 and
the earlier cross-reference) to recommend
sigker::signature_truncated/linear_path_kernel_closed_form and cite PR `#350` as
the reason.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a461269b-6cfe-41ff-bd3d-5031a73e84cd
📒 Files selected for processing (3)
.claude/knowledge/pr-x12-bgz-jc-substrate-synergies.md.claude/knowledge/pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md.gitignore
✅ Files skipped from review due to trivial changes (1)
- .gitignore
Arithmetic errors - R-11 (canon-resolutions): 132,710 was 8×8 leaves/frame, not 64×64 CTUs (which is 2,040). Relabelled the per-CTU breakdown table and budget derivation to per-leaf; clarified the 1 CTU = ~64 leaves at max split depth relationship. Latency narrative unchanged. - R-12 (canon-resolutions): per-CTU flush rate at 4K was 80,000/sec but 2,040 CTUs × 60 fps = 122,400/sec; 1080p figure refined to 30,600/sec (510 CTUs × 60). - x266 §6 bandwidth: HEVC at 4K/60 from 1080p/30 scales as 4 (res) × 2 (fps) × 6.25 MB = 50 MB, not 4 × 4 × 6.25 = 100 MB. PR-X12 wins by ~6× (not 12×); crossover ~1.3× (not 3×). Bits 14-15 consistency (3 sites reconciled to R-2 canon) - merged-canon M:E-J §3 formalisation note: replaced stale 'bits 14-15 = leaf_size' with R-2's bit 15 = UNIVERSAL inter-tier / bit 14 = CONSUMER-TYPED via ConsumerProfile. Leaf size lives in Ctu<const N> at the type level (M:E-G), not in header bits. - x266 §5 header layout: same R-2 alignment for the HEVC-compatible header block. - anti-neural §6: enhancement-layer flag moved from per-leaf bit 14 (claimed by R-2 consumer-typed demux) to the frame header reserved area (alongside ConsumerProfile and FlushUnit per R-2/R-12). Path / citation corrections (cam-pq-sigker-dn-tree doc) - Absolute /home/user/ndarray/... paths replaced with repo-relative src/hpc/... since this repo IS ndarray. - /home/user/lance-graph/... paths marked as external repo (adaworldapi/lance-graph), not resolvable in this checkout. - Hambly-Lyons 2010 citation now includes arXiv:math/0507536 and Annals of Mathematics 171(1):109-167. All claims re-verified by reading each affected file in full (canon-resolutions 1281 lines, x266 321, merged-canon 647, anti-neural 337, cam-pq 395) before edits — the same protocol applied to the bgz-jc proofread. https://claude.ai/code/session_01HbqooFZHAjaUtFEzhA1R2u
AdaWorldAPI
pushed a commit
that referenced
this pull request
May 22, 2026
Brings claude/continue-ndarray-x0Oaw in sync with the PR branch (claude/pr-x12-canon-resolutions-MAOO0, commit 21b61eb) for the four docs that exist on both branches: - pr-x12-anti-neural-lookup-inversion.md (enhancement-flag bit reassignment from leaf bit 14 to frame-header reserved area) - pr-x12-cam-pq-sigker-dn-tree-substrate-bindings.md (path corrections + Hambly-Lyons arXiv:math/0507536) - pr-x12-substrate-merged-canon.md (M:E-J §3 R-2 alignment: bit 15 universal / bit 14 consumer-typed; leaf_size lives in Ctu<const N> not header bits) - pr-x12-x266-3dgs-spacetime-upscaling.md (R-2 header layout + HEVC 4K/60 bandwidth math: 4 res × 2 fps × 6.25 = 50 MB) pr-x12-substrate-canon-resolutions.md is NOT brought across — that file exists only on the PR branch and arrives via the PR #197 → master merge. https://claude.ai/code/session_01HbqooFZHAjaUtFEzhA1R2u
6 tasks
AdaWorldAPI
pushed a commit
that referenced
this pull request
May 22, 2026
Per other-session feedback: six nitpick-level findings on PR #197 didn't block the merge but stayed unaddressed. Folding them into this PR. 1. GGUF Escape forward-ref to F-4 gguf-llm-weights-encoding.md §2.4 said "Escape must be lossless ... This is an additional R-N candidate" with no pointer. F-4 in §10 already explains the mechanism (rANS bypass channel in A8, HEVC escape-coefficient precedent). Added an inline cross-ref so readers don't have to scroll to find the resolution. 2. Phone-class viability overclaim re KV cache gguf-llm-weights-encoding.md line 269 claimed "7B at PR-X12 is genuinely runnable on a phone-class device". Weight compression alone takes 7B from 4 GB to 3 GB, but KV cache at 8K context is ~1-2 GB independent of weight compression. Qualified the claim: PR-X12 weights are necessary but not sufficient; KV-cache lane (Plan D, M:H-3, R-4) is the second lever for full phone viability. 3. EncodingDomain::LLMWeights timing §11 implication #2 says "LLM lane lands post-PR-X12, but the harness must be lane-extensible"; implication #5 said "Reserve an EncodingDomain::LLMWeights discriminant ... now". Clarified: PR-X12 reserves the enum-discriminant *slot* now (forward-compat lock); the LLMWeights variant + decoder land post-PR-X12 without a wire-format break. 4. Per-arch `match Arch::CURRENT` const-eval woa-multiarch-orchestration.md §3.3's `const DCT_BATCH_CROSSOVER = match Arch::CURRENT { ... }` does not compile under stable Rust const-eval — `Arch::CURRENT` would need to be a const, and architecture-conditional const matches require build-script-emitted integers or `cfg!(target_feature = ...)`. Rewrote as pseudocode pointing at a `build.rs` mechanism (decision matrix → `OUT_DIR` generated const) with a `cfg!()` fallback shape. 5. G-8 / G-9 numbering collision cam-pq-sigker-dn-tree-substrate-bindings.md §5 labelled bgz-jc's two prior gaps as G-8 / G-9 (continuing cam-pq's own G-1..G-7), but bgz-jc-substrate-synergies.md §5 didn't use any G-N IDs, so the cross-doc reference was dangling and the namespace was implicitly shared without rules. Gave bgz-jc §5.1 / §5.2 explicit IDs G-1 / G-2 (canonical to that doc) and updated cam-pq to cite them as "bgz-jc G-1" / "bgz-jc G-2" with a namespace-isolation note. 6. "landed" terminology in x266 §8 prerequisites table The status column claimed "landed" / "landed in concept" for R-1 trait shape, R-2 header bytes, and R-13 federated codebook policy. None of these have shipping code — they are canon-fixed (the resolution doc commits the design) but implementation is scheduled in Plan A4 / A8 / F. Renamed status to "canon-fixed" + a glossary line distinguishing "canon-fixed" (doc commitment) from "scheduled" (plan card exists) from shipping code. https://claude.ai/code/session_01HbqooFZHAjaUtFEzhA1R2u
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Docs-only PR. Adds
.claude/knowledge/pr-x12-substrate-canon-resolutions.md(1281 lines) — companion to the merged canon (pr-x12-substrate-merged-canon.md, master commitbc9da4ad) that resolves the eighteen open items raised during review of PR #196.The merged canon successfully synthesised sessions A and B but raised four load-bearing claims to abstraction without committing to concrete shapes:
LinearReduce<Basis>cited as the universal reduce kernel — no trait signaturePlus three pieces of session-A detail (DCT crossover, SSD-via-VNNI math, tropical-GEMM complexity) and three pieces of session-B detail (Plan G framing, topology-free claim, sub-1-bit/Gaussian math) that the merge underrepresented. Plus three commitments missing entirely (latency budget, streaming granularity, federated codebook distribution policy).
This PR commits all 18 items as resolutions R-1 through R-13 (the 5 affirmations are §3, the 13 substantive resolutions are §4-§7).
Coverage map — every previous-message point gets a resolution
§3 — 5 affirmations (preserved canon synthesis)
LinearReduce<Basis>unifies α / rANS / sum / softmax)ndarray-codec)Ctu<const N: usize>for block-size reconciliation)§4 — 4 resolutions of items the canon raised but did not commit
Basis<T>+LinearReducetwo-trait signatures, with rationale for splitting basis (data) from reduce (logic), no const-generic ondim(), and concrete impl listConsumerProfilein frame header§5 — 3 restorations from session A
||A||² - 2A·B + ||B||²for VNNI block-match ME; ~30-50× over hand-tuned SAD; lands asbatched_ssd_searchinndarray::hpc::blas_level2O(4^d) → O(d²)via matrix-relaxation Bellman-Ford; ~16× speedup; requireslance-graph::blasgraphafter Plan H extraction§6 — 3 restorations from session B
PredictiveSignal::neighboursreturns[Option<NeighbourRef>; 4]with NO spatial semantics at codec layer; consumer-side reinterpretation only; falsifiable via grep audit§7 — 3 new commitments missing from both originals and merge
FlushUnittag in frame headerPlus the integration pieces
PredictiveSignal,Basis<T>+LinearReduce,CurveOrder<const N>,RdoMetricTrajectory
Wall-clock total: ~10.5 weeks to demonstrable M:H-NEW-1 (single binary, 4 loads → 1 Lance column).
Test plan
.claude/knowledge/src/changes; pure.claude/additionBasis<T>+LinearReduce) is the right factoring — alternative is single-trait with associatedBasistype; this doc argues two-traitGenerated by Claude Code
Summary by CodeRabbit
Documentation
Chores