---
title: Operations planning examination and OpenAI final text
examined_at: '2026-10-23'
examiner: codex
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
branch: agent/platform-operations-plan-exam-1
---
# Examination of the Operations Planning Layer

## Verdict for Andrew

The revised layer describes the pinned module with explicit sources, separates observed behavior from approved intent, and leaves disputed or insufficiently proved outcomes as findings. Its weakest areas are complete acceptance proof, application-transition concurrency and real-provider licensing activation. Before design starts, Andrew should decide the recorded intent conflicts and the team should close the delivery, integration and recovery defects and bind the proposed proof matrices.

## Scope and method

This OpenAI examination opened pinned source references, read the named test assertions, compared route schemas, service ordering, persistence constraints and console behavior, and checked the cited approval records. Source assertions were examined statically; this job did not execute the Platform, shared-library or console test suites and did not inspect live-provider configuration. Technical source inventories retain their literal identifiers, while all product narrative, definitions, facets, rules, examples, journey text and acceptance wording were rewritten by codex. Verification corrections were committed before separate final-text commits, with later discoveries recorded in additional verification and final-text commits.

The existing sixteen outcome capabilities and four broad concepts remain appropriate: shared execution, recovery, notifications, audience-specific inspection and record persistence have distinct contracts, while licensing separates commercial decisions, standing and operational preparation. No identifier was renumbered, reused or superseded merely to raise artifact counts. Approval remains Andrew’s decision; planning examination does not approve this layer.

## Counts examined

| Item | Count |
|---|---|
| Module, findings and permanent identifier ledger | 3 |
| Features | 4 |
| Concepts | 4 |
| Capabilities | 16 |
| Acceptance sets | 16 |
| Journeys | 5 |
| Module artifacts before this report | 48 |
| Module-added actor rows | 1: ACT-PFM-043 |
| Final rule rows | 160 |
| Must-prove rule rows | 129 |
| Acceptance scenarios | 123 |
| Scenarios retaining bound proof | 4 |
| Scenarios remaining proposed | 119 |
| Existing scenarios downgraded or unbound | 112 |
| Findings retained or added | 32: 25 retained, 7 added |
| Open questions retained | 3 |

## Coverage inventory

Covered counts mean a named capability or technical evidence line addresses the inventory item; they do not mean every behavior has passing acceptance proof. The module catalogue supplies the operation, table, view, permission and test-group mappings.

| Inventory | Covered / total | Mapping | Uncovered by name |
|---|---|---|---|
| Business HTTP operations | 29 / 29 | MODULE coverage_catalog operations table | None |
| Technical health registrations | 3 / 3 | jobs.routes.ts, audit.routes.ts, licensing.routes.ts: healthRoute | None; technical evidence only |
| Owned module tables | 11 / 11 | MODULE table mappings to CAP-003, 010, 011, 012, 014, 015 | None |
| Cross-job views | 3 / 3 | CAP-007 | None |
| Permission keys | 9 / 9 | MODULE permission mappings; provisioning permission is a dependency | None |
| Platform backend e2e files | 5 / 5 | CAP-005, 006, 008, 011, 012 | None |
| Platform integration files | 40 / 40 | MODULE test mappings | None |
| Platform unit files | 18 / 18 | MODULE test mappings | None |
| Shared jobs test files | 19 / 19 | CAP-001, 002, 004, 007 and technical inventory below | Variant proof remains open under FND-032 |
| Console browser files | 7 / 7 | MODULE browser mappings | Real HubSpot integration absent: FND-013 |
| Owned Step Functions machines | 0 / 0 | Machines belong to job-kind owners; shared builder evidence in CAP-001 | None owned |
| Queues and schedules | 4 / 4 | CAP-002 reconciler schedule; CAP-012 source queue, dead-letter queue and nightly schedule | None |
| Standalone console pages | 5 / 5 | CAP-005 Maintenance home and Scheduled Jobs; CAP-006 HQ list and detail; CAP-016 Applications host | None |
| Embedded screen hosts | 2 / 2 | CAP-006 HQ home card; CAP-013 workspace licensing host | None within module ownership |
| Earlier inventory seeds | 2 / 2 | CAP-CRM-AUD-006 and CAP-CRM-EXP-017 in supersedes | None |

