Key facts.
- ISO/IEC 42001:2023 Article 6.1.2: AI risk assessment including verification controls is a required pre-deployment activity, not a post-incident response.
- Retrofitting verification into an existing production agent system costs 3-5x more than building it during initial development, per engineering practice synthesis from enterprise AI deployments.
- Verification designed after architecture is set leaves structural gaps: action paths that weren't designed to be observable can't easily be made observable without redesign.
- The three architectural decisions that make verification hardest to retrofit: tight coupling between action execution and state management (can't add a verification point without touching both), lack of action type abstraction (verification must be added per-action-instance instead of per-action-type), and no audit log design (adding audit logging after the fact requires retroactive instrumentation of every code path).
Why retrofitting verification is expensive
Tight coupling is the most common structural barrier. When action execution and state management are tightly coupled in a single function, adding a verification point between them requires either refactoring the function (touching production code in a running system) or wrapping it with an interceptor (adding indirection that makes the code harder to reason about). Neither is cheap, and both introduce regression risk in code that's currently working.
Lack of action type abstraction means that each unique action in the system is a separate implementation, not an instance of a typed action class. A verification contract for "all read-file actions" requires modifying every read-file implementation in the codebase, not adding a single contract to a shared action type definition. In a system with 50 action implementations, this is 50 modification points - each with its own regression risk.
No audit log design means that adding observability to a running system requires instrumentation of every code path that produces state changes - not just adding a logging configuration flag. Each instrumentation point must be added, tested, and validated in a production system that can't be taken offline for a redesign.
What design-time verification enables
Observable action boundaries. When verification is a design constraint from the start, action execution is designed to emit verification events as a natural part of its contract, not as a bolted-on side effect. Every action boundary is observable by design.
Action type abstraction. When verification contracts are designed per action type, the codebase enforces that every new action implementation instantiates a typed action class that carries its verification contract. Adding a new action type automatically adds its verification contract; no action type can exist without one.
Immutable audit log. When the audit log is designed in from the start, it's part of the data model - not a separate table added after the fact. Every state change is captured at the persistence layer, not instrumented at the application layer. The audit log is complete by design.
# Design-time verification architecture class ActionType(Protocol): @abstractmethod def execute(self, params: ActionParams) -> ActionResult: pass@abstractmethod def verify(self, result: ActionResult, params: ActionParams) -> VerificationResult: pass
@abstractmethod def audit_record(self, result: ActionResult, params: ActionParams) -> AuditRecord: pass
Every action implementation must provide all three methods
Verification and audit are not optional extensions - they are part of the type contract
class ReadFileAction(ActionType): def execute(self, params): ... def verify(self, result, params): ... # required by the type def audit_record(self, result, params): ... # required by the type
Design-time vs retrofit comparison
| Approach | Relative cost | Coverage completeness | Regression risk |
|---|---|---|---|
| Design-time verification | 1x | Complete (all action types) | None (part of initial build) |
| Retrofit at 6 months | 3-5x | Partial (high-priority paths only) | Medium (touching production code) |
| Retrofit post-incident | 5-8x | Incident-class only (reactive) | High (emergency changes to production) |
| No verification | 0 upfront; 10-20x incident cost | 0% | N/A (cost is incident, not regression) |
Checks bolted on after integration cost more; a newer model inherits the same design-time omission.
The Pattern Intelligence Layer makes design-time verification non-negotiable by encoding it in the pattern specification. A pattern isn't complete until its verification contracts are specified. An action type isn't valid until its verify() and audit_record() methods are defined. The architecture enforces the principle that ISO/IEC 42001:2023 mandates and that experience confirms: verification designed in costs a fraction of verification bolted on.