---
title: Independent examination and final wording for batch management
examined_at: '2026-10-23'
examiner: codex
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
branch: agent/accounting-batches-plan-exam-1
---

# Batch management planning examination

## Scope and method

This OpenAI examination checks the supplied planning draft against the pinned Accounting and console revisions. It reviews rule sources, provenance, recorded intent, enforcement boundaries, scenario bindings, coverage and planning grain. The initial reference audit opens 129 distinct pinned source paths covering 1,144 source, origin and test-binding references; existence and title matches alone do not establish whole-scenario proof. Subsequent focused reading checks route schemas, persistence safeguards, generation, submission, recovery, recurrence, fiscal recognition and console boundaries, and narrows statements where the cited evidence is weaker than the draft.

The final wording pass replaces every planning artifact’s body and every checked human-facing rule, example, scenario, journey, assertion and concept field. A comparison against the supplied draft finds no identical strings remaining in those prose fields. A second comparison against the verification checkpoint finds zero changes to identifiers, sources, provenance, origins, enforcement fields, must-prove markers, levels, proof lists, bindings, intent values, implementation-evidence values, source pins or supersession values during the wording pass. Verification and wording are committed separately for each of the 55 planning artifacts. The charter, findings, allocation descriptions and the three batch-added actor rows also receive final wording.

This is a static examination of the pinned source, not a new execution of Accounting integration tests or console browser journeys. The corpus checks and tests are executed locally. No product acceptance or approval is inferred from code, milestone progress or this examination.

## Counts examined

| Item | Supplied | Final |
|---|---:|---:|
| Features | 5 | 5 |
| Concepts, including superseded history | 5 | 5 |
| Active concepts | 5 | 4 |
| Capabilities | 20 | 20 |
| Journeys | 5 | 5 |
| Acceptance test sets | 20 | 20 |
| Rule rows | 203 | 208 |
| Must-prove rules | 186 | 201 |
| Rules deriving confirmed intent from recorded origins | 55 | 52 |
| Acceptance scenarios | 154 | 159 |
| Acceptance scenarios with existing bindings | 145 | 141 |
| Findings | 24 | 36 |
| Open product questions | 5 | 5 |
| Batch-added actor rows | 3 | 3 |

The supplied charter claimed one more acceptance scenario and one more bound scenario than its actual frontmatter contained. The final counts are computed from the artifact rows. Of the final must-prove rules, 193 have acceptance scenarios and eight have finding homes; scenario presence does not imply the test proves every part of its description.

## Coverage

Covered means a named specification or finding home exists. It does not mean approved intent, a passing runtime test or complete customer experience.

| Surface | Covered / total | Homes | Uncovered behavior or proof by name |
|---|---|---|---|
| Batch HTTP operations | 29/29 | Capability operation index below | None without a home; the health route is infrastructure |
| Table files and tables | 10/10 files; 13/13 tables | Storage index below | Inter-unit setup has no complete writer experience |
| Views | 3/3 | Batch reading, ledger reading, revenue schedules | Reporting permission evaluation needs proof |
| Explicitly declared permission keys | 22/22 | Authorization index in the charter | Four keys have no requiring route; imported helper expansion remains outside the pin |
| Module end-to-end source files | 9/9 | Charter test-source index | Whole-scenario and boundary gaps remain in findings |
| Integration source files | 55/55 | Charter test-source index | These source suites are indexed and inspected as cited, not executed here |
| Non-carried unit source files | 21/21 | Charter test-source index | Imported scheduler and renderer boundaries remain unproved |
| Carried regression source files | 54/54 | Earlier-product suite groups | Regression reference does not establish approved intent |
| Posting state machines | 2/2 | Submission and ordinary recovery | Job-start reconciliation is missing |
| Scheduled work kinds | 3/3 | Rolling, automatic close, attention maintenance | First-run and failed-start follow-up need decisions or proof |
| Module-owned queues | 0/0 | None declared in the batch module | Occurrence delivery belongs to scheduling |
| Console experiences | 6/6 | Hosted-screen index in the charter | Status history, add-transactions, correction creation, delivery and export connections are incomplete |
| Earlier inventory capabilities | 20/21 mapped; remaining one has a finding | Supersession references | External-ledger delivery and export |
| Earlier inventory rule rows | 71/71 | Supersession references | Contradictions are retained as findings |
| Earlier journey records | 54/54 | Supersession references | Automation flags are stale |
| Console browser specification files | 30/32 bound in acceptance; 32/32 have a source home | Acceptance, journeys and findings | Creation specification remains journey evidence; taxed-deferral specification cannot prove an exact gross total |
| Must-prove rows | 201/201 with scenario or finding | 193 scenario homes; eight finding homes | Listed immediately below |

