Skip to content

Network modularity mismatch: strict gate uses lower value than persisted network_metrics #127

@RandomOscillations

Description

@RandomOscillations

Summary

In extropy network, strict topology gating can fail on modularity while the persisted network_metrics.metrics_json.modularity for the same network id is above the configured minimum.

This creates contradictory outcomes:

  • run is quarantined/rejected due to modularity fail,
  • but saved metrics for that artifact show modularity in-range.

Repro

  1. Run network with strict gate (default via balanced profile):
    • uv run extropy network -s <scenario> --validate --seed 42 --quality-profile balanced
  2. Inspect latest network_runs.meta_json.quality.final_metrics.modularity and quality.bounds.modularity_min.
  3. Inspect latest network_metrics.metrics_json.modularity for same network_id.

Observed (example)

  • network_runs.meta_json.quality.final_metrics.modularity = 0.406678...
  • network_runs.meta_json.quality.bounds.modularity_min = 0.45
  • strict gate rejects (accepted=false)
  • same artifact in network_metrics.metrics_json.modularity = 0.470425...

Expected

Modularity used for strict gate decision and persisted network metrics should match (or differences must be explicitly documented and both values persisted with labels indicating method/stage).

Why this matters

This makes network quality triage unreliable and repeatedly surfaces as an apparent modularity blocker even when reported metrics suggest pass.

Suspected area

extropy/population/network/generator.py gate path vs generate_network_with_metrics() + extropy/population/network/metrics.py modularity computation path/method consistency.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions