Q&A — Phase 29.1 SelfModel

[web3guru888]

Q&A — Phase 29.1 SelfModel

Issue: #627 | Show & Tell: #632 | Planning: #626

Post your questions about the SelfModel component here. Below are answers to the most common questions from the planning discussion.

---

Q1: Why exactly five domains? Isn't this taxonomy arbitrary?

A: The five-domain taxonomy (ARCHITECTURE, RESOURCE, COMPETENCE, HISTORY, SOCIAL) maps directly to Neisser's (1988) five kinds of self-knowledge from cognitive psychology: ecological, private, conceptual, extended, and interpersonal. While any taxonomy involves design choices, this one has three advantages: (1) it aligns with established cognitive science, (2) the domains are roughly orthogonal — knowing your module topology tells you nothing about your social trust scores, and (3) each domain has a distinct staleness profile, enabling per-domain refresh rates. That said, the enum is extensible — adding a sixth domain (e.g., EMOTIONAL from Phase 21's EmotionModel) requires only adding the enum variant and a corresponding _refresh_domain branch.

Q2: How is the auto-refresh interval tuned per domain?

A: Each domain has a staleness_threshold_s in SelfModelConfig:

Domain	Default Threshold	Rationale
RESOURCE	5 seconds	CPU/memory/token budgets change rapidly
COMPETENCE	30 seconds	Scores shift after task completions
ARCHITECTURE	60 seconds	Module topology changes are rare
HISTORY	120 seconds	Autobiographical entries accumulate slowly
SOCIAL	300 seconds	Peer trust scores evolve gradually

These are configurable at runtime. The _refresh_loop checks time.monotonic() - last_refresh[domain] > threshold on each cycle, so the actual refresh rate is max(loop_interval, threshold). In practice, the loop runs every 2 seconds, so RESOURCE refreshes every ~6s (next cycle after staleness), while SOCIAL refreshes every ~300s.

Q3: How does competence assessment actually work?

A: The CapabilityAssessor computes competence scores using a weighted exponential moving average (EMA) over recent task outcomes:

score_new = α * outcome + (1 - α) * score_old

Where outcome ∈ [0.0, 1.0] is task success (binary or graded), and α = 0.1 by default (tunable). The EMA naturally decays old performance, so a system that was once good at reasoning but has degraded will see its score drop. The CompetenceProfile also stores a deque(maxlen=100) of raw outcomes for trend analysis — the MetaCognitiveMonitor (29.3) can detect if scores are systematically declining.

Q4: What happens when the ResourceInventory becomes stale?

A: Staleness is handled through a two-tier strategy:

1. Soft staleness (age > threshold but < 2×threshold): The snapshot is returned with stale=True flag. Consumers can decide whether to trust it — the ExecutiveController (28.4) may widen its planning margins when working with stale resource data.
2. Hard staleness (age > 2×threshold): The asi_self_model_staleness_alerts_total counter increments, a warning is logged, and a forced refresh is attempted. If that also fails, the system falls back to conservative defaults (e.g., assume only 50% of nominal resource budgets).

This mirrors interoception in biological systems — when you can't tell how tired you are, you assume you're more tired than you probably are.

Q5: How does ArchitectureNode health scoring work?

A: Each ArchitectureNode (representing a loaded module/component) has a health_score: float computed from four signals:

Signal	Weight	Source
Heartbeat recency	0.3	Last successful health check
Error rate (5-min window)	0.3	Prometheus error counter
Latency p99 vs SLA	0.2	PerformanceProfiler (16.1)
Dependency health (mean of children)	0.2	Recursive from dependency graph

The final score is Σ(weight_i * signal_i) clipped to [0.0, 1.0]. Scores below 0.5 trigger architectural alerts; scores below 0.2 mark the node as DEGRADED in the architecture map.

Q6: What's the testing strategy — mocks or real subsystems?

A: Both, at different levels:

• Unit tests: Use NullSelfModel (no-op implementation) to test consumers that depend on SelfModel Protocol. Use unittest.mock.AsyncMock to test DynamicSelfModel with mocked data sources.
• Integration tests: Wire DynamicSelfModel to a real WorldModel (Phase 13.1) and PerformanceProfiler (Phase 16.1) in a test harness. Verify that staleness thresholds trigger refreshes and that snapshot data flows correctly.
• Property-based tests (Hypothesis): Generate random SelfModelDomain sequences and verify that the snapshot is always consistent (no partial updates visible to consumers).

Key test targets from the issue spec: test_snapshot_frozen_immutable, test_stale_domain_triggers_refresh, test_competence_ema_convergence, test_architecture_health_recursive.

Q7: How does SelfModel integrate with WorldModel (Phase 13.1)?

A: The relationship is complementary but distinct:

• WorldModel represents the external environment — what the system knows about the world
• SelfModel represents the internal state — what the system knows about itself

They share the same update() pattern (periodic refresh with staleness tracking) but operate on different data sources. The SelfModel subscribes to WorldModel events to understand its own position within the world — e.g., "I am node 3 of 5 in a federated deployment, and peer latencies are rising." The WorldModel does not know about the SelfModel; the dependency is one-directional.

In code:

class DynamicSelfModel:
    def __init__(self, world_model: WorldModel, ...):
        self._world_model = world_model
        # Subscribe to world changes that affect self-knowledge
        world_model.on_update(self._handle_world_change)

---

Ask your questions below! Tag the issue (#627) for implementation-specific queries.