1---2name: requirements-budget-verification3description: Convert AAO telescope or instrument concepts into traceable requirements, budgets, verification matrices, test plans, and release gates. Use when a project needs machine-readable requirements, mass or power budgets, optical or thermal allocations, or evidence-backed design-status reporting.4---56# Requirements Budget Verification78## Workflow910- Confirm that the material is safe for the broad AAO skills repository. Put sensitive requirements, partner-private criteria, or controlled verification evidence in the restricted workflow.11- Start from the user-visible design promise: what the instrument must do, where it operates, what interfaces it must respect, and what evidence would prove progress.12- Prefer structured files such as YAML, JSON, CSV, or tables when the repository already has machine-readable config.13- Keep these objects distinct:14 - `requirements`: shall/should statements and source assumptions15 - `budgets`: allocated quantities with margins and owners16 - `verification matrix`: requirement paths mapped to methods, commands, artifacts, or open gaps17 - `test plan`: later campaign areas, acceptance logic, and evidence still needed18 - `release gate`: checks that must pass before outputs are called current19- Every scoped requirement should have at least one verification method or a named open gap.20- Budgets should not be decorative. Require positive margin or an explicit overrun/risk entry for mass, power, WFE, alignment, thermal, pointing, radiation, contamination, or other relevant categories.2122## Checks2324- Shared values, such as aperture, focal length, orbit, thermal targets, launcher, mass, and power, agree across narrative docs and structured config.25- Verification commands or artifacts are reproducible from a clean checkout where possible.26- Generated summaries cannot silently satisfy a gate if their inputs are stale.27- Screening evidence is labeled separately from engineering verification or test evidence.28- Requirement identifiers remain stable enough for reviews, TODOs, and test plans to refer to them.2930## Output Expectations3132- Produce traceable requirement tables, budget ledgers, verification matrices, or review findings.33- Point out missing owners, ambiguous units, stale assumptions, and unverified margins.34- Avoid marking a requirement verified unless the named evidence has actually been inspected or run.