Built around the decision owner
Make a changed AI system understandable before asking for approval.
A technical path from approved configuration through semantic change and scoped assurance. Single-system change/assurance concepts exist in the product repository; estate-wide connectors remain future design.
Your operational decision.
Explain why this change requires these exact checks and not a complete restart of readiness work.
- The model, tool or prompt changed but approval relevance is hard to establish.
- Test reruns are broad because evidence dependencies are not mapped.
- An unmapped new capability can disappear in a routine deployment handoff.
What the product must make inspectable.
Source-informed design elements below are explained with authored examples; release availability must be checked during pilot scoping.
Approved vs candidate
Use the governed baseline rather than the last Git commit alone as the reference.
Semantic change
Represent a model, tool, prompt or permission change in terms of its assurance implications.
Assurance Delta
Separate preserved proof from impacted, stale or unmapped evidence.
Human decision
Send scoped evidence and unresolved dependencies to explicit review; do not auto-approve.
A pilot should answer real questions, not prove an invented dashboard.
Start with one bounded workflow and agreed acceptance criteria. Future connector coverage and estate-wide behavior are not included unless separately demonstrated.
Pilot intake
- Bring one representative AI agent or workflow and a meaningful recent change.
- Show the actual approved reference and which evaluations are used today.
- Define measurable acceptance around mapped/unknown change and evaluation scope.