Drift Detection
Approval is a snapshot; production is a moving target. From the moment a package is approved, IronArchitects captures its approval baseline (the design, its flows, and its control results as approved) and continuously compares reality against it. When the two diverge, a drift finding opens; when they re-converge, it resolves itself.
Plan Availability
Drift detection is available on the Medium plan and above. The environment comparisons additionally use discovery inventories, available on Large and above.
Where It Lives
Operate → Drift shows the baseline card (what was approved and when) and the findings list. Checks run continuously on a schedule; Check Now runs one on demand. Editing an approved design is deliberately not blocked; the platform detects and reports instead, so emergency changes are possible but never silent.
What Can Drift
| Finding | What It Means |
|---|---|
| Design changed | The design was edited or re-run after approval: components added or removed, technologies or flows changed |
| Control regressed | A control that passed at approval is failing now |
| No longer compliant | The package's overall compliance posture dropped |
| Not found in environment | An approved component has no discovered counterpart running in your estate (after a grace window for deployment lag) |
| Unsanctioned technology | Something is running in your estate that no approved design or catalog entry accounts for; reported at the organization level |
| Built out of sequence | Later delivery phases started while earlier ones have not (needs an exported delivery plan) |
| Security tasks skipped | Build work is done in your tracker but security hardening tasks remain open |
| Done but not observed | Work is marked done in your tracker but the component is not observed in the environment |
| Vendor contract at risk | A contract the design leverages is renewing within 90 days, or has lapsed while components still depend on it |
The Finding Lifecycle
Findings are deduplicated: the same condition never opens twice; it just updates its last-seen time. When the underlying condition clears (the design is restored, the control passes again, the contract is renewed) the finding auto-resolves with no action from you.
Your two actions:
- Acknowledge: the governed override. The finding stays visible but stops counting against you; acknowledged findings never block the conformance gate. Use it when the drift is understood and accepted.
- Resolve: close a finding you have dealt with outside the platform's view. If the condition persists, the next check reopens it.
Who Hears About It
New findings notify the package's people (owner, assignee, contributors), and organization-level findings notify org admins. Drift events also fire webhooks and are written to the audit log, which means they flow to your SIEM if SIEM Export is configured.
Drift Is the Operating Rhythm
A healthy package spends its life at zero open findings. Treat an open finding like a failing test: fix the condition, acknowledge it deliberately, or revise the design and re-approve; do not let it age.