Other HQ pages and unrelated controls on the two embedded hosts remain with their registered owning modules. The module does not acquire their rules through screen hosting. Queue coverage counts the source queue and dead-letter queue separately, correcting the draft’s three-item aggregate.

### Shared jobs file inventory

| Pinned test file | Capability or evidence |
|---|---|
| `packages/jobs/src/architecture.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/aws/job-state-machine.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/job-cancellation.spec.ts` | `CAP-PFM-OPS-004`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/job-continuation.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/job-engine.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/job-root-status-model.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/job-step-status-model.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/local-job-runner.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/engine/start-job-execution.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/persistence/cross-job-history.views.spec.ts` | `CAP-PFM-OPS-007`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/persistence/cross-job-query.view.spec.ts` | `CAP-PFM-OPS-007`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/reconciler/job-reconciler-handler.spec.ts` | `CAP-PFM-OPS-002`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/reconciler/job-reconciler.spec.ts` | `CAP-PFM-OPS-002`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/testing/in-memory-job-repository.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/tests/integration/cross-job-query.integration.spec.ts` | `CAP-PFM-OPS-007`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/tests/integration/cross-job-schemas.integration.spec.ts` | `CAP-PFM-OPS-007`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/tests/integration/job-family-repository.integration.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/workflow/job-workflow-continuation.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |
| `packages/jobs/src/workflow/job-workflow.spec.ts` | `CAP-PFM-OPS-001`; implementation/test inventory, variant proof `FND-PFM-OPS-032` |

## Verification changes

