The Gold Standard · Archaeology
Make the decision path visible
A compensating control is approved because the primary surveillance rule cannot be used safely. Months later, the bridge model changes, a new sample range appears or the substitute is moved into a different workflow. The control may still run perfectly while no longer covering the decision it was meant to protect.
The gold standard defines coverage as a living contract, monitors the assumptions behind comparability and requires revalidation after material change. Until equivalent protection is demonstrated again, affected claims are restricted or routed through an independent safeguard.
Choose the route closest to your decision
Chapter contents
Chapters 1–3
Chapters 4–6
Chapters 7–9
Chapters 10–12
CHAPTER 1 OF 12 · DEFINE COVERAGE
1. Write the original coverage contract
State the primary risk, claim range, detection target, acceptable delay, independence assumptions and residual risk accepted when the substitute was approved.
Without a baseline contract, later teams can only ask whether the control still runs—not whether it still protects the same decision.
CHAPTER 2 OF 12 · DEFINE COVERAGE
2. Identify coverage boundaries and exclusions
Map specimen types, concentration or age ranges, instruments, bridge versions, software paths, operating conditions and reviewer capacity.
Make exclusions visible to downstream users. A control that protects the central range may not protect rare but consequential edges.
Evidence check
Check whether the scope, owner and decision consequence are explicit before continuing.
CHAPTER 3 OF 12 · DEFINE COVERAGE
3. Name the changes that trigger revalidation
Triggers include new bridge coefficients, software updates, instrument replacement, changed reference material, expanded range, altered alert routing and different review staffing.
Use risk-based thresholds, but do not let teams decide after seeing the result whether a change was material.
| Element | Record |
|---|---|
| Risk | What must be detected? |
| Range | Where protection applies |
| Delay | How quickly? |
| Residual | What remains? |
CHAPTER 4 OF 12 · DETECT DRIFT
4. Monitor leading indicators of coverage loss
Track shadow-alert yield, fault-detection rate, delay, unreviewed queue, independence failures, distribution shift and divergence between primary and substitute evidence.
Stable alert counts can hide loss of sensitivity when the monitored population or bridge model has moved.
CHAPTER 5 OF 12 · DETECT DRIFT
5. Separate control performance from system compatibility
A substitute may pass its own tests yet receive the wrong inputs, thresholds or timestamps after a system change.
Validate interfaces, transformations and version identifiers as well as the statistic itself.
Evidence check
Ask a second reviewer to reconstruct the example from the preserved evidence and stated assumptions.
CHAPTER 6 OF 12 · DETECT DRIFT
6. Worked example: a boundary shift moves faults outside the substitute range
Suppose a substitute control was validated for mid-range calibrated samples while a noisy primary rule was suppressed. A bridge-model update expands classification into a lower range, but the substitute keeps its old inclusion filter. No alert appears because the new samples never enter its calculation.
A coverage audit finds the exclusion, restricts lower-range claims and replays representative faults through the updated pipeline. The substitute is revalidated only after the filter and thresholds are revised. Changed-context check: if lower-range samples are explicitly non-decisional research outputs, exclusion may be acceptable, but the label and downstream rule must prevent operational use.
| Change | Question |
|---|---|
| Model | Did decision boundaries move? |
| Instrument | Did measurement behaviour change? |
| Software | Did inputs or routing change? |
| Workflow | Did reviewer capacity change? |
CHAPTER 7 OF 12 · REVALIDATE PROTECTION
7. Revalidate with representative faults and real dependencies
Replay known failures across old, current and edge conditions. Include acquisition, transformation, model, notification and review paths.
A laboratory-only test that bypasses production routing cannot demonstrate operational protection.
CHAPTER 8 OF 12 · REVALIDATE PROTECTION
8. Re-test independence after every architectural change
Check shared sensors, clocks, code libraries, reference materials, queues and reviewers. New consolidation can create common-cause failure where none existed before.
Preserve at least one independent high-consequence route while revalidation is incomplete.
Evidence check
Verify that the control still reaches the intended decision under a changed but plausible context.
CHAPTER 9 OF 12 · REVALIDATE PROTECTION
9. Stage re-authorisation with explicit acceptance criteria
Use shadow mode, limited ranges and named review checkpoints before restoring full reliance.
Acceptance should cover detection, delay, false alarms, independence, version traceability and reviewer response—not merely successful execution.
| Test | Pass condition |
|---|---|
| Fault replay | Expected detection |
| Edge cases | Scope understood |
| Independence | Common causes bounded |
| Operations | Alert reaches an owner |
CHAPTER 10 OF 12 · RESTORE GOVERNANCE
10. Bound and repair the exposure interval
Identify when coverage was lost, which specimens and claims entered the unsupported region and which releases depended on the substitute.
Re-run or reopen material cases. Do not assume the absence of alarms proves the interval was safe.
CHAPTER 11 OF 12 · RESTORE GOVERNANCE
11. Update the approval record and communicate residual limits
Record the new scope, evidence, owner, expiry and remaining exclusions. Notify analysts and decision-makers whose use has changed.
A revalidated control is a new governed state, not an invisible continuation of the earlier approval.
Evidence check
Confirm that versions, notices and unresolved limits remain visible in the final record.
CHAPTER 12 OF 12 · RESTORE GOVERNANCE
12. Audit whether revalidation keeps pace with change
Measure unreviewed triggers, time to revalidate, exposed intervals, repeated edge failures and changes implemented before approval.
The gold standard protects equivalence over time. Compensating control status must change when the system it compensates for changes.
| Measure | Warning |
|---|---|
| Trigger backlog | Change outruns review |
| Coverage gap | Unsupported claims |
| Revalidation delay | Long exposure |
| Repeat edge failure | Scope design weak |
Frequently asked questions
When must a compensating control be revalidated?
After any material change to range, model, instrument, software, routing or review capacity that could affect comparable protection.
Is a successful unit test enough?
No. Revalidation must include production inputs, dependencies, notifications and representative failure conditions.
What happens while revalidation is incomplete?
Restrict affected claims or maintain an independent safeguard; do not assume the old approval still applies.
Can a control drift without changing its code?
Yes. Population, range, upstream data, thresholds, bridge models and workflows can move around unchanged code.
Continue through verified routes
Core routes
Archaeology subject root · Gold Standard of Education · Gold Standard directory · How X Works hub
Specialist routes
- Suppression dependency, compensating controls and single-point blindness
- Suppression renewal and automatic reinstatement
- Alert suppression and independent challenge
- Decision-limit surveillance and reopening historical claims