Technical design review

Produce a reviewable decision document, not an implementation plan disguised as prose. Keep the chain visible:

user problem → target outcome → constraints → design options
→ evidence → risks/ownership → validation → rollout decision

Workflow

1. Frame the decision. Record the user/job, current baseline, target outcome, goals, non-goals, assumptions, constraints, affected code or systems, and decision owner. If facts are missing, label them as questions or assumptions.
2. Write the one-page overview. Include a 1–3 sentence summary, platforms/environments, team/contact, tracking item, and broad code or data surfaces. A reader should know what is changing and why without reading the rest.
3. Describe the design. Explain motivation, alternatives considered, major modules and seams, data/control flow across processes, threads, storage, and network, compatibility, and ownership after launch. Prefer diagrams or short flows when they remove ambiguity.
4. Review the principles. Address performance (speed, memory, power), user and operational simplicity, security/threat model, privacy/data handling, accessibility where relevant, and lifecycle cost. Explicitly say “no material impact” with a reason when a section does not apply.
5. Define evidence and gates. For each important claim, name the source or experiment, expected observation, threshold, owner, and decision it unlocks. Separate observed, inferred, and unknown. Unknown is not absent.
6. Plan rollout and recovery. State waterfall, staged rollout, experiment, feature flag, or other strategy; monitoring and regression metrics; pause/rollback conditions; migration and version-skew handling; and cleanup or follow-up work.
7. Run the review. Ask reviewers to challenge the problem, alternatives, ownership, failure modes, security/privacy, metrics, and exit criteria. Resolve each objection in the document or record it as an explicit open decision.