---
id: ADR-ACC-CLS-003
title: Execution Rechecks Readiness While Holding the Period Lock
product_area: accounting
module: close
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Execution revalidates readiness under its period lock, retains the calculation
  and atomically releases a blocked month with run failure; preview does not
  authorize closure.
constrains:
  - DOM-ACC-CLS-002
  - DOM-ACC-CLS-003
  - WF-ACC-CLS-001
  - WF-ACC-CLS-005
  - SCR-ACC-CLS-001
origin: >-
  services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 74 (class A;
  plan approved 2026-10-21)
alternatives:
  - option: Also reject unusable readiness at submission.
    why_not: >-
      An early check cannot replace execution revalidation; whether to add that
      interaction remains an existing product question.
  - option: Accept the displayed evaluation as authorization.
    why_not: >-
      The approved execution direction requires another evaluation when the job
      acts.
  - option: Retain closing state after a readiness blocker.
    why_not: >-
      Staff need to correct the outstanding books and submit afresh; the current
      implementation releases the month instead.
consequences:
  - >-
    Revalidation persists its calculation and can release the month, so it is a
    writable validation path.
  - >-
    A blocking refusal requires a new request after correction rather than retry
    of the released run.
  - Posting waits while the binding evaluation holds the target month.
  - The shared transaction does not freeze every record that readiness reads.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    modules/fiscal-close/services/jobs/fiscal-close-job-tasks.ts:revalidate;
    services/persistence/readiness-transactions.ts.
---

# Execution Rechecks Readiness While Holding the Period Lock

## Context

The month’s work can change after a controller reviews the screen. Execution needs its own recorded basis for proceeding.

## Decision

Use the job’s calculation as the binding review and preserve it on the run and successful snapshot. A required blocker returns the protected month to open in the same transaction.

## Alternatives Considered

Also reject unusable readiness at submission. An early check cannot replace execution revalidation; whether to add that interaction remains an existing product question.

Accept the displayed evaluation as authorization. The approved execution direction requires another evaluation when the job acts.

Retain closing state after a readiness blocker. Staff need to correct the outstanding books and submit afresh; the current implementation releases the month instead.

## Consequences

Revalidation persists its calculation and can release the month, so it is a writable validation path. A blocking refusal requires a new request after correction rather than retry of the released run. Posting waits while the binding evaluation holds the target month. The shared transaction does not freeze every record that readiness reads.