| Artifact or row | Correction |
|---|---|
| `BR-CAP-PFM-OPS-003-03` | The conditional upsert accepts pending notices and supplies no exclusive sender lease. Changed statement. |
| `BR-CAP-PFM-OPS-005-01` | The original incorrectly applied the customer permission to HQ routes. Changed statement. |
| `BR-CAP-PFM-OPS-005-06` | Cursor decoding validates its shape, without issuer authentication. Changed statement. |
| `BR-CAP-PFM-OPS-005-07` | The kinds response carries no count. Changed statement, provenance, source. |
| `BR-CAP-PFM-OPS-009-04` | Audit cursors are also shape-checked, not authenticated. Changed statement. |
| `BR-CAP-PFM-OPS-010-05` | UUIDv7 supplies a tie breaker, not proof that every later insertion sorts later. Changed statement. |
| `BR-CAP-PFM-OPS-010-06` | The cited test verifies event fields, not atomic publication or every caller. Changed provenance, source, statement. |
| `BR-CAP-PFM-OPS-011-02` | The customer-workspace expiry requirement reads workspace type in the service; the database checks date ordering only. Changed enforced_at. |
| `BR-CAP-PFM-OPS-011-06` | Audit insertion occurs after the decision transaction. Changed statement, provenance, source. |
| `BR-CAP-PFM-OPS-011-07` | Submitting an asynchronous flush does not prove access changes within the request. Changed statement. |
| `BR-CAP-PFM-OPS-014-02` | Code gives current and grace contract windows priority over grant overrides. Changed statement, provenance, source. |
| `BR-CAP-PFM-OPS-014-09` | The unit test proves map keys, not lossless migration for every workspace. Changed statement. |
| `BR-CAP-PFM-OPS-015-05` | Routes audit after the service has changed state and requested a flush; generic provisioning and backfill do not always audit. Changed statement, provenance, source. |
| `BR-CAP-PFM-OPS-015-08` | Upsert collision handling is not a lock around the whole setup sequence. Changed statement. |
| `BR-CAP-PFM-OPS-015-09` | The prior test directly deletes an override; lifecycle declaration is evidence for both tables. Changed provenance, source. |
| `JNY-PFM-OPS-002`, AS-JNY-PFM-OPS-002-01 | The test proves sequential suppression after delivery, not strict once-only delivery across concurrent or interrupted sends. |
| `JNY-PFM-OPS-002`, step 4 | The persistence claim test cannot prove rendered email delivery. |
| `JNY-PFM-OPS-004`, step 3 | Submitting a flush is not evidence that the next request has refreshed authority. |
| `JNY-PFM-OPS-004`, AS-JNY-PFM-OPS-004-03 | The cited test checks job submission, not completion of cache invalidation. |
| `JNY-PFM-OPS-005`, step 3 | Sync performs no application setup and submits asynchronous invalidation. |
| `JNY-PFM-OPS-005`, AS-JNY-PFM-OPS-005-01 | Preserving a snapshot does not suspend known contractual expiry. |
| `JNY-PFM-OPS-003`, reporting-failure path | The cited browser test exhausts server-error retries and expects no visit in Recent Items. |
| ATS-PFM-OPS-005-09 | Added the browser drawer assertion to bound_to so read-only behavior has direct proof alongside workspace scope and subject evidence. |
| BR-CAP-PFM-OPS-001-01 | Submission conflict handling returns the winner outside a caller transaction; a caller transaction instead needs retry. Source changed from the narrow test to observed createJob implementation. |
| BR-CAP-PFM-OPS-002-02 | Reported success is refused when a step remains running or retrying; queued steps alone are not the claimed refusal. |
| BR-CAP-PFM-OPS-002-10 | A repair exception after successful job reconciliation prevents website reconciliation. |
| BR-CAP-PFM-OPS-002-09, BR-CAP-PFM-OPS-003-09 | Marked must_prove for malformed invocation and missing notification configuration; proof debt linked to FND-028. |
| BR-CAP-PFM-OPS-003-11 | Added duplicate-delivery race and interrupted-outcome-write behavior; FND-026. |
| BR-CAP-PFM-OPS-012-16 through 19 | Added worker acknowledgement, webhook publication failure recovery, queue retention/retry and missing initialization behavior; FND-029. |
| BR-CAP-PFM-OPS-015-10 | Added the unlocked transition/preparation concurrency gap; FND-030. |
| BR-CAP-PFM-OPS-001-11 and 12 | Added progress calculation and successor-execution recording; FND-032 retains missing acceptance proof. |
| BR-CAP-PFM-OPS-002-11 and 12 | Added deferred lookup failures, unregistered-family alerts and bounded successor following; FND-032. |
| MOD-PFM-OPS | Replaced draft narrative, corrected queue/schedule counting, added health, shared-engine and hosted-screen coverage and synchronized projected titles and classifications. |
| ID_REGISTRY | Reserved new rule and finding identifiers before writing; corrected operations actor allocation to 035 and synchronized final titles. |
| MOD-PFM-OPS registry row in PRODUCT-AREAS | Corrected actual read paths and supporting dependencies; status is planning examined. |
| CON-PFM-OPS-001 and 003 | Clarified requested invalidation after completed staff changes and the always-available exception to readiness gating. |

