---
id: WF-ACC-REC-010
title: Accept a blocker with a second person's approval
trigger: An authorized person requests policy acceptance of a blocker.
product_area: accounting
module: reconciliation
revision: 3
status: draft
design_intent: confirmed
origin: >-
  Andrew's Decision 2, 2026-10-16 (accepting a blocker takes two commands by two
  users), recorded in services-accounting docs/reconciliation/architecture.md
  §13.2
implementation_evidence: observed
inference: []
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
implements:
  - CAP-ACC-REC-016
  - CAP-ACC-REC-020
moves:
  - STATE-ACC-REC-005
  - STATE-ACC-REC-004
crosses:
  - SVC-ACC-REC-reconciliation
idempotency: >-
  Request, approval and withdrawal have distinct key scopes and replay matching
  retained answers. Audited refusals retain history without storing a successful
  answer.
concurrency: >-
  Request and approval compare locked versions. Withdrawal checks the current
  pending requester without an expected version; each successful mutation
  increments the record version.
hops:
  - 'n': 1
    actor_or_service: Requester
    action: >-
      Request acceptance with a written conclusion and current version; do not
      supply an approver.
    anchor: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-exceptions.ts:acceptException
    seam: sync
    on_failure: 'Audited guards reject closed, stale or already pending work.'
    left_inconsistent: No policy acceptance is granted.
    observer: Exception history retains the refused attempt.
    provenance: observed
    source: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-exceptions.ts:acceptException
  - 'n': 2
    actor_or_service: Exception persistence
    action: >-
      Retain requester, time and conclusion while preserving open or
      investigating status.
    anchor: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-exceptions.ts:acceptException
    seam: state_machine
    on_failure: A storage failure aborts the request.
    left_inconsistent: No partial request persists.
    observer: Readiness continues to block and the screen shows the requester.
    provenance: observed
    source: >-
      services-accounting:modules/reconciliation/db/reconciliation-exceptions.table.ts:reconciliation_exceptions_acceptance_request_check
  - 'n': 3
    actor_or_service: Second approver
    action: >-
      Have another authorized person approve the pending request at the current
      version.
    anchor: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-exceptions.ts:approveExceptionAcceptance
    seam: sync
    on_failure: Audit invalid approval without changing the pending request.
    left_inconsistent: The blocker remains active.
    observer: History and readiness retain the refusal and pending work.
    provenance: observed
    source: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-exceptions.ts:approveExceptionAcceptance
  - 'n': 4
    actor_or_service: Exception persistence
    action: >-
      Record accepted status with requester as resolver and the independent
      approver; resolve enabled attention.
    anchor: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-blocker-items.ts:resolveBlockerAttention
    seam: sync
    on_failure: Any write failure aborts acceptance completion.
    left_inconsistent: No partially granted acceptance commits.
    observer: Readiness lists accepted work and retains overdue money in clearing.
    provenance: observed
    source: >-
      services-accounting:modules/reconciliation/services/persistence/reconciliation-exceptions.ts:approveExceptionAcceptance
branches:
  - Only the requester can withdraw the current pending acceptance.
  - Resolution or detector clearing removes a pending request.
  - Warnings complete acceptance in one authorized command.
waits:
  - A pending request has no deadline.
evidence:
  - >-
    services-accounting at f47cb263:
    modules/reconciliation/services/persistence/reconciliation-exceptions.ts,
    reconciliation-blocker-items.ts; db/reconciliation-exceptions.table.ts;
    aws/api/outstanding.routes.ts; docs/reconciliation/architecture.md §13.2.
  - >-
    react-console at baf6dae3:
    components/accounting/reconciliation/exceptions-screen.tsx;
    lib/accounting/reconciliation/store.tsx.
controls: [TC-IAM-001, TC-IAM-002, TC-IAM-004, TC-IAM-005, TC-IAM-006, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-005, TC-AZ-006, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-DAT-001, TC-LOG-001, TC-LOG-002, TC-LOG-003, TC-LOG-004, TC-LOG-005, TC-PI-001, TC-PI-002, TC-PI-003, TC-PI-005, TC-AI-005]
---
# Accept a blocker with a second person's approval

## What It Does

Blocker acceptance permits an understood concern to stop blocking reconciliation readiness. One person supplies the conclusion, and another grants acceptance; warnings need only one person.

## The Flow

```mermaid
sequenceDiagram
  participant A as Requester
  participant E as Exception commands
  participant B as Second approver
  participant P as Platform attention
  A->>E: accept (resolution, key, version)
  E-->>A: still open, request recorded
  B->>E: approve (key, version)
  E->>P: resolve attention as accepted
  E-->>B: accepted
  opt change of mind
    A->>E: withdraw (requester only)
  end
```

## When Something Fails

Audited refusals leave the request and business status intact. Withdrawal, resolution or approval concludes a pending request, and database constraints enforce the independence of accepted blockers.

## Open Design Questions

Accepted conditions are currently suppressed by later raising. Product must decide whether acceptance has a reconsideration boundary.