Handbook
Sessions and audit
Operators and reviewers who need to steer, audit, or attach evidence from an intelligence run without reading raw implementation code.
Updated
Who is this for?
Operators and reviewers who need to steer, audit, or attach evidence from an intelligence run without reading raw implementation code.
What problem does it solve?
Every intelligence session must explain what happened: which ladder rungs fired, how tokens were spent, where ambiguity arose, and what artifacts were produced. Forge Intelligence uses a session dual-wiki — machine records are truth; the human report is a faithful projection.
What can you do?
- Start a session with a problem class and receive structured telemetry throughout the run.
- Review route trace — which capabilities ran and their outcomes.
- Review token ledger — planned vs actual spend per stage.
- Review ambiguity assessments — when deterministic stages abstained or escalated.
- Read a generated human report suitable for steering and audit.
- Attach machine session JSON to evidence consumers (ForgeRun extensions) while Lenses remains the system of record.
What can you not do?
- Hand-edit the human session report — it is regenerated from machine records.
- Use FI session storage as the authoritative run spine — attach evidence; do not replace Lenses ForgeRun.
Limitations
Session examples are runtime artifacts under sessions/ in the product repo — they are not published as handbook pages. Operators integrate via session outputs their deployment exposes.
Trust model
| Element | Role |
|---|---|
| Machine records | Source of truth for routing, spend, ambiguity, artifacts |
| Human report | Derived narrative for humans — checked by freeze gate |
| Freeze gate | Fails if human report drifts from machine records |
Next steps
- Reasoning economy — what ladder choices mean in a session
- Boundaries — FI vs Lenses vs LCDL
- System depth: paired system page, Session data governance