DOSSIER readiness lens — design
../software/programs/dossier.md— DOSSIER charter (T1–T3); this resolves its “overview view” open question.2026-06-30-dossier-viewer-design.md— the rolodex that shipped (read-only browse). This lens complements it; it does not replace it.../software/programs/dossier-data-model.md— the intel record schema; §8 lists the overview view as open.../software/runtime/mission-objectives.md+ ADR-0043 — the objective graph this lens reads.../software/runtime/recon-mode.md— where missing gates get closed (recon is entered from the same Mission Runner).../software/programs/enrichment-contract.md—dossier-commit/dossier-has?; the sanctioned write path.- ADR-0040 — UDS sanctioned-write boundary (this lens is read-only).
- ADR-0042 — first-party programs; enrich-never-gate.
- ADR-0046 — programs are knEmacs major-modes.
1. Problem
Section titled “1. Problem”DOSSIER’s charter and data model both leave one surface explicitly open: the overview view — the generated “all targets / all open gates” render (dossier.md open questions; data-model §8). The shipped rolodex answers “what have I filed on this entity” (browse), but it does not answer the decision the whole intel economy turns on: “for the job in front of me, is what I know sufficient and confident enough, or do I go case it first?”
That decision is the primary DOSSIER moment. This doc specifies where it gets answered.
2. Decisions carried in from the brainstorm
Section titled “2. Decisions carried in from the brainstorm”The 2026-07-23 brainstorm settled these forks; they are the premises here, not open items:
- Reuse, don’t rebuild. DOSSIER interaction is a knEmacs major-mode (ADR-0046); the readiness surface reuses existing panel machinery, not a new subsystem.
- Overview-first, decision-time. The surface is optimized for the readiness check, with the rolodex as drill-down.
- Contract-relative. Rows are the gates of the job in context (held vs. missing), not a global archive view.
- Nothing on board. Gate requirements are invisible before the operator accepts the contract; readiness appears only after accept, in the Mission Runner. This keeps rip-and-run genuinely blind and preserves the rip-vs-measured axis (recon-mode §2).
- Runner-side panel. The readiness surface lives in the Mission Runner (scoped to the accepted contract) and cross-links into the rolodex. The shipped standalone rolodex is untouched.
3. Design
Section titled “3. Design”A. A DOSSIER gate is a goal with an intel prerequisite
Section titled “A. A DOSSIER gate is a goal with an intel prerequisite”The Runner already renders an objective panel: the objective graph, a Lisp list of goals the operator drives with CAR/CDR/INFO (mission-objectives §9, ADR-0043). The model already has :locked goals and a :requires link. Extend the prerequisite so it can name a DOSSIER key, not only a sibling goal:
(goal open-relay :role :primary :reveal :briefed :requires (intel acct:fin-relay-07:routing :min-conf :verified) :reward ((¤ (scale 800))))The engine holds the goal :locked until (dossier-has? 'acct:fin-relay-07:routing :min-conf :verified) passes, then transitions it to :open (the model’s existing :locked → :open edge, §2.2). Nothing new in the state machine; one new prerequisite form.
Why this framing. It makes the readiness surface a lens over data that already exists, not a parallel gate system. And it gives nothing-on-board for free: the objective graph is a value on current-mission, exposed only to the Mission Runner (mission-objectives §7); the board renders contracts, never the objective panel. So an intel gate is invisible until accept and visible the instant the operator is in the Runner. No separate redaction mechanism is invented.
Hard-gate vs. de-risk. A hard gate is a :primary goal locked on an intel prerequisite (the path is unfinishable without the key). A de-risk is not a goal the operator must close; it is intel the generator reads to soften the job (recon-mode §5). De-risks are declared on the contract schema as the intel the generator consulted, and the lens surfaces them read-only as informational rows (“held → this job starts softened”). Only hard gates ride the objective graph; de-risks are contract-schema reads.
B. The readiness lens
Section titled “B. The readiness lens”Not a new screen. A filtered view of the Runner’s objective panel that shows only the intel-gated rows, each rendered with held/missing status and the confidence floor. Four legible states:
● routing ✓ verified satisfied (fin-relay-07)◌ beneficial-owner ~ held: rumored needs :verified (shell-3) ← the verified wall◌ tanaka-creds ✗ not filed (tanaka-h) ← go case it+ topology · de-risk (optional) not filed (gateway-2) ← soft bias, informational●satisfied — the key is filed at or above the gate’s confidence floor. The path is open.◌ ~ held below floor— the key is filed, but asrumored/inferredunder a floor that demands more. The verified wall: the operator corroborates (active recon, heat) or routes around.◌ ✗ not filed— no such key. Case it, buy it, or take a different path.+de-risk — an optional soft bias; present or absent, never blocking.
The status reads straight off the goal state (:locked vs :open) plus a dossier-has? confidence probe for the “how close” detail. Row order: hard gates first (blocking), then de-risks.
C. Cross-link to the shipped rolodex
Section titled “C. Cross-link to the shipped rolodex”INFO (or CAR) on an intel-gate row deep-links to the rolodex focused on that entity:
(launch-app :dossier :payload (:focus "fin-relay-07"))BACK returns to the Runner. This is the one small addition the built viewer needs: it currently seats the cursor at 0 on enter (viewer design §5), so it gains an optional focus-on-entity entry that seats the cursor on the named entity when present. The rolodex is otherwise exactly as shipped.
D. Verbs, entry, and the loop
Section titled “D. Verbs, entry, and the loop”Reuses the panel grammar so an operator who can drive the objective panel can drive the lens:
| Key | Action |
|---|---|
CDR / CAR | cycle to the next / previous intel-gate row |
INFO | drill to the rolodex at the row’s entity (C) |
| filter key | toggle the intel-lens on/off within the objective panel (binding finalized with the objective-panel design) |
BACK / NIL | back out to the full objective panel / Runner |
Entry: the lens is reached from the Runner objective panel, post-accept only. It has no board presence and no standalone launch (that is the rolodex’s job).
The loop closes in one place. Recon is also entered from the Mission Runner (recon-mode §7): see a missing gate → enter recon → surface the authored fact → dossier-commit → the row flips ◌→● → proceed. The readiness lens is the surface that makes the gap visible before the job punishes it, and recon is one step away on the same screen.
E. Dependencies and non-goals
Section titled “E. Dependencies and non-goals”Depends on:
- The objective-panel rendering — still open (mission-objectives §10.2). The lens is a filter over that panel, so it lands with or just after it.
- The
(intel key :min-conf …)prerequisite form — extends ADR-0043’s:requires/link facet and the ADR-0006:objectivesclause. Flagged here as a downstream ADR amendment, not written in this doc. - A contract-schema de-risk declaration — the keys the generator consulted, so the lens can surface de-risk rows. A
defcontract-schemaclause, small, additive. - The rolodex focus deep-link — a minor addition to the built viewer (C).
Non-goals:
- No new write path. The lens is read-only; the sole durable write stays
dossier-commit(ADR-0040). - No second DOSSIER mode. The lens is a Runner surface, not a mode of the DOSSIER program; the shipped rolodex stands alone.
- No global “all contracts” view. Contract-scoped only — which is exactly what nothing-on-board buys.
- No de-risk mechanics change. This surfaces de-risk reads; the soft-bias math is the recon/economy tuning, unchanged.
4. Reconciliation with what shipped
Section titled “4. Reconciliation with what shipped”- The rolodex is untouched. It remains the standalone browse of filed intel (
TERMexits it). The lens is a different surface, in the Runner, that links into the rolodex. - No redesign of the objective model. The lens reads the ratified objective graph (ADR-0043) through one new prerequisite form; the goal cell, state machine, and reward model are unchanged.
- The data model’s target still stands. When the store grows profiles/links (data-model), the lens gains richer drill-through, but it needs only key + confidence +
dossier-has?to ship — all present today.
5. Testing (TDD sketch)
Section titled “5. Testing (TDD sketch)”Headless ctest, mirroring the rolodex suite:
- Prerequisite resolution — a goal with
(intel k :min-conf :verified)is:lockedwhen the store lacksk;:openwhenkis filed at:verified; stays:lockedwhenkis filed only at:inferred. Round-trips each confidence floor. - Lens derivation — from a seeded objective graph + seeded
DossierStore, the lens yields exactly the intel-gated rows, in hard-then-de-risk order, each with the correct one of the four states. - Cross-link payload —
INFOon a row emits(launch-app :dossier :payload (:focus <entity>))with the row’s entity; the rolodex seats its cursor on that entity (and falls back to 0 when absent, never raises). - Empty / bare — no accepted contract → no lens; accepted contract with no intel gates → lens empty, renders, never raises.
6. Out of scope (later)
Section titled “6. Out of scope (later)”- The de-risk soft-bias magnitudes (recon/economy tuning).
- Rich drill-through (provenance, links) — arrives with the store’s profile/link growth.
- Any board-side readiness hint — deliberately excluded (nothing-on-board).
- Cross-mission “career readiness” summaries — the archive framing, not the decision-time framing this doc serves.