Review architecture drift
Compare architecture across time while distinguishing verified changes from missing or incomparable evidence.
Drift starts with a comparison. A single review can establish a model at a point in time; it cannot tell you what changed since an earlier state unless that state is available.
Establish a usable baseline
Run at least two completed or partial reviews for the same connected repository. Open Drift to inspect the repository comparison. The current comparison uses its latest two terminal architecture snapshots and displays the evidence behind changed items.
Archive reviews support architecture exploration and decision proposals. They do not establish repository history by themselves. When no comparable history exists, the interface asks for it instead of presenting a drift verdict.
Check whether the observations are comparable
Before interpreting a difference, check:
- The source repository, revision, and observation date of each snapshot.
- The source families present in each review.
- Missing collection scopes, stale observations, or partial results.
- Whether the evidence describes the same account and environment boundary.
An item absent from a later partial snapshot may be not re-observed, rather than removed. Missing cloud collection is not proof that a public route disappeared.
Follow the change to its evidence
Open an added, removed, or changed entity or relationship and inspect the supporting observations. Use Map to understand the surrounding path and Truth to read provenance and confidence.
For the gateway example, a new direct API route matters because it can bypass a boundary. Code and IaC may declare the route; cloud observations can corroborate the deployed configuration. Those records explain the difference before any vulnerability finding is considered.
Review what the change means for intent
A changed relationship and an invalidated decision are separate questions. Compare the new evidence with the decision's guardrail, its rationale, and the exact baseline it references.
An authorized person decides what the change means for a prose guardrail. Supported structured criteria can return a deterministic result, but missing evidence can still make verification inconclusive. Hyperoru does not invent the team's intent to fill that gap.
Understand the regression gate
| Result | Meaning |
|---|---|
| Pass | The evaluated comparison satisfies the configured gate. This is bounded to its evidence and policy. |
| Review | A policy condition asks a person to inspect the change. |
| Blocked | An evaluated policy condition blocks the change. |
| Insufficient evidence | The comparison cannot support the required conclusion. |
Gate policy can include minimum coverage, matching source families, removal behavior, or particular new relationship kinds. See change intelligence for the API and policy contract.
Leave a clear next action
After reviewing, identify the next observation, decision, or change needed. It may be collecting missing cloud evidence, correcting a route, or ratifying a revised architecture decision. Keep that action attached to the facts that motivated it.