All capability examples previously labelled test were converted to inferred examples with an explicit reasoning note where the cited assertion establishes only a component of the illustrative flow. These 32 row identifiers are: `SC-CAP-PFM-OPS-001-01`, `SC-CAP-PFM-OPS-001-02`, `SC-CAP-PFM-OPS-001-03`, `SC-CAP-PFM-OPS-002-01`, `SC-CAP-PFM-OPS-002-02`, `SC-CAP-PFM-OPS-003-01`, `SC-CAP-PFM-OPS-003-02`, `SC-CAP-PFM-OPS-004-01`, `SC-CAP-PFM-OPS-004-02`, `SC-CAP-PFM-OPS-005-01`, `SC-CAP-PFM-OPS-005-02`, `SC-CAP-PFM-OPS-006-01`, `SC-CAP-PFM-OPS-006-02`, `SC-CAP-PFM-OPS-007-01`, `SC-CAP-PFM-OPS-007-02`, `SC-CAP-PFM-OPS-008-01`, `SC-CAP-PFM-OPS-008-02`, `SC-CAP-PFM-OPS-008-03`, `SC-CAP-PFM-OPS-009-01`, `SC-CAP-PFM-OPS-009-02`, `SC-CAP-PFM-OPS-010-01`, `SC-CAP-PFM-OPS-010-02`, `SC-CAP-PFM-OPS-011-01`, `SC-CAP-PFM-OPS-011-02`, `SC-CAP-PFM-OPS-012-01`, `SC-CAP-PFM-OPS-012-02`, `SC-CAP-PFM-OPS-013-01`, `SC-CAP-PFM-OPS-014-01`, `SC-CAP-PFM-OPS-014-02`, `SC-CAP-PFM-OPS-015-01`, `SC-CAP-PFM-OPS-015-02`, `SC-CAP-PFM-OPS-016-01`.

