operational safety protocols

security controls must include brakes

a verification layer that breaks production is worse than no verification at all. the protocols below document how the system behaves under uncertainty and how errors are resolved.

a recurring lesson: security tooling often fails in a few recurring ways: checks get bypassed, input boundaries get crossed, systems become brittle under load, and teams miscalibrate the cost of blocking vs. allowing. these aren't isolated bugs — they're structural failure modes.

that's why 1seal treats operations as part of the product: Degraded Mode Policy, Appeal and Resolution, Invariant Lifecycle, and Error Cost Framework.

canonical spec: github.com/1seal/lmv-spec

degraded mode policy

what it answers: what happens when verification cannot complete?

verification can fail for many reasons: service unavailable, config missing, parsing error, timeout. the question is what the system does next.

domain defaults

domain default rationale
container configurable (dev: fail-open with audit; prod: fail-closed) balance velocity vs. release integrity
fintech fail-closed + fast override path regulatory requirements + high C_fn
firmware fail-closed C_fn dominates (bricking, safety)
ai/ml configurable (dev: permissive; prod: conservative) experimentation vs. prod blast radius
crypto tiered (high-value: fail-closed; low-value: configurable) irreversible loss, value-dependent risk tolerance
document fail-open with audit (or configurable) avoid blocking workflows when C_fn is often reversible

every override is logged with: who, when, why, evidence, expiry.

configuration example

degraded_mode:
  defaults:
    container: fail_open_with_audit   # dev
    container_prod: fail_closed       # prod
    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

what it answers: what if legitimate operations get blocked?

false positives are inevitable in any security system. the question is whether there's a path to resolve them without disabling the control entirely.

flow

  1. block occurs with reason code and evidence snapshot.
  2. operator requests review with counter-evidence.
  3. review against invariant definition. is this a rule bug or an actual violation?
  4. outcome: override granted, invariant updated, or block upheld.
  5. every step logged with identity, timestamp, rationale.

time bounds: deployment-defined targets (recommended defaults: initial response 24h, resolution 72h for standard cases).

invariant lifecycle

what it answers: how do rules get created, updated, and retired?

static rules become false-positive generators. what was valid yesterday may block legitimate operations tomorrow. invariants need a lifecycle.

stages

  • proposal: new invariant proposed with evidence of attack pattern.
  • experimental: warn-only mode, gather fp/fn data. 7-30 days.
  • active: enforcing mode, ongoing monitoring.
  • deprecated: sunset period, warn-only. 30 days.
  • retired: removed from enforcement, archived for audit.

review cadence: quarterly review of all active invariants.

error cost framework

what it answers: how do you choose thresholds?

optimal thresholds depend on domain-specific error costs. blocking a firmware update has different consequences than blocking a low-value transaction.

inputs

  • c_fp: cost of false positive. blocking legitimate operation.
  • c_fn: cost of false negative. allowing attack.
  • base_rate: expected attack frequency in this context.

output: threshold and bias direction.

examples

domain c_fp c_fn bias
container low (dev), medium (prod) extreme permissive (dev), conservative (prod)
fintech high extreme conservative + fast appeal
firmware medium extreme very conservative
ai/ml low (dev), medium (prod) high permissive (dev), conservative (prod)
crypto medium (low-value), high (high-value) extreme configurable by value tier
document medium medium balanced

recalibration triggers: threat landscape change, fp rate exceeds threshold, incident post-mortem.

protocol summary

protocol question answered key guarantee
Degraded Mode Policy what happens when verification fails? explicit behavior, audit trail
Appeal and Resolution what if legitimate operations get blocked? time-bounded path to resolution
Invariant Lifecycle how do rules evolve? managed evolution, no stale rules
Error Cost Framework how to choose thresholds? domain-specific calibration

see these protocols applied across different domains

domain applications the problem