STD-01 evidence pack

What to show for each STD-01 temporal right at three tiers, from instrumented logs to stress-tested proof, with how teams fake it and what auditors ask.

Tiered evidence model

Tier 0 to Tier 2 minimum

Start at Tier 0 for baseline proof, then scale to Tier 2 for resilience.

  • Tier 0 (minimum): System outputs that prove the clause is instrumented. Event logs, UI snapshots, and receipt payloads.
  • Tier 1 (operational): Evidence the control is used and reviewed. Decision logs, appeal outcomes, reviewer rosters, and clock compliance reports.
  • Tier 2 (resilient): Stress-tested proof that controls survive real incidents. Incident postmortems, drill results, and remediation follow-through.

Evidence packs per clause

Each clause lists the minimum evidence an operator would show to meet it, once the standard is adopted.

  • STD-01.1.1 (§1.1) — when an automated process is in progress, provide a visible, universally accessible halt control.
    Evidence: ui_control, event_log
  • STD-01.1.2 (§1.2) — when a process is halted by the user, save the paused state so the user can return without penalty; never destroy data as a penalty for halting.
    Evidence: state_snapshot, retention_policy
  • STD-01.1.3 (§1.3) — when a user is in a multi-step flow, offer a permanent exit option on every screen.
    Evidence: ui_state, interaction_map
  • STD-01.2.1 (§2.1) — when a user seeks to end their relationship with a system, allow exit with equal or less friction than entry.
    Evidence: journey_map, time_cost_log
  • STD-01.2.2 (§2.2) — when entry required a single step, require no more than one step to exit.
    Evidence: journey_map, ui_state
  • STD-01.2.3 (§2.3) — when a user starts to cancel or leave, do not require retention flows, exit surveys, or confirmations of loss before exit.
    Evidence: journey_map, policy
  • STD-01.3.1 (§3.1) — when a process has pending, processing, or review states, define a maximum duration for each state.
    Evidence: system_sla, event_log
  • STD-01.3.2 (§3.2) — when a request is not resolved within its declared timeframe, default to a failure state or to human escalation.
    Evidence: escalation_policy, event_log
  • STD-01.3.3 (§3.3) — when a user is asked to commit to a process, declare the estimated time to completion before the user commits.
    Evidence: ui_copy, journey_map
  • STD-01.4.1 (§4.1) — when a user takes an action with consequential effects, such as deletion, transfer, or publication, provide a grace period in which the action can be reversed without administrative intervention.
    Evidence: ui_state, policy
  • STD-01.4.2 (§4.2) — when a system removes user data, archive it by default (soft delete); never destroy it permanently on a single input.
    Evidence: data_retention_policy, event_log
  • STD-01.5.1 (§5.1) — when a user is placed in a waiting state, show accurate, real-time queue position and expected wait time.
    Evidence: ui_state, queue_metrics
  • STD-01.5.2 (§5.2) — when a system shows progress or waiting status, do not use fake progress bars, placebo buttons, or looping animations to simulate activity while idle or stalled.
    Evidence: ui_state, event_log
  • STD-01.5.3 (§5.3) — when a wait exceeds five minutes, offer a callback or notification so the user need not hold an active connection.
    Evidence: ui_state, journey_map
  • STD-01.5.4 (§5.4) — when a stated clock for an application, appeal, or prior-authorization request expires without a decision, resolve the request in the applicant's favor, or escalate to a human reviewer where the default outcome falls harder on the applicant than on the institution; a clock with no stated consequence is not a clock.
    Evidence: expiry_rule, expired_request_log
  • STD-01.6.1 (§6.1) — when an automated decision denies a user access, service, or property, provide a clearly defined path to appeal to a human agent.
    Evidence: policy, support_workflow
  • STD-01.6.2 (§6.2) — when an automated agent errs or delays, accept full liability as the operating institution; algorithmic error is not a defense.
    Evidence: policy, governance_record
  • STD-01.7.1 (§7.1) — when a system imposes a compliance or usage burden on the public, measure and publish the time tax it imposes.
    Evidence: burden_report, time_cost_log
  • STD-01.7.2 (§7.2) — when a major system update is made, audit it to confirm it does not increase the cognitive load or time required for existing tasks.
    Evidence: burden_impact_statement, time_cost_log

Anti-weaponization evidence

Evidence requirements for AW-01 through AW-04

Treat anti-weaponization clauses as enforceable audit requirements.

  • AW-01: Burden metrics report + resourcing plan for the next window.
  • AW-02: Appeal path regression tests + replacement notice evidence.
  • AW-03: Receipts + clock compliance for downgrades and eligibility changes.
  • AW-04: Assisted channel response deadline + staffing roster for high-burden flows.

Link the constraints in Anti-weaponization to STD-01 clause evidence bundles.

How teams fake this

Common compliance theater patterns

Ways a team can appear to meet STD-01 without meeting it. An auditor will look for each one.

  • Receipts exist but omit owner, clocks, or appeal path.
  • UI screenshots are staged once and never updated after release.
  • Event logs exist but are not tied to decision log entries or remedy outcomes.
  • Kill switch drills are logged without showing the actual halt time or restoration proof.

What auditors ask

Audit questions to prepare for

Answer these with links to the clause evidence list and decision records.

  • Show the last five receipts for halted flows and their remedy outcomes.
  • Provide evidence that exit paths match entry friction across the top three flows.
  • Demonstrate a recent kill switch drill and its time-to-halt measurement.
  • Explain how exceptions are reviewed and how long they lasted.