​

SPEC-099 v0.1 — Dewey (Recallgate)

​

Summary

​

Why this exists

​

Watched task-classes

• Spec implementation work (touching files in backend/app/services/ linked to a SPEC entity)
• BIOS edits (CLAUDE.md, AGENTS.md, templates/CLAUDE.md, templates/AGENTS.md)
• Governance changes (rules, ADRs, method-fragments, anything under docs/adrs/, docs/specs/, docs/method-fragments/)
• Cross-lane work (assignment_routing changes, persona-binding changes)

• Docs surface tweaks (Mintlify nav, copy edits)
• Dashboard / UI work that doesn’t touch governance state
• Telemetry surface changes

• Per-specialization watched lists (e.g. install lane has different Tier-1 than engineering)
• Per-surface lists (Codex vs Claude Code task-classes may differ)

​

Trigger semantics

• (a) the agent is accepting a new assignment (signal TaskAssigned, operator chat assignment, or self-initiated prism_todo add) AND
• (b) the assignment matches a Tier-1 or Tier-2 task-class AND
• (c) the session has NOT issued a semantic_recall call within the recent window scoped to the current assignment context.

​

Behavior — by mode

​

off

​

advisory (v0.1 default)

{
  "ok": true,
  "warnings": [
    {
      "kind": "missing_recall_on_task_start",
      "task_class": "tier1",
      "assignment_id": "...",
      "remediation": "Issue semantic_recall against TriGraph for prior work on this task-class before producing material output."
    }
  ]
}

​

enforce (v0.2-eligible)

{
  "ok": false,
  "error": "missing_recall_on_task_start",
  "stage": "recallgate_preflight",
  "task_class": "tier1",
  "assignment_id": "...",
  "remediation": "Issue semantic_recall before re-attempting task acceptance, or pass force=true with reason."
}

​

Force-override (audited)

• session_id, agent_identity, force_reason
• assignment_id, task_class
• would_have_required_recall: bool

​

Watson hook on every recall

• session_id, agent_identity
• assignment_id (current active assignment, if any)
• query, source_types, top_k (request shape)
• results_returned (count, not bodies)
• invoked_at

​

Backend

def detect_missing_recall_at_task_start(
    *,
    session_id: UUID,
    assignment_id: UUID,
    task_class: TaskClass,
    recent_recall_invocations: list[RecallInvocation],
    mode: RecallgateMode,
) -> RecallgateOutcome: ...

​

Phasing

• v0.1 (this SPEC): Phase 0 advisory mode behind PRISM_RECALLGATE_MODE=advisory default. Telemetry: recallgate_warning_count per session, recall_invoked audit events flowing.
• v0.2: flip default to enforce for Tier-1 task-classes after — (a) 7-day advisory observation period, (b) Texi + Candi review of telemetry, (c) test coverage in place. No automatic flip on zero fires (mirrors SPEC-096 nit 3).
• v0.3: per-specialization / per-surface task-class lists.

​

Tests (mandatory before flag flip)

• Task-class matching (Tier 1 / Tier 2 / unmatched)
• Mode behavior (off / advisory warns / enforce-Tier1 refuses / enforce-Tier2 warns)
• Recent-window logic (recall just before task-accept clears the gate)
• Force-override audit event emission (required force_reason ≥10 chars)
• Lifecycle invariant — enforced refusal does NOT trigger session shutdown calls
• recall_invoked audit event shape on every semantic_recall in a watched class

• Tier-1 task-acceptance without prior recall → advisory warning surfaces
• Same flow in enforce mode → refusal returned, session still active
• Force-override path → success + audit event written

​

Out of scope (v0.1)

• Recall quality assessment. v0.1 only checks recall happened, not whether the query was useful. Quality scoring is downstream.
• Cross-session recall coverage. “Donna already ran this recall yesterday in another session” doesn’t satisfy v0.1’s window — v0.1 is per-session.
• Auto-recall. Agents must explicitly invoke semantic_recall; the gate does not run recall on their behalf.
• Memorule-specific recall enforcement. v0.1 accepts any semantic_recall; SPEC-094 v0.4 (Memorules) interaction comes in v0.2 once Memorules surface lands.

​

Cross-references

• method.wall-break.persistence v0.2 — Element 5 (recall-on-task-start) is the methodology this SPEC operationalizes
• SPEC-096 v0.2 — phasing pattern, mode-trinary, Tier-1/Tier-2 split, force-override semantics, lifecycle invariant — all mirrored here
• SPEC-094 v0.3 + v0.4 — substrate + Memorules; Recallgate v0.2 will integrate Memorule-aware recall
• (future) Watson SPEC — consumes recall_invoked and recallgate_force audit events
• Plan 003 Phase 3 — this SPEC’s home phase

​

Risk

• Adoption: R2 — methodology change affecting how every Tier-1 task-acceptance proceeds. Backward-compat preserved via advisory default + force-override.
• Highest-risk surface: the trigger surface (where assignment-acceptance is detected). Mis-firing on assignments that are NOT real task-starts (e.g. routine prism_todo adds for housekeeping) creates noise. Tier-1 watched-task list must err narrow at v0.1.

​

Acceptance criteria for v0.1 → v0.2 promotion

1. Phase 0 advisory shipped + observed for at least 7 days of active multi-agent sessions.
2. Telemetry: recallgate_warning_count non-zero AND recall_invoked audit events flowing in observable volume.
3. Texi architecture review of v0.1 → v0.2 deltas.
4. Candi governance ratification of v0.2.
5. Backend test coverage per §Tests.
6. Lifecycle invariant test passes (no session-shutdown calls on enforced refusal).