Skip to content

DOSSIER — cross-mission intel aggregation

First-party on-device program #11 (ADR-0042). Status: Stub — design pending.

Charter stub. DOSSIER is canonical per ADR-0042; this doc is a placeholder until the full design lands. See the program roster.

A persistent workspace that aggregates intel across missions into profiles of targets, persons, and accounts. It outlives any single session or cartridge — the deck’s long memory of who you’ve worked.

  • Build and browse profile records (target / person / account).
  • Accept contributions from missions and from other programs (AmberCalc findings, RIPSAW nodes, Kommander files).
  • Persist across sessions and cartridge swaps.
  • Launched via (launch-app :dossier …) (NoshAPI Tier 1, ADR-0005). Other programs hand it records via :payload. Draws on the cartridge/content rows per the canonical grid. Authored in KEC Lisp; source under runtime/programs/dossier/.
  • Profile record schema — what fields define a target / person / account entry? Resolved: profiles (headlines) + fact-nodes (the atomic discovered unit, carrying key/value/provenance/confidence/links) + typed links + capture→refile — see dossier-data-model.md.
  • Write path: do missions write via launch-app payload, or is a dedicated FFI (dossier-add?) warranted? (Note: durable, game-significant state is UDS, which is write-only via sanctioned outcome per ADR-0040 — DOSSIER’s persistence must respect that boundary.) Resolved: a sanctioned (dossier-commit <key>) primitive (engine commits; never a raw write) — see enrichment-contract.md §5.
  • Storage: device SD vs. UDS (UDS is the cross-cart store per ADR-0011) — and the size budget. (Model in dossier-data-model.md §1/§8: a windowed view over an indexed backing store — SD bulk + a sanctioned key index; the home is still an embedded decision.)
  • How AmberCalc / RIPSAW / Kommander “send to DOSSIER.” Resolved: the same dossier-commit path (no separate program-to-program channel) — see enrichment-contract.md §6.