basin-IS-a-node: members/memberof navigation + GUID self-routing + field-perturbation probe#549
Merged
Merged
Conversation
…istance, Morton-pyramid perturbation field A basin IS a GUID-keyed Node owning a MailboxSoA of its members; the substrate becomes a tree of MailboxSoAs (= E-PANCAKES radix subtree made physical). Distance is implicit as hop count = the already-wired node_distance(PrefixDepth) tree-hop metric [G]. The 4-ary basin fan-out IS the Morton tile pyramid (quadtree subdivision = HHTL nibble-interleave), so mailbox distribution is modeled by perturbation-sim's L1-L4 cascade and becomes a field perturbation-learning surface. Out-family slot resolution subsumes the operator's 3 options: ClassView inheritance (1+2) picks the sibling basin-node; global edge (3) = basin-tree ref-escape walk, no 16-byte-block widening. SoA-ownership recursion graded CONJECTURE (deserves a 5+3 before wiring); distance=hop=PrefixDepth identity is FINDING [G]; field-perturbation- learning needs a probe before promotion. CHAODA reclassified as unary node_anomaly, not a pairwise DistanceMeans. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…oarse Walsh band of its members In a Morton/Walsh tile pyramid the parent tile is the low-pass downsample (coarse Walsh band) of its 4 children. E-BASIN-IS-A-NODE made the basin the parent node in that pyramid, so a family/basin node structurally carries the coarse-band summary of its members' field in its own value = walsh_pyramid_energy coarse fraction = the per-basin free-energy proxy (E-WHT-META-AWARENESS Claim 1). Meta-awareness is therefore not a new SoA column or service — it is what a family node already IS by sitting one pyramid level above its mailbox. Recursion: the root node is global meta-awareness; surprise is visible at the parent without a member sweep. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
… navigation Realizes basin-IS-a-node (E-BASIN-IS-A-NODE) as virtual tree navigation over the flat MailboxSoA — no ownership change, no SoA restructure, zero-copy invariant untouched. Both are pure key arithmetic, zero value decode: - members(basin_row): the direct child nodes one HHTL tier down (is_ancestor_of + depth check) — one-to-many. - memberof(member_row): the parent basin via NiblePath::parent — many-to-one; None at the top tier or when the parent lives in another shard (resolve via the coarse router). They are inverses: every r in members(b) has memberof(r) == b. 5 new tests (direct-children, parent + inverse property, top-tier None, cross-shard None, F2 zero-value-decode guard). 15/15 mailbox_scan tests pass; clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…es the basin tree E-GUID-SELF-ROUTES-THE-BASIN-TREE: the HHTL nibbles are already in the GUID (classid·HEEL·HIP·TWIG), so the parent basin's address is HHTL-tier truncation of the child's own key (NiblePath::parent / from_guid_prefix). That prefix IS the shard/route key (E-COARSE-QUANTIZER) — no separate coarse-fingerprint table. memberof now returns Option<BasinOf>: - Local(row) — parent materialized in this mailbox; - Route(path) — parent in another shard, addressed by its HHTL prefix (route it); - None — only at the top tier (a top basin has no parent). An unmaterialized parent is a Route, not an absence: the GUID self-routes, so the entire ancestor chain's addresses derive from one key by truncation, zero lookups for addresses. 16/16 mailbox_scan tests pass (new: routes-when-parent- in-another-shard); clippy clean. Epiphany prepended. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
…in tree (green) Tests the one CONJECTURE left in E-BASIN-IS-A-NODE: that the Morton-pyramid distribution is perturbation-learnable. Minimal falsifiable form — the spectral perturbation already shipped (hhtl_keys = recursive Cheeger/Fiedler bisection, the dominant Laplacian perturbation eigenmode per tier) used AS the basin placement, measured by the exact node_distance(PrefixDepth) tree-hop metric. Result on a planted-community grid (4×8 nodes, 76 similar pairs): perturbation-derived placement: mean tree-hop 1.00 over similar pairs random placement : 4.13 improvement : 75.8% (gate >= 15%, asserts) Promotes the mechanism CONJECTURE -> measured FINDING [G]: the field perturbation finds a placement that clusters similar items at far lower hop than random. The full online iterative learner stays future work; this proves its precondition. Zero-dep (SplitMix64), deterministic; clippy + fmt clean. Epiphany updated with the probe result. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
Board-hygiene prepend for the members/memberof navigation + GUID-self-routing + field-perturbation probe + three epiphanies (E-BASIN-IS-A-NODE, E-FAMILY-NODE-IS-META-AWARENESS, E-GUID-SELF-ROUTES-THE-BASIN-TREE). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughAdds ChangesBasin Navigation and Placement Probe
Internal Dev-Board Notes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
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 |
![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: 839c4a953a
ℹ️ 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".
| /// - `None` — only at the top tier (`parent() == None`, the basin/DOLCE top facet | ||
| /// has no parent). | ||
| pub fn memberof<V: MailboxSoaView>(view: &V, member_row: usize) -> Option<BasinOf> { | ||
| let parent = view.hhtl_path_at(member_row)?.parent()?; |
There was a problem hiding this comment.
When a view uses the documented deferred-binding behavior for MailboxSoaView::hhtl_path_at and returns None, this ? makes memberof return the same None used for a real top-tier basin. That contradicts the new API contract that None means only parent() == None, and consumers cannot tell “no path materialized; fall back” from “this node has no parent,” so rows with missing HHTL paths will silently stop routing instead of being handled as unresolved.
Useful? React with 👍 / 👎.
AdaWorldAPI
added a commit
that referenced
this pull request
Jun 19, 2026
…outage-probe basin-node follow-up: codex #549 P2 (memberof Top vs unresolved) + outage-over-HHTL probe (corrects E-BASIN-IS-A-NODE)
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 19, 2026
…erit are the same members/memberof primitive (#545..#551) Operator nudge (2026-06-19): "the family nodes introduced in lance-graph 545..551 could serve as mixin — group.memberof/members where group is the mixin node." This RESOLVES a divergence I flagged wrong earlier this session. When asked whether the Rails spine could verify Odoo AR-shapedness, I said yes but called Odoo's _inherit "a non-AR shape with no Rails analog." That was wrong: the Rails analog is include (concerns), and BOTH lower to the family-node members/memberof primitive from #549 (graph::mailbox_scan::{members, memberof, BasinOf}). A mixin IS a family/group node; include/_inherit IS the memberof edge. New surface: - mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>> Reads includes_module (Rails) or inherits_from (Odoo), ns-strips, returns the `members` direction (memberof is the transpose). - shared_mixin_groups(members, min) -> Vec<group> The ≥2-member fan-out filter: a group shared by ≥2 classes is a genuine mixin; a single-member group is an STI base / model extension, not a mixin. Same distinction members(basin) draws in #549. Grounded in the harvest (not asserted): - OSB carries 37 includes_module triples (Client→PublicActivity::Model, Estimate→Trackstamps/DateFormats). - Odoo carries 166 inherits_from triples; mail_thread is a group node with 70+ members (sale_order, account_account, purchase_order, ...). account_move rides mail_activity_mixin + sequence_mixin, NOT mail_thread directly — the test preserves the harvest's distinction. - Cross-curator semantic convergence: OSB PublicActivity::Model (activity tracking) ≈ Odoo mail_thread / mail_activity_mixin. Both curators independently grew an activity mixin group. 4 tests, all green: - odoo_mail_thread_is_a_family_group_node_with_many_members - osb_rails_public_activity_model_is_a_family_group_node - rails_include_and_odoo_inherit_are_the_same_family_node_primitive (the divergence-resolution test) - single_member_extension_is_not_a_mixin_group (fan-out honesty) Plus all 31 prior tests still green → 35/35 total. ar_shape clippy-clean. The lesson: an apparent "Odoo non-AR divergence" should first be checked against the lance-graph substrate primitives (#545..#551 members/memberof, the family-node tree) before being called a divergence — the substrate already had the home for it. The mixin group node carries shared behaviour down to members, which is E-FAMILY-NODE-IS-META-AWARENESS instantiated for ERP mixins (parent = coarse summary members inherit). EPIPHANIES E-OGAR-AR-SHAPE-SMOKE-6 prepended (includes the correction of my earlier wrong claim). Cross-refs: - E-BASIN-IS-A-NODE + E-FAMILY-NODE-IS-META-AWARENESS + E-GUID-SELF-ROUTES-THE-BASIN-TREE (the #545..#551 family-node arc) - graph::mailbox_scan::{members, memberof} (#549 substrate primitive) - E-OGAR-AR-SHAPE-SMOKE-5 (the concept-edge AST test; mixin membership is the inheritance-edge complement to the composition-edge graph) - AdaWorldAPI/OGAR project_actor (STI-collapse used the same shape) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xzyc27Nx3f8WC5KzwfWfjx
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 19, 2026
…erit are the same members/memberof primitive (#545..#551) Operator nudge (2026-06-19): "the family nodes introduced in lance-graph 545..551 could serve as mixin — group.memberof/members where group is the mixin node." This RESOLVES a divergence I flagged wrong earlier this session. When asked whether the Rails spine could verify Odoo AR-shapedness, I said yes but called Odoo's _inherit "a non-AR shape with no Rails analog." That was wrong: the Rails analog is include (concerns), and BOTH lower to the family-node members/memberof primitive from #549 (graph::mailbox_scan::{members, memberof, BasinOf}). A mixin IS a family/group node; include/_inherit IS the memberof edge. New surface: - mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>> Reads includes_module (Rails) or inherits_from (Odoo), ns-strips, returns the `members` direction (memberof is the transpose). - shared_mixin_groups(members, min) -> Vec<group> The ≥2-member fan-out filter: a group shared by ≥2 classes is a genuine mixin; a single-member group is an STI base / model extension, not a mixin. Same distinction members(basin) draws in #549. Grounded in the harvest (not asserted): - OSB carries 37 includes_module triples (Client→PublicActivity::Model, Estimate→Trackstamps/DateFormats). - Odoo carries 166 inherits_from triples; mail_thread is a group node with 70+ members (sale_order, account_account, purchase_order, ...). account_move rides mail_activity_mixin + sequence_mixin, NOT mail_thread directly — the test preserves the harvest's distinction. - Cross-curator semantic convergence: OSB PublicActivity::Model (activity tracking) ≈ Odoo mail_thread / mail_activity_mixin. Both curators independently grew an activity mixin group. 4 tests, all green: - odoo_mail_thread_is_a_family_group_node_with_many_members - osb_rails_public_activity_model_is_a_family_group_node - rails_include_and_odoo_inherit_are_the_same_family_node_primitive (the divergence-resolution test) - single_member_extension_is_not_a_mixin_group (fan-out honesty) Plus all 31 prior tests still green → 35/35 total. ar_shape clippy-clean. The lesson: an apparent "Odoo non-AR divergence" should first be checked against the lance-graph substrate primitives (#545..#551 members/memberof, the family-node tree) before being called a divergence — the substrate already had the home for it. The mixin group node carries shared behaviour down to members, which is E-FAMILY-NODE-IS-META-AWARENESS instantiated for ERP mixins (parent = coarse summary members inherit). EPIPHANIES E-OGAR-AR-SHAPE-SMOKE-6 prepended (includes the correction of my earlier wrong claim). Cross-refs: - E-BASIN-IS-A-NODE + E-FAMILY-NODE-IS-META-AWARENESS + E-GUID-SELF-ROUTES-THE-BASIN-TREE (the #545..#551 family-node arc) - graph::mailbox_scan::{members, memberof} (#549 substrate primitive) - E-OGAR-AR-SHAPE-SMOKE-5 (the concept-edge AST test; mixin membership is the inheritance-edge complement to the composition-edge graph) - AdaWorldAPI/OGAR project_actor (STI-collapse used the same shape) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xzyc27Nx3f8WC5KzwfWfjx
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 20, 2026
…erit are the same members/memberof primitive (#545..#551) Operator nudge (2026-06-19): "the family nodes introduced in lance-graph 545..551 could serve as mixin — group.memberof/members where group is the mixin node." This RESOLVES a divergence I flagged wrong earlier this session. When asked whether the Rails spine could verify Odoo AR-shapedness, I said yes but called Odoo's _inherit "a non-AR shape with no Rails analog." That was wrong: the Rails analog is include (concerns), and BOTH lower to the family-node members/memberof primitive from #549 (graph::mailbox_scan::{members, memberof, BasinOf}). A mixin IS a family/group node; include/_inherit IS the memberof edge. New surface: - mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>> Reads includes_module (Rails) or inherits_from (Odoo), ns-strips, returns the `members` direction (memberof is the transpose). - shared_mixin_groups(members, min) -> Vec<group> The ≥2-member fan-out filter: a group shared by ≥2 classes is a genuine mixin; a single-member group is an STI base / model extension, not a mixin. Same distinction members(basin) draws in #549. Grounded in the harvest (not asserted): - OSB carries 37 includes_module triples (Client→PublicActivity::Model, Estimate→Trackstamps/DateFormats). - Odoo carries 166 inherits_from triples; mail_thread is a group node with 70+ members (sale_order, account_account, purchase_order, ...). account_move rides mail_activity_mixin + sequence_mixin, NOT mail_thread directly — the test preserves the harvest's distinction. - Cross-curator semantic convergence: OSB PublicActivity::Model (activity tracking) ≈ Odoo mail_thread / mail_activity_mixin. Both curators independently grew an activity mixin group. 4 tests, all green: - odoo_mail_thread_is_a_family_group_node_with_many_members - osb_rails_public_activity_model_is_a_family_group_node - rails_include_and_odoo_inherit_are_the_same_family_node_primitive (the divergence-resolution test) - single_member_extension_is_not_a_mixin_group (fan-out honesty) Plus all 31 prior tests still green → 35/35 total. ar_shape clippy-clean. The lesson: an apparent "Odoo non-AR divergence" should first be checked against the lance-graph substrate primitives (#545..#551 members/memberof, the family-node tree) before being called a divergence — the substrate already had the home for it. The mixin group node carries shared behaviour down to members, which is E-FAMILY-NODE-IS-META-AWARENESS instantiated for ERP mixins (parent = coarse summary members inherit). EPIPHANIES E-OGAR-AR-SHAPE-SMOKE-6 prepended (includes the correction of my earlier wrong claim). Cross-refs: - E-BASIN-IS-A-NODE + E-FAMILY-NODE-IS-META-AWARENESS + E-GUID-SELF-ROUTES-THE-BASIN-TREE (the #545..#551 family-node arc) - graph::mailbox_scan::{members, memberof} (#549 substrate primitive) - E-OGAR-AR-SHAPE-SMOKE-5 (the concept-edge AST test; mixin membership is the inheritance-edge complement to the composition-edge graph) - AdaWorldAPI/OGAR project_actor (STI-collapse used the same shape) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xzyc27Nx3f8WC5KzwfWfjx
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 20, 2026
…erit are the same members/memberof primitive (#545..#551) Operator nudge (2026-06-19): "the family nodes introduced in lance-graph 545..551 could serve as mixin — group.memberof/members where group is the mixin node." This RESOLVES a divergence I flagged wrong earlier this session. When asked whether the Rails spine could verify Odoo AR-shapedness, I said yes but called Odoo's _inherit "a non-AR shape with no Rails analog." That was wrong: the Rails analog is include (concerns), and BOTH lower to the family-node members/memberof primitive from #549 (graph::mailbox_scan::{members, memberof, BasinOf}). A mixin IS a family/group node; include/_inherit IS the memberof edge. New surface: - mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>> Reads includes_module (Rails) or inherits_from (Odoo), ns-strips, returns the `members` direction (memberof is the transpose). - shared_mixin_groups(members, min) -> Vec<group> The ≥2-member fan-out filter: a group shared by ≥2 classes is a genuine mixin; a single-member group is an STI base / model extension, not a mixin. Same distinction members(basin) draws in #549. Grounded in the harvest (not asserted): - OSB carries 37 includes_module triples (Client→PublicActivity::Model, Estimate→Trackstamps/DateFormats). - Odoo carries 166 inherits_from triples; mail_thread is a group node with 70+ members (sale_order, account_account, purchase_order, ...). account_move rides mail_activity_mixin + sequence_mixin, NOT mail_thread directly — the test preserves the harvest's distinction. - Cross-curator semantic convergence: OSB PublicActivity::Model (activity tracking) ≈ Odoo mail_thread / mail_activity_mixin. Both curators independently grew an activity mixin group. 4 tests, all green: - odoo_mail_thread_is_a_family_group_node_with_many_members - osb_rails_public_activity_model_is_a_family_group_node - rails_include_and_odoo_inherit_are_the_same_family_node_primitive (the divergence-resolution test) - single_member_extension_is_not_a_mixin_group (fan-out honesty) Plus all 31 prior tests still green → 35/35 total. ar_shape clippy-clean. The lesson: an apparent "Odoo non-AR divergence" should first be checked against the lance-graph substrate primitives (#545..#551 members/memberof, the family-node tree) before being called a divergence — the substrate already had the home for it. The mixin group node carries shared behaviour down to members, which is E-FAMILY-NODE-IS-META-AWARENESS instantiated for ERP mixins (parent = coarse summary members inherit). EPIPHANIES E-OGAR-AR-SHAPE-SMOKE-6 prepended (includes the correction of my earlier wrong claim). Cross-refs: - E-BASIN-IS-A-NODE + E-FAMILY-NODE-IS-META-AWARENESS + E-GUID-SELF-ROUTES-THE-BASIN-TREE (the #545..#551 family-node arc) - graph::mailbox_scan::{members, memberof} (#549 substrate primitive) - E-OGAR-AR-SHAPE-SMOKE-5 (the concept-edge AST test; mixin membership is the inheritance-edge complement to the composition-edge graph) - AdaWorldAPI/OGAR project_actor (STI-collapse used the same shape) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xzyc27Nx3f8WC5KzwfWfjx
AdaWorldAPI
pushed a commit
that referenced
this pull request
Jun 21, 2026
…erit are the same members/memberof primitive (#545..#551) Operator nudge (2026-06-19): "the family nodes introduced in lance-graph 545..551 could serve as mixin — group.memberof/members where group is the mixin node." This RESOLVES a divergence I flagged wrong earlier this session. When asked whether the Rails spine could verify Odoo AR-shapedness, I said yes but called Odoo's _inherit "a non-AR shape with no Rails analog." That was wrong: the Rails analog is include (concerns), and BOTH lower to the family-node members/memberof primitive from #549 (graph::mailbox_scan::{members, memberof, BasinOf}). A mixin IS a family/group node; include/_inherit IS the memberof edge. New surface: - mixin_members(triples, ns, is_rails) -> BTreeMap<group, BTreeSet<member>> Reads includes_module (Rails) or inherits_from (Odoo), ns-strips, returns the `members` direction (memberof is the transpose). - shared_mixin_groups(members, min) -> Vec<group> The ≥2-member fan-out filter: a group shared by ≥2 classes is a genuine mixin; a single-member group is an STI base / model extension, not a mixin. Same distinction members(basin) draws in #549. Grounded in the harvest (not asserted): - OSB carries 37 includes_module triples (Client→PublicActivity::Model, Estimate→Trackstamps/DateFormats). - Odoo carries 166 inherits_from triples; mail_thread is a group node with 70+ members (sale_order, account_account, purchase_order, ...). account_move rides mail_activity_mixin + sequence_mixin, NOT mail_thread directly — the test preserves the harvest's distinction. - Cross-curator semantic convergence: OSB PublicActivity::Model (activity tracking) ≈ Odoo mail_thread / mail_activity_mixin. Both curators independently grew an activity mixin group. 4 tests, all green: - odoo_mail_thread_is_a_family_group_node_with_many_members - osb_rails_public_activity_model_is_a_family_group_node - rails_include_and_odoo_inherit_are_the_same_family_node_primitive (the divergence-resolution test) - single_member_extension_is_not_a_mixin_group (fan-out honesty) Plus all 31 prior tests still green → 35/35 total. ar_shape clippy-clean. The lesson: an apparent "Odoo non-AR divergence" should first be checked against the lance-graph substrate primitives (#545..#551 members/memberof, the family-node tree) before being called a divergence — the substrate already had the home for it. The mixin group node carries shared behaviour down to members, which is E-FAMILY-NODE-IS-META-AWARENESS instantiated for ERP mixins (parent = coarse summary members inherit). EPIPHANIES E-OGAR-AR-SHAPE-SMOKE-6 prepended (includes the correction of my earlier wrong claim). Cross-refs: - E-BASIN-IS-A-NODE + E-FAMILY-NODE-IS-META-AWARENESS + E-GUID-SELF-ROUTES-THE-BASIN-TREE (the #545..#551 family-node arc) - graph::mailbox_scan::{members, memberof} (#549 substrate primitive) - E-OGAR-AR-SHAPE-SMOKE-5 (the concept-edge AST test; mixin membership is the inheritance-edge complement to the composition-edge graph) - AdaWorldAPI/OGAR project_actor (STI-collapse used the same shape) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xzyc27Nx3f8WC5KzwfWfjx
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
Closes the edge-distance / basin-node arc. The result: the substrate is a virtual tree of MailboxSoAs, navigated by pure key arithmetic — with no ownership restructure. A basin IS a node; the tree is the radix trie of the GUID keys; parent↔children is two prefix functions over the flat SoA. The zero-copy / Lance-tombstone invariant is untouched.
Code (lance-graph core —
graph::mailbox_scan)members(basin)(one-to-many) — the direct child nodes one HHTL tier down (is_ancestor_of+ depth).memberof(node) -> Option<BasinOf>(many-to-one) — the parent basin viaNiblePath::parent:BasinOf::Local(row)— parent materialized in this mailbox;BasinOf::Route(NiblePath)— parent in another shard, addressed by its HHTL prefix (the prefix IS the route key — no coarse-fingerprint table);None— only at the top tier (a top basin has no parent).members/memberofare inverses. All pure key arithmetic, zero value decode (F2-guarded). 5 new tests; 16/16 mailbox_scan tests green; clippy clean.Probe (perturbation-sim —
examples/basin_placement_learning.rs)Tests the one CONJECTURE left in
E-BASIN-IS-A-NODE(field-perturbation learns placement). The spectral perturbation already shipped (hhtl_keys= recursive Cheeger/Fiedler bisection = the dominant Laplacian perturbation eigenmode per tier) used as the basin placement, scored by the exactnode_distance(PrefixDepth)tree-hop.Green → promotes the mechanism CONJECTURE → measured FINDING [G]. The full online iterative learner stays future work; this proves its precondition. Zero-dep (SplitMix64), deterministic.
Epiphanies (the arc)
E-BASIN-IS-A-NODE— basin = node; distance is implicit as hop count = the already-wirednode_distance(PrefixDepth); the 4-ary basin fan-out IS the Morton tile pyramid, so the mailbox distribution is a perturbation-learnable field.E-FAMILY-NODE-IS-META-AWARENESS— the parent node IS the coarse Walsh band of its subtree, so meta-awareness is structural (a parent), not a new SoA column.E-GUID-SELF-ROUTES-THE-BASIN-TREE— HHTL-tier truncation of the GUID gives every ancestor's route key;memberofneeds no coarse-fingerprint table.Capstone: one 512-byte key, read five ways — representation / ontology / compute (Morton pyramid) / learning / meta-awareness — four of the five are key-resident, zero value decode.
Deferred
memberofcross-shard row-fetch via a path→row index (the route key is returned today; the fetch is the consumer's).node_anomaly(out ofDistanceMeans); helix/PqAdc value-tier means.Board hygiene
PR_ARC_INVENTORY.md+LATEST_STATE.mdupdated in-branch (per the Mandatory Board-Hygiene Rule).🤖 Generated with Claude Code
Generated by Claude Code
Summary by CodeRabbit
New Features
Documentation