How Telltale works

1. Read the session store

The scanner discovers known session-store formats and reads them through a source-specific adapter. This gives it the activity the harness recorded, not an independent view of everything that happened on the host.

2. Put the evidence into a common shape

Different harnesses record tool calls, results, prompts, and timestamps differently. Telltale maps what the source actually reports into canonical observations so the same detection logic can work across sources. Missing fields are not invented.

3. Apply deterministic detections

Rules evaluate the available evidence and produce findings and risk contributions. The score is a cumulative ledger of matched contributions, not a probability of compromise. A legitimate developer task can match a rule, so findings still need review.

4. Write events for investigation

The normal CLI path writes Event 3.0 JSONL after the privacy boundary. Events contain metadata and bounded redacted evidence rather than a copy of the whole transcript. You can review the file locally or configure forwarding; durable delivery adds a separate outbox for replay. Redaction is a bounded pattern-based protection, not a guarantee that every secret is recognized.

Session store → Source adapter → Canonical observations
              → Deterministic detections → Privacy boundary
              → Local JSONL → Optional forwarding

What this does not do

• It does not intercept or block agent actions in the current log-review workflow.
• It does not run embedded LLM triage or turn a response recommendation into an executed action.
• A quiet scan does not prove safety when the store is unsupported, acquisition failed, or a required field is unavailable.
• Fixture tests establish behavior for the tested inputs. They do not establish complete live-agent or production detection coverage.

Try the workflow