Knowledge ledger: entry shape, decay, and propagation #3

New issue

Open

opened 2026-11-15 01:09:53 +00:00 by muse-lantern · 0 comments

muse-lantern commented

2026-11-15 01:09:53 +00:00

Member

The plan

The knowledge ledger is the hive mind's memory: what a Commander knows, with provenance. Every entry is one thing a layer knows — what happened, where, when, who perceived it, how sure they are, and the path it travelled. The ledger's rules decide what stealth means in practice: a silent kill leaves no entry, a found body creates one, and a stale last-seen position must not let the AI cheat by remembering the player forever.

Current state

addons/daisy/src/knowledge.gd defines DaisyKnowledgeEntry with what, where, when, who_perceived, confidence, and propagation_path. DaisyCommander.knowledge_ledger is an append-only array; receive_knowledge appends, on_body_found writes a unit_lost entry with path [finder, commander], and union_knowledge() on the Director concatenates Commanders' ledgers on demand. apply_decay exists as a documented no-op — the decay rules are undecided, and nothing prunes the ledger yet.

What changes

Settle the entry shape, the decay and staleness rules, and the propagation rules. The work, in order:

Entry shape. Decide whether the current six fields are the final shape or whether entries need more: an expiry, a source layer, a supersedes link for corroboration/contradiction. Any new field must be justifiable from a rule below, not added speculatively.
Decay and staleness. Decide the rule for how knowledge goes stale: do last-seen positions decay in confidence over time, expire after a fixed interval, or stay until contradicted? The three options behave very differently in play — decay makes the AI gradually unsure, expiry makes it forget on a clock, until-contradicted makes it certain until proven wrong. Pick one per entry kind if the kinds differ (a lost unit is a fact; a last-seen position is a guess).
Implement decay. Fill in apply_decay per the settled rule and add a ledger prune pass. Decide when pruning runs — on a tick, on read, or on write — and make sure pruning never deletes the unit_lost fact of a found body while the alert it caused is still live.
Corroboration and contradiction. When a second NPC perceives the same thing, confidence rises; when a perception contradicts an entry (the player is seen somewhere else), the old entry is superseded, not silently kept alongside. Define the merge rule.
Propagation only via interruptible report. Knowledge travels up the chain only when an NPC reports it — shout, radio, or runner — and a report is an action that can be interrupted. If the reporting NPC is killed mid-report, the knowledge never arrives. Today perceive_sight hands the entry to the Commander directly; the report mechanic is new work: define what a report is mechanically (a timed action? a message with travel time?), what channels exist, and what interrupts one.
Tests. A stale entry expires or decays per the settled rule; a contradicted entry is superseded; an interrupted report never lands in the ledger; a completed report lands with its full propagation path.

What done looks like

apply_decay implements the settled rules, the ledger prunes on the settled schedule, reports are interruptible actions with named channels, corroboration and contradiction behave per the merge rule, and a test proves each rule. The design doc's knowledge section is updated to match.

Open questions

Decay, expiry, or until-contradicted — and does the answer differ by entry kind?
Does confidence decay with time, or only on contradiction?
What is a report mechanically — a timed action, a message with travel time, or something else?
What propagation channels exist — shout (instant but local, and the enemy hears it?), radio (instant but needs equipment?), runner (slow but silent)?
Does a unit_lost entry ever decay, or is a lost unit a permanent fact?

## The plan The knowledge ledger is the hive mind's memory: what a Commander knows, with provenance. Every entry is one thing a layer knows — what happened, where, when, who perceived it, how sure they are, and the path it travelled. The ledger's rules decide what stealth means in practice: a silent kill leaves no entry, a found body creates one, and a stale last-seen position must not let the AI cheat by remembering the player forever. ## Current state `addons/daisy/src/knowledge.gd` defines `DaisyKnowledgeEntry` with `what`, `where`, `when`, `who_perceived`, `confidence`, and `propagation_path`. `DaisyCommander.knowledge_ledger` is an append-only array; `receive_knowledge` appends, `on_body_found` writes a `unit_lost` entry with path `[finder, commander]`, and `union_knowledge()` on the Director concatenates Commanders' ledgers on demand. `apply_decay` exists as a documented no-op — the decay rules are undecided, and nothing prunes the ledger yet. ## What changes Settle the entry shape, the decay and staleness rules, and the propagation rules. The work, in order: 1. **Entry shape.** Decide whether the current six fields are the final shape or whether entries need more: an expiry, a source layer, a supersedes link for corroboration/contradiction. Any new field must be justifiable from a rule below, not added speculatively. 2. **Decay and staleness.** Decide the rule for how knowledge goes stale: do last-seen positions decay in confidence over time, expire after a fixed interval, or stay until contradicted? The three options behave very differently in play — decay makes the AI gradually unsure, expiry makes it forget on a clock, until-contradicted makes it certain until proven wrong. Pick one per entry kind if the kinds differ (a lost unit is a fact; a last-seen position is a guess). 3. **Implement decay.** Fill in `apply_decay` per the settled rule and add a ledger prune pass. Decide when pruning runs — on a tick, on read, or on write — and make sure pruning never deletes the `unit_lost` fact of a found body while the alert it caused is still live. 4. **Corroboration and contradiction.** When a second NPC perceives the same thing, confidence rises; when a perception contradicts an entry (the player is seen somewhere else), the old entry is superseded, not silently kept alongside. Define the merge rule. 5. **Propagation only via interruptible report.** Knowledge travels up the chain only when an NPC reports it — shout, radio, or runner — and a report is an action that can be interrupted. If the reporting NPC is killed mid-report, the knowledge never arrives. Today `perceive_sight` hands the entry to the Commander directly; the report mechanic is new work: define what a report is mechanically (a timed action? a message with travel time?), what channels exist, and what interrupts one. 6. **Tests.** A stale entry expires or decays per the settled rule; a contradicted entry is superseded; an interrupted report never lands in the ledger; a completed report lands with its full propagation path. ## What done looks like `apply_decay` implements the settled rules, the ledger prunes on the settled schedule, reports are interruptible actions with named channels, corroboration and contradiction behave per the merge rule, and a test proves each rule. The design doc's knowledge section is updated to match. ## Open questions - Decay, expiry, or until-contradicted — and does the answer differ by entry kind? - Does confidence decay with time, or only on contradiction? - What is a report mechanically — a timed action, a message with travel time, or something else? - What propagation channels exist — shout (instant but local, and the enemy hears it?), radio (instant but needs equipment?), runner (slow but silent)? - Does a `unit_lost` entry ever decay, or is a lost unit a permanent fact?

muse-lantern referenced this issue

2026-11-15 01:10:25 +00:00

Build sequence: code first, then model integration #11

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

dead-air/daisy#3

No description provided.

Rows
Columns