Cross-Service Write Decoupling
IAM party cache + NATS write APIs for workflow/ORE

1. 4.3 — IAM hot-path party reads (auth_handler, account_handler) currently query ores_refdata_parties_tbl directly on every login. Replace with a NATS-backed party cache local to IAM.
2. 5.2 — Workflow writes to IAM and refdata tables during tenant onboarding. Replace with IAM and refdata NATS write APIs consumed by workflow.
3. 5.3 — ORE writes to workflow tables as a job queue during import. Replace with a workflow NATS write API consumed by ORE. Blocked on 5.2.

Cache strategy: in-process, full per-tenant load, event-invalidated.

• Party data is slow-changing; a full load per active tenant on startup is acceptable. Reload-on-restart is not a concern.
• Assumption: party hierarchies are small enough that caching all active parties for all tenants in process memory is not a problem. Cache sizes must be logged at load and refresh time so this assumption can be monitored in production.
• No DB-backed cache table. An in-process map avoids schema coupling and the two-layer invalidation problem. Each IAM instance independently subscribes to change notifications and maintains its own copy; this is correct cache behaviour, not a consistency problem.

Steps:

1. Refdata exposes a NATS request/reply subject refdata.v1.parties.read returning all active party records for a given tenant. Refdata also publishes to refdata.v1.parties.changed on any INSERT/UPDATE/DELETE to ores_refdata_parties_tbl (wire the existing LISTEN/NOTIFY eventing infrastructure to this NATS subject).
2. IAM implements an in-process party_cache (a per-tenant map of party_id → party record + descendant sets). On IAM startup, for each active tenant, send a refdata.v1.parties.read request and populate the cache. Log the number of tenants loaded and total party records cached. Subscribe to refdata.v1.parties.changed; on notification for tenant T, reload the full party set for T and log the new size.
3. Replace party_repository::read_descendants and party_repository::read_latest calls in auth_handler.hpp and account_handler.hpp with lookups into the party_cache.
4. Remove ores_refdata_parties DML and SELECT grants from the IAM service registry entry once no IAM handler reads from the refdata DB directly. Regenerate grants.
5. Remove CMake links from ores.iam.core/src/CMakeLists.txt to any refdata targets only used by the removed DB reads.

The provisioning path (bootstrap_handler) uses a SECURITY DEFINER function and does not consult the party cache. IAM can start and handle provisioning before the cache is warm. Verify no other startup path depends on party cache availability before marking this complete.

1. IAM exposes a NATS write API (request/reply) for account and role provisioning operations performed during onboarding.
2. Refdata exposes a NATS write API for party record creation.
3. Workflow replaces direct DB writes with calls to these NATS subjects.
4. Remove ores_iam_* and ores_refdata_parties DML from the workflow service registry entry; regenerate grants.

Phase 4.3 must be fully landed before 5.2 ships, because the refdata parties NATS write API (step 2) is the same surface that Phase 4.3's party cache reads will rely on for change notifications.

When Phase 5.2 was implemented it turned out that steps 1–3 were already complete: the provision_parties workflow was already routing all writes through NATS (refdata.v1.parties.save, iam.v1.accounts.save, iam.v1.account-parties.save), and ores.workflow.core links only against API packages, not ores.iam.core or ores.refdata.core. The workflow_handler::provision_parties() entry point only publishes a JetStream message and never writes to IAM or refdata tables directly. The DML grants in the service registry were therefore dead leftovers. Step 4 (removing the grants and regenerating) was all that was needed.

1. Workflow exposes a NATS write subject for job queue submission.
2. ORE replaces direct DB writes with calls to this subject.
3. Remove ores_workflow_* DML from the ORE service registry; regenerate grants.

Blocked on Phase 5.2: the workflow NATS API surface from 5.2 establishes conventions that 5.3 must follow.

When Phase 5.3 was implemented it turned out that steps 1–2 were already complete: the ORE service already routes workflow submission through NATS (nats_.js_publish(start_workflow_message::nats_subject, data)) and ores.ore.service links only API and service packages, never ores.workflow.core. The ores_workflow_* DML grant in the service registry and the ores.workflow.core.lib CMake link were dead leftovers. Step 3 (removing the grant, removing the CMake link, and regenerating) was all that was needed.