Field Guides / Session Hygiene
Session Hygiene
Atlas Protocol · V1.0 · 2026-05-02 · Schema FVE-1 V5.6
For: The human managing model instances across a research or build program.
Session hygiene is the set of practices that prevent context contamination from moving between sessions, instances, and tasks. A session that runs clean produces output that is traceable to the spec, the input, and the operator's decisions — not to accumulated context from prior exchanges.
Authority Boundary
Three Layers
Which model handles which task and why.
What context an instance receives, when to split sessions, and what never crosses session boundaries.
The structured review process for build output and written work.
Layer 1 — Instance Selection
1.1 — Task-Based Instance Assignment
Different tasks go to different models. The assignment is declared before the session opens, not chosen during it.
| Task type | Primary instance | Notes |
|---|---|---|
| Protocol drafting | Claude | Governing document author |
| Script / tool build | Claude | Build from approved spec only |
| Logic / protocol review | Skywork or DeepSeek | Opposing reviewer for Claude output |
| Writing review | Perplexity or GPT / Gemini | Opposing reviewer for Claude writing |
| HTML / UI review | Fresh Claude (incognito), Perplexity COMP, or Mistral | Reviewer receives spec only — no transcript |
| Exploratory ideation | Any | Sandbox rules apply — no production output |
Named models reflect current practice. The requirement is a fresh non-builder instance independent of the original session. The independence requirement is fixed. The named model is not.
1.2 — Author and Reviewer Separation
The model that authors output does not review its own output. This is a hard rule.
A model that authored a document has already committed to a reading of the spec. It cannot perform neutral review of its own output.
1.3 — Sandbox Instance Isolation
A sandbox instance does not graduate to a build instance. When a sandbox session has produced an approved spec, close it. Open a fresh instance for the build.
A sandbox instance has accumulated context — half-formed ideas, rejected approaches, exploratory builds — that is not in the spec. That context will influence the build even if it is not explicitly referenced.
Layer 2 — Context Contamination Prevention
2.1 — What Never Crosses Session Boundaries
| Item | Rule |
|---|---|
| Session transcript | Never sent to opposing reviewer or fresh instance |
| Sandbox context | Never carried into build session |
| Prior build assumptions | Never carried into fix cycle |
| Conversational framing | Never substitutes for spec in build session |
| Instance summary of prior session | Never used as spec substitute |
The spec is the only legitimate carrier of context across session boundaries. If something is not in the spec, it does not belong in the build session.
2.2 — Context Width Rules
| Session type | Context rule |
|---|---|
| Build session | Full approved spec only — no unrelated prior context |
| Opposing review | Narrow — spec and output only, no transcript |
| Fix cycle | Fresh instance — spec and reviewer report only |
| Sandbox | Unconstrained — context compression is a sandbox problem, not a build problem |
| Long sandbox → production build | Hard stop — close sandbox, open fresh build instance |
2.3 — Post-Sandbox Build Rules
After a sandbox session of any significant length, before any production build:
| Output type | Risk | Rule |
|---|---|---|
| Python script | Sandbox assumptions baked into logic | Fresh instance, approved spec only |
| JSON structure | Field names and structure drift from spec | Fresh instance, approved spec only |
| HTML / UI tool | Feature assumptions from exploration persist | Fresh instance, approved spec only — review with second fresh instance |
2.4 — Mid-Session Split Triggers
Split to a fresh instance when any of the following occur:
How to split cleanly
2.5 — The Transcript Rule
Session transcripts are never sent to opposing reviewers or fresh instances. The transcript contains the operator's reasoning process, the instance's rejected approaches, conversational framing, and mid-session corrections — none of which belong in the spec.
If a finding from a session needs to carry forward, it goes into the spec or the operator's notes — not the transcript.
Layer 3 — Opposing Review
3.1 — What the Reviewer Receives
The opposing reviewer receives exactly two things: the approved spec and the output under review. Nothing else. The reviewer evaluates the output against the spec, not against the instance's account of its own work.
3.2 — Reviewer Report Format
The opposing reviewer produces a structured report — a document, not a conversation — with three sections:
3.3 — Acting on the Reviewer Report
The operator reviews the report against the spec before acting on any proposed fix. The reviewer's proposed fix is a recommendation, not an instruction. Fix cycle procedure follows Build From Spec §3.2.
3.4 — When Opposing Review Is Not Required
Opposing review is required for all production build output. Not required for: sandbox exploratory builds, draft field notes before the operator's own review pass, or intermediate outputs reviewed in a subsequent build step.
When in doubt, run opposing review. The cost of a structured report is lower than the cost of accepting drifted output.
Context Rules — Quick Reference
| What | Crosses session boundary? | How |
|---|---|---|
| Approved spec | Yes | Paste in full |
| Reviewer report | Yes | Paste proposed fixes only |
| Session transcript | No | Never |
| Sandbox context | No | Never |
| Instance summary | No | Never — restate from spec |
| Operator notes | Yes, conditionally | Only if promoted into explicit spec addendum or reviewer packet — not raw conversational notes |
Common Failure Modes
The spec is the only legitimate carrier of context across session boundaries. If it is not in the spec, it does not belong in the build session.