probe: family-basin Weyl multi-hop is hop-local at the crisp tier (reinstates hop-bounds-reach, tier-scoped)#551
Merged
Conversation
… the crisp tier (reinstatement) Tests the operator hypothesis "with family basin it works now with weyl multihop" on real ES PyPSA data, sweeping every HHTL tier. Containment = fraction of L⁺ dipole-response energy kept in the seed's basin: tier basins within seam ratio verdict HEEL 2 0.957 0.621 1.54 HOP-LOCAL HIP 4 0.579 0.621 0.93 leaks LEAF 7 0.529 0.485 1.09 leaks At the crisp top split a within-basin perturbation stays 95.7% contained and beats the seam-straddle (ratio 1.54) — Davis-Kahan block-localization under weak inter-block coupling. REINSTATES "hop bounds reach" on the eigenvalue axis (tier-scoped): the earlier E-OUTAGE-CASCADE-IS-NON-LOCAL was the un-partitioned global solve AND seeded the max-flow line = the seam itself. Finer tiers leak (within ~ seam), matching probe C (bisection stable at top, marginal deeper) and the out-of-family tie growth 0->2->9->20. Self-correction: first verdict rubber-stamped a 0.044 gap + a vacuous DK bound (2199) as SUPPORTED; tightened to per-tier within>=0.70 AND within/seam>=1.30 AND Weyl, dropped DK-as-evidence. Epiphany E-FAMILY-BASIN-WEYL-HOP-LOCAL-AT- CRISP-TIER prepended (paired reinstatement). Zero-dep, deterministic; clippy + fmt clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
More reviews will be available in 41 minutes and 23 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. 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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a new Rust example ChangesFamily Basin Weyl Hop-Locality Measurement
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/board/EPIPHANIES.md:
- Line 1: The statement on Line 1 uses Davis–Kahan as evidence to support the
claim about block-localization at the crisp top split, but Line 19 indicates
that Davis–Kahan was removed from the evidence policy. Reword the explanation in
Line 1 to remove the parenthetical Davis–Kahan reference and instead anchor the
claim solely to the retained gates and metrics that support the reinstatement of
the hop-local behavior at the crisp tier level. This ensures consistency between
the evidence cited and what is actually retained in the document.
In `@crates/perturbation-sim/examples/family_basin_weyl_multihop.rs`:
- Around line 46-62: Add a #[cfg(test)] module at the end of the file to include
focused unit tests for the helper functions. Create test functions for the
containment function covering normal cases and edge cases such as zero or
near-zero theta vectors, test the dipole function to verify it correctly creates
a balanced ±1 dipole vector at positions s and t, and add tests for gate
behavior when within and straddle evidence lists are empty. Each test should
validate the expected mathematical behavior of these measurement helpers and
edge cases.
- Around line 153-165: The tier support gate in the `supported` variable can
produce false positives because `weyl_ok` defaults to true when no edges exist
with matching partition endpoints (due to `is_none_or()` returning true in the
none case), and `ratio` becomes `f64::INFINITY` when `sm` is zero, allowing the
`ratio >= 1.30` check to pass trivially without actual seam samples. To fix
this, modify the logic so that `weyl_ok` only passes if at least one matching
edge exists AND the Weyl condition is satisfied, and modify the `ratio`
condition to require that seam samples actually exist (either by preventing the
infinity default or by adding an explicit requirement that `sm > 0.0` as part of
the `supported` gate alongside the existing ratio check).
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 41347855-3b11-4f40-b5ea-6e29a142dd4e
📒 Files selected for processing (3)
.claude/board/EPIPHANIES.mdcrates/perturbation-sim/Cargo.tomlcrates/perturbation-sim/examples/family_basin_weyl_multihop.rs
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
…g (coderabbit #551) Three CodeRabbit comments, all valid: 1. Gate false-positive (Major): weyl_ok defaulted to true when no within-basin line existed (is_none_or), and ratio became ∞ when no seam samples existed — either could label a tier HOP-LOCAL without a valid check. Fixed: weyl_ok unwraps to false on no within-line; ratio = 0 (not ∞) on no seam; extracted a single-source tier_supported() that requires has_within && has_straddle. 2. Missing tests (Major): added #[cfg(test)] for containment (incl. zero-field and empty-members edges), dipole balance, and the gate (incl. the missing- evidence cases that would previously false-positive). 3/3 pass. 3. EPIPHANIES DK wording (Minor): line 1 framed Davis-Kahan as the evidence while the body drops the DK bound as evidence. Reworded line 1 to anchor on the containment ratio (the retained gate) and mark DK explicitly as the mechanism, not the numeric evidence. Probe verdict unchanged (HEEL HOP-LOCAL, HIP/LEAF leak); clippy --tests + fmt clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi
4 tasks
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.
What this settles
You asked whether — with family basins — Weyl multi-hop works (vs the plain Weyl-first-hop + Kirchhoff, vs full CHAODA). I built the probe on the real ES PyPSA data, swept every HHTL tier, and the answer is yes, tier-scoped.
Containment = fraction of the L⁺ dipole-response energy kept in the seed's basin (high WITHIN + low SEAM ⇒ hop-local):
At the crisp top split, a within-basin perturbation stays 95.7% contained and clearly beats the seam-straddle — Davis-Kahan block-localization under weak inter-block coupling. This reinstates "hop bounds reach" on the eigenvalue axis (tier-scoped). The earlier
E-OUTAGE-CASCADE-IS-NON-LOCALfinding had two removable errors: it ran on the un-partitioned global solve AND seeded the max-flow line = the seam itself (a seam trip leaks by construction).Honest scope: HIP/LEAF leak (within ≈ seam) — the perturbation is not contained at finer tiers. This matches the spectral structure exactly: probe C (bisection stability) solid at the top (ES
(λ₃−λ₂)/λ₂ = 3.23), marginal deeper; and your "without family nodes" table's out-of-family tie growth 0→2→9→20. The 2-basin "HEEL" split here is that table's HIP 2-line seam (lines 46, 150) — labels offset by one, structure agrees.The three-axis close (a "surge" decomposes)
ndarray::hpc::clam)The family-basin layer (
E-BASIN-IS-A-NODE) is the keystone that block-diagonalizes the Laplacian so per-basin Weyl chains seam-to-seam.Process note (kept honest)
The probe's first verdict rubber-stamped a 0.044 within-vs-seam gap + a vacuous Davis-Kahan bound (2199) as "SUPPORTED" — the confirmation-bias trap. Tightened the gate to per-tier within ≥ 0.70 AND within/seam ratio ≥ 1.30 AND Weyl, and dropped the DK bound as evidence (uninformative when the eigengap is tiny). Under the honest gate only HEEL passes — the correct, nuanced result.
Zero-dep, deterministic; clippy + fmt clean. Excluded crate (runs locally/on-demand). Epiphany
E-FAMILY-BASIN-WEYL-HOP-LOCAL-AT-CRISP-TIERprepended as the paired reinstatement toE-OUTAGE-CASCADE-IS-NON-LOCAL.🤖 Generated with Claude Code
Generated by Claude Code
Summary by CodeRabbit
Documentation
Examples