feat(contract): recipe_loci — Door C, the 24-loci organ gate on recipe dispatch (Maslow carry + prune, organ-derived rung)#784
Conversation
…e dispatch (Maslow carry + prune, organ-derived rung) Closes #780's Axis-B gap on the DISPATCH path. #780 wired the organs into the ctx (SubstrateView) but the dispatch gate stayed on the 8-field scalar proxy. recipe_loci is the missing half: a dispatch gate keyed to the live CausalWitnessFacet 24 loci. - required_loci(id): each recipe's consumed Locus dimensions, grounded in the recipe's own recipes.rs::substrate string. - loci_disqualifier / reachable: per-specific-dimension gate (never a popcount) — a recipe fires only when every required dimension is BOUND. - locus_rung / loci_rung / loci_dispatch_order: the ORDER is organ-derived too — a recipe is as deep as its deepest required dimension (ICR #31 → Counterfactual apex because Kausal/Contradiction ARE apex dimensions), replacing the static Tier+inference table (kept as a documented cross-check). - carried_awareness: lower-rung groundings read UP the Maslow climb, monotone, never re-derived (the anti-exponential-rediscovery property; #777). - active_after_prune: higher thinking subsumes lower-related (strict dimension superset) and drops it from active dispatch. Complements the two shipped reach-doors (A style-fan / B select_tactic) which gate on style/mechanism/scalar and never read the organ. Additive, zero-dep, nothing existing touched. 11 module tests + examples/recipe_loci_walk.rs with 4 measured gates (selector 7/34, organ 34/34 grounded, carry monotone, prune fires + apex survives). Board: E-RECIPE-LOCI-ORGAN-GATE-1, LATEST_STATE inventory, STATUS_BOARD D-REC-LOCI-1. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Awg6TXocHcwTtc6eGsHcdD
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
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. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_0e21a5b9-c2d3-4702-bd1c-2e579c89cffb) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fcbccaf368
ℹ️ 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".
| #[must_use] | ||
| pub fn carried_awareness(w: &CausalWitnessFacet, up_to: u8) -> Vec<Locus> { | ||
| let mut carried: Vec<Locus> = Vec::new(); | ||
| for &id in loci_dispatch_order().iter().filter(|&&id| loci_rung(id) <= up_to) { |
There was a problem hiding this comment.
When a witness binds just one locus from a recipe checklist, this loop still adds that locus to the carried set because it filters only by rung and w.is_bound(l). For example, Kausal alone is reported as carried even though every Kausal-consuming recipe is disqualified without its other required loci, so the Maslow carry probe can treat partially grounded work as already-derived awareness. Filter the recipes to grounded/reachable steps before adding their required loci.
Useful? React with 👍 / 👎.
…#783 = CONVERGENT E-RECIPE-LOCI-CONVERGENCE-1: recipe_loci is the organ-gated dispatch half that pairs with my organ-input half; witness_fabric→recipe_loci is a clean producer→consumer chain. One MEASURED tension: two rung definitions (organ-depth vs inference-cost) dispatch 38% of recipe-pairs in a different order (both agree ICR#31 apex). No hard collision. Recommends 3 small wiring follow-ups. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki
2 participants
What
Closes #780's Axis-B gap on the dispatch path. #780's audit measured that the 34 recipe kernels read only the 8-field scalar proxy — 0 read a real organ — and wired the organs INTO the ctx (
SubstrateView), but the dispatch gate itself stayed scalar.recipe_locisupplies the missing half: a dispatch gate keyed to the liveCausalWitnessFacet24-loci reading.Door C — the organ gate.
docs/NARS_RECIPES_DISPATCH.md§7 already reaches 34/34 via Door A (style→mechanism fan) + Door B (surprise selectorselect_tactic, measured here at 7/34). Both gate on style/mechanism/scalar; neither reads the organ. Door C reaches a recipe by GROUNDING its 24-dimension loci — the organ decides, not the style label. It does not raise the count above Door A's 34; it makes reachability contingent on the real organ.The 24 dimensions × the rung-level walk
required_loci(id)— each recipe's consumedLocusdimensions, grounded in the recipe's ownrecipes.rs::substratestring.loci_disqualifier/reachable— per-specific-dimension gate (never a popcount): a recipe fires only when every required dimension is BOUND.locus_rung/loci_rung/loci_dispatch_order— the order is organ-derived too: a recipe is as deep as its deepest required dimension (ICR Add migration inventory for rustynum → ndarray/hpc consolidation Cross-repo reference document covering module map, BLAS parity, quantized GEMM verification, NaN guard audit, and migration roadmap. https://claude.ai/code/session_01CdqyUTUfjKZuk8YGJzv6LB #31 → Counterfactual apex becauseKausal/Contradictionare apex dimensions), replacing the staticTier+inferencetable (kept as a documented cross-check;loci_rung_is_organ_derivedasserts they differ).rung_level— names the rung in the shippedRungLevelMaslow-pyramid vocabulary (E-FOVEATED-AWARENESS-1).Carry + prune (the Maslow economy)
carried_awareness— the register is READ, not consumed, across the whole climb, so a dimension grounded for a shallow recipe stays grounded for every deeper one. Monotone non-decreasing → lower-rung awareness is carried up, never re-derived (the anti-exponential-rediscovery property; plan: causal rung trajectories + standing-wave awareness (p64→v3 cognition layer) #777 "orientation for free").active_after_prune— higher thinking subsumes lower-related recipes (strict dimension-superset) and drops them from active dispatch. RTE feat: bump arrow 57, datafusion 51, lance 2 #1[MeaningLevel]is pruned once SSR fix: rewrite zeckbf17 — golden-step traversal, i16 base, L1 distance #21[Contradiction,MeaningLevel]grounds; apex ICR Add migration inventory for rustynum → ndarray/hpc consolidation Cross-repo reference document covering module map, BLAS parity, quantized GEMM verification, NaN guard audit, and migration roadmap. https://claude.ai/code/session_01CdqyUTUfjKZuk8YGJzv6LB #31 is never pruned.Shape clarified (witness vs awareness; CE64 vs V3)
The witness (
CausalWitnessFacet) is pointer-only — 24×i4 = WHERE each dimension's filler sits. Actual awareness = witness ⊕ rung (elected ClassView, zero bytes) ⊕ the last-6part_of:is_aNaN-skipped (the A1SpoFacetL16×(8:8)taxonomy ancestry the witness'sBasinAnchoronly points at) ⊕ truth+direction (A3+A6) ⊕ higher-prunes-lower. This is the V3-vs-CausalEdge64move: CE64 crams (what × how-confidently × where) into 64 fixed bits; V3 decomposes that into full-width content-blind facet readings over the 12-byte register (6×2= the6×(8:8)rails;24×i4= the loci). Wiring the A1-basin-6 chain into the gate is the documented next composition (a sibling reading, no new storage).Verification
recipe_loci),cargo clippy -p lance-graph-contract --all-targetsclean,cargo fmtclean.examples/recipe_loci_walk.rs— 4 measured gates green: Door B selector reaches 7/34; Door C organ reaches 34/34 when grounded; carry monotone up the pyramid (4→14 loci); prune fires (34 reachable → 22 active at the apex) + ICR Add migration inventory for rustynum → ndarray/hpc consolidation Cross-repo reference document covering module map, BLAS parity, quantized GEMM verification, NaN guard audit, and migration roadmap. https://claude.ai/code/session_01CdqyUTUfjKZuk8YGJzv6LB #31 survives.recipe_dispatch::ladderscalar path.Board hygiene (same commit)
E-RECIPE-LOCI-ORGAN-GATE-1(EPIPHANIES), LATEST_STATE Contract Inventory (recipe_locisurface), STATUS_BOARDD-REC-LOCI-1.🤖 Generated with Claude Code
Generated by Claude Code