Templates for FDE documents

# Customer brief and assumption register

## Customer outcome

<!-- What the customer will be able to do, or stop doing, when this works. Say how you would measure it. -->

## Current workflow

<!-- How the work happens today, step by step, and who does each step. -->

## Assumptions

<!-- What you believe but have not confirmed. Keep facts the customer stated in a separate list. -->

## Validation plan

<!-- For each important assumption: who you will ask or what you will test, and what answer would change the plan. -->

# Discovery summary

## Outcomes

<!-- The measurable results the customer needs, in their words where possible. -->

## Constraints

<!-- Confirmed limits on the solution: network, data, security, budget, people, deadlines. Note who confirmed each. -->

## Conflicts

<!-- Where two stakeholders or two constraints pull against each other, and who has to decide. -->

## Open Questions

<!-- What is still unknown, why it matters, and who can answer it. -->

# Pilot scope and acceptance criteria

## Scope

<!-- What the pilot covers: users, workflows, systems, and duration. -->

## Acceptance criteria

<!-- Testable conditions for success, covering function, safety, and operations. Each one should be checkable by someone other than you. -->

## Exclusions

<!-- What is explicitly out, so the pilot cannot grow into an unplanned rollout. -->

# Architecture decision record

## Context

<!-- The problem, the constraints that shape it, and the options you considered. -->

## Decision

<!-- What you chose and the main reason. One paragraph. -->

## Diagram

<!-- Components, data flows, trust boundaries, and where a human approves an action. Text or a diagram link is fine. -->

## Consequences

<!-- What gets easier, what gets harder, and what you will have to watch. -->

# Threat model

## Assets

<!-- What an attacker or a failure could harm: data, credentials, systems, decisions, audit records. -->

## Threats

<!-- Credible ways each asset could be misused or fail, including mistakes by the AI parts of the system. -->

## Mitigations

<!-- For each material threat, the control that prevents, detects, or recovers from it. -->

# Incident root-cause report

## Containment

<!-- What you did to stop the harm, and when. -->

## Impact statement

<!-- Who and what was affected, for how long, and how you know. -->

## Evidence review

<!-- The logs, traces, and records you examined, and what each showed. -->

## Root cause

<!-- The underlying cause, not just the visible failure. Explain why the failure looked acceptable at the time. -->

## Corrective control

<!-- The change that removes the cause. -->

## Regression test

<!-- The test that fails if the corrective control is removed. -->

## Restoration criteria

<!-- The conditions that must hold before normal service resumes. -->

## Customer communication

<!-- What you told the customer, or will tell them, about what happened and what changed. -->

# Executive readout

## Outcome

<!-- Results against the acceptance criteria, with no claim you cannot back with evidence. -->

## Risks and mitigations

<!-- The risks that remain and the named controls that make each one acceptable. -->

## Rollout plan

<!-- A realistic path from pilot to wider use, with checkpoints. -->

## Operating model and cost

<!-- Who runs it day to day and what drives the cost. -->

## Decision requested

<!-- The one decision you need from the sponsor. -->