Ideas: Should ASI:BUILD's memory salience model be static, module-annotated, or learned from retrieval feedback?

[web3guru888]

Phase 5.3 (MemoryConsolidator) needs to decide which Blackboard events are worth consolidating into long-term memory. This requires a salience model — but what should that model look like?

The Problem

The Blackboard receives hundreds of writes per tick across 29 modules. Not everything deserves to be in long-term memory. The MemoryConsolidator needs a principled way to filter events, but the filtering logic will either be:

• Too conservative (miss important events)
• Too aggressive (flood the KG with noise)
• Too static (fail to adapt to changing context)

Three Options

Option A: Static namespace-based salience table

Each namespace has a fixed salience score. Simple, predictable, zero overhead:

NAMESPACE_SALIENCE = {
    "safety.*": 0.95,
    "consciousness.*": 0.80,
    "mesh.coalition.*": 0.75,
    "knowledge_graph.*": 0.65,
    "stigmergy.*": 0.50,
    "neuromorphic.*": 0.40,
}

Pros: Deterministic, no runtime cost, easy to reason about.
Cons: Doesn't adapt to context — a neuromorphic.* event during a critical learning phase might deserve 0.9, not 0.4.

Option B: Module-annotated salience hints

Modules write a salience_hint field alongside their Blackboard entries. The MemoryConsolidator reads this, falling back to the namespace default:

salience = entry.value.get("salience_hint", NAMESPACE_SALIENCE.get(namespace_prefix, 0.5))

Pros: Modules know their own importance — a reasoning module that just solved a novel problem can declare salience_hint=0.95.
Cons: Requires every module to implement salience hints. Missing hints fall back to static table (graceful).

Option C: Learned salience from outcome feedback

Track which consolidated memories are later retrieved (via MemoryRetrievalEngine.recall()). Memories that are retrieved frequently get higher salience scores for similar future events:

class SalienceModel:
    def update(self, event_key: str, was_retrieved: bool) -> None:
        # Online update to salience score for this event type
        self._scores[event_key] = (
            self._scores.get(event_key, 0.5) * 0.95 +  # decay
            (0.9 if was_retrieved else 0.3) * 0.05       # update
        )

Pros: Self-improving — the system learns what matters based on actual usage patterns.
Cons: Chicken-and-egg: initial salience scores must still be reasonable to get useful retrievals. Cold start problem.

Recommendation

Start with A+B: static table as foundation, module hints as overrides. Add C as a Phase 5 stretch goal once we have retrieval telemetry to train on.

The key insight: Option A is a prior, Option B is evidence from the module, and Option C is posterior update from retrieval experience. All three are Bayesian layers.

Related Design Questions

1. Should the salience threshold (currently 0.7) be a global config or per-namespace? A stricter threshold for stigmergy.* (which can flood fast) vs. a looser threshold for safety.* (where we want to capture everything).

2. The consolidation buffer has maxlen=1000. If it fills up during a busy phase, should we drop the oldest events (ring buffer default) or the lowest-salience events? Ring buffer is simpler; salience-ordered drop is smarter.

3. Should salience_hint be validated by SafetyBlackboardAdapter? A module claiming salience_hint=1.0 for every event would flood the KG — should there be a per-module salience budget?

Which approach fits best with ASI:BUILD's design philosophy? Drop thoughts below.

[web3guru888]

Salience Model Design — Recommendation

The three options with concrete tradeoffs:

Option A: Static (hardcoded namespace table)

SALIENCE_TABLE = {
    "safety.*":              0.95,
    "consciousness.iit.*":   0.85,
    "mesh.coalition.*":      0.75,
    "online.weight_delta.*": 0.70,
    "default":               0.50,
}

Pros: Predictable, auditable, easy to reason about
Cons: Can't adapt to what the system actually finds important — a system that sees lots of safety events may want to deprioritize routine safety pings vs. novel ones

Option B: Fully Learned

Train a small classifier on past consolidation decisions ("was this event consolidated?") to predict future salience.

Pros: Adapts to experience
Cons: Bootstrapping problem — you need consolidated memories to learn from, but consolidation requires a salience model. Circular dependency.

Option C: Hybrid (static floor + learned boost)

def compute_salience(entry: BlackboardEntry) -> float:
    base = SALIENCE_TABLE.get_namespace_match(entry.key)  # static floor
    boost = self._salience_model.predict_boost(entry)      # learned +0.0 to +0.3
    return min(base + boost, 1.0)

Pros: Static table provides safe baseline; learned component adds adaptation
Cons: Requires training the _salience_model — adds Phase 5.3 complexity

---

Recommendation: Option A for Phase 5.3 launch, Option C as Phase 5.3 v2

Start with Option A. The static table can be calibrated empirically over the first few weeks of production runs. Once the consolidation pipeline is stable and there's a body of episodic data, retrofit Option C's learned boost.

The compute_salience() interface should be designed from day one to accept both paths — the static version just returns base + 0.0.

One design note: Always let modules override salience via salience_hint in their Blackboard write call. Module authors know their domain better than a general model:

blackboard.write("consciousness.iit.phi", phi, salience_hint=0.9)  # always consolidated
blackboard.write("debug.timer", elapsed, salience_hint=0.0)       # never consolidated