audit

name	audit
description	Use when reviewing an existing blueprint for gaps, missing flows, terminology conflicts, coverage of error cases, or untestable requirements.

Structured checklist audit of an existing blueprint — evaluates systematically against six dimensions, produces a findings report. Not a rewrite. For panel debate with multiple perspectives, use review instead.

Read the entire blueprint before producing findings. Isolated observations often disappear when the document is read as a whole; apparent gaps may be covered elsewhere. Check the stated completion tier in README.md — audit against what the tier promises. A Tier 1 blueprint intentionally lacks scenarios.

Terminology conflicts are the most damaging class of blueprint problem.

Check: same concept under multiple names, same term meaning different things in different sections, Terminology entries not used consistently in Scenarios/Requirements, terms in Scenarios/Requirements not in Terminology.

For each conflict: name the conflicting terms, state which sections each appears in, identify the canonical term, state what needs to change. Do not leave a conflict annotated as "equivalent to" — resolution means one term survives everywhere.

For each actor: at least one scenario shows their primary journey, permissions demonstrated, restrictions demonstrated.

For each user story: at least one scenario traces how the system delivers the outcome.

For each entity state: at least one scenario shows entry, at least one shows exit (unless terminal).

Error path coverage for each scenario: happy path documented, primary failure modes documented, timeout edge cases covered, multi-actor interactions show each actor's view.

Each entity: has definition, has states listed (if lifecycle), has named transitions with triggers, has named relationships with cardinality, has lifecycle owner.

Model as whole: every entity in scenarios appears in domain model and vice versa, no unreachable terminal states, no implicit states hiding in boolean combinations.

Testability: every functional requirement must support writing a pass/fail test.

Sourcing: every business rule needs a source — policy, regulation, stakeholder decision. "Users with free plans cannot create more than 3 projects" — why? Product decision? Pricing constraint? Infrastructure limit? The source determines whether the rule can be changed and by whom.

Coverage: scan scenarios for implied constraints not stated in requirements:

• A scenario shows a deadline — is the duration in Requirements?
• A scenario shows a role restriction — is it in Business Rules?
• A scenario shows a notification — is the triggering condition and recipient in Requirements?

Decision log: decisions recorded with rationale (not just outcome), contested decisions have both positions, each has date and owner.

Open questions: specific enough to be answerable (not "figure out the pricing model"), each has an owner, each has deadline or blocking note. Open questions without owners do not get resolved.

A decision log without rationale is almost useless. "We decided to use soft delete" is less valuable than "We decided to use soft delete because audit requirements mean we cannot lose the record."

A blueprint must not contain implementation decisions. Every one is a constraint the team did not consciously impose.

Exception: when a vendor/technology is a genuine business constraint, name it and source it. The test is whether a business stakeholder made this decision, not an engineer.

Blocking: terminology conflicts, missing primary journey scenarios, entity states with no entry/exit path, requirements with no acceptance criteria, ownerless blocking open questions, implementation decisions as requirements.

Advisory: missing minor edge case error paths, imprecise but testable requirements, unclear but unambiguous terminology, missing rationale for stable decisions, minor implementation leakage.