[AdaWorldAPI]

This PR adds arm C to the Foundry parity lab merged in #1991. Arm C closes half of gap G1: per-store ingredient cost, which mask-RISC cannot express. The change is lab-only and no production contract changes.

What

For every store and every item, C[store][item] = Σ_k cost[store][k] · demand[k][item]. This is one u8 × i8 → i32 GEMM through ndarray::simd::int8_gemm_packed_strided (ndarray#418, now merged). The lab host runs the AMX TDPBUSD tier.

• Demanded lanes only. Only the cost lanes of the 23 categories some item demands are bound, plus storeId. If a binding is missing any of these lanes, arm C refuses it with NotBound, as arm B does; it never treats a missing lane as zero cost.
• A is staged. The source owns one i32 lane per category, which is A's transpose, and the kernel reads u8 rows. So the bound lanes are copied once per binding into a 64 × 64 u8 buffer (4 096 B, counted). A cost that doesn't fit u8 is refused, never truncated.
• B is prepared once and reused only under the same menu revision. This is the identity-and-revision rule dr-isa-stream-lab: INT8 direct arm on prepacked INT8 B #1992's ReuseKey applies to its operands; a digest never decides reuse.
• Still blocked: the per-store limiting resource. It is a min/argmin across lanes, not a matrix product, so it stays in G1.

Evidence

The lab now has 24 integration tests, 8 of them new:

• Parity with the oracle and with the materialized null model over 64 stores × 8 items × q ∈ {1, 3, 128}.
• Summing arm C over arm B's CanCook mask equals arm B's network_cost. These are two independent arms.
• Only demanded lanes are bound, with one borrow each, and A is staged once.
• A u8 overflow (300) is refused, and 255 is admitted with an exact result.
• These are refused: a binding missing a demanded cost lane (including an identity-only binding), a stale binding after a price change, a demand band prepared for another menu revision, and q outside 1..=128.
• A reversed row order gives the same answers by identity.

Disable runs, each turned the suite red and was restored: truncate instead of refuse; ignore the denied mask; demand in the wrong column; admit any menu; stage only the first cost lane. The missing-lane test failed before its fix (Codex review) and passes after it.

Gates: cargo test --release, cargo clippy --all-targets -- -D warnings, cargo fmt --check.

Measured

cargo run --release --manifest-path crates/foundry-parity-lab/Cargo.toml --bin bench. One AMX VM, single thread, median of 41 runs, three runs:

Stage	Time
Bind 23 cost lanes + storeId (cold)	5.6–6.0 µs
Open: borrow_all + stage A (cold)	1.1–1.6 µs
Prepare the demand band (once per menu revision)	0.45–0.63 µs
Per-store cost, 64 stores × 8 items	0.65–1.17 µs
Arm A (materialized objects), same answer	1.19–1.66 µs

The first arm A comparator called fx::recipe once per (store, item) and measured 7.7–15 µs. That was 512 allocations, not object access, so it was replaced; the fair ratio is about 1.5–1.8×. At this size the GEMM's fixed per-call cost likely dominates. Scaling was not measured.

Not done

• The limiting resource, and the per-store maximum without the q sweep (G1 remainder; needs a decision on element-wise min/argmin in mask-RISC/Quack).
• Arm C was not run on the kernel's scalar tier, because the host has AMX. ndarray#418 tests both tiers against each other.
• Board: tracked on EXO (EXO-223) until lance-graph-dt64-lance: DR's map table made durable through the fire-and-forget cycle writer #1993 settles, as instructed; no repo board files change here.

Locality contract questions

1. Once per binding: route, frame, basis, mapping, staged A and the denied mask. Once per menu revision: the packed demand band. Per question: one GEMM.
2. What invalidates reuse: the frame (tested via a price change), the route, the basis, the mapping and the scope (LaneBinding::check), and the menu revision for B (tested).
3. Bytes copied: 4 096 B to stage A, which the kernel's u8 row layout requires. Nothing else.
4. Measured: the table above. Hypothesis: anything about scaling.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01XAqKMPJjVvasjwqhjJ6c9p

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: db07fd18-8b81-4a53-82d4-62da146f1889

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-10T19:43:32.753875Z	611b252	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 611b25227a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".