The following 112 acceptance identifiers lost unsupported complete-proof claims. Their candidate references remain in evidence_candidates rather than bound_to, and proposed status leaves the full stated result to be proved: `ATS-PFM-OPS-001-01`, `ATS-PFM-OPS-001-02`, `ATS-PFM-OPS-001-04`, `ATS-PFM-OPS-001-05`, `ATS-PFM-OPS-001-06`, `ATS-PFM-OPS-001-07`, `ATS-PFM-OPS-002-01`, `ATS-PFM-OPS-002-03`, `ATS-PFM-OPS-002-04`, `ATS-PFM-OPS-002-05`, `ATS-PFM-OPS-002-06`, `ATS-PFM-OPS-002-07`, `ATS-PFM-OPS-002-08`, `ATS-PFM-OPS-003-01`, `ATS-PFM-OPS-003-02`, `ATS-PFM-OPS-003-03`, `ATS-PFM-OPS-003-06`, `ATS-PFM-OPS-003-07`, `ATS-PFM-OPS-004-01`, `ATS-PFM-OPS-004-02`, `ATS-PFM-OPS-004-03`, `ATS-PFM-OPS-004-04`, `ATS-PFM-OPS-004-05`, `ATS-PFM-OPS-004-06`, `ATS-PFM-OPS-004-07`, `ATS-PFM-OPS-005-02`, `ATS-PFM-OPS-005-03`, `ATS-PFM-OPS-005-04`, `ATS-PFM-OPS-005-05`, `ATS-PFM-OPS-005-06`, `ATS-PFM-OPS-005-07`, `ATS-PFM-OPS-005-08`, `ATS-PFM-OPS-006-01`, `ATS-PFM-OPS-006-02`, `ATS-PFM-OPS-006-03`, `ATS-PFM-OPS-007-01`, `ATS-PFM-OPS-007-02`, `ATS-PFM-OPS-007-03`, `ATS-PFM-OPS-007-04`, `ATS-PFM-OPS-007-05`, `ATS-PFM-OPS-007-06`, `ATS-PFM-OPS-008-01`, `ATS-PFM-OPS-008-02`, `ATS-PFM-OPS-008-03`, `ATS-PFM-OPS-008-04`, `ATS-PFM-OPS-008-05`, `ATS-PFM-OPS-008-06`, `ATS-PFM-OPS-008-07`, `ATS-PFM-OPS-008-08`, `ATS-PFM-OPS-008-09`, `ATS-PFM-OPS-008-11`, `ATS-PFM-OPS-009-01`, `ATS-PFM-OPS-009-02`, `ATS-PFM-OPS-009-03`, `ATS-PFM-OPS-009-04`, `ATS-PFM-OPS-009-05`, `ATS-PFM-OPS-009-06`, `ATS-PFM-OPS-010-01`, `ATS-PFM-OPS-010-02`, `ATS-PFM-OPS-010-03`, `ATS-PFM-OPS-010-04`, `ATS-PFM-OPS-010-05`, `ATS-PFM-OPS-010-06`, `ATS-PFM-OPS-010-07`, `ATS-PFM-OPS-010-08`, `ATS-PFM-OPS-010-09`, `ATS-PFM-OPS-011-01`, `ATS-PFM-OPS-011-02`, `ATS-PFM-OPS-011-03`, `ATS-PFM-OPS-011-04`, `ATS-PFM-OPS-011-05`, `ATS-PFM-OPS-011-06`, `ATS-PFM-OPS-011-07`, `ATS-PFM-OPS-011-08`, `ATS-PFM-OPS-011-09`, `ATS-PFM-OPS-011-10`, `ATS-PFM-OPS-011-11`, `ATS-PFM-OPS-012-01`, `ATS-PFM-OPS-012-02`, `ATS-PFM-OPS-012-03`, `ATS-PFM-OPS-012-04`, `ATS-PFM-OPS-012-05`, `ATS-PFM-OPS-012-06`, `ATS-PFM-OPS-012-08`, `ATS-PFM-OPS-012-09`, `ATS-PFM-OPS-012-10`, `ATS-PFM-OPS-012-11`, `ATS-PFM-OPS-012-12`, `ATS-PFM-OPS-012-13`, `ATS-PFM-OPS-013-01`, `ATS-PFM-OPS-013-02`, `ATS-PFM-OPS-013-03`, `ATS-PFM-OPS-013-04`, `ATS-PFM-OPS-013-05`, `ATS-PFM-OPS-014-01`, `ATS-PFM-OPS-014-02`, `ATS-PFM-OPS-014-03`, `ATS-PFM-OPS-014-04`, `ATS-PFM-OPS-014-05`, `ATS-PFM-OPS-014-06`, `ATS-PFM-OPS-014-07`, `ATS-PFM-OPS-015-01`, `ATS-PFM-OPS-015-02`, `ATS-PFM-OPS-015-03`, `ATS-PFM-OPS-015-04`, `ATS-PFM-OPS-015-05`, `ATS-PFM-OPS-015-06`, `ATS-PFM-OPS-015-07`, `ATS-PFM-OPS-015-08`, `ATS-PFM-OPS-016-01`, `ATS-PFM-OPS-016-02`, `ATS-PFM-OPS-016-03`. Existing already-proposed rows remain proposed.

## Final-text changes by artifact

