# CF-YYYY-NNN — [Short incident name]

| Field | Value |
|---|---|
| **Case ID** | CF-YYYY-NNN |
| **Incident date** | |
| **Systems involved** | [agent framework, underlying model(s), platform] |
| **Incident type** | Operational failure / Misuse / Misalignment / Contested |
| **Investigation status** | None published / Internal only / Partial public record / Investigated |
| **Last reviewed** | |

## Summary

Three to five sentences. What happened, what makes it investigatively significant, and what the current state of the record is.

## Incident description

The factual narrative, from public sources only. Separate what was observed from what was claimed — by the operator, by the developer, and by the agent itself. Cite every claim.

## Investigative questions

What a structured investigation of this incident would need to answer. Typical categories:

1. **Causal chain** — what sequence of inputs, states, and decisions produced the action?
2. **Intent vs. failure** — does the evidence distinguish goal-directed behavior from malfunction? Can it?
3. **Evidence integrity** — what records exist, who holds them, and could the agent itself have contaminated them?
4. **Accountability** — deployer, developer, model provider, agent: how does responsibility distribute, and what blocks attribution?

## Investigation status

What was actually done. Who investigated (if anyone), what was published, what evidence was preserved, what remains unanswered. Absence of investigation is a finding — record it explicitly.

## Sources

Primary sources first (operator statements, company statements, the agent's own published outputs), then technical analyses, then press coverage. Include access dates for anything likely to disappear.