STD-02 evidence pack
What to show for STD-02 challenges, review clocks, and remedies at three tiers, from a working appeal path to proof under incident load, and what auditors ask.
On this page
Tiered evidence model
Tier 0 to Tier 2 minimum
Begin with Tier 0 to prove access, then move up to resilience evidence.
- Tier 0 (minimum): Proof the appeal path exists and is reachable in-product. UI links, receipt payloads, and appeal intake records.
- Tier 1 (operational): Proof that challenges are reviewed and clocks are honored. Reviewer rosters, appeal outcomes, and clock compliance dashboards.
- Tier 2 (resilient): Proof that the challenge route survives scale, incident load, and exceptions. Postmortems, exception audits, and throughput stress tests.
Receipt payloads should conform to the Agent Receipt schema, so an auditor's tools can read them.
Evidence packs per clause
The evidence each STD-02 clause asks for, from the clause register.
-
STD-02.1.1 (§1.1) — when
an automated decision is made, produce a decision object containing reason codes, evidence sources, and scope boundaries.
Evidence: decision_object, decision_log -
STD-02.1.2 (§1.2) — when
reasons are given to the person a decision is about, write them in language a layperson can understand; legalese and internal codes are insufficient.
Evidence: ui_notice, decision_object -
STD-02.1.3 (§1.3) — when
an automated decision is made, make its reasons available at the moment of decision; an explanation deferred until requested does not comply.
Evidence: ui_notice, decision_log -
STD-02.1.4 (§1.4) — when
a reason is given for a consequential decision, or the component that decided gives no reasons, state what the decision actually rested on; label any explanation written afterward by another component as an account; where the decider gives no reasons, record that on the decision object with the policy, threshold, and inputs, and add evidential support to the class's standards of review.
Evidence: decision_record.decision, decision_record.policy_refs, decision_record.evidence_basis, standing_register.decision_classes.standard_of_review -
STD-02.2.1 (§2.1) — when
a decision is sent or shown to the person it is about, make the appeal path reachable directly from the decision notification or interface.
Evidence: ui_state, journey_map -
STD-02.2.2 (§2.2) — when
an appeal path is offered, name the accountable authority that holds reversal power.
Evidence: appeal_policy, authority_matrix -
STD-02.2.3 (§2.3) — when
an appeal path is offered, publish appeal deadlines, bound them in time, and enforce them.
Evidence: sla_doc, ui_copy, event_log -
STD-02.3.1 (§3.1) — when
a decision can be reviewed, declare the maximum duration of the review.
Evidence: sla_doc, review_policy -
STD-02.3.2 (§3.2) — when
the review clock expires without a resolution, escalate the case automatically to a higher authority, or default to reversal.
Evidence: escalation_policy, event_log -
STD-02.3.3 (§3.3) — when
a review is pending, give the person the decision is about provisional protection: continued access, the status quo, or a safe fallback.
Evidence: interim_protection_policy, case_log -
STD-02.4.1 (§4.1) — when
a challenge is upheld, reverse the contested decision unless safety criteria explicitly prohibit it.
Evidence: appeal_outcome_log, remedy_policy -
STD-02.4.2 (§4.2) — when
a decision causes wrongful harm, issue credits, fee waivers, or restitution automatically, without requiring a separate claim.
Evidence: remedy_policy, remediation_log -
STD-02.4.3 (§4.3) — when
a remedy is delivered, record delivery with timestamps and have the person it is owed to verify it.
Evidence: remediation_log, case_log -
STD-02.4.4 (§4.4) — when
a defect is found to arise from a rule, a model, or a notice rather than from one decision, reach every affected case without a further claim; enumerate the affected population from the institution's own records, reverse each affected decision, restore each person it harmed, and tell each person what was reversed and how they were restored.
Evidence: affected_population, remediation_log, notification_log -
STD-02.5.1 (§5.1) — when
a decision is made, emit a receipt with a timestamp, the owner, and a reference to the decision object.
Evidence: receipt_template, decision_log -
STD-02.5.2 (§5.2) — when
challenges are decided, publish appeal passage rates and reversal rates, and use them to improve decisions.
Evidence: appeal_outcome_log, published_metrics -
STD-02.5.3 (§5.3) — when
a decision is contested, enter the decision in the decision log, linked to its evidence, reviewers, and outcome.
Evidence: audit_trail, case_log -
STD-02.5.4 (§5.4) — when
an objection is answered with a burden score, safety-case result, audit finding, or other measurement the challenged party did not produce, treat it as evidence and not a bar; do not cite it to dispose of the objection or to establish that the person's account is unfounded; route the conflict between a score and an account to a named reviewer holding authority to resolve it.
Evidence: objection_record, review_assignment, score_provenance -
STD-02.6.1 (§6.1) — when
an automated system denies a claim or takes a consequential action, offer human review on request, with no new evidence, additional form, or stated reason required.
Evidence: review_policy, support_workflow -
STD-02.6.2 (§6.2) — when
reviewers are evaluated, do not reward upheld denials, closure speed, or any other metric that biases against remedies; disclose the evaluation policy.
Evidence: performance_policy, incentive_plan -
STD-02.6.3 (§6.3) — when
logs support review or remedy, retain them, tamper-evident, for at least the full review and appeal period plus the limitation window.
Evidence: audit_trail, retention_policy -
STD-02.7.1 (§7.1) — when
automation causes an error or a delay, accept liability for the resulting harm as the operating institution.
Evidence: policy, governance_record -
STD-02.7.2 (§7.2) — when
a vendor operates the logs, the models, or the controls, still guarantee access and remedy to the person the system decided about, as the operating institution.
Evidence: vendor_contract, access_policy -
STD-02.7.3 (§7.3) — when
automation increases the throughput of decisions, fund review capacity in proportion to the actions taken, and include the capacity plan in the deployment's evidence.
Evidence: capacity_plan, case_volume_metrics -
STD-02.8.1 (§8.1) — when
a class of consequential decision can be challenged, publish a standing register entry naming who may challenge, what may be challenged, admissible evidence, the obliged responder, the response deadline, the standard of review, and the possible state transitions.
Evidence: standing_register.who_may_challenge, standing_register.responder, standing_register.response_deadline, standing_register.standard_of_review, standing_register.possible_state_transitions -
STD-02.8.2 (§8.2) — when
a responder is obliged to answer a challenge, state the standard the answer is decided against: policy conformance, policy correctness, evidentiary support, or reasonableness of outcome.
Evidence: standing_register.standard_of_review, appeal_outcome_log -
STD-02.8.3 (§8.3) — when
a challenge can succeed, enumerate the state transitions success can produce: stand, narrow, suspend, reverse, correct, or expand or withdraw the grant behind the decision.
Evidence: standing_register.possible_state_transitions, reconsideration.outcome -
STD-02.8.4 (§8.4) — when
a party absorbs the system's errors, grant standing to the people the decision falls on and to the operators who handle exceptions, work the queues, and perform the manual repair the automation assumes; name both in who_may_challenge as affected_party and corrective_labor, each with the force of §8.5 and the same response deadline.
Evidence: standing_register.who_may_challenge, standing_register.response_deadline, exception_handling_roster, case_log -
STD-02.8.5 (§8.5) — when
a party with standing files a challenge, guarantee receipt, an answer within the deadline, and a decision against the published standard, without granting the power to compel the outcome.
Evidence: standing_register.response_deadline, appeal_outcome_log, policy -
STD-02.8.6 (§8.6) — when
a consequential decision class issues decisions faster than challenges to them can be answered, state answer capacity per period on the register entry; where issue rate times measured or stated error rate exceeds it, treat the class as uncontestable in practice until capacity rises or issue rate falls, without narrowing standing.
Evidence: standing_register.decision_classes.response_deadline, standing_register.decision_classes.responder, challenge_load_ledger, decision_issue_log -
STD-02.9.1 (§9.1) — when
records are retained for a consequential delegation, retain what is needed to decide whether the delegation still deserves to stand: the authority it ran under, the policy versions that authority rested on, the assumptions declared, the correction capacity claimed, and the challenges received and answered.
Evidence: authority_grant.evidence_basis, policy_record.version, policy_record.assumptions, audit_trail -
STD-02.9.2 (§9.2) — when
a component is supplied by a third party, keep the retained set sufficient for the operating institution to answer the standing question without that supplier's cooperation.
Evidence: vendor_contract, access_policy, audit_trail -
STD-02.9.3 (§9.3) — when
a delegation is live, ask whether it still deserves to stand on a published cadence and record the answer, dated, whether or not anything changed.
Evidence: review_cadence_policy, governance_record -
STD-02.10.1 (§10.1) — when
a party became affected after adoption, without consenting or without any new decision by them, extend standing to that party; the enumeration of affected parties made at adoption records who was affected then and does not define who may challenge now.
Evidence: standing_register.who_may_challenge, dependency_record.dependents, case_log -
STD-02.10.2 (§10.2) — when
any level of reversibility has moved from evidenced to not evidenced, or exposure_score or substitution_cost has risen by a quarter or more, against the values recorded when consent was given, disclose the change to the consenting party, naming which measure moved, by how much, and the standing route; stop treating the original consent as covering the new degree of dependence.
Evidence: dependency_record.exposure_score, dependency_record.substitution_cost, dependency_record.reversibility, consent_record
Anti-weaponization evidence
Evidence requirements for AW-01 through AW-04
The evidence each anti-weaponization constraint asks for, alongside the STD-02 clauses.
- AW-01: Burden remediation plan tied to challenge metrics.
- AW-02: Appeal path regression tests + public replacement notice.
- AW-03: Receipts + clock compliance for automated downgrades.
- AW-04: Assisted channel logs with escalation outcomes.
Pair this with diagnostics checks to validate AW compliance.
How teams fake this
Common compliance theater patterns
Ways an appeal path can exist on paper and fail in use.
- Appeal links exist but lead to dead ends or generic inboxes.
- Review clocks are defined but not visible to the people the decisions are about.
- Manual review happens, but outcomes and reversals are not entered in the decision log.
- Exception paths are used to avoid remedies without any expiry or review cadence.
What auditors ask
Audit questions to prepare for
Provide clause-linked evidence and decision logs in response.
- Show appeal outcomes for the last quarter and the median review time.
- Demonstrate how many remedies were delivered within the remedy clock.
- Provide evidence that exception classes are time-bounded and reviewed.
- Show how decision logs reference evidence packs for contested decisions.
- Show, for each decision class, how many challenges were upheld, and what changed in the rule after them, or the STD-07 reconsideration record that kept it.