Designing validation evidence for infrastructure change approval
Infrastructure change should not be approved because a design looks plausible; it should be approved because the team can show intent, dependencies, risk, rollback, observability, and acceptance evidence before execution.
The problem
Many infrastructure decisions are approved from diagrams, vendor confidence, and verbal assurance. That may be enough to start discussion, but it is not enough to protect an implementation window, an operations team, or a business service. A design can be coherent and still be unready because ownership, failure domains, validation evidence, and rollback authority have not been made explicit.
The evidence model
A reviewable change package should make six things visible before execution:
- Intent: the decision being made, the business or operational reason, and the boundary of the change.
- Dependencies: systems, vendors, routes, identities, monitoring, people, and process dependencies affected by the change.
- Risk: the expected failure modes, blast radius, and signals that indicate degradation.
- Rollback: the technical path back, the authority to invoke it, and the condition that triggers it.
- Observability: the metrics, logs, transactions, and operator checks that prove the system is healthy.
- Acceptance: the evidence required to say the change is complete and safe to leave in place.
Sample validation matrix
| Review area | Evidence before approval | Go/no-go question |
|---|---|---|
| Intent | Written decision statement and excluded scope | Does everyone agree what is changing? |
| Dependencies | Dependency map and owner list | Are all affected systems and teams known? |
| Risk | Failure-domain summary and blast-radius estimate | Can the team describe what failure looks like? |
| Rollback | Rollback sequence, authority, and timer | Can the team reverse the change before damage spreads? |
| Observability | Pre-change baseline and post-change checks | Can health be proven rather than assumed? |
| Acceptance | Pass/fail criteria and evidence owner | Who signs off, using what proof? |
Example go/no-go gate
A change should not proceed if any of the following are missing: dependency owner, rollback authority, health baseline, acceptance criteria, monitoring path, and communications owner. These are not paperwork items. They are the minimum controls that keep a technical change from becoming an unmanaged incident.
Executive summary pattern
Proceed only when the implementation team can demonstrate the intended outcome, affected dependencies, failure signals, rollback authority, validation evidence, and post-change ownership. If any of these are unknown, the change may still be technically possible, but it is not yet reviewable.
How Bradford uses this method
Bradford Informatics applies this structure to architecture reviews, validation evidence packages, and runbook hardening. The goal is not to make every project slower. The goal is to prevent teams from discovering missing ownership, missing evidence, or missing rollback only after execution has begun.