| Must-prove rule without an acceptance scenario | Finding home |
|---|---|
| `BR-CAP-ACC-BAT-002-08` | `FND-ACC-BAT-033` |
| `BR-CAP-ACC-BAT-005-07` | `FND-ACC-BAT-005` |
| `BR-CAP-ACC-BAT-008-07` | `FND-ACC-BAT-032` |
| `BR-CAP-ACC-BAT-009-13` | `FND-ACC-BAT-033` |
| `BR-CAP-ACC-BAT-014-11` | `FND-ACC-BAT-011` |
| `BR-CAP-ACC-BAT-019-06` | `FND-ACC-BAT-033` |
| `BR-CAP-ACC-BAT-019-13` | `FND-ACC-BAT-033` |
| `BR-CAP-ACC-BAT-019-14` | `FND-ACC-BAT-034` |

### Operation homes

| Operation | Capability |
|---|---|
| `createBatch` | `CAP-ACC-BAT-001` |
| `listBatches`, `getBatch`, `getDependentBatches` | `CAP-ACC-BAT-002` |
| `updateBatch` | `CAP-ACC-BAT-003` |
| `closeBatch`, `reopenBatch`, `archiveBatch`, `unarchiveBatch`, `listBatchActions`, `performBatchAction` | `CAP-ACC-BAT-004` |
| `deleteBatch` | `CAP-ACC-BAT-006` |
| `createRecurringBatch`, `listRecurringBatches`, `getRecurringBatch`, `updateRecurringBatch`, `deleteRecurringBatch` | `CAP-ACC-BAT-009` |
| `listRecurringBatchRuns`, `previewRecurringBatchRoll` | `CAP-ACC-BAT-010` |
| `getBatchAssignmentSettings`, `saveBatchAssignmentSettings`, `deleteBatchAssignmentSettings`, `evaluateBatchAssignment` | `CAP-ACC-BAT-011` |
| `previewBatchPostings` | `CAP-ACC-BAT-012` |
| `postBatches` (and the `post` action) | `CAP-ACC-BAT-013` |
| `unpostBatches` (and the `unpost` action) | `CAP-ACC-BAT-016` |
| `listSubledgerEntries`, `getSubledgerEntry` | `CAP-ACC-BAT-018` |
| `describeInvoiceLineRevenue` | `CAP-ACC-BAT-019` |
| `post_system_batch`, `reverse_system_batch`, `recognise_due_entries`, `unrecognise_entries` (service functions the close calls) | `CAP-ACC-BAT-020` |

### Storage and projection homes

| File | Capabilities |
|---|---|
| `batches.table.ts` | `CAP-ACC-BAT-001` to `CAP-ACC-BAT-008`, `CAP-ACC-BAT-010` |
| `batches.view.ts` | `CAP-ACC-BAT-002` |
| `batch-postings.table.ts` | `CAP-ACC-BAT-013`, `CAP-ACC-BAT-016` |
| `batch-posting-jobs.table.ts` | `CAP-ACC-BAT-013`, `CAP-ACC-BAT-016` |
| `subledger-entries.table.ts`, `subledger-entry-lines.table.ts` | `CAP-ACC-BAT-015`, `CAP-ACC-BAT-017`, `CAP-ACC-BAT-018` |
| `subledger-entry-lines.view.ts` | `CAP-ACC-BAT-018` |
| `revenue-recognition-schedules.table.ts` | `CAP-ACC-BAT-019`, `CAP-ACC-BAT-020` |
| `revenue-schedule-entries.view.ts` | `CAP-ACC-BAT-019` |
| `recurring-batches.table.ts` | `CAP-ACC-BAT-009`, `CAP-ACC-BAT-010` |
| `batch-assignment-settings.table.ts`, `batch-assignment-rules.table.ts` | `CAP-ACC-BAT-011` |
| `business-unit-inter-entity-accounts.table.ts` | `CAP-ACC-BAT-014` (`FND-ACC-BAT-011`) |

