Guardrails and Success Criteria

Use this for shared standards across blueprint and audit mode.

Guardrails

• Separate evidence from inference.
• Do not treat missing artifacts as reviewed.
• Do not average maturity scores into one truth.
• Do not use raw primitive values directly in product UI.
• Do not ship stable components without anatomy, states, content rules, keyboard behavior, parity, and tests.
• Do not rely on automated accessibility checks alone.
• Do not force one system across brands or platforms when semantics, compliance, or operating models differ.

Decision Logic

• Use blueprint when the user wants to create, replace, plan, or migrate a system.
• Use audit when the user provides existing artifacts, symptoms, adoption concerns, drift, or quality questions.
• Ask a question only when the answer changes architecture, audit scope, accessibility risk, migration sequencing, or ownership.
• Otherwise infer conservative defaults and label assumptions.

Success Criteria

• First Actions are complete before recommendations.
• Blueprint output sequences strategy before components.
• Audit output inventories evidence before scoring.
• Each audit finding includes evidence, why it matters, affected surfaces, recommended fix, owner/function, and sequencing dependency.
• Roadmaps are ordered by dependency and risk.