consciousness/poc-memory/.claude/analysis/2026-03-14-link-strength-feedback.md

Link Strength Feedback Design

2026-03-14, designed with Kent

The two signals

"Not relevant" → weaken the EDGE

The routing failed. Search followed a link and arrived at a node that doesn't relate to what I was looking for. The edge carried activation where it shouldn't have.

• Trace back through memory-search's recorded activation path
• Identify which edge(s) carried activation to the bad result
• Weaken those edges by a conscious-scale delta (0.01)

"Not useful" → weaken the NODE

The routing was correct but the content is bad. The node itself isn't valuable — stale, wrong, poorly written, duplicate.

• Downweight the node (existing poc-memory wrong behavior)
• Don't touch the edges — the path was correct, the destination was bad

Three tiers of adjustment

Tier 1: Agent automatic (0.00001 per event)

• Agent follows edge A→B during a run
• If the run produces output that gets used → strengthen A→B
• If the run produces nothing useful → weaken A→B
• The agent doesn't know this is happening — daemon tracks it
• Clamped to [0.05, 0.95] — edges can never hit 0 or 1
• Logged: every adjustment recorded with (agent, edge, delta, timestamp)

Tier 2: Conscious feedback (0.01 per event)

• poc-memory not-relevant KEY → trace activation path, weaken edges
• poc-memory not-useful KEY → downweight node
• poc-memory used KEY → strengthen edges in the path that got here
• 100x stronger than agent signal — deliberate judgment
• Still clamped, still logged

Tier 3: Manual override (direct set)

• poc-memory graph link-strength SRC DST VALUE → set directly
• For when we know exactly what a strength should be
• Rare, but needed for bootstrapping / correction

Implementation: recording the path

memory-search already computes the spread activation trace. Need to:

1. Record the activation path for each result (which edges carried how much activation to arrive at this node)
2. Persist this per-session so not-relevant can look it up
3. The record-hits RPC already sends keys to the daemon — extend to include (key, activation_path) pairs

Implementation: agent tracking

In the daemon's job functions:

1. Before LLM call: record which nodes and edges the agent received
2. After LLM call: parse output for LINK/WRITE_NODE actions
3. If actions are created and later get used → the input edges were useful
4. If no actions or actions never used → the input edges weren't useful
5. This is a delayed signal — requires tracking across time

Simpler first pass: just track co-occurrence. If two nodes appear together in a successful agent run, strengthen the edge between them. No need to track which specific edge was "followed."

Clamping

fn adjust_strength(current: f32, delta: f32) -> f32 {
    (current + delta).clamp(0.05, 0.95)
}

Edges can asymptotically approach 0 or 1 but never reach them. This prevents dead edges (can always be revived by strong signal) and prevents edges from becoming unweakenable.

Logging

Every adjustment logged as JSON event:

{"ts": "...", "event": "strength_adjust", "source": "agent|conscious|manual",
 "edge": ["nodeA", "nodeB"], "old": 0.45, "new": 0.4501, "delta": 0.0001,
 "reason": "co-retrieval in linker run c-linker-42"}

This lets us:

• Watch the distribution shift over time
• Identify edges that are oscillating (being pulled both ways)
• Tune the delta values based on observed behavior
• Roll back if something goes wrong

Migration from current commands

• poc-memory wrong KEY [CTX] → splits into not-relevant and not-useful
• poc-memory used KEY → additionally strengthens edges in activation path
• Both old commands continue to work for backward compat, mapped to the most likely intent (wrong → not-useful, used → strengthen path)