dead-air/daisy
Watch
3
0
Fork
You've already forked daisy
 1
Code Issues 10 Pull requests Projects Releases Packages Wiki Activity Actions

Build sequence: code first, then model integration #11

New issue
Open
opened 2026-11-15 01:10:25 +00:00 by muse-lantern · 0 comments
muse-lantern commented 2026-11-15 01:10:25 +00:00
Member
Copy link

The plan

D.A.I.Sy is built code first, then model integration. The heuristic system has to be proven on the simulation scenarios before a decision model touches either slot. This issue is the sequence: what gets built in what order, what each step depends on, and what done looks like for the whole prototype. The scaffolding PR (#1) is the base everything builds on.

The sequence

Work goes in this order. Each step's issue is the full plan for that step — this issue only sequences them.

  1. Order vocabulary (#2) — first. Everything builds against it: the brain executes it, the Commander issues it, the Director's objectives translate into it, and later a model is validated against it. Nothing else can settle until the vocabulary is stable.
  2. Knowledge ledger (#3) — second. The ledger's shape and rules gate the Commander and the sensing work: decay, staleness, corroboration, and interruptible reports all have to be settled before the Commander reasons over its ledger.
  3. NPCEntity small brain (#4) and fallback behaviour (#7) — third, together. The execution layer: the brain's HOW (navmesh, sensing, stuck handling) and what an NPC does with no Commander or a stale order. These two are one step because the fallback is part of the brain.
  4. Commander (#5) — fourth. Team tactics on top of the settled vocabulary and ledger: role-based tasking, environment knowledge, the alert ladder, the body-discovery chain, cadence.
  5. Director (#6) — fifth. Objectives and the coordination guard, on top of the Commander: the objective vocabulary, the coordination mechanism, more guard failure modes, cadence, the map picture, alert policy.
  6. Simulation scenarios (#8) — throughout. The smoke scenario (in PR #1) is scenario 1. Each further scenario lands as the issue it depends on settles, and a scenario is the acceptance bar for its issue: an issue is not done until its scenario passes.
  7. Spawning / reinforcement ownership (#9) — after the Director. Spawning plugs into whatever shape the Director settles into, so it waits until the Director issue lands.
  8. Model integration (#10) — LAST, and only then. Heuristic default plus a swappable local model behind the same interface at Director and Commander, measured against the heuristic on the scenario suite. This issue is marked FUTURE and must not be started early.

Dependencies

  • The small brain (#4) needs the vocabulary (#2).
  • The Commander (#5) needs the vocabulary (#2) and the ledger (#3).
  • The Director (#6) needs the Commander's objective translation (#5).
  • The scenarios (#8) need the issues they test, one at a time.
  • Spawning (#9) needs the Director (#6).
  • Model integration (#10) needs all of it, plus a settled evaluation metric.

What done looks like

The whole sequence is done when the heuristic system — vocabulary, ledger, brain, fallback, Commander, Director, spawning — is proven on the scenario suite, and the model-integration issue can start from a stable, measured baseline. Until then, the prototype is a workbench, not a game system.

Open questions

  • Commander vs Controller: the name is still WIP in the design. The code says Commander throughout; if Controller wins, the rename rides with the vocabulary or Commander issue — this tracking issue does not decide it.
  • Is the sequence right, or should spawning come before the Director work?
  • At what point does the prototype graduate from this repo into the DEAD AIR engine — after the heuristic system is proven, or only once a model slot is proven too?
## The plan D.A.I.Sy is built code first, then model integration. The heuristic system has to be proven on the simulation scenarios before a decision model touches either slot. This issue is the sequence: what gets built in what order, what each step depends on, and what done looks like for the whole prototype. The scaffolding PR (#1) is the base everything builds on. ## The sequence Work goes in this order. Each step's issue is the full plan for that step — this issue only sequences them. 1. **Order vocabulary (#2) — first.** Everything builds against it: the brain executes it, the Commander issues it, the Director's objectives translate into it, and later a model is validated against it. Nothing else can settle until the vocabulary is stable. 2. **Knowledge ledger (#3) — second.** The ledger's shape and rules gate the Commander and the sensing work: decay, staleness, corroboration, and interruptible reports all have to be settled before the Commander reasons over its ledger. 3. **NPCEntity small brain (#4) and fallback behaviour (#7) — third, together.** The execution layer: the brain's HOW (navmesh, sensing, stuck handling) and what an NPC does with no Commander or a stale order. These two are one step because the fallback is part of the brain. 4. **Commander (#5) — fourth.** Team tactics on top of the settled vocabulary and ledger: role-based tasking, environment knowledge, the alert ladder, the body-discovery chain, cadence. 5. **Director (#6) — fifth.** Objectives and the coordination guard, on top of the Commander: the objective vocabulary, the coordination mechanism, more guard failure modes, cadence, the map picture, alert policy. 6. **Simulation scenarios (#8) — throughout.** The smoke scenario (in PR #1) is scenario 1. Each further scenario lands as the issue it depends on settles, and a scenario is the acceptance bar for its issue: an issue is not done until its scenario passes. 7. **Spawning / reinforcement ownership (#9) — after the Director.** Spawning plugs into whatever shape the Director settles into, so it waits until the Director issue lands. 8. **Model integration (#10) — LAST, and only then.** Heuristic default plus a swappable local model behind the same interface at Director and Commander, measured against the heuristic on the scenario suite. This issue is marked FUTURE and must not be started early. ## Dependencies - The small brain (#4) needs the vocabulary (#2). - The Commander (#5) needs the vocabulary (#2) and the ledger (#3). - The Director (#6) needs the Commander's objective translation (#5). - The scenarios (#8) need the issues they test, one at a time. - Spawning (#9) needs the Director (#6). - Model integration (#10) needs all of it, plus a settled evaluation metric. ## What done looks like The whole sequence is done when the heuristic system — vocabulary, ledger, brain, fallback, Commander, Director, spawning — is proven on the scenario suite, and the model-integration issue can start from a stable, measured baseline. Until then, the prototype is a workbench, not a game system. ## Open questions - Commander vs Controller: the name is still WIP in the design. The code says Commander throughout; if Controller wins, the rename rides with the vocabulary or Commander issue — this tracking issue does not decide it. - Is the sequence right, or should spawning come before the Director work? - At what point does the prototype graduate from this repo into the DEAD AIR engine — after the heuristic system is proven, or only once a model slot is proven too?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#11
No description provided.