| Artifact | Final wording |
|---|---|
| `ATS-PFM-OPS-001` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-002` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-003` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-004` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-005` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-006` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-007` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-008` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-009` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-010` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-011` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-012` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-013` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-014` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-015` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `ATS-PFM-OPS-016` | Scenario titles, fixtures, steps, expected results and coverage narrative. |
| `CAP-PFM-OPS-001` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-002` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-003` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-004` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-005` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-006` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-007` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-008` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-009` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-010` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-011` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-012` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-013` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-014` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-015` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CAP-PFM-OPS-016` | Purpose, outcomes, conditions, rule statements, examples and How It Works. |
| `CON-PFM-OPS-001` | Definition, facets, distinctions, relationships, lifecycle and six-section concept narrative. |
| `CON-PFM-OPS-002` | Definition, facets, distinctions, relationships, lifecycle and six-section concept narrative. |
| `CON-PFM-OPS-003` | Definition, facets, distinctions, relationships, lifecycle and six-section concept narrative. |
| `CON-PFM-OPS-004` | Definition, facets, distinctions, relationships, lifecycle and six-section concept narrative. |
| `FEAT-PFM-OPS-01` | Grouping title, purpose and outcomes. |
| `FEAT-PFM-OPS-02` | Grouping title, purpose and outcomes. |
| `FEAT-PFM-OPS-03` | Grouping title, purpose and outcomes. |
| `FEAT-PFM-OPS-04` | Grouping title, purpose and outcomes. |
| `JNY-PFM-OPS-001` | Goal, steps, alternatives, failures, assertions, browser rationale and story. |
| `JNY-PFM-OPS-002` | Goal, steps, alternatives, failures, assertions, browser rationale and story. |
| `JNY-PFM-OPS-003` | Goal, steps, alternatives, failures, assertions, browser rationale and story. |
| `JNY-PFM-OPS-004` | Goal, steps, alternatives, failures, assertions, browser rationale and story. |
| `JNY-PFM-OPS-005` | Goal, steps, alternatives, failures, assertions, browser rationale and story. |
| MOD-PFM-OPS | Module purpose, boundaries, hosted descriptions and projected artifact catalogue. |
| FINDINGS | All finding statements and open-question explanations, choices and recommendations. |
| ID_REGISTRY | Ledger narrative and artifact title projections; identifiers remain permanent. |
| ACT-PFM-043 | Commercial actor name, description, goal and broad actions; other module actor rows unchanged. |

## Disagreements and unfinished work

Every finding remains open unless its statement records a local documentary correction; findings do not approve alternative product intent.

| Finding | Remaining disagreement or gap |
|---|---|
| `FND-PFM-OPS-001` | The original read scope names an absent HQ route group and omits the Applications host. The registry now identifies the actual HQ, configuration and supporting evidence paths; overlapping hosts retain their owning-module boundaries. |
| `FND-PFM-OPS-002` | Jobs, audit and licensing lack dedicated milestone records. Authority instead comes from the cited approved HQ plan, accepted application proposal and recorded audit acceptance, leaving a gap in milestone traceability. |
| `FND-PFM-OPS-003` | The HQ detail page reads a staleness flag absent from backend job responses, so its intended stalled-work warning cannot appear for real jobs. |
| `FND-PFM-OPS-004` | The provisioning-retry button checks jobs retry authority while the called operation checks workspace provisioning authority. Holding only one permission can expose a refused action or hide an otherwise callable action. |
| `FND-PFM-OPS-005` | The shared engine supports cancellation and eligibility population opts into it, but Platform has no cancellation route or screen. The jobs guide and HQ plan still describe cancellation as absent from the engine. |
| `FND-PFM-OPS-006` | The accepted HQ refresh design slows after two minutes, whereas both current monitors keep polling active work every five seconds. The jobs guide describes a different interval again. |
| `FND-PFM-OPS-007` | The jobs guide describes staff-wide results through the customer monitor. Code and tests retain customer scope there and reserve cross-customer inspection for HQ. |
| `FND-PFM-OPS-008` | The HQ plan specifies explorer-based saved views, richer filters and visible retry lineage. The current list supplies status filtering and the detail page omits lineage presentation. |
| `FND-PFM-OPS-009` | Requester messages link to staff-only HQ pages. That matches today’s provisioning audience but would not provide a usable destination for future customer-requested notifying kinds. |
| `FND-PFM-OPS-010` | The jobs schedule also hosts stranded-workspace repair and website reconciliation. These cross-module responsibilities share one invocation and its failure surface. |
| `FND-PFM-OPS-011` | Licensing decisions and state changes commit before their expected audit entries. A later audit failure can leave an access-affecting change without its security-history account. |
| `FND-PFM-OPS-012` | The accepted expiry decision requires renewal warnings beginning sixty days before the term ends. The examined module contains no sender for those warnings. |
| `FND-PFM-OPS-013` | The pinned operating guide records HubSpot activation as unfinished, with no configured token and unconfirmed property names. Stubbed resolver and sync tests therefore do not establish real-provider behavior. |
| `FND-PFM-OPS-014` | Later approved entitlement directions replace parts of the current licensing model, including overrides, product mapping and notice audiences. The examined implementation still uses the earlier model. |
| `FND-PFM-OPS-015` | The HQ panel requires a twenty-character reason beyond the backend’s nonblank requirement. It also requests a revocation reason that the served route neither accepts nor retains. |
| `FND-PFM-OPS-016` | The console’s failed-application retry address uses a hyphen where the backend uses an underscore. Shared mocks and tests reproduce the console spelling and therefore miss the integration mismatch. |
| `FND-PFM-OPS-017` | The workspace application read is claimed by both security and operations. Its licensing rule is retained here, but the overlapping corpus ownership needs reconciliation outside this job’s write scope. |
| `FND-PFM-OPS-018` | Export allowances are stored in licensing while the export module owns their HQ administration. The licensing guide does not explain this boundary. |
| `FND-PFM-OPS-019` | Current activity removal is limited to workspace retirement, leaving view-event growth unbounded. The recorded retention decision remains deferred with its compliance due date. |
| `FND-PFM-OPS-020` | The audit guide and seed inventory understate registered view targets and organization tracking. Organizations now report views, committees are registered, and no committee reporting screen is established. |
| `FND-PFM-OPS-021` | The custom-record read writes a visit for every accepted API read, using a server-generated key. Its history therefore includes callers beyond console navigation. |
| `FND-PFM-OPS-022` | Current public history reads select view events only. Other stored activity types have no corresponding reader here, and the raw person and colleague history capabilities remain without console screens. |
| `FND-PFM-OPS-023` | The Scheduled Jobs description and several labels expose internal workspace terminology. The product should use workspace wording on these customer surfaces. |
| `FND-PFM-OPS-024` | Staff company inspection, manual synchronization and feed-health operations exist without matching HQ screens. |
| `FND-PFM-OPS-025` | The seven proof gaps identified in the draft remain open. Examination also demotes broader partially bound acceptance matrices, retaining their candidate evidence under the separate proof-strength finding. |
| `FND-PFM-OPS-026` | Requester notice claiming permits duplicate delivery during simultaneous pending claims or a send followed by a failed outcome write. Its implemented delivery contract falls short of strict once-only intent. |
| `FND-PFM-OPS-027` | The guide prioritizes staff grants over contract windows, but the resolver reports current and grace contract coverage before grants. Availability can agree while source and reported dates differ. |
| `FND-PFM-OPS-028` | Acceptance matrices often claim several results while naming one narrow assertion. Candidate bindings remain traceable but cannot stand for complete proof; the mutation example does not test business rollback and the purge example directly deletes an override. |
| `FND-PFM-OPS-029` | Contract sync stores new coverage without preparing a missing application despite accepted initialization intent. Recorded provider failure and failed webhook publication also wait for later reconciliation rather than immediate queue retry. |
| `FND-PFM-OPS-030` | Row insertion handles conflicts, but the wider transition does not lock its initial state check or participant work. Concurrent actions can overwrite later decisions or repeat preparation, without an acceptance matrix establishing safe concurrency. |
| `FND-PFM-OPS-031` | Following a successful jobs pass, a stranded-provisioning repair exception prevents website reconciliation and fails the invocation. The draft’s independent-pass claim exceeds the handler’s actual failure isolation. |
| `FND-PFM-OPS-032` | The examination adds omitted progress, continuation and deferred-reconciliation rules. Their acceptance matrices remain open, and submission races inside a caller transaction require caller retry rather than always returning the winning job. |

The product should resolve the retention, requester-destination and management-control questions before using this layer as a complete design contract. Provider activation remains a statement from the pinned operating guide rather than a finding from current AWS inspection.

## Validation

`npm ci && npm run check` passes with zero conformance errors. `npm test` passes all four repository checker tests. These validate this specification corpus; they do not execute the source repositories’ acceptance suites.