A verification control needs an operating policy.

Degraded mode policy

Draft source on GitHub: degraded mode

what happens when verification cannot complete?

A check may be incomplete because a service is unavailable, configuration is missing, parsing fails or time runs out. That is not proof of an attack. A completed check may find a mismatch without establishing malicious intent. Keep the result separate from the operational decision: allowing an exception does not turn either outcome into PASS.

Only the primary domain has a default informed by research.

Mapped domains — conceptual

• fintechusually fail-closed with a fast override path — high cost of a missed attack, regulatory constraints
• firmwareusually fail-closed — bricking and safety dominate
• AI / MLoften configurable — permissive in dev, conservative in prod
• cryptooften tiered by value — high value fail-closed, low value configurable
• documentoften fail-open with audit where errors are reversible

The draft requires each override to be logged with who, when, why, evidence and expiry. An override without an expiry is a permanent hole with a friendly name.

degraded_mode:
  defaults:
    container:      fail_open_with_audit   # dev
    container_prod: fail_closed            # prod
    # non-primary domains below are illustrative mappings, not validated defaults
    fintech:  fail_closed_fast_override
    firmware: fail_closed
    ai_ml:    configurable
    crypto:   tiered_by_value
    document: fail_open_with_audit
  override_log_fields: [who, when, why, evidence, expiry]

Appeal and resolution

Draft source on GitHub: appeal and resolution

what if legitimate operations get blocked?

False positives are inevitable in any security control. The question is whether a path exists to resolve one without disabling the control entirely — because that is what teams do when no path exists.

1. Block occurs with a reason code and an evidence snapshot.
2. Operator requests review with counter-evidence.
3. Review against the invariant definition: rule bug, or actual violation?
4. Outcome: override granted, invariant updated, or block upheld.
5. Every step logged with identity, timestamp and rationale.

Time bounds are deployment-defined. Set an owner, escalation path and expiry for each deployment. No response-time or resolution-time figure is asserted here.

Invariant lifecycle

Draft source on GitHub: invariant lifecycle

how do rules get created, updated and retired?

Static rules become false-positive generators. What was valid yesterday blocks legitimate operations tomorrow. Invariants need a lifecycle with an exit.

• proposalnew invariant proposed with evidence of an attack pattern
• experimentalwarn-only; gather false-positive and false-negative data — duration set by the deployment
• activeenforcing, with ongoing monitoring
• deprecatedsunset period, warn-only — duration set by the deployment
• retiredremoved from enforcement, archived for audit

Review cadence: set and record a review interval for active invariants; no review cadence is claimed as implemented.

Error cost framework

how do you choose thresholds?

Optimal thresholds depend on domain-specific error costs. Blocking a firmware update and blocking a low-value transaction are not the same mistake.

• C_fpcost of a false positive — blocking a legitimate operation
• C_fncost of a false negative — allowing an attack
• base rateexpected attack frequency in this context

Output: a threshold and a bias direction — not a score.

These qualitative costs are draft calibration assumptions, not measurements or validated deployment defaults. Development and production costs follow the recorded specification revision. Rows marked mapped are conceptual, not measured.

Recalibration triggers: threat-landscape change, false-positive rate above threshold, incident post-mortem.

Domains — same gap, different shape

Domains that sign or authorize can exhibit this class of gap: what you intend against what gets committed. The attack paths, invariants and error costs depend on the deployment.

Container signing is the only row informed by published research. Everything tagged mapped is a starting point for a deployment conversation, not a validated default.

On smaller screens, scroll the table horizontally to see all columns.

Error costs and bias per domain are in §4.4; degraded-mode defaults in §4.1. The five exploitation patterns these all instantiate are on the gap.

Which protocol matters most, per domain

• containerinvariant lifecycle — approved base-image lists go stale fastest; appeal for urgent releases
• fintechappeal and resolution with strict targets; determine audit requirements for the specific deployment
• firmwaredegraded mode must be fail-closed; override requires strong authentication
• AI / MLinvariant lifecycle as models evolve; experimental phase for new model approvals
• cryptoerror cost drives tiered thresholds; appeal for time-sensitive trades
• documentstandard application; appeal for urgent documents

The loop, in one table