### Authorization homes

| Key | Capability or evidence home |
|---|---|
| `accounting.batches.read` | `CAP-ACC-BAT-002`, `CAP-ACC-BAT-004` |
| `accounting.batches.create` | `CAP-ACC-BAT-001`, `CAP-ACC-BAT-005` |
| `accounting.batches.update` | `CAP-ACC-BAT-003`, `CAP-ACC-BAT-004`, `CAP-ACC-BAT-005`, `CAP-ACC-BAT-007` |
| `accounting.batches.delete` | `CAP-ACC-BAT-006` |
| `accounting.batches.query` | `CAP-ACC-BAT-002` |
| `accounting.batches.bulk` | `FND-ACC-BAT-012` |
| `accounting.batch-postings.post` | `CAP-ACC-BAT-013`, `CAP-ACC-BAT-004` |
| `accounting.batch-postings.unpost` | `CAP-ACC-BAT-016`, `CAP-ACC-BAT-004` |
| `accounting.batch-postings.preview` | `CAP-ACC-BAT-012` |
| `accounting.subledger-entries.read` | `CAP-ACC-BAT-018`, `CAP-ACC-BAT-019` |
| `accounting.subledger-entry-lines.query` | `CAP-ACC-BAT-018` |
| `accounting.revenue-schedule-entries.query` | `CAP-ACC-BAT-019` |
| `accounting.recurring-batches.read`, `.create`, `.update`, `.delete` | `CAP-ACC-BAT-009`, `CAP-ACC-BAT-010` |
| `accounting.recurring-batches.bulk` | `FND-ACC-BAT-012` |
| `accounting.batch-assignment-settings.read`, `.update`, `.delete` | `CAP-ACC-BAT-011` |
| `accounting.batch-assignment-settings.create`, `.bulk` | `FND-ACC-BAT-012` |

### Test-source homes

