{
  "meta": {
    "generatedAt": "2026-06-03T23:21:30.105Z",
    "count": 11,
    "permalink": "/mechanisms",
    "release": {
      "id": "2026.01",
      "label": "2026.01",
      "date": "2026-01-09",
      "permalink": "/api/v/2026.01"
    }
  },
  "patterns": [
    {
      "id": "MEC-01",
      "type": "mechanism",
      "slug": "decision-log",
      "title": "MEC-01 Decision log with dissent",
      "summary": "Capture high-stakes calls, dissenting views, and follow-ups so governance stays legible to teams and impacted people.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "design-authority",
        "repair-log",
        "contestability"
      ],
      "cues": [
        "Record why options were ruled out and who was consulted.",
        "Attach plain-language summaries for external readers.",
        "Set a review date tied to the stewardship window."
      ],
      "diagnostics": [
        "burden-modeler"
      ],
      "steps": [
        "Log the decision, rejected options, and who was consulted in one place.",
        "Attach a short summary alongside the canonical record for external readers.",
        "Set a review date with a clear owner tied to the stewardship window."
      ],
      "artifacts": [
        {
          "name": "Decision record template",
          "purpose": "Captures the decision, dissent, and follow-ups with owners."
        },
        {
          "name": "Plain-language summary",
          "purpose": "One-paragraph recap teams can paste into briefs or release notes without jargon."
        },
        {
          "name": "Stewardship calendar entry",
          "purpose": "Review reminder aligned to maintenance or appeal windows."
        }
      ],
      "example": {
        "title": "Recording a launch gate call",
        "description": "A cross-functional team logs why an automation launch was delayed, notes dissent from support leads, links the appeal path, and schedules a stewardship review in six weeks."
      },
      "anti_patterns": [
        {
          "title": "Logs without dissent",
          "failure": "Records the decision but omits rejected options and dissenting views.",
          "counterfactual": "Decision logs include rejected options, dissent, and a dated review owner.",
          "warning": "If no dissent exists, log the absence explicitly so future reviewers can see it was considered."
        },
        {
          "title": "Out-of-band records",
          "failure": "Keeps accountability logs in private documents that impacted teams cannot access.",
          "counterfactual": "Logs live in the canonical record with a shareable receipt link.",
          "warning": "Sensitive data can be redacted, but the receipt must remain referenceable."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-01 Decision log with dissent)\n- Maintain a decision log for high-stakes changes with dissenting views and a dated review owner.\n- Store the log in a shared system of record and retain links in audit and incident records.\nReference: https://ethotechnics.org/mechanisms/patterns/decision-log",
      "product_requirement": "Product requirement (MEC-01)\n- Every high-stakes automated decision emits a decision-log entry ID in the receipt.\n- The UI links to a plain-language summary within two clicks of the decision outcome.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-01)\n[ ] Decision log entries include owner, dissent, and review date.\n[ ] Plain-language summaries are attached and shareable.\n[ ] Stewardship reviews were completed on schedule.",
      "postmortem_trigger": "Postmortem trigger (MEC-01)\nTrigger review if a high-stakes decision ships without a logged entry or dissent record.",
      "citation": {
        "permalink": "/mechanisms/patterns/decision-log",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/decision-log",
      "refs": [
        "design-authority",
        "repair-log",
        "contestability"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-02",
      "type": "mechanism",
      "slug": "progressive-consent",
      "title": "MEC-02 Progressive consent prompts",
      "summary": "Stage requests for data or automation over time, with reminders and exits that honor the consent journey.",
      "filters": [
        "friction",
        "policy"
      ],
      "glossary_refs": [
        "consent-journey",
        "permission-surface",
        "safety-valve"
      ],
      "cues": [
        "Pair each ask with why it is needed and how to revoke it.",
        "Show impacts of opting out before a person commits.",
        "Include a safety valve that defaults to privacy-preserving behavior."
      ],
      "diagnostics": [
        "llm-capacity-benchmark"
      ],
      "steps": [
        "Break large asks into small prompts that explain why each is needed.",
        "Preview what happens if someone opts out and keep the path visible.",
        "Offer a safety valve that defaults to privacy-preserving behavior."
      ],
      "artifacts": [
        {
          "name": "Consent journey map",
          "purpose": "Shows each request, rationale, and rollback path across the flow."
        },
        {
          "name": "Opt-out copy kit",
          "purpose": "Short blurbs teams reuse in UI states, emails, and help docs."
        },
        {
          "name": "Safety valve checklist",
          "purpose": "Confirms every step has a reversible, privacy-first fallback before shipping."
        }
      ],
      "example": {
        "title": "Piloting a model-powered assistant",
        "description": "Product and legal teams stage data collection prompts over several sessions, preview how opting out affects recommendations, and keep a global “pause automation” control visible in the UI."
      },
      "anti_patterns": [
        {
          "title": "One-shot consent bundles",
          "failure": "Asks for every permission at once without explaining timing or scope.",
          "counterfactual": "Requests are staged with clear rationale, timing, and reversible defaults.",
          "warning": "Bundling can be acceptable if the scope is minimal and opt-outs are explicit."
        },
        {
          "title": "Opt-out that does not stick",
          "failure": "Offers a toggle but automation continues or re-enables without notice.",
          "counterfactual": "Opt-outs pause automation and are logged with a visible confirmation.",
          "warning": "Some baseline data use can remain if it is disclosed and required for service safety."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-02 Progressive consent prompts)\n- Stage consent requests with clear revocation paths and visible opt-out impacts.\n- Document safety-valve defaults that preserve privacy when consent is withheld.\nReference: https://ethotechnics.org/mechanisms/patterns/progressive-consent",
      "product_requirement": "Product requirement (MEC-02)\n- Each consent request includes purpose, duration, and revocation instructions.\n- Opt-out paths remain visible and do not degrade core safety access.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-02)\n[ ] Consent journey map shows each ask, rationale, and rollback path.\n[ ] Opt-out copy kit deployed across UI, email, and help surfaces.\n[ ] Safety-valve defaults verified in staging and production.",
      "postmortem_trigger": "Postmortem trigger (MEC-02)\nTrigger review if opt-out actions fail, are ignored, or re-enable without notice.",
      "citation": {
        "permalink": "/mechanisms/patterns/progressive-consent",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/progressive-consent",
      "refs": [
        "consent-journey",
        "permission-surface",
        "safety-valve"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-03",
      "type": "mechanism",
      "slug": "maintenance-windowing",
      "title": "MEC-03 Maintenance windowing",
      "summary": "Schedule improvements, monitoring, and resourcing using a visible stewardship window.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "maintenance-window",
        "maintenance-metabolism",
        "repair-log"
      ],
      "cues": [
        "Set owners and success criteria for each window.",
        "Map communication cadences to risk levels and audiences.",
        "Align dependencies so a degraded tool has a safe fallback."
      ],
      "diagnostics": [
        "maintenance-simulator"
      ],
      "steps": [
        "Define maintenance windows with owners, success criteria, and rollbacks.",
        "Publish communication cadences by risk level and audience.",
        "Check dependencies so degraded modes route to safe fallbacks."
      ],
      "artifacts": [
        {
          "name": "Window calendar",
          "purpose": "Shared schedule with owners, coverage, and success criteria."
        },
        {
          "name": "Comms templates",
          "purpose": "Prewritten updates for high, medium, and low-risk changes tied to roles."
        },
        {
          "name": "Fallback matrix",
          "purpose": "Lists degraded modes and who is paged when dependencies fail."
        }
      ],
      "example": {
        "title": "Coordinating a stewardship sprint",
        "description": "Engineering and operations publish a two-week window with a fallback matrix, schedule status updates by audience, and rehearse degraded-mode protocols before shipping changes."
      },
      "anti_patterns": [
        {
          "title": "Stewardship without owners",
          "failure": "Publishes a maintenance window without naming accountable owners or success criteria.",
          "counterfactual": "Each window has a named owner, success criteria, and rollback authority.",
          "warning": "Shared ownership is fine if responsibilities are explicit and visible."
        },
        {
          "title": "Silent maintenance",
          "failure": "Ships changes without comms or status updates, leaving users unaware of risks.",
          "counterfactual": "Comms are published by audience and risk tier, with fallback coverage noted.",
          "warning": "Emergency patches can shorten comms, but they still require an after-action log."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-03 Maintenance windowing)\n- Publish stewardship windows with named owners, success criteria, and rollback authority.\n- Require comms cadences by risk tier before shipping changes.\nReference: https://ethotechnics.org/mechanisms/patterns/maintenance-windowing",
      "product_requirement": "Product requirement (MEC-03)\n- Release plans include a window ID and owner in change tickets.\n- Status updates and fallback behavior are visible to affected users.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-03)\n[ ] Window calendar lists owners, coverage, and success criteria.\n[ ] Comms templates are published by risk level and audience.\n[ ] Fallback matrix confirms safe degraded modes for dependencies.",
      "postmortem_trigger": "Postmortem trigger (MEC-03)\nTrigger review if changes ship outside the stewardship window or without comms.",
      "citation": {
        "permalink": "/mechanisms/patterns/maintenance-windowing",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/maintenance-windowing",
      "refs": [
        "maintenance-window",
        "maintenance-metabolism",
        "repair-log"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-05",
      "type": "mechanism",
      "slug": "kill-switch",
      "title": "MEC-05 Kill switch for runaway automation",
      "summary": "Pre-authorized halt paths with named stewards, thresholds, and restoration drills so harms stop in seconds.",
      "filters": [
        "governance",
        "friction"
      ],
      "glossary_refs": [
        "stoppability",
        "ethical-interrupts",
        "time-to-halt"
      ],
      "cues": [
        "Define triggers tied to moral performance indicators and frontline reports.",
        "Name the people who can fire the switch and protect them from retaliation.",
        "Rehearse rollbacks so halts land in reversible, well-communicated states."
      ],
      "diagnostics": [
        "maintenance-simulator",
        "burden-modeler"
      ],
      "steps": [
        "Map the automation path and mark where halts must land safely with owners.",
        "Set tripwires for ethical interrupts that align with time-to-halt targets.",
        "Run drills that practice firing, communicating, and restoring from the halt."
      ],
      "artifacts": [
        {
          "name": "Kill switch runbook",
          "purpose": "Documents triggers, authorized operators, and post-halt messaging."
        },
        {
          "name": "Rollback checklist",
          "purpose": "Confirms data, access, and user impact are stable before resuming."
        },
        {
          "name": "After-action log template",
          "purpose": "Captures what tripped the switch and how to tighten thresholds or observability."
        }
      ],
      "example": {
        "title": "Containing a runaway recommendation loop",
        "description": "Operations staff notice a spike in appeals and trip the kill switch, freezing recommendations, routing cases to humans, and restoring with updated thresholds before re-enabling automation."
      },
      "anti_patterns": [
        {
          "title": "Kill switch without rehearsal",
          "failure": "A halt path exists but no drills confirm that it works under pressure.",
          "counterfactual": "Teams rehearse halts and document restore steps with time-to-halt targets.",
          "warning": "Simulation is acceptable when production drills are risky, but it must be documented."
        },
        {
          "title": "Single-point approval",
          "failure": "Only one person can trigger the halt, creating dead zones off-hours.",
          "counterfactual": "A pre-authorized roster can halt automation without retaliation risk.",
          "warning": "Small teams can assign a primary/secondary if coverage is explicit."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-05 Kill switch for runaway automation)\n- Maintain a pre-authorized halt path with a named roster and protection from retaliation.\n- Publish tripwires tied to moral performance indicators and time-to-halt targets.\nReference: https://ethotechnics.org/mechanisms/patterns/kill-switch",
      "product_requirement": "Product requirement (MEC-05)\n- The kill switch is reachable within one operational step from monitoring dashboards.\n- Halt events emit receipts with owner, trigger, and restoration checklist links.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-05)\n[ ] Kill switch runbook names authorized operators and triggers.\n[ ] Drill logs demonstrate time-to-halt performance.\n[ ] Rollback checklists show safe restoration steps.",
      "postmortem_trigger": "Postmortem trigger (MEC-05)\nTrigger review when time-to-halt targets are exceeded or the kill switch is unavailable.",
      "citation": {
        "permalink": "/mechanisms/patterns/kill-switch",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/kill-switch",
      "refs": [
        "stoppability",
        "ethical-interrupts",
        "time-to-halt"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-06",
      "type": "mechanism",
      "slug": "appeal-paths",
      "title": "MEC-06 Appeal paths inside the UI",
      "summary": "Give people a built-in channel to dispute outputs, get human review, or learn how a decision was made.",
      "filters": [
        "friction",
        "governance"
      ],
      "glossary_refs": [
        "contestability",
        "appeal-passage-rate",
        "permission-surface"
      ],
      "cues": [
        "Explain who reviews appeals and the expected response time.",
        "Pre-fill context to reduce effort during stressful moments.",
        "Track appeal outcomes to improve signal credibility."
      ],
      "diagnostics": [
        "burden-modeler",
        "maintenance-simulator"
      ],
      "steps": [
        "Place an appeal entry point near the affected decision with response times.",
        "Pre-fill context so people can submit without rebuilding the story.",
        "Track outcomes and feed them back into product and policy updates."
      ],
      "artifacts": [
        {
          "name": "Appeal intake form",
          "purpose": "Collects the minimum details with pre-filled context from the UI."
        },
        {
          "name": "Reviewer rota",
          "purpose": "Lists who reviews appeals, coverage hours, and escalation paths."
        },
        {
          "name": "Outcome log",
          "purpose": "Keeps decisions, response times, and fixes visible to teams and leadership."
        }
      ],
      "example": {
        "title": "Adding appeals to a risk scoring tool",
        "description": "The team adds an on-screen “Dispute this score” link with expected response times, routes submissions to a staffed rota, and logs turnaround data to improve credibility with regulators."
      },
      "anti_patterns": [
        {
          "title": "Appeal link buried",
          "failure": "Appeals exist but are hidden in help docs or separate portals far from the decision.",
          "counterfactual": "Appeal entry points sit next to the affected decision with visible timelines.",
          "warning": "Low-frequency contexts can use a help center if it is still clear and accessible."
        },
        {
          "title": "Appeals without feedback",
          "failure": "Collects disputes but provides no receipt, timeline, or outcome signal.",
          "counterfactual": "Every appeal generates a receipt, timeline, and outcome log.",
          "warning": "Timelines can vary by case complexity if the variance is stated and tracked."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-06 Appeal paths inside the UI)\n- Provide an in-product appeal channel with published response timelines.\n- Log appeal outcomes and feed them into governance review cycles.\nReference: https://ethotechnics.org/mechanisms/patterns/appeal-paths",
      "product_requirement": "Product requirement (MEC-06)\n- Every appeal submission generates a receipt with response timeline and owner.\n- Appeals are accessible from the decision surface without extra navigation.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-06)\n[ ] Appeal intake form includes pre-filled context.\n[ ] Reviewer rota and escalation paths are documented.\n[ ] Outcome log tracks response times and resolutions.",
      "postmortem_trigger": "Postmortem trigger (MEC-06)\nTrigger review when appeal backlogs breach published response timelines.",
      "citation": {
        "permalink": "/mechanisms/patterns/appeal-paths",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/appeal-paths",
      "refs": [
        "contestability",
        "appeal-passage-rate",
        "permission-surface"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-07",
      "type": "mechanism",
      "slug": "accountability-latency-tracker",
      "title": "MEC-07 Accountability latency tracker",
      "summary": "Measure how quickly teams can intervene, halt, and restore systems when accountability is on the line.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "audit-trail",
        "design-authority",
        "time-to-halt"
      ],
      "cues": [
        "Instrument veto, halt, and restore events with owner and trigger metadata.",
        "Publish accountability latency targets alongside time-to-halt SLAs.",
        "Tie latency deltas to post-incident repair log entries."
      ],
      "diagnostics": [
        "maintenance-simulator"
      ],
      "steps": [
        "Define the telemetry contract for veto, halt, and restoration events.",
        "Surface a dashboard that shows median latency and breach incidents.",
        "Review latency drift during governance reviews and update runbooks."
      ],
      "artifacts": [
        {
          "name": "Telemetry contract",
          "purpose": "Defines event names, required fields, and tags for observability tooling."
        },
        {
          "name": "Dashboard snapshot",
          "purpose": "Shares latency trends and breach annotations for governance reviews."
        },
        {
          "name": "Latency response runbook",
          "purpose": "Outlines response owners, escalation paths, and remediation steps."
        }
      ],
      "example": {
        "title": "Tracking veto response time during an incident",
        "description": "Operations teams add veto latency tracking to their Datadog dashboards, review weekly deltas, and tie missed targets to repair log updates and training."
      },
      "anti_patterns": [
        {
          "title": "Latency tracked without owners",
          "failure": "Metrics exist, but no one is accountable for acting on latency breaches.",
          "counterfactual": "Dashboards list named owners and escalation paths for each latency tier.",
          "warning": "Shared ownership works when escalation paths are explicit and rehearsed."
        },
        {
          "title": "Telemetry without repair links",
          "failure": "Latency events are logged but never tied to remediation plans.",
          "counterfactual": "Every breach links to a repair log entry with follow-up actions.",
          "warning": "If the repair log lives elsewhere, provide a canonical cross-link."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-07 Accountability latency tracker)\n- Track veto, halt, and restore latencies with owner, trigger, and system context.\n- Publish accountability latency targets in incident response runbooks.\nReference: https://ethotechnics.org/mechanisms/patterns/accountability-latency-tracker",
      "product_requirement": "Product requirement (MEC-07)\n- Monitoring dashboards show accountability latency alongside time-to-halt metrics.\n- Veto events emit receipts linked to the repair log and designated escalation owners.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-07)\n[ ] Telemetry captures veto, halt, and restore events with timestamps.\n[ ] Dashboards report median and worst-case accountability latency.\n[ ] Incident reviews include latency deltas and corrective actions.",
      "postmortem_trigger": "Postmortem trigger (MEC-07)\nTrigger review when accountability latency breaches published targets or telemetry is missing.",
      "citation": {
        "permalink": "/mechanisms/patterns/accountability-latency-tracker",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/accountability-latency-tracker",
      "refs": [
        "audit-trail",
        "design-authority",
        "time-to-halt"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-08",
      "type": "mechanism",
      "slug": "contestation-apis",
      "title": "MEC-08 Contestation APIs",
      "summary": "Expose programmatic interfaces that let affected people challenge decisions and trigger binding state changes.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "contestability",
        "permission-surface",
        "escalation"
      ],
      "cues": [
        "Publish a stable API contract that documents inputs, owners, and response timelines.",
        "Return receipts with contest IDs, status, and escalation paths on submission.",
        "Require binding authority to update system state when contests are upheld."
      ],
      "diagnostics": [
        "burden-modeler",
        "maintenance-simulator"
      ],
      "steps": [
        "Define an authenticated contestation endpoint with required evidence fields.",
        "Emit status updates via webhooks or receipts tied to the decision record.",
        "Link contest outcomes to state-change logs and remedy tracking."
      ],
      "artifacts": [
        {
          "name": "Contestation API spec",
          "purpose": "Defines endpoints, required fields, and receipt payloads."
        },
        {
          "name": "Receipt + webhook schema",
          "purpose": "Standardizes status updates and escalation metadata for contested decisions."
        },
        {
          "name": "State-change log",
          "purpose": "Links contest outcomes to decision reversals and remedy actions."
        }
      ],
      "example": {
        "title": "Appeal API for eligibility reversals",
        "description": "A benefits platform ships an appeal API that accepts structured evidence, returns a receipt with a 72-hour SLA, and automatically updates eligibility state when reviewers reverse the decision."
      },
      "anti_patterns": [
        {
          "title": "Contest intake without state change",
          "failure": "Contests are accepted but never mutate the underlying decision state.",
          "counterfactual": "Contestation outcomes are wired directly to state-change workflows.",
          "warning": "Manual overrides are acceptable only when logs prove timely updates."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-08 Contestation APIs)\n- Publish a contestation API with binding authority and response timelines.\n- Ensure contest outcomes can trigger state changes without manual re-entry.\nReference: https://ethotechnics.org/mechanisms/patterns/contestation-apis",
      "product_requirement": "Product requirement (MEC-08)\n- Each contest submission returns a receipt with owner, SLA clock, and escalation path.\n- Contest outcomes update the decision state and notify the impacted party.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-08)\n[ ] API contract and auth policy are documented and versioned.\n[ ] Receipts include timestamps, owners, and escalation metadata.\n[ ] State-change logs link contest outcomes to remediation steps.",
      "postmortem_trigger": "Postmortem trigger (MEC-08)\nTrigger review when contest outcomes fail to update system state within the SLA.",
      "citation": {
        "permalink": "/mechanisms/patterns/contestation-apis",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/contestation-apis",
      "refs": [
        "contestability",
        "permission-surface",
        "escalation"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-09",
      "type": "mechanism",
      "slug": "burden-dashboards",
      "title": "MEC-09 Burden dashboards",
      "summary": "Make user burden visible with dashboards that track time, steps, and escalation effort across cohorts.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "burden-index",
        "user-burden-ratio",
        "time-to-halt"
      ],
      "cues": [
        "Publish burden metrics alongside outcome and SLA dashboards.",
        "Segment burden by cohort, channel, and escalation tier.",
        "Flag burden spikes as governance incidents with owners."
      ],
      "diagnostics": [
        "burden-modeler"
      ],
      "steps": [
        "Define burden signals (time, steps, waiting, handoffs) and thresholds.",
        "Build a dashboard view with cohort breakdowns and trend lines.",
        "Review burden deltas during governance or product reviews."
      ],
      "artifacts": [
        {
          "name": "Burden metric spec",
          "purpose": "Defines calculation inputs and thresholds for burden tracking."
        },
        {
          "name": "Dashboard snapshot",
          "purpose": "Shows burden trends by cohort and escalation tier."
        },
        {
          "name": "Burden remediation log",
          "purpose": "Tracks actions taken to reduce burden spikes."
        }
      ],
      "example": {
        "title": "Publishing a monthly burden readout",
        "description": "A city services portal ships a burden dashboard that highlights time spent per appeal, escalations required, and targeted reductions quarter over quarter."
      },
      "anti_patterns": [
        {
          "title": "Burden tracking without action",
          "failure": "Teams measure burden but do not assign remediation owners.",
          "counterfactual": "Burden alerts route to named owners with fix timelines.",
          "warning": "Small teams can use rotating ownership if coverage is clear."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-09 Burden dashboards)\n- Publish burden metrics and thresholds for high-impact systems.\n- Assign owners to remediate burden spikes within a defined window.\nReference: https://ethotechnics.org/mechanisms/patterns/burden-dashboards",
      "product_requirement": "Product requirement (MEC-09)\n- Dashboards report median and tail burden metrics by cohort.\n- Burden alerts trigger a remediation task with accountable owners.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-09)\n[ ] Burden signals are defined and logged consistently.\n[ ] Dashboards include cohort breakdowns and escalation visibility.\n[ ] Remediation actions are tracked against burden alerts.",
      "postmortem_trigger": "Postmortem trigger (MEC-09)\nTrigger review when burden thresholds are exceeded without remediation.",
      "citation": {
        "permalink": "/mechanisms/patterns/burden-dashboards",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/burden-dashboards",
      "refs": [
        "burden-index",
        "user-burden-ratio",
        "time-to-halt"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-10",
      "type": "mechanism",
      "slug": "reversibility-audit-logs",
      "title": "MEC-10 Reversibility audit logs",
      "summary": "Track which actions can be reversed, how long reversal takes, and why irreversibility exists.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "reversibility",
        "audit-trail",
        "irreversibility-index"
      ],
      "cues": [
        "Document reversibility status and rationale for every high-impact action.",
        "Log reversal attempts with time-to-restore metrics.",
        "Surface irreversibility as a risk flag in governance reviews."
      ],
      "diagnostics": [
        "maintenance-simulator"
      ],
      "steps": [
        "Tag actions with reversibility status and documented rationale.",
        "Log every reversal attempt with timestamps and outcome.",
        "Review irreversibility trends and update mitigation plans."
      ],
      "artifacts": [
        {
          "name": "Reversibility status registry",
          "purpose": "Lists actions with reversibility status, owners, and rationales."
        },
        {
          "name": "Reversal attempt log",
          "purpose": "Tracks reversal attempts, outcomes, and time-to-restore metrics."
        },
        {
          "name": "Irreversibility review memo",
          "purpose": "Summarizes irreversibility rationale and mitigation commitments."
        }
      ],
      "example": {
        "title": "Logging reversal attempts in a claims system",
        "description": "A healthcare claims team logs every reversal attempt, including time-to-restore and irreversibility rationale, and reviews the audit log quarterly."
      },
      "anti_patterns": [
        {
          "title": "Implicit irreversibility",
          "failure": "Actions are treated as irreversible without documenting why.",
          "counterfactual": "Reversibility status and rationale are explicit and reviewed.",
          "warning": "Short-term irreversibility is acceptable if mitigations are documented."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-10 Reversibility audit logs)\n- Maintain an audit log that tracks reversibility status and rationale.\n- Record reversal attempts with time-to-restore outcomes.\nReference: https://ethotechnics.org/mechanisms/patterns/reversibility-audit-logs",
      "product_requirement": "Product requirement (MEC-10)\n- Decision records display reversibility status and owner.\n- Reversal attempts emit receipts with timestamps and outcomes.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-10)\n[ ] Reversibility status is captured for high-impact actions.\n[ ] Reversal attempts are logged with time-to-restore metrics.\n[ ] Irreversibility rationale is documented and reviewed.",
      "postmortem_trigger": "Postmortem trigger (MEC-10)\nTrigger review when reversibility logs are missing or reversal attempts exceed targets.",
      "citation": {
        "permalink": "/mechanisms/patterns/reversibility-audit-logs",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/reversibility-audit-logs",
      "refs": [
        "reversibility",
        "audit-trail",
        "irreversibility-index"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-11",
      "type": "mechanism",
      "slug": "escalation-slas",
      "title": "MEC-11 Escalation SLAs",
      "summary": "Guarantee response times for human escalation when automated decisions are contested.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "escalation",
        "contestability",
        "time-to-halt"
      ],
      "cues": [
        "Publish escalation clocks with named owners and coverage windows.",
        "Tie escalation SLAs to staffing plans and on-call rosters.",
        "Trigger safe-mode or reversal when escalation SLAs are breached."
      ],
      "diagnostics": [
        "maintenance-simulator"
      ],
      "steps": [
        "Define escalation tiers with SLA targets and authority scopes.",
        "Instrument SLA tracking with receipts and breach alerts.",
        "Review breach trends and adjust staffing or automation guardrails."
      ],
      "artifacts": [
        {
          "name": "Escalation SLA matrix",
          "purpose": "Lists tiers, response targets, and authority scopes."
        },
        {
          "name": "Coverage roster",
          "purpose": "Shows staffing coverage aligned to SLA commitments."
        },
        {
          "name": "Breach response log",
          "purpose": "Tracks SLA breaches and fallback actions."
        }
      ],
      "example": {
        "title": "24-hour escalation guarantee for disputes",
        "description": "A financial platform publishes a 24-hour human escalation SLA for contested denials and routes breaches into automatic provisional reinstatement."
      },
      "anti_patterns": [
        {
          "title": "Escalation without coverage",
          "failure": "Escalation timelines exist but no staffing covers nights or weekends.",
          "counterfactual": "Coverage rosters align with published escalation SLAs.",
          "warning": "Limited hours are acceptable if clearly disclosed and mitigated."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-11 Escalation SLAs)\n- Publish escalation response time guarantees and owners.\n- Define breach actions that trigger safe-mode or reversal.\nReference: https://ethotechnics.org/mechanisms/patterns/escalation-slas",
      "product_requirement": "Product requirement (MEC-11)\n- Escalation receipts include SLA targets and responsible owners.\n- SLA breaches trigger automatic fallback or halt actions.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-11)\n[ ] Escalation SLAs and owners are published.\n[ ] Breach alerts and fallback actions are logged.\n[ ] Staffing plans map to escalation coverage requirements.",
      "postmortem_trigger": "Postmortem trigger (MEC-11)\nTrigger review when escalation SLA breaches exceed thresholds.",
      "citation": {
        "permalink": "/mechanisms/patterns/escalation-slas",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/escalation-slas",
      "refs": [
        "escalation",
        "contestability",
        "time-to-halt"
      ],
      "deprecated_by": null,
      "supersedes": []
    },
    {
      "id": "MEC-12",
      "type": "mechanism",
      "slug": "stoppability-testing",
      "title": "MEC-12 Stoppability testing",
      "summary": "Verify pre-deployment that systems can be halted by authorized stakeholders under defined conditions.",
      "filters": [
        "governance",
        "policy"
      ],
      "glossary_refs": [
        "stoppability",
        "time-to-halt",
        "design-authority"
      ],
      "cues": [
        "Run stoppability drills before launch and after major changes.",
        "Document who can halt, how, and the expected time-to-halt.",
        "Log stoppability test outcomes and remediation actions."
      ],
      "diagnostics": [
        "maintenance-simulator"
      ],
      "steps": [
        "Define stoppability test scenarios with triggers and owners.",
        "Execute drills that measure time-to-halt and safe restoration.",
        "Publish test results and close gaps before release."
      ],
      "artifacts": [
        {
          "name": "Stoppability test plan",
          "purpose": "Defines scenarios, triggers, and expected time-to-halt targets."
        },
        {
          "name": "Drill log",
          "purpose": "Records stoppability test outcomes and restoration steps."
        },
        {
          "name": "Launch gate checklist",
          "purpose": "Confirms stoppability tests are complete before deployment."
        }
      ],
      "example": {
        "title": "Pre-launch halt drill for automated approvals",
        "description": "A public benefits team runs a stoppability drill before release, measuring time-to-halt and verifying restoration steps before approving launch."
      },
      "anti_patterns": [
        {
          "title": "Stoppability assumed, not tested",
          "failure": "Teams rely on documentation without running drills.",
          "counterfactual": "Stoppability drills run on a calendar and log outcomes.",
          "warning": "Simulated drills are acceptable if production tests are risky."
        }
      ],
      "policy_requirement": "Policy requirement (MEC-12 Stoppability testing)\n- Require stoppability drills before launch and after major changes.\n- Publish time-to-halt targets and authorized halt owners.\nReference: https://ethotechnics.org/mechanisms/patterns/stoppability-testing",
      "product_requirement": "Product requirement (MEC-12)\n- Stoppability tests log time-to-halt and restoration outcomes.\n- Launch gates verify test completion and remediation.",
      "audit_evidence_checklist": "Audit evidence checklist (MEC-12)\n[ ] Drill logs include time-to-halt metrics and outcomes.\n[ ] Authorized halt owners are documented.\n[ ] Remediation actions are tracked to closure.",
      "postmortem_trigger": "Postmortem trigger (MEC-12)\nTrigger review when stoppability tests are skipped or time-to-halt targets are missed.",
      "citation": {
        "permalink": "/mechanisms/patterns/stoppability-testing",
        "version": "v1.1.0",
        "published": "2025-12-03T00:00:00Z",
        "updated": "2026-01-09T00:00:00Z",
        "doi": "Pending Zenodo deposit",
        "archive_url": "https://web.archive.org/save/https://ethotechnics.org/mechanisms",
        "license": {
          "label": "CC BY-SA 4.0",
          "href": "https://creativecommons.org/licenses/by-sa/4.0/"
        },
        "attribution": "Credit Ethotechnics Institute, include the page title + version, and link to the canonical permalink."
      },
      "href": "/mechanisms/patterns/stoppability-testing",
      "refs": [
        "stoppability",
        "time-to-halt",
        "design-authority"
      ],
      "deprecated_by": null,
      "supersedes": []
    }
  ]
}