| Files | Capabilities |
|---|---|
| `e2e/batches.e2e.spec.js`, `e2e/batch-actions.e2e.spec.js`, `e2e/batch-totals.e2e.spec.js` | `CAP-ACC-BAT-001` to `CAP-ACC-BAT-004`, `CAP-ACC-BAT-006`, `CAP-ACC-BAT-009` |
| `e2e/recurring-batches.e2e.spec.js`, `e2e/batches-security.e2e.spec.js`, `e2e/batch-assignment-settings.e2e.spec.js` | `CAP-ACC-BAT-009`, `CAP-ACC-BAT-010`, `CAP-ACC-BAT-011` |
| `e2e/batch-postings.e2e.spec.js`, `e2e/subledger-entries.e2e.spec.js`, `e2e/system-batches.e2e.spec.js` | `CAP-ACC-BAT-012`, `CAP-ACC-BAT-013`, `CAP-ACC-BAT-016`, `CAP-ACC-BAT-018`, `CAP-ACC-BAT-004`, `CAP-ACC-BAT-006` |
| `integration/db/*` (5) | `CAP-ACC-BAT-001`, `CAP-ACC-BAT-002`, `CAP-ACC-BAT-009`, `CAP-ACC-BAT-011`, `CAP-ACC-BAT-018`, `CAP-ACC-BAT-019` |
| `integration/services/persistence/batches*`, `batch-totals*`, `batch-attention-items*` | `CAP-ACC-BAT-001` to `CAP-ACC-BAT-008` |
| `integration/services/persistence/recurring-batches*`, `batch-assignment-settings*` (including the queries spec) | `CAP-ACC-BAT-009`, `CAP-ACC-BAT-011` |
| `integration/services/persistence/batch-postings.queries*`, `posting-periods.queries*` | `CAP-ACC-BAT-013`, `CAP-ACC-BAT-016` |
| `integration/services/persistence/subledger-entries*`, `ledger-minor-units*`, `reference-records*` | `CAP-ACC-BAT-014`, `CAP-ACC-BAT-017`, `CAP-ACC-BAT-018` |
| `integration/services/persistence/revenue-recognition-schedules*`, `system-batches.queries*` | `CAP-ACC-BAT-019`, `CAP-ACC-BAT-020` |
| `integration/services/posting/*` (20, including `foreign-currency-table-rate`) | `CAP-ACC-BAT-013` to `CAP-ACC-BAT-016`, `CAP-ACC-BAT-019` |
| `integration/services/jobs/*` (4) | `CAP-ACC-BAT-013` |
| `integration/services/close/*` (6) | `CAP-ACC-BAT-013`, `CAP-ACC-BAT-016`, `CAP-ACC-BAT-020`, `CAP-ACC-BAT-004` |
| `integration/services/roll/*` (2) | `CAP-ACC-BAT-009`, `CAP-ACC-BAT-010` |
| `integration/services/lifecycle/ledger-purge*` | `CAP-ACC-BAT-017` |
| `integration/well-known-objects*` | `CAP-ACC-BAT-015` (the carried suites' fixtures) |
| `unit/actions`, `unit/attention`, `unit/close`, `unit/jobs`, `unit/rules`, `unit/defects`, `unit/carried-cases.spec.js` | `CAP-ACC-BAT-004`, `CAP-ACC-BAT-008`, `CAP-ACC-BAT-011` to `CAP-ACC-BAT-015`, `CAP-ACC-BAT-018` to `CAP-ACC-BAT-020` |
| `unit/carried/**` (Rhythm 1.0 suites of batches, batch posting, recurring batches, batch assignment, financial transactions, fiscal years) | `CAP-ACC-BAT-001` to `CAP-ACC-BAT-015` (regression reference) |

## Changes by artifact

Every listed artifact receives final wording. The descriptions below identify verification changes; rows without a separate correction retain their checked metadata.

| Artifact | Examination result and final change |
|---|---|
| `ATS-ACC-BAT-001` | Adds the existing default-currency test as a binding; all scenario wording is replaced. |
| `ATS-ACC-BAT-002` | Adds traversal-limit acceptance, total-rounding proof and the existing real-transaction total test. |
| `ATS-ACC-BAT-003` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-004` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-005` | Replaces the refused-posting setup with an unresolved customer after automatic close. |
| `ATS-ACC-BAT-006` | Connects deletion to recurring-pointer clearing. |
| `ATS-ACC-BAT-007` | Connects implicit intake to assignment proof. |
| `ATS-ACC-BAT-008` | Connects publication to its side-effect rule. |
| `ATS-ACC-BAT-009` | Adds proposed renderer-boundary proof. |
| `ATS-ACC-BAT-010` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-011` | Adds proposed document and order precedence proof. |
| `ATS-ACC-BAT-012` | Removes the preview binding that cannot establish all eligibility guards and uses direct observed generation evidence. |
| `ATS-ACC-BAT-013` | Unbinds the combined action/engine status contract, keeps it proposed and adds job-control proof. |
| `ATS-ACC-BAT-014` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-015` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-016` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-017` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `ATS-ACC-BAT-018` | Corrects the accidental numeric forbidden-response value to a readable permission refusal. |
| `ATS-ACC-BAT-019` | Unbinds the combined strategy-precedence and exact gross-tax claims and adds cash-payment origin proof. |
| `ATS-ACC-BAT-020` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `CAP-ACC-BAT-001` | Limits currency enforcement to the service; distinguishes ordinary transaction and legacy creation from fiscal system types; narrows the closed-period example to what its API source establishes. |
| `CAP-ACC-BAT-002` | Marks total rounding and reporting refusal behavior must-prove; adds bounded dependent traversal with its proposed acceptance scenario. |
| `CAP-ACC-BAT-003` | Includes external reference and lock in accepted patch fields; preserves lock-only edits for completed states; makes stale-version refusal conditional on a submitted version. |
| `CAP-ACC-BAT-004` | Corrects illustrative action availability to omitted actions rather than unsupported disabled controls. |
| `CAP-ACC-BAT-005` | Narrows scheduled-close illustration to service behavior; changes the proposed posting-refusal setup so preparation is reached after close. |
| `CAP-ACC-BAT-006` | Marks recurring-pointer clearing during deletion as a must-prove side effect and connects its scenario. |
| `CAP-ACC-BAT-007` | Separates documented correction intent from unverified enforcement, qualifies amendment by money guards and marks assignment intake must-prove. |
| `CAP-ACC-BAT-008` | Treats the attention bulk action as a declared contract with no proven console grouping; marks attention writes must-prove. |
| `CAP-ACC-BAT-009` | Records the renderer boundary as documented, adds its rule and proposed proof, and marks the list limit must-prove. |
| `CAP-ACC-BAT-010` | Treats repeated-failure pause as documented at the imported scheduler boundary and corrects the illustrative occurrence date. |
| `CAP-ACC-BAT-011` | Separates assignment comparisons from the caller contract and adds pro forma and order precedence with proposed proof. |
| `CAP-ACC-BAT-012` | Records shared period locking and the absence of ordinary status and update-lock checks in preview. |
| `CAP-ACC-BAT-013` | Separates creation-time existence checks from execution-time unit checks, distinguishes action and engine status sets and period timing, and adds job retry/cancellation controls. |
| `CAP-ACC-BAT-014` | Removes a broad rule origin whose decision only confirms a narrower account-resolution policy. |
| `CAP-ACC-BAT-015` | Qualifies per-document generation for cash accounting rather than promising an invoice entry universally. |
| `CAP-ACC-BAT-016` | Allows recovery of dependencies together when the selected set satisfies the guard and removes the narrower permission-policy origin from the full recovery rule. |
| `CAP-ACC-BAT-017` | Distinguishes ordinary entry deletion from retained fiscal reversal history. |
| `CAP-ACC-BAT-018` | Retains the source-backed reading behavior; records the console completeness limit in a new finding. |
| `CAP-ACC-BAT-019` | Corrects strategy precedence, separates cash invoice and payment origins, removes an overbroad correction origin, marks date and query safeguards must-prove and adds the empty-weight fallback rule. |
| `CAP-ACC-BAT-020` | Qualifies fiscal recognition to the applicable current open schedules and due-booked entries. |
| `CON-ACC-BAT-001` | Absorbs recurring facets, related capabilities and source references; retains Batch as the broad conceptual home. |
| `CON-ACC-BAT-002` | Marks the former recurrence concept superseded without reusing its identifier. |
| `CON-ACC-BAT-003` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `CON-ACC-BAT-004` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `CON-ACC-BAT-005` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `FEAT-ACC-BAT-01` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `FEAT-ACC-BAT-02` | Removes separate concept ownership after the recurrence grouping is absorbed by Batch. |
| `FEAT-ACC-BAT-03` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `FEAT-ACC-BAT-04` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `FEAT-ACC-BAT-05` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `JNY-ACC-BAT-001` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `JNY-ACC-BAT-002` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `JNY-ACC-BAT-003` | Corrects the current-pointer assertion so a protected old collection can remain Open and cites observed persistence behavior. |
| `JNY-ACC-BAT-004` | Fixes dependency lookup direction and cites observed traversal for the errored downstream collection. |
| `JNY-ACC-BAT-005` | No separate verification correction; replaces the human-facing text while preserving the verified metadata. |
| `MOD-ACC-BAT` | Expands the registered source boundary, updates actual counts and coverage meanings, and replaces charter wording. |
| `ID_REGISTRY` | Reserves five rules, five acceptance scenarios and twelve findings before their addition; corrects referenced actor allocations and synchronizes final titles. |
| `FINDINGS` | Adds twelve examination findings, rewrites the earlier findings and questions, and qualifies unsupported past-occurrence runtime claims. |
| `ACT-ACC-012`, `ACT-ACC-013`, `ACT-ACC-014` | Rewrites only the batch-added actor descriptions; shared earlier actors remain unchanged. |
| `PRODUCT-AREAS: MOD-ACC-BAT` | Updates only the batch row to planning examined with the corrected source registration. |

## Verification field audit

This index records fields changed between the supplied draft and the verification checkpoint. A row index identifies its existing permanent identifier; length changes identify previously allocated additions. It excludes the subsequent wording pass, whose protected fields have no differences.

| Artifact | Changed verification fields |
|---|---|
| `ATS-ACC-BAT-001` | `scenarios[4].bound_to.length` |
| `ATS-ACC-BAT-002` | `scenarios.length`, `scenarios[2].proves.length`, `scenarios[3].bound_to.length` |
| `ATS-ACC-BAT-005` | `scenarios[4].expected`, `scenarios[4].preconditions` |
| `ATS-ACC-BAT-006` | `scenarios[1].proves.length` |
| `ATS-ACC-BAT-007` | `scenarios[0].proves.length` |
| `ATS-ACC-BAT-008` | `scenarios[1].proves.length` |
| `ATS-ACC-BAT-009` | `scenarios.length` |
| `ATS-ACC-BAT-011` | `scenarios.length` |
| `ATS-ACC-BAT-012` | `scenarios[1].bound_to.length`, `scenarios[1].expected`, `scenarios[1].provenance`, `scenarios[1].source` |
| `ATS-ACC-BAT-013` | `scenarios.length`, `scenarios[3].bound_to.length`, `scenarios[3].expected`, `scenarios[3].provenance`, `scenarios[3].source` |
| `ATS-ACC-BAT-019` | `scenarios.length`, `scenarios[1].bound_to.length`, `scenarios[1].expected`, `scenarios[1].provenance`, `scenarios[1].source`, `scenarios[1].title`, `scenarios[9].bound_to.length`, `scenarios[9].provenance`, `scenarios[9].source` |
| `CAP-ACC-BAT-001` | `rules[4].enforced_at.length`, `rules[7].provenance`, `rules[7].source`, `rules[7].statement`, `scenarios[1].then` |
| `CAP-ACC-BAT-002` | `rules.length`, `rules[4].must_prove`, `rules[7].must_prove` |
| `CAP-ACC-BAT-003` | `outcomes[2]`, `rules[0].provenance`, `rules[0].source`, `rules[0].statement`, `rules[2].provenance`, `rules[2].source`, `rules[2].statement`, `rules[6].provenance`, `rules[6].source`, `rules[6].statement` |
| `CAP-ACC-BAT-004` | `scenarios[1].then` |
| `CAP-ACC-BAT-005` | `scenarios[0].provenance`, `scenarios[0].source`, `scenarios[0].then` |
| `CAP-ACC-BAT-006` | `rules[6].must_prove` |
| `CAP-ACC-BAT-007` | `rules[7].statement`, `rules[8].enforced_at.length`, `rules[8].note`, `rules[9].must_prove` |
| `CAP-ACC-BAT-008` | `rules[2].must_prove`, `rules[6].enforced_at.length`, `rules[6].must_prove`, `rules[6].note`, `rules[6].provenance`, `rules[6].source`, `rules[6].statement`, `scenarios[0].then` |
| `CAP-ACC-BAT-009` | `concepts[0]`, `outcomes[0]`, `rules.length`, `rules[12].must_prove` |
| `CAP-ACC-BAT-010` | `concepts.length`, `concepts[0]`, `rules[7].note`, `scenarios[0].then` |
| `CAP-ACC-BAT-011` | `concepts[0]`, `rules.length`, `rules[7].provenance`, `rules[7].source`, `rules[7].statement` |
| `CAP-ACC-BAT-012` | `outcomes[0]`, `outcomes[2]`, `rules[2].provenance`, `rules[2].source`, `rules[2].statement`, `rules[5].source`, `rules[5].statement` |
| `CAP-ACC-BAT-013` | `rules.length`, `rules[1].provenance`, `rules[1].source`, `rules[1].statement`, `rules[4].provenance`, `rules[4].source`, `rules[4].statement`, `rules[5].provenance`, `rules[5].source`, `rules[5].statement`, `scenarios[0].then` |
| `CAP-ACC-BAT-014` | `rules[9].note`, `rules[9].origin` |
| `CAP-ACC-BAT-015` | `outcomes[0]`, `rules[0].statement` |
| `CAP-ACC-BAT-016` | `rules[0].note`, `rules[0].origin`, `rules[6].provenance`, `rules[6].source`, `rules[6].statement`, `scenarios[1].then` |
| `CAP-ACC-BAT-017` | `outcomes[2]` |
| `CAP-ACC-BAT-019` | `rules.length`, `rules[1].provenance`, `rules[1].source`, `rules[1].statement`, `rules[5].must_prove`, `rules[7].note`, `rules[7].origin`, `rules[9].must_prove`, `rules[9].provenance`, `rules[9].source`, `rules[9].statement`, `rules[12].must_prove` |
| `CAP-ACC-BAT-020` | `rules[4].provenance`, `rules[4].source`, `rules[4].statement` |
| `CON-ACC-BAT-001` | `acted_on_by.length`, `evidence.length`, `facets.length`, `relationships.length`, `relationships[0].provenance`, `relationships[0].source`, `relationships[0].statement`, `relationships[0].to`, `relationships[1].source`, `relationships[1].statement`, `relationships[1].to`, `supersedes.length` |
| `CON-ACC-BAT-002` | `status` |
| `FEAT-ACC-BAT-02` | `concepts.length` |
| `JNY-ACC-BAT-003` | `assertions[1].provenance`, `assertions[1].source`, `assertions[1].statement` |
| `JNY-ACC-BAT-004` | `steps[4].action`, `steps[4].expected`, `steps[4].provenance`, `steps[4].source` |

## Findings and disagreements left open

All thirty-six finding records remain available for product or implementation follow-up. Correcting the specification does not resolve the underlying code, record or acceptance disagreement. No new capability is needed for the added behaviors: each belongs to an existing outcome, and the missing external delivery outcome remains explicitly unbuilt.

| Finding | Remaining issue |
|---|---|
| `FND-ACC-BAT-001` | Ledger generation uses batch fiscal placement, while the recorded accounting-date decision describes document-based placement. The milestone walkthrough describes the built choice but has not received product acceptance. Andrew needs to reconcile the decision and implemented accounting result. |
| `FND-ACC-BAT-002` | The former module registration omitted posting records and several console configuration paths used by this layer. Registration now includes the examined batch records and screens so the source boundary matches the work being specified. |
| `FND-ACC-BAT-003` | The posting milestone has inconsistent progress labels and no completed plan. Its reversible build choices establish proposed behavior, while only explicitly recorded product rulings establish confirmed intent. |
| `FND-ACC-BAT-004` | Earlier inventory wording and table comments describe compensating ordinary unposting. The later reporting decision instead requires deleting ordinary entries while retaining posting history. Those earlier descriptions still need alignment with the replacement policy. |
| `FND-ACC-BAT-005` | Automatic-close validation accepts timestamps in the past despite the earlier acceptance expectation of refusal. The schedule can therefore be created with an already-passed occurrence; delivery behavior at the imported scheduling boundary still needs focused proof. |
| `FND-ACC-BAT-006` | The operational recurrence record still describes automatic posting as awaiting a decision. A later recorded decision and the implemented preparation path establish that rolling and automatic closing can request posting. |
| `FND-ACC-BAT-007` | The earlier acceptance material expects deactivation to close current intake. The implemented change disables scheduling and leaves the current batch available to assignment, so the expected lifecycle needs reconciliation. |
| `FND-ACC-BAT-008` | The empty-batch deletion option is accepted but does not change generation’s deletion choice. The product should either honor the option or remove it from the request contract. |
| `FND-ACC-BAT-009` | Earlier acceptance material says preview cannot find missing accounts. Generation preview and its integration evidence now report those configuration problems, so the older readiness descriptions are stale. |
| `FND-ACC-BAT-010` | Several visible batch experiences lack service connections: status history, adding existing transactions and creating corrections are incomplete, while delivery and export lists return empty results. Submitted action reasons are not retained. The product should communicate those limits before staff depend on them. |
| `FND-ACC-BAT-011` | Cross-unit account resolution requires configured inter-unit account pairs. Storage and reading exist, but the registered implementation has no setup route, screen or seed for those pairs. Supported cross-unit sales therefore lack a complete configuration path. |
| `FND-ACC-BAT-012` | Four explicitly declared permission keys have no requiring route: batch and recurring bulk access, and assignment create and bulk access. Additional keys generated by the imported catalogue helper cannot be established from this pinned module alone. |
| `FND-ACC-BAT-013` | Job creation commits before workflow start. A failed start can leave submitted work without execution, including scheduled posting, and the registered module has no reconciler for that state. |
| `FND-ACC-BAT-014` | Reactivation can retire the collection retained during inactivity without requesting its posting. Rolling does request accounting work for its retired collection. The recorded open item leaves this difference for a product decision. |
| `FND-ACC-BAT-015` | Taxed deferral can schedule the tax-inclusive line total while posting credits only tax-exclusive deferred revenue. That mismatch can release more than the deferred credit, and the acceptance records leave its accounting treatment undecided. |
| `FND-ACC-BAT-016` | Earlier acceptance material treats description text as a production error directive. The current posting test demonstrates that the old marker behaves as ordinary description text. |
| `FND-ACC-BAT-017` | Live totals and posting statistics use different document-counting definitions. The migration record leaves their customer-facing interpretation for a product decision; the product should explain the difference or adopt one count. |
| `FND-ACC-BAT-018` | The action description omits Error from its posting summary even though retrying an errored batch is implemented and recorded in milestone history. The stale summary needs alignment with the supported action. |
| `FND-ACC-BAT-019` | Earlier acceptance material expects immediately recognising scheduled dates before the batch date. Generation instead moves those dates to the batch date for subsequent fiscal recognition. |
| `FND-ACC-BAT-020` | Journey automation flags remain unset despite existing browser specifications and a recorded milestone run. This layer cites the specifications directly and does not treat the flags as evidence of whether automation exists. |
| `FND-ACC-BAT-021` | Earlier inventory identifiers resemble the permanent identifiers allocated here but represent different groupings. Supersession references explicitly identify the inventory so readers can distinguish the two corpora. |
| `FND-ACC-BAT-022` | External ledger delivery and export have no implemented producer for the downloaded lifecycle, and the visible lists are placeholders. Their design decisions remain open; this planning layer records the gap without inventing a delivery capability. |
| `FND-ACC-BAT-023` | Two separate recorded rulings share the same short decision label. Citations must include the owning record and context to distinguish posting-failure policy from ordinary-entry deletion policy. |
| `FND-ACC-BAT-024` | Earlier acceptance material expects reopening to restore automatic close. Leaving Open clears that schedule, so reopening alone does not restore the former close time. |
| `FND-ACC-BAT-025` | Preview holds a shared fiscal-period lock although its source header says it locks nothing. The rule now follows the executable read path. |
| `FND-ACC-BAT-026` | Preview does not apply the ordinary status or update-lock guards before marking candidates eligible. An archived or locked batch can therefore pass preview and fail the posting check. |
| `FND-ACC-BAT-027` | The named Post action and posting engine accept different status sets. The engine additionally accepts verified batches and stale posting work and reads an environment override; the existing repost test does not prove that whole contract. |
| `FND-ACC-BAT-028` | Period schedules use a line service period, but fixed-date and matching relative-date strategies run first. The draft overstated service-period precedence; the combined strategy contract still needs a proving scenario. |
| `FND-ACC-BAT-029` | The taxed-deferral browser test accepts either gross or net schedule totals. It cannot prove the exact gross result stated by the draft acceptance scenario, whose binding is removed; the code evidence remains. |
| `FND-ACC-BAT-030` | The batch entry reader stops after five thousand entries and computes its account summary from that partial result without returning a completeness flag. A larger posting needs an explicit incomplete-result treatment. |
| `FND-ACC-BAT-031` | The shared administrator and reader actors describe product-catalogue permissions but batches reuse them for batch administration and inspection. This module cannot safely rewrite another module’s actor rows; their shared permission descriptions need reconciliation. |
| `FND-ACC-BAT-032` | The attention provider declares a bulk Post action, but no pinned console binding examined here proves grouping and execution by business unit. The planned action is not established console behavior. |
| `FND-ACC-BAT-033` | Coverage gaps remain for the Batches reporting permission and identifier display, recurring-list limit, earlier schedule-date adjustment, and Revenue Schedule Entries query permission. Existing dataset tests establish rows but do not establish permission evaluation. |
| `FND-ACC-BAT-034` | When an effective date yields no truncation weights, the correction falls back to schedule inversion. No acceptance scenario yet proves that fallback across the posting path. |
| `FND-ACC-BAT-035` | The document date and immutable-money rule cites a product decision, not executable enforcement. The rule is retained as documented intent with no established enforcement layer; cross-document proof requires the Transactions scope. |
| `FND-ACC-BAT-036` | Some illustrative and journey rows combine an API result with unproved console or follow-up behavior. Provenance must describe the whole claim; the examination narrows those rows where the cited test only proves the service result. |

## Validation

The required clean-install command completes successfully and conformance reports zero errors. The corpus test command passes all four tests. The final wording audit finds zero unchanged draft prose fields and zero protected-metadata differences against the verified checkpoint. The working branch descends from the supplied starting commit; changes are confined to the authorized module, its added actor rows and its registration row, and no push is performed.

## Verdict for Andrew

The examined layer provides a sourced description of the pinned module, with proven corrections incorporated and unresolved disagreements explicitly retained rather than treated as approval. Its weakest areas are whole-workflow acceptance proof, imported execution boundaries and conflicting accounting decisions on fiscal placement and taxed deferral. Before design begins, Andrew should resolve those accounting decisions and the action-versus-engine eligibility disagreement, then commission focused proof for the findings that could mislead readiness or recovery design.