v0.49.0: Deliver managed deadlines and bounded escalation

[grove]

Outcome

Evaluate overdue review cases while business tables remain idle and deliver at most one permitted escalation per MDM case occurrence and configured level. Preserve existing deadlines and prevent repeated escalation after retries, restarts, audit updates, or human edits.

Scope and boundaries

• Reuse the supported React temporal path and ordinary poll/worker runtime. First map the installed public API and prove time-only liveness. Missing temporal functionality requires re-estimation before further implementation.
• Use one authoritative database-time sample per evaluation unit, timezone-aware timestamps, and the qualified UTC elapsed-time profile. Document the due boundary, proposed as equality counting as due. Freeze numeric detection/dispatch latency and admission bounds before acceptance.
• Request typed ESCALATE through the existing transactional MDM adapter. Require the v0.48.0 transaction, deduplication, binding, and stale-work gates plus real MDM M2 escalation support and exact receipt fixtures. MDM retains authority over eligibility, manual protection, recurrence, level limits, and acceptance.
• Obtain owner agreement on level and catch-up semantics. The proposed first profile advances at most one next permitted level per case per evaluation, emits at most one condition row per case_key, and bounds total levels and per-cycle admissions. Prevent repeated applied levels across new request keys, lifecycle generations, human edits, retries, and restore.
• Preserve deadlines unless an explicitly reviewed policy replacement authorizes a change. Exclude audit-only fields from action-driving revisions, converge to a no-op after delivery, preserve immutable attempted work, and block stale or incompatible queued escalation after human changes, replacement, or the pause barrier.
• Expose public evidence for deadlines, configuration, sampled time, requested/applied levels, protection/no-op reasons, pending work, receipts, and stale/rejected outcomes. Keep control delivery distinct from case closure and business resolution.
• Qualify deterministic time boundaries and real managed-runtime idle-case liveness, concurrency, bounded backlog/catch-up, adjacent upgrade, restart, coherent restore, and clone startup isolation. Apply common gates C01-C12 to present behavior. Repeated controls and unauthorized actions have zero tolerance. Upgrades preserve request codecs and applied levels and cannot silently enable escalation.

The budget is 30 person-days, including independent review and operational documentation. Excluded are rolling/hopping windows, business calendars, arbitrary event sequences, network alerts, human approval routing, a generic temporal DSL, a separate scheduler, and a broad temporal-engine rewrite.

Extra profiles and convenience metrics may be cut. Real time-only testing, recurrence identity, duplicate prevention across new keys, and restart catch-up safety may not.

Source specification

• Authoritative specification: https://github.com/trickle-labs/pg-react/blob/843256fb465de69f172fb61e66c5f76d981f0670/plans/v0.49.0.md
• Repository-relative path: plans/v0.49.0.md
• Commit: 843256fb465de69f172fb61e66c5f76d981f0670
• SHA-256: cc9b0345c80e10cecaf997b190e47d8a9173c768fc51cedcd270d69101866e9a

The linked specification and its referenced release gates remain authoritative. This issue does not replace them with an acceptance contract.

[grove]

Planning handoff binding sources, part 1 of 2.

For work/v0-49-0-managed-deadlines-and-bounded-escalation.md v1, SHA-256 f7c251c4b049f4ec07bed93733bfe19f4d5d59bbf1ca63593b1d3c5d31ba701b. These are exact recoverable input copies, not approval. Preserve the paths and UTF-8 bytes inside each fence.

Path: specs/v0.49.0-issue-8.md
SHA-256: 59c3f3e846d425ca119d7bf33576848f2b452a77fff1da53ee2659bf8a5929c6

# Source snapshot: issue #8

Source attribution: https://github.com/trickle-labs/pg-react/issues/8; updated 2026-09-26T22:37:38Z; retrieved 2026-09-26T22:45:03.361189+00:00. No comments, prior handoffs, approvals or amendments were present.

Source: [plans/v0.49.0.md](../plans/v0.49.0.md), [docs/planning/RELEASE-GATES.md](../docs/planning/RELEASE-GATES.md), [plans/PLAN_PG_REACT_MDM_STEWARDSHIP.md](../plans/PLAN_PG_REACT_MDM_STEWARDSHIP.md), [plans/PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md](../plans/PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md), [contracts/MDM-STEWARDSHIP-1-v3.json](../contracts/MDM-STEWARDSHIP-1-v3.json), [contracts/MDM-STEWARDSHIP-1-fixture.json](../contracts/MDM-STEWARDSHIP-1-fixture.json)

The four Markdown sources match commit 843256fb465de69f172fb61e66c5f76d981f0670 byte-for-byte. The approved MDM v3 contract and its fixture are captured from checkout c9c20778ec3b9e4783e71688678d24ca91958716.

## Binding scope and reconciliation

The v0.49 plan and common gates remain authoritative. The companion plans supply referenced R3 ownership, identity, transactional and demonstration obligations, without importing unrelated future milestones. Navigation links and historical source citations are attribution, not additional release scope. The later approved MDM v3 contract supersedes the older revision-1 binding administration pin, preserving its canonical codec fixture. This follows the existing v0.48 manifest selection, not a new contract amendment. That manifest records owner approval dated 2026-09-25 and v3 digest fd6f5e6ceb7c65fc93924c004a24f348e4296f2d83e83ce4e82cea6493e77efe. Historical evidence is not proof for v0.49.

## Binding input digests

- plans/v0.49.0.md: SHA-256 cc9b0345c80e10cecaf997b190e47d8a9173c768fc51cedcd270d69101866e9a
- docs/planning/RELEASE-GATES.md: SHA-256 70a14db53e0fa7575fbc4bf6b2c9c785be41e62caadf6e6663f9c8408fcb5d53
- plans/PLAN_PG_REACT_MDM_STEWARDSHIP.md: SHA-256 130a07066ba77fede81b580a8d110d2406e26e070cc1c6b9c77da8f4baf45d2e
- plans/PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md: SHA-256 fab1cdaa93e809bc0a75c58e1bd07f45c9a9093cd741491683b5f15a0a8403c0
- contracts/MDM-STEWARDSHIP-1-v3.json: SHA-256 fd6f5e6ceb7c65fc93924c004a24f348e4296f2d83e83ce4e82cea6493e77efe
- contracts/MDM-STEWARDSHIP-1-fixture.json: SHA-256 900f365533bab13480fcb88ab8e8b7956beb4f14a8cfc92cd46770b2e26ef3e4

## Imported issue title

v0.49.0: Deliver managed deadlines and bounded escalation

## Imported issue body

## Outcome

Evaluate overdue review cases while business tables remain idle and deliver at most one permitted escalation per MDM case occurrence and configured level. Preserve existing deadlines and prevent repeated escalation after retries, restarts, audit updates, or human edits.

## Scope and boundaries

- Reuse the supported React temporal path and ordinary poll/worker runtime. First map the installed public API and prove time-only liveness. Missing temporal functionality requires re-estimation before further implementation.
- Use one authoritative database-time sample per evaluation unit, timezone-aware timestamps, and the qualified UTC elapsed-time profile. Document the due boundary, proposed as equality counting as due. Freeze numeric detection/dispatch latency and admission bounds before acceptance.
- Request typed `ESCALATE` through the existing transactional MDM adapter. Require the v0.48.0 transaction, deduplication, binding, and stale-work gates plus real MDM M2 escalation support and exact receipt fixtures. MDM retains authority over eligibility, manual protection, recurrence, level limits, and acceptance.
- Obtain owner agreement on level and catch-up semantics. The proposed first profile advances at most one next permitted level per case per evaluation, emits at most one condition row per `case_key`, and bounds total levels and per-cycle admissions. Prevent repeated applied levels across new request keys, lifecycle generations, human edits, retries, and restore.
- Preserve deadlines unless an explicitly reviewed policy replacement authorizes a change. Exclude audit-only fields from action-driving revisions, converge to a no-op after delivery, preserve immutable attempted work, and block stale or incompatible queued escalation after human changes, replacement, or the pause barrier.
- Expose public evidence for deadlines, configuration, sampled time, requested/applied levels, protection/no-op reasons, pending work, receipts, and stale/rejected outcomes. Keep control delivery distinct from case closure and business resolution.
- Qualify deterministic time boundaries and real managed-runtime idle-case liveness, concurrency, bounded backlog/catch-up, adjacent upgrade, restart, coherent restore, and clone startup isolation. Apply common gates C01-C12 to present behavior. Repeated controls and unauthorized actions have zero tolerance. Upgrades preserve request codecs and applied levels and cannot silently enable escalation.

The budget is 30 person-days, including independent review and operational documentation. Excluded are rolling/hopping windows, business calendars, arbitrary event sequences, network alerts, human approval routing, a generic temporal DSL, a separate scheduler, and a broad temporal-engine rewrite.

Extra profiles and convenience metrics may be cut. Real time-only testing, recurrence identity, duplicate prevention across new keys, and restart catch-up safety may not.

## Source specification

- Authoritative specification: https://github.com/trickle-labs/pg-react/blob/843256fb465de69f172fb61e66c5f76d981f0670/plans/v0.49.0.md
- Repository-relative path: `plans/v0.49.0.md`
- Commit: `843256fb465de69f172fb61e66c5f76d981f0670`
- SHA-256: `cc9b0345c80e10cecaf997b190e47d8a9173c768fc51cedcd270d69101866e9a`

The linked specification and its referenced release gates remain authoritative. This issue does not replace them with an acceptance contract.

<!-- grove:create-parent-issue source=trickle-labs/pg-react:plans/v0.49.0.md -->

Path: plans/v0.49.0.md
SHA-256: cc9b0345c80e10cecaf997b190e47d8a9173c768fc51cedcd270d69101866e9a

# v0.49.0 — Managed deadlines and bounded escalation

> **Status:** Proposed  
> **Predecessor:** `0.48.0`  
> **Source milestone:** R3 — Deadline escalation  
> **Budget:** 30 person-days / six person-weeks  
> **Owners:** React temporal/runtime owner and adapter owner; MDM owner approves level semantics; independent reviewer checks liveness and repeated-action prevention

[Roadmap](../ROADMAP.md) · [Common release gates](../docs/planning/RELEASE-GATES.md) · [Evidence and sources](../docs/planning/EVIDENCE.md)

## 1. User-visible outcome

A review case that becomes overdue while the business tables are idle is evaluated by the managed runtime and receives at most one permitted escalation for each configured level in its MDM case occurrence. Restart, retry, audit updates and human edits do not create uncontrolled escalation loops.

The existing due date remains authoritative unless a reviewed policy replacement explicitly authorizes changing it. React requests `ESCALATE` through the same typed transactional MDM adapter as other controls; MDM retains authority to accept or reject it. [S0 §§4–7]

## 2. Entry gates and scope

The 0.48.0 transaction, deduplication, binding and stale-work gates must pass on the exact stack. MDM must define escalation eligibility, maximum levels, manual protection, recurrence, duplicate/no-op behavior and action-driving revision semantics. The managed React deadline/temporal entry point must be mapped from the installed public contract rather than guessed.

Require the real MDM M2 `ESCALATE` implementation and its exact receipt fixtures. MDM `0.11.0` does not implement escalation. pg-trickle `0.108.0` does not make a `now()` predicate a time-only trigger; its EXTERNAL graph mode also excludes IMMEDIATE maintenance. Keep the existing React temporal path and prove idle-case liveness on the selected joint profile. [S8, S9]

The release adds managed time-only reevaluation and the signed bounded escalation profile. It does not add rolling/hopping event windows, business calendars, a new scheduler, arbitrary sequences of events, network alerts or human approval routing. The ordinary pg-react poll/worker model remains the runtime. [S0 §4; S7]

## 3. Implementation design

### 3.1 Audit and reuse the installed temporal path

Start by identifying the exact public temporal/deadline registration and execution path in the selected runtime, its ownership, granularity and recovery contract. The baseline concepts establish that advanced temporal/deadline facilities exist, not that any guessed function signature is supported.

Write an executable proof that a deadline initially in the future is evaluated after time passes without modifying the business source tables. If the supported path needs an explicit sampled-time relation, use its approved managed maintenance mechanism and document that technical input. Do not introduce arbitrary wall-clock polling or a separate scheduler as a fallback.

Only proceed beyond the audit task when the selected path can satisfy liveness. A missing temporal mechanism is a discovered core dependency requiring re-estimation, not permission to hide a `now()` expression in a materialized condition.

### 3.2 Explicit time semantics

Capture one authoritative database-time sample per evaluation unit through the supported mechanism. Apply a documented boundary rule for `due_at == sampled_time`; the proposed first profile treats equality as due. Use timezone-aware timestamps and the already qualified UTC elapsed-time service-window profile.

Persist or expose enough public evaluation-time evidence to explain why the case was eligible. Time is a policy input, but it must not become a request-key salt. A later sample with unchanged eligibility must not manufacture a new intended action or reset a deadline.

Freeze the allowed detection/dispatch latency budget from the configured managed poll interval and measured queue behavior before acceptance. Record both “became due” and “control accepted” times; a worker wakeup alone is not proof of delivered escalation.

### 3.3 Bounded escalation policy

Use the MDM-owned open/closed state, due date, current or previously applied escalation state, automation protection, active policy binding and configured level limits. Only emit a desired control that differs from current MDM state and is permitted by MDM.

**Proposed first profile:** progress to at most one next permitted level per case per evaluation, then reevaluate after committed MDM state is visible. Bound total levels and per-cycle admissions. Emit at most one condition row per MDM `case_key`; the next level is an action-driving payload value, not a new composite ordinary semantic key. Do not replay every missed time interval as a burst of escalation work after downtime. The policy owner must agree to catch-up semantics before tests are frozen.

“Same request is deduplicated” alone is not enough: a new lifecycle generation or action revision can produce a new request key for the same level. Jointly prove the semantic invariant across such keys. MDM must expose/validate the necessary occurrence and applied-level state, or the approved adapter must retain minimal delivery-deduplication state atomically with the intent. This is action bookkeeping, not a human review ledger. The chosen mechanism must be in the signed contract and survive restore.

A human's change must not allow a previously applied level to be silently reissued for the same occurrence. Genuine recurrence is identified by MDM, not inferred from a disappearing/reappearing row or a publication timestamp.

### 3.4 Prevent feedback and preserve deadlines

Define explicit watched/action-driving columns. Exclude receipt timestamps, worker heartbeats and audit-only publication updates from work creation. Preserve these fields as observation metadata when useful, but do not let them advance the action-driving revision.

After stale tokens, use the existing bounded reevaluation path. A new time sample does not make a stale payload valid. Existing attempted work remains immutable; a changed intended action requires a new item.

An accepted queue assignment or escalation can change the published MDM projection. Ensure that this feedback leads to a no-op once the desired state is reached. Due-date setting must not keep extending its own deadline on every publication. Authorized deadline replacement must be explicit, reviewed and tested against already queued escalation.

### 3.5 Public operational evidence

Expose through public React/adapter views or existing explanation output: original due date, configuration version, sampled evaluation time, requested/applied level, no-op/protection reason, pending work, receipt and stale/rejected outcome. Keep delivery, case closure and business resolution distinct.

Proposed files: `integrations/pg-mdm/sql/deadline-runtime.sql`, `escalation.sql`, action-column mapping and `tests/integrations/pg-mdm/time/`. No new generic temporal DSL or scheduler is introduced.

## 4. Work breakdown: 30 person-days

| Task | Days | Deliverable |
|---|---:|---|
| W49.1 — Temporal and escalation contract audit | 4 | Exact API mapping, time-only proof, level/recurrence/catch-up decisions |
| W49.2 — Managed deadline integration | 6 | Supported sampled-time evaluation, explicit due boundary and recovery mapping |
| W49.3 — Typed bounded escalation | 5 | `ESCALATE` consequence, per-occurrence/level safety, work admission bounds |
| W49.4 — Feedback and deadline preservation | 4 | Watched-column mapping, no-op convergence, authorized replacement behavior |
| W49.5 — Liveness/restart/concurrency qualification | 6 | Idle-time, downtime, human-edit, audit-loop and bounded-load evidence |
| W49.6 — Explanation, operations and review | 3 | Public diagnostics, timer/recovery guide and release notes |
| W49.7 — Contingency | 2 | Integrated fixes |
| **Total** | **30** | **Six person-weeks** |

W49.1 is an early stop/go point. W49.2 and W49.3 must converge on one immutable request-generation rule before W49.4. No broad temporal-engine rewrite is included.

## 5. Acceptance tests

| ID | Scenario | Expected result |
|---|---|---|
| T49.01 | Open idle case crosses due time | Evaluation and permitted control occur within the predeclared bound without business-table changes |
| T49.02 | Immediately before/at/after due time | Boundary behavior matches the documented rule using a consistent time sample |
| T49.03 | Repeated polls at same eligible level | At most one applied escalation for the same MDM case occurrence and configured level |
| T49.04 | Retry/crash around escalation commit | Existing immutable key/body is reused; atomic control/receipt/completion behavior retained |
| T49.05 | New generation/revision but same occurrence/level | No duplicate semantic escalation even when a new work identity could otherwise be generated |
| T49.06 | Worker down across several deadlines | Bounded documented catch-up; no unbounded burst, lost eligibility or repeated applied levels |
| T49.07 | Audit/receipt/heartbeat/publication-only changes | No new command solely because observation metadata advanced |
| T49.08 | Existing due date and policy replacement | Deadline preserved by default; only explicit authorized replacement changes it; queued incompatible work is blocked/withdrawn |
| T49.09 | Human closes case or protects assignment | Stale pending escalation cannot override current MDM state |
| T49.10 | Genuine recurring review | New MDM occurrence can receive its permitted actions without reusing a prior occurrence's request identity |
| T49.11 | Maximum level and suspended binding | Level bounds enforced; paused/disabled bindings accept no new intents after the barrier |
| T49.12 | Mixed due workload under resource limits | Per-cycle bounded admissions, measured backlog behavior and eventual progress within the declared supported profile |

Use deterministic time-input fixtures for boundary enumeration and at least one real managed-runtime wall-clock test for liveness. Test synchronization should observe public state with a bounded deadline, not rely on a fixed sleep as evidence. Required real-time cases cannot be replaced by manually updating the business rows to force refresh.

Apply common gates C01–C12 to the now-present behavior. Correctness budgets for repeated controls and unauthorized actions remain zero.

## 7. Upgrade and recovery

Append the adjacent migration for temporal registrations/configuration and any minimal delivery-level bookkeeping. Keep existing request codec versions and previously applied MDM levels intact. Enabling a new escalation policy must be explicit and reviewed; an upgrade cannot silently turn on escalation for existing cases.

Pause adapter admission, reach the barrier and preserve coherent state before changing temporal configuration. After restart/restore, recheck artifact/capability identity, active binding and current MDM facts, then resume bounded evaluation. Do not reset original deadlines to recovery time or treat every missed poll as a new action.

Use the common clone startup guard. No cloned database may run overdue automation merely because copied timestamps are already in the past. A persisted “enabled” flag is not sufficient isolation.

## 8. Definition of done and scope cut

R3 completes when time-only liveness, deadline preservation, semantic per-occurrence/level uniqueness and feedback convergence pass on the real stack. The qualified temporal API and numeric workload-specific latency/admission bounds are documented.

Cut extra escalation profiles, advanced calendar rules and convenience metrics first. Do not cut real time-only testing, recurrence identity, duplicate prevention across new keys, or restart catch-up safety. If the temporal audit finds missing generic functionality, split that work into a new approved release rather than exceeding six person-weeks silently.

**Next:** [v0.50.0 — Joint rollout and operating envelope](v0.50.0.md).

Path: docs/planning/RELEASE-GATES.md
SHA-256: 70a14db53e0fa7575fbc4bf6b2c9c785be41e62caadf6e6663f9c8408fcb5d53

# Common implementation and release gates

> Applies to proposed pg-react `0.46.0` through `0.51.0`. These are proposed engineering requirements derived from the supplied integration contract and the current release boundary. Source identifiers resolve in [EVIDENCE.md](EVIDENCE.md).

## 1. Estimation and admission rules

Every version has a 30-person-day budget, including integration coding, review, tests, documentation and two days of contingency. A person-day is an effort unit, not elapsed pipeline time. External upstream/MDM implementation and waiting are dependencies, not unpriced React tasks. Required upstream behavior must already exist at the relevant entry gate.

Start R0 compatibility qualification on released pg-trickle `0.108.0` and pg-mdm `0.11.0`. Pass the released upstream conformance gate before dependent integration implementation. The older wait for a future `0.97` or `0.104` release no longer applies. MDM M0, M1, and M2 remain separate contract, projection, and intent dependencies; fixtures cannot substitute for their installed APIs. [S8, S9]

Record the actual predecessor version, source commit, extension versions, PostgreSQL runtime version, image digest, platform, isolation, CDC mode, coordinator ownership and capability response. Re-run admission after upgrades or a capability change. A lost required capability prevents new adapter effects and leaves inspectable blocked state. Delta V1.1 stays unused in this sequence.

## 2. One authority model

The core extension works without MDM installed. The optional adapter uses only approved public MDM relations and functions; no MDM private catalogs, direct review writes, identity changes, human approval calls, or nested refreshes are allowed. Generic pg-react internals must not become an MDM-specific rule language.

Start with one administrative scope, one active routing binding, a non-RLS policy projection and explicit grants. Prove negative permissions as ordinary roles, including indirect source exposure and hostile `search_path`. No `BYPASSRLS`, superuser evaluation as a convenience, or a view that disguises an RLS-backed source.

Contract/interface installation may need an installer role. Runtime submission must use the least privileged identity capable of the signed intent operation. Prove that this identity cannot approve reviews or alter MDM identity decisions. Do not infer capability from successful function lookup alone. [S0 §§1–3, S2]

## 3. Delivery and immutable identity

For every real work item persist, before the first attempt, its canonical encoding version, stable request key, complete body, public policy/work identity, and the MDM review/concurrency identities needed by the signed contract. Preserve the source key recipe:

```text
binding ID + policy revision + case occurrence + lifecycle generation
+ action-driving revision + consequence identity + escalation level
```

Specify typed and unambiguous encoding, null handling, normalization and stable test vectors. A different request body cannot share a key. A retry cannot recompute its payload from current tables. Operator-requested reevaluation creates new work when an intended action changes; it does not edit old attempted work.

MDM intent submission, receipt association and React database-work completion must share one PostgreSQL transaction. Inject failures between each step and prove the entire local operation rolls back. Replayed attempts after an uncertain commit must reuse the same identity and reconcile against MDM's idempotency response. This is not a claim of exactly-once delivery outside PostgreSQL.

Treat `APPLIED_CONTROL` as control delivery only; `ACCEPTED_PENDING_PUBLICATION` remains separate from `APPLIED_PUBLICATION` and business resolution. Stale/superseded work is terminal and triggers explicit reevaluation. Denied, invalid and idempotency-conflict outcomes stop work and require correction. Only contract-classified transient failures use bounded retry. Unknown outcomes fail closed. [S0 §6]

## 4. Lifecycle, policy replacement and pause

Version policy packages and bind their digest to the MDM automation binding. In a supported single local transaction, change the policy and corresponding binding together. Otherwise keep the binding disabled across the transition, validate both sides, and activate explicitly. Incompatible queued work must be held or withdrawn; completed attempted payloads remain immutable.

A pre-check in React alone cannot prevent a replacement race. MDM must validate the expected active binding/digest within the same atomic action that applies the intent, or supply an equivalent documented locking contract. Test both lock orders and both outcomes.

Define pause at a precise linearization point: no new intent may be accepted after the acknowledged pause barrier. An intent accepted before that point is not undone. A persisted pause flag without handling in-flight work is insufficient evidence. Reversal is an explicit separately authorized MDM action, never a compensating action invented by React. [S0 §7]

## 5. Required evidence matrix

| Gate ID | Suite | Minimum evidence |
|---|---|---|
| C01 | Exact stack and capability admission | Real versions/digests; enabled/disabled/missing/unsupported-major cases; rejection before side effects |
| C02 | Core isolation | Fresh core install without MDM; adapter disabled/absent leaves ordinary policies functional |
| C03 | Authorization | Installer, author, runtime, observer and unauthorized-role cases; fixed search path; rejected RLS sources; no human approval privileges |
| C04 | Ordinary compatibility | Existing valid authoring/review/deploy/replace/inspect calls remain valid; expected errors and stale-review rejection retained |
| C05 | Fresh and adjacent install | Deterministic fresh artifact; populated predecessor upgrade; schema/API inventory agrees; adapter installed and absent variants |
| C06 | Atomicity and retry | Duplicate requests, concurrent claims, same-key/different-body conflict, deadlock/rollback and uncertain-commit replay |
| C07 | Concurrent stewardship | Human changes, case closure/reopening, source/evidence revision changes, binding replacement and pause races |
| C08 | Feedback and time | Audit-only updates do not create work; time-only expiry does; recurrence and every bounded escalation level tested |
| C09 | Comparison | Fixed population with exact coverage; partial results not accepted as complete; no effect calls or selected/unselected state mutations |
| C10 | Recovery and clones | Restart, coherent populated backup/restore, failed upgrade recovery, disabled-effect clone boot, explicit resumption |
| C11 | Resource bounds | Representative load, queue growth, backlog drain, database writes/WAL/storage and retained receipt/key horizon measured; unavailable metrics labeled |
| C12 | Packaged qualification | Exact artifact under test is the artifact published; full logs and structured failures retained; no required skips |

Apply a gate to the behavior present in a release. Before real delivery exists, C06/C07 must still prove no-effect boundaries and applicable deployment races; absence of delivery is not evidence that future delivery semantics pass. Record later tests as deferred to their named owning version. The rollout release reruns every applicable earlier gate against the final joint stack.

## 6. Evidence format and numeric limits

Write a machine-readable release evidence record containing release and source identities, contract digest, environment, test ID, command, expected result, actual result, status, artifact/log references and required/optional classification. Proposed location: `tests/integrations/pg-mdm/evidence/<version>/` for schema and manifests; retain generated logs as release artifacts rather than committing large mutable logs.

Record numeric limits before qualification: cohort size, case churn, queue/level bounds, poll interval, time-only response budget, backlog drain budget, receipt/key retention horizon, database storage/WAL growth and recovery time budget. These documents do not invent achieved throughput or latency. Freeze workload-specific numbers in the signed qualification manifest after baseline measurements and before acceptance; blank thresholds block qualification.

Correctness budgets are already fixed: zero unauthorized controls, zero same-request duplicate controls, zero controls from stale/disabled bindings, zero unexplained population omissions, zero clone effects before activation, and zero required tests silently skipped. Ordinary compatibility and safety cannot be traded for throughput. [S0 §8; S3, S5]

## 7. Upgrade, restore and clone protocol

Append adjacent migration SQL; never edit published install/upgrade history. Preserve valid ordinary calls. Version the optional adapter explicitly and qualify it with the matching core release. A planning-only merge must not bump the released version.

Before a live upgrade, pause adapter acceptance and reach its barrier, preserve a consistent whole-database recovery point and exact matching binaries, inventory pending/leased/retry work, request snapshots, bindings, MDM receipts and publication references. Upgrade the tested sequence. Start with adapter effects disabled, verify integrity and capability admission, then resume deliberately.

On migration failure, roll back the transaction where supported. If binary/runtime recovery is required, restore the coherent database and matching prior artifacts; do not promise reverse `ALTER EXTENSION` migrations. Do not restore React request state independently of corresponding MDM receipts/control state. Already accepted business directives are not undone by an adapter pause.

A byte-for-byte clone cannot be assumed to identify itself from copied database rows. The supported restore/clone deployment procedure must prevent adapter execution before an environment-specific operator activation check, for example through a validated startup configuration or equivalent agreed external guard. A copied persisted `enabled` flag is not sufficient. Prove the actual launch procedure in CI. Deployments that bypass it are outside the qualified clone-safety contract; do not claim automatic detection of arbitrary clones. Clone activation cannot rewrite an existing attempted request key. [S0 §§6–8]

## 8. Completion and scope control

Release qualification requires code installed and exercised, independent review, complete source/evidence links, updated support/limits/recovery documentation and no open critical correctness or authorization defect. A fixture-only deliverable is labeled fixture-only; a blocked upstream gate remains blocked.

If a plan exceeds 30 person-days, first remove optional sample variety, dashboards, convenience helpers or performance polish that is not required for the named workload. Re-estimate or split newly discovered semantics into another approved version. Never silently omit idempotency, authorization, transactional boundaries, temporal liveness, immutable work, or restore evidence.

Path: plans/PLAN_PG_REACT_MDM_STEWARDSHIP.md
SHA-256: 130a07066ba77fede81b580a8d110d2406e26e070cc1c6b9c77da8f4baf45d2e

# pg-react: MDM stewardship policy integration plan

**Status:** Ready for R0 compatibility work; live stewardship depends on MDM M1/M2\
**Updated:** 12 September 2026\
**Baseline:** pg-react `0.45.0`; qualify pg-trickle `0.108.0` and pg-mdm `0.11.0` plus the companion's new APIs\
**Repository:** `trickle-labs/pg-react`  
**Companion:** [pg-mdm implementation plan](PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md)  
**Proposed shared contract:** `MDM-STEWARDSHIP/1`

## 1. Goal and ownership

Provide an optional integration that turns MDM review facts into **routing decisions, deadline policies, and durable requests for MDM-controlled actions**.

Reuse pg-react's relational conditions, decisions, command work, policy sets, comparison, and explanations. Do not add a general workflow engine, a duplicate review ledger, or a second identity resolver. The existing pg-react contract explicitly excludes general workflow/BPM semantics. Human approvals and final identity decisions belong to MDM. [1][2][6]

```text
MDM policy-case relation
    -> React conditions and routing decisions
    -> React durable command work
    -> typed MDM intent API
    -> MDM receipt

Human approval -> authenticated MDM approval API, not a React worker
```

Package the integration as an optional adapter and policy example maintained in this repository. Neither core extension should acquire a mandatory dependency on the other.

## 2. Dependencies and implementation gate

Start R0 stack qualification now that pg-trickle `0.108.0` advertises stable, enabled Graph V1.2 and Delta V1.1. Collect the released assurance evidence and pass the agreed conformance cases before dependent integration implementation. MDM `0.11.0` implements review publication but lacks the proposed policy projection and intent API. MDM M1 and M2 remain prerequisites for read-only and effectful joint qualification respectively. [4][5]

Compatibility is the first engineering task. pg-react `0.45.0` pins pg-trickle `0.98.0` and requires disabled Graph/Delta capabilities in `sql/current/pgtrickle.sql`. MDM `0.11.0` pins `0.105.1`. Update React admission, diagnostics, fixtures, and packaging for `0.108.0`, then qualify both projects on the same PostgreSQL 18 artifact. Resolve the existing PostgreSQL 18.3/18.4 image discrepancy using effective runtime identity. [3][4]

Keep React's explicit coordinator, trigger CDC, scheduler-off profile, and differential-refresh safeguard. MDM owns its EXTERNAL graph members and strict refresh transaction. An enabled Graph or Delta capability does not mean React must consume it. Test committed policy-table visibility, shared-source CDC, skipped ordinary refreshes, and FULL fallback before accepting the joint profile. Never infer successful delivery from NOTIFY or freshness metrics. [5]

The first integration reads ordinary local policy tables. It does not depend on Tide, a semantic event feed, output-delta consumption, or a prepared/resumable MDM execution path.

## 3. Shared contract and policy inputs

Treat section 4 of the [MDM plan](PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md#4-shared-interface-mdm-stewardship1) as the proposed normative contract. React implements a client, not a competing definition.

Consume the proposed `mdm_steward.policy_cases_v1` table, submit through `mdm_steward.submit_policy_intent(...)`, and read `mdm_steward.policy_receipts_v1`. Those names are proposals, not installed APIs.

MDM M1 must publish this table from released `mdm_out.<entity>_review` rows, preserve UUID review occurrences, and allocate the bigint case key. M0 must map `concurrency_version`, definition versions, decision epoch, publication revision, and evidence basis to exact intent types. React must not assemble an authoritative projection by joining MDM private catalogs. `mdm_steward.decide()` is a human directive API, not a substitute for M2 request deduplication or automation authority. [4]

Use the MDM-provided `case_key bigint` as the policy subject. Preserve the original review identity and concurrency tokens in the work snapshot. This avoids relying on broader key support than the current ordinary comparison interface provides: that interface requires one unique, non-null bigint key. [3]

Begin with one administrative scope and a non-RLS policy projection containing only authorized metadata. pg-react currently rejects RLS-protected evaluated sources. Reject unsupported deployments explicitly; do not hide an RLS source behind a view or grant `BYPASSRLS` as a workaround. Multi-tenant qualification is separate work. [3]

## 4. Initial policy package

| Policy | Inputs | Consequence |
| --- | --- | --- |
| **Route a review** | Reason code, entity type, approved business metadata, manual-assignment protection | Request an allowed queue through `ASSIGN_QUEUE`. |
| **Set a due date** | Case creation time and versioned service-window configuration | Request `SET_DUE_AT`, subject to MDM's deadline limits. |
| **Escalate an overdue review** | Open state, due date, escalation level, sampled database time | Request one `ESCALATE` action per case and configured level. |

Emit work only when the desired control value differs from current MDM state and the case permits automation. Use one active routing-policy binding per scope and explicit priority rules. Tied routing candidates produce an inspectable ambiguous result, not arbitrary assignment. A missing candidate leaves the case available for manual handling. React already distinguishes winner, ambiguous, and no-candidate decisions. [2]

For deadlines, use the supported managed deadline/temporal facilities, with a test proving time advancement alone causes evaluation. **Do not rely on a materialized condition containing `now()` refreshing without data changes.** Preserve the original deadline unless an authorized policy replacement explicitly changes it. [2]

## 5. Implementation milestones

| Milestone | Deliverables | Exit evidence |
| --- | --- | --- |
| **R0 — Stack and contract qualification** | Align the selected pg-trickle build with React's managed runtime. Approve `MDM-STEWARDSHIP/1`, supported SQL types, authorization rules, and shared fixtures. | Packaged stack passes coordination, ownership, rollback, and upgrade tests. |
| **R1 — Read-only policy package** | Add MDM condition views, routing candidates, deadline configuration, and versioned policy declarations. Use existing validate/preview/compare surfaces. | Expected routes and deadlines are explained without writing MDM state or creating real external effects. |
| **R2 — Durable intent adapter** | Add typed consequences, stable request-key generation, receipt correlation, stale-work reconciliation, and domain-outcome handling. | Repeated execution produces one MDM control change; no private access or nested MDM refresh occurs. |
| **R3 — Deadline escalation** | Wire managed time evaluation and bounded escalation levels. Prevent feedback from receipts and audit fields. | An idle overdue case escalates once; restart and retry do not duplicate the escalation. |
| **R4 — Optional approval-policy integration** | After MDM M3 is qualified, propose approval requirements within MDM's administrator-set limits. Display MDM-owned approval outcomes. | React never records human votes or bypasses MDM authorization; unsupported capabilities fail closed. |
| **R5 — Joint rollout** | Run the shared failure suite, shadow comparison, narrowly scoped enablement, dashboards, and recovery exercises. | First-release routing/escalation scope is qualified; approval support remains independently opt-in. |

Suggested new locations: `integrations/pg-mdm/` for adapter contracts and SQL, `showcase/mdm-stewardship/` for a runnable example, and `tests/integrations/pg-mdm/` for cross-project tests. Keep MDM-specific logic out of the generic rule evaluator.

Execute R0 → R1 → R2 → R3 → R5 for the first release, corresponding to pg-react `0.46.0`–`0.50.0`. Run MDM M0 alongside R0, require M1 to close R0/R1, and require M2 to qualify R2/R3. Run MDM M4 with R5. R4 remains independently gated on MDM M3 and maps to `0.51.0`. The [roadmap handoff table](../ROADMAP.md#3-approach-qualify-first-deliver-a-narrow-vertical-slice) assigns owners; each version plan retains its acceptance cases and effort budget.

## 6. Execution and retry semantics

R0 uses `contracts/MDM-STEWARDSHIP-1.json` and
`contracts/MDM-STEWARDSHIP-1-fixture.json`. Their approved SHA-256 digests
are `2161ce22b9d924ff3f3e6d8acde62fed01b6b1c1c4d7ba0fd4d5eb6e396e0fcf` and
`900f365533bab13480fcb88ab8e8b7956beb4f14a8cfc92cd46770b2e26ef3e4`.
The request-key and policy-digest vector hashes are
`3ebd5539467befabbc0492e51e49fe2dc866a225cc73a36256d0a95a06b06d4e` and
`741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614`.
Both repositories' conformance tests passed on 2026-09-13.

Execute a local MDM intent call, record its receipt reference, and finish the corresponding React database work in one PostgreSQL transaction. Do not invoke `mdm.refresh()` from a consequence; MDM refresh runs independently after committed control changes. Database consequences already use transactional execution in pg-react. [1][2]

Derive a request key from a canonical, versioned encoding of:

```text
binding ID + policy revision + case occurrence + lifecycle generation
+ action-driving revision + consequence identity + escalation level
```

For `MDM-STEWARDSHIP/1`, React derives the 32-byte key by SHA-256 hashing two
unsigned-32-bit-big-endian-length-framed parts: the UTF-8 domain tag
`pg_react/mdm-stewardship-request-key/v1`, then the UTF-8 compact canonical
JSON object with sorted keys and `canonical_encoding_version: 1`. Its fields
are `binding_id` (canonical lowercase UUID text), `policy_revision`,
`case_key`, `lifecycle_generation`, `action_revision`, `consequence_identity`,
and `escalation_level`. The shared fixture pins the exact input bytes and
expected digest. Retries persist and reuse the same key and request body.
The exact vector is `request_key_vector` in the frozen shared fixture.
React computes the policy digest with `pg_react/mdm-stewardship-policy/v1`
over canonical JSON v1 containing the policy revision and complete normalized
policy package; MDM compares the 32-byte value with the active binding digest.
MDM captures the authenticated effective database role as the receipt actor;
React does not pass or choose that actor.

Persist that key and the complete request body with the work. Every retry uses the same values. Distinct intended actions need distinct keys; audit timestamps and unrelated publication changes must not manufacture new requests.

| Result | React behavior |
| --- | --- |
| `APPLIED_CONTROL` | Record successful control delivery; do not claim the identity case is resolved. |
| `ACCEPTED_PENDING_PUBLICATION` | For later decision support, show MDM acceptance separately from final publication. |
| `APPLIED_PUBLICATION` | Surface the MDM publication reference; React does not infer this from enqueue success. |
| Stale or superseded request | Record a terminal domain outcome and explicitly reevaluate current case facts; do not retry the stale payload forever. |
| Denied, invalid, or idempotency-conflict request | Stop that work, expose the reason, and require correction. |
| Transient database failure or uncertain commit | Use existing bounded retries with the same request key. |

Keep command completion distinct from business resolution. No external exactly-once guarantee is introduced. A later optional Tide adapter may deliver notifications, but network retries belong to that transport integration, not this MDM adapter. [1]

## 7. Prevent loops and unsafe policy changes

Watch only action-relevant columns. Exclude receipt timestamps, worker heartbeats, and audit-only updates; do not trigger new work solely because a publication boundary advanced. After a stale result, reevaluate using fresh MDM tokens. A changed request body creates a new work item and request key; never rewrite an attempted request or reuse its key for different arguments.

Version policy packages and preview replacements before deployment. Activate the matching MDM automation-binding policy digest in the same local deployment transaction where supported; otherwise keep the binding disabled until both sides are consistent. Withdraw or hold incompatible queued work. Execution must recheck the active binding so an old policy cannot act after replacement.

A pause prevents new intents. It does not reverse accepted MDM directives or published identities. Reversal is an explicit MDM action with its own authorization and audit.

## 8. Acceptance and rollout

Test duplicate execution, concurrent human edits, source/evidence changes, recurring reviews, ambiguous routing, time-only expiry, stale policy work, MDM publication failure, disabled bindings, missing capabilities, privileges, restore, and clone isolation.

First add one runnable end-to-end example: publish an ambiguous case, propose and apply its queue and due date, advance managed time without business writes, escalate once, accept a human decision, then independently refresh MDM to close the review. Assert exact policy rows, request bytes, receipts, React work outcomes, and final published review state. Reuse the same fixtures in both projects' release checks; a count-only assertion cannot prove that the intended case or action was processed.

Start with side-effect-free comparisons and representative cases. A bounded or `partial` comparison is not proof of complete population safety; partition a fixed test population into supported bounded comparisons or use an isolated qualification database. Preserve pg-react's documented comparison limits. [1][2]

Enable only routing and escalation for a small named cohort after tests pass. Monitor stale-intent rate, denied requests, overdue-case age, work backlog, repeated escalation attempts, and accepted-but-unpublished decisions. Retain public policy/work references needed to join MDM receipts throughout the shared audit horizon.

**First-release success:** a case is routed and escalated safely, human stewardship remains authoritative, and retries, pauses, or restarts cannot silently change identity or duplicate an intended control action.

## Sources reviewed

[1] [pg-react README](../README.md).

[2] [pg-react concepts](../docs/concepts.md).

[3] [pg-react support matrix](../docs/support-matrix.md) and [R0 implementation plan](v0.46.0.md).

[4] [MDM companion plan](PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md) and [pg-mdm 0.11.0 source evidence](../docs/planning/EVIDENCE.md#s9-pg-mdm-0110-foundation-and-missing-contract).

[5] [pg-trickle 0.108.0 source evidence](../docs/planning/EVIDENCE.md#s10-pg-trickle-01080-release).

[6] [MDM ownership and approval safeguards](PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md#6-approval-and-automation-safeguards).

[grove]

Planning handoff binding sources, part 2 of 2.

For work/v0-49-0-managed-deadlines-and-bounded-escalation.md v1, SHA-256 f7c251c4b049f4ec07bed93733bfe19f4d5d59bbf1ca63593b1d3c5d31ba701b. These are exact recoverable input copies, not approval. Preserve the paths and UTF-8 bytes inside each fence.

Path: plans/PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md
SHA-256: fab1cdaa93e809bc0a75c58e1bd07f45c9a9093cd741491683b5f15a0a8403c0

# pg-mdm: policy-assisted stewardship implementation plan

**Status:** Post-0.11 implementation plan; proposed stewardship APIs remain unimplemented\
**Updated:** 12 September 2026\
**Dependency target:** pg-mdm `0.11.0` plus the work below, pg-trickle `0.108.0`, and the pg-react `0.46.0`–`0.50.0` sequence\
**Repository:** `trickle-labs/pg-mdm`\
**Companion:** [pg-react implementation plan](PLAN_PG_REACT_MDM_STEWARDSHIP.md)  
**Proposed shared contract:** `MDM-STEWARDSHIP/1`

## 1. Goal and ownership

Let pg-react recommend where an identity-review case should go, when it should be escalated, and later which approval policy applies. pg-mdm remains the authority for review state, human approvals, permitted decisions, and identity changes.

pg-mdm `0.11.0` implements review publication, durable pair `MATCH` and `NOT_MATCH` decisions, anchored golden overrides, and transactional graph refresh. Reuse those implementations. Assignment, deadlines, escalation controls, automation bindings, policy receipts, and approval proposals remain new work. This optional integration extends the released core without making pg-react a core dependency. [1][2][3]

```text
MDM publishes a review case
    -> React evaluates a policy
    -> React submits a bounded intent through an MDM API
    -> MDM validates and records the permitted control change
    -> A later MDM refresh publishes any resulting identity change
```

There is no synchronous MDM -> React -> MDM refresh cycle. Human decisions remain possible without pg-react.

## 2. Entry gate

Start joint stack qualification now. Released pg-trickle `0.108.0` advertises stable, enabled `external_graph_refresh` major 1, minor 2 and `output_delta_consumer` major 1, minor 1. Replace the old wait for the planned `0.97` freeze with a check of this release's artifact and assurance evidence. Pass the MDM graph, rollback, recovery, and clone-isolation cases before dependent integration implementation. [5]

MDM `0.11.0` pins pg-trickle `0.105.1`. Qualify `0.108.0` using the existing MDM E2E, upgrade, restore, security, and package checks. Keep full-entity resolution and the forced FULL candidate-pair nodes in `src/graph_spec.rs`; `0.108.0` has no engine changes that establish a fix for the multi-row pair-insert problem. Delta V1.1 remains unused. [4][5]

Qualify pg-react against the same packaged stack in R0. Its released `0.45.0` runtime accepts pg-trickle `0.98.0` with disabled Graph/Delta capabilities, so both admission logic and packaging need changes. Use trigger CDC, scheduler off, `READ COMMITTED`, and separate MDM-owned EXTERNAL graphs as the initial joint profile. These are joint restrictions, not all of pg-trickle's capabilities. [6]

Keep M0–M4 as proposed post-0.11 MDM work packages. The MDM roadmap has no assigned later release numbers. Assign an MDM implementation owner and estimate these packages separately from the React release budgets before setting joint dates.

## 3. First release scope

Ship **queue assignment, due dates, escalation state, and audit receipts**. Use one administrative scope in one PostgreSQL database. Keep sensitive identity evidence behind MDM permissions; policy inputs expose only approved metadata.

Defer multi-person approvals to the next optional milestone. Defer automatic `MATCH` / `NOT_MATCH`, direct merge/split commands, bulk actions, cross-database delivery, and a reviewer UI. Existing MDM matching rules continue to make their normal automatic decisions.

## 4. Shared interface: `MDM-STEWARDSHIP/1`

This section is the proposed normative interface for both plans. Names below are **new proposed names**, not existing SQL functions. Freeze exact PostgreSQL types and signatures in the contract milestone.

Build on the released public data without treating it as the finished policy contract:

| Released foundation | Required addition |
| --- | --- |
| `mdm_out.<entity>_review` after first publication | Project `review_id uuid`, `issue_key bytea`, `occurrence integer`, status, reason, masked metadata, and `concurrency_version bigint` into an MDM-owned policy table. Add queue, due date, escalation, permissions, and basis fields. |
| Review recurrence creates a new UUID and occurrence | Allocate a persistent bigint `case_key` for each occurrence. Retain closed mappings for replay and restore. |
| `mdm.describe(entity_name text, format text)` | Map definition versions, decision epoch, publication revision, and `pending_stewardship` to documented contract fields. Add a policy-specific evidence digest and action-driving revision. |
| `mdm_steward.decide(...)` and golden-override APIs | Preserve these as human stewardship operations. They have optimistic versions but no policy request-key protocol; do not use them as an automated intent adapter. |

MDM's `pending_stewardship` uses the latest successful publication observation, including no-change observations. Do not infer pending state solely from an unchanged publication revision. Freeze the mapping between review `concurrency_version`, decision epoch, definition versions, and proposed intent tokens in M0. [1][2]

| Proposed surface | Contract |
| --- | --- |
| `mdm_steward.policy_cases_v1` | Permission-controlled, logged policy-input table. MDM alone maintains it. Expose a unique, non-null `case_key bigint`, the original `review_id`, immutable occurrence `opened_at timestamptz`, entity, reason, open/resolved state, permitted actions, queue, due date, escalation level, and concurrency/basis tokens. |
| `mdm_steward.submit_policy_intent(...)` | Typed, allowlisted command API. Initial actions are `ASSIGN_QUEUE`, `SET_DUE_AT`, and `ESCALATE`. No arbitrary SQL, private-table writes, or identity mutations. |
| `mdm_steward.policy_receipts_v1` | Authorized results keyed by binding and request key; record action, outcome, reason, policy provenance, actor, and any resulting publication revision. |

**Identity and freshness.** Allocate `case_key` once per review occurrence, retain its mapping, and never reuse it. Do not hash an opaque review ID into a bigint. The MDM V1 design gives recurring issues new review occurrences; the integration must preserve that distinction. [2]

Record `opened_at` when a new occurrence is first published. Retain it through later publications and restore; recurrence gets its own timestamp. Released review rows have revision numbers but no creation timestamp. M0 must define an auditable backfill for existing occurrences from retained publication evidence. If that evidence is unavailable, expose an unknown timestamp and withhold automatic deadline assignment until an authorized backfill supplies it. Never use adapter installation or retry time as the case opening time.

Each intent carries `binding_id`, `request_key`, `case_key`, typed action arguments, expected review version, definition version, publication revision, stewardship epoch, evidence-basis digest, and policy/evaluation/work references. The basis includes relevant subject membership and evidence. Relevant changes invalidate an unexecuted proposal. The first implementation may reject conservatively when the wider boundary changes.

**Authorization and concurrency.** Authenticate the caller, then check for an existing request. For a new request, lock and validate the case and automation binding in the same transaction as the control update. Check allowed actions, queue membership, deadline limits, manual assignment locks, and the binding's currently authorized policy digest. Conflicting requirements fail closed; an automated request cannot weaken an administrator's minimum review requirements.

**Idempotency.** Enforce uniqueness on `(binding_id, request_key)`. An identical authorized retry returns the existing receipt without repeating the action. Reuse with different arguments returns `IDEMPOTENCY_CONFLICT`. Preserve request identity across retries and ambiguous connection outcomes.

**Publication.** Evidence fields in the policy table change only with a successful MDM publication; administrative fields change with their control transaction. `APPLIED_CONTROL` means a routing or deadline update committed. Later identity-decision support must distinguish `ACCEPTED_PENDING_PUBLICATION` from `APPLIED_PUBLICATION`; only the latter records a successful resulting MDM publication. Resolving identity is never inferred from an intent receipt alone. This preserves the design's separation between accepted stewardship input and published semantic state. [2][3]

## 5. Implementation milestones

| Milestone | Deliverables | Exit evidence |
| --- | --- | --- |
| **M0: contract and scope** | MDM contract owner and React adapter owner freeze the shared SQL contract, roles, tokens, state transitions, errors, and exact fixtures. Qualify the target dependencies with R0. | Both projects approve one contract revision; M1 can implement without guessing types or authority. |
| **M1: review projection** | MDM implementation owner adds the logged policy table, retained occurrence-key mapping, masked fields, and publication-atomic updates. | Exact public rows and rollback state pass on real MDM; unlocks React R0 completion and R1 joint acceptance. |
| **M2: routing and escalation** | MDM implementation owner adds binding administration, three typed actions, receipts, manual locks, bounded deadlines/levels, and deduplication. May proceed alongside React R1 after M0/M1. | Full receipt and control-state assertions pass for duplicate, stale, unauthorized, paused, and replaced-binding calls; unlocks React R2/R3. |
| **M4: joint qualification** | Joint release owners run concurrency, restore, privilege, failure, upgrade, and end-to-end tests with React R5 at `0.50.0`. | The initial cohort passes all required cases before enablement; exact artifacts and recovery steps are recorded. |
| **M3: optional approval requirements** | MDM approval owner adds an exact-action proposal ledger, authenticated human approval API, requirement versions, and final validation. Schedule independently before React R4 at `0.51.0`. | Two required approvals mean two distinct authorized humans; self-approval, stale evidence, and requirement downgrades fail. |

Deliver M0 → M1 → M2 → M4 for the initial rollout. M3 retains its original identifier but follows its own approval gate. The released `mdm.preview()` validates or samples definitions; it does not implement M3 proposal approval.

## 6. Approval and automation safeguards

An approval covers a specific proposed action and its subjects and evidence. Capture human identity from authenticated database access or a separately trusted identity gateway. Never accept an actor string supplied by pg-react as proof of human identity. The React worker cannot supply human votes.

Reuse MDM's database-role binding checks and fixed-path privileged helpers. Its released APIs verify role names and OIDs and reject superuser/BYPASSRLS application sessions. Add a distinct automation binding and role that can submit allowed controls but cannot call human decision or override APIs. Prove this through React's actual worker execution identity, including `SET ROLE` and `SECURITY DEFINER` behavior. [1]

MDM checks approval requirements at acceptance and checks directive coherence again during publication. Changed evidence, membership, definitions, or requirements require a new review of the affected proposal. Rejecting a proposal is not the same as creating a durable `NOT_MATCH` constraint.

Automatic resolution requires a separate future capability and review. Do not implement the earlier illustrative “95% confidence” shortcut: V1 specifies evidence strengths and deterministic rules, not a calibrated probability contract. A machine policy must not acquire the manual `MATCH` operation's ability to override authoritative conflicts. Preserve cannot-link, lock, completeness, and component-integrity checks. [2]

## 7. Acceptance and recovery

| Scenario | Required result |
| --- | --- |
| Repeated request or retry after uncertain commit | One control change and one logical receipt. |
| Human changes the case while React work is queued | Stale work is rejected; manual intent is not overwritten. |
| Case closes, reopens, or changes definition | Old occurrence work cannot affect the new occurrence. |
| MDM refresh fails after a later identity decision is accepted | Previous publication stays intact; receipt remains pending, never falsely published. |
| Restore, clone, or policy replacement | New automated writes remain disabled until bindings, deduplication state, and case bases are reconciled. |
| Unauthorized or cross-scope access | No state mutation or disclosure of protected case details. |

Retain receipts, key mappings, and approval evidence for the documented replay/audit horizon. Out-of-horizon requests fail closed rather than being treated as new. A pause blocks new automated intents; accepted directives require explicit supersession to reverse them.

**First joint demonstration:** an ambiguous customer case is assigned, becomes overdue without further source edits, is escalated once, receives a human decision, and is closed only after a successful MDM publication.

Implement this demonstration in `showcase/mdm-stewardship/` with exact expected policy rows, immutable requests, receipt rows, work outcomes, and final review state. Reuse MDM's `scripts/build_e2e_image.sh`, `scripts/run_e2e_tests.sh`, `tests/e2e.sql`, `tests/restore.sql`, and upgrade/security checks. Include multi-row candidate inserts and AUTO/FULL equivalence before changing refresh safeguards. A release tag or expected-results manifest is not a passing test log.

## Sources reviewed

[1] pg-mdm `v0.11.0`, commit `97b78c8`: `README.md`, `sql/archive/pg_mdm--0.11.0.sql`, `src/api/steward.rs`, and `src/catalog.rs` in `../pg-mdm`. See the [release evidence register](../docs/planning/EVIDENCE.md#s9-pg-mdm-0110-foundation-and-missing-contract).

[2] pg-mdm `v0.11.0`: `src/output.rs`, `src/review.rs`, `src/api/describe.rs`, and `DESIGN_V1.md` in `../pg-mdm`.

[3] pg-mdm `v0.11.0`: `DESIGN_V2.md` section 12 describes future stewardship assignment and approval work.

[4] pg-mdm `v0.11.0`: `DEPENDENCIES.md`, `ROADMAP.md`, `plans/v0.11.md`, and `src/graph_spec.rs` in `../pg-mdm`.

[5] pg-trickle `v0.108.0`, commit `8bd0a4b5`: `docs/capability-manifest.json`, `CHANGELOG.md`, and release qualification manifest in `../pg-trickle1`. See the [release evidence register](../docs/planning/EVIDENCE.md#s10-pg-trickle-01080-release).

[6] [pg-react support matrix](../docs/support-matrix.md) and [R0 implementation plan](v0.46.0.md).

Path: contracts/MDM-STEWARDSHIP-1-v3.json
SHA-256: fd6f5e6ceb7c65fc93924c004a24f348e4296f2d83e83ce4e82cea6493e77efe

{
  "contract": "MDM-STEWARDSHIP/1",
  "revision": 3,
  "status": "approved",
  "revision_2_authorization": "Authorized by the requesting contract owner on 2026-09-23, who confirmed approval to amend the shared agreement. Personal approver names were not supplied.",
  "change_notes": [
    {
      "revision": 2,
      "affected": ["bindings"],
      "previous": "Revision 1 froze register, pause, and replace under the mdm_administrator path, one active binding per scope, and no per-binding queue or action limits.",
      "new": "Revision 2 freezes entity-scoped create, replace, and runtime-state APIs under the entity execution role; each binding carries canonical action and queue limits, due interval and escalation maximum, optimistic versions, and least-privilege automation role checks.",
      "authorization": "The requesting contract owner confirmed approval to change the shared contract in this session.",
      "compatibility": "Retire revision 1 binding-administration APIs. Preserve existing binding and receipt history; pause existing bindings until an operator replaces and explicitly activates a fully bounded revision 2 binding."
    },
    {
      "revision": 3,
      "affected": ["bindings"],
      "previous": "Revision 2 exposed allowed_queues as name[] on the entity-role create and replace APIs.",
      "new": "Revision 3 exposes allowed_queues as text[] on the Rust-facing create and replace APIs; values are validated and stored in the durable name[] column.",
      "authorization": "The requesting contract owner approved the proposed contract adjustment in this session on 2026-09-23.",
      "compatibility": "The v0.14 API is introduced in this release; use the revision 3 signatures in the extension SQL and callers."
    }
  ],
  "approvals": {
    "pg_mdm_owner": {
      "status": "approved",
      "role": "pg-mdm M0 contract owner",
      "approved_on": "2026-09-13"
    },
    "pg_react_owner": {
      "status": "approved",
      "role": "pg-react R0 adapter owner",
      "approved_on": "2026-09-13"
    }
  },
  "sql": {
    "relation": "mdm_steward.policy_cases_v1",
    "columns": [
      ["case_key", "bigint", "primary key, positive, generated, retained, never reused"],
      ["review_id", "uuid", "unique, not null"],
      ["entity_name", "name", "not null"],
      ["issue_key", "bytea", "not null, exactly 32 bytes"],
      ["occurrence", "integer", "not null, positive"],
      ["status", "text", "not null, open|resolved"],
      ["severity", "text", "not null"],
      ["reason_code", "text", "not null"],
      ["approved_metadata", "jsonb", "not null; v1 value is always {}"],
      ["permitted_actions", "text[]", "not null; sorted distinct subset of ASSIGN_QUEUE, SET_DUE_AT, ESCALATE"],
      ["assigned_queue", "name", "nullable"],
      ["due_at", "timestamptz", "nullable"],
      ["escalation_level", "integer", "not null, nonnegative"],
      ["manual_assignment_protected", "boolean", "not null"],
      ["opened_at", "timestamptz", "nullable"],
      ["opened_at_source", "text", "not null, publication|administrator|unknown"],
      ["resolved_at", "timestamptz", "nullable"],
      ["review_version", "bigint", "not null, positive"],
      ["definition_version", "bigint", "not null, positive"],
      ["publication_revision", "bigint", "not null, nonnegative"],
      ["stewardship_epoch", "bigint", "not null, nonnegative; equals the decision_epoch observed by the latest successful publication"],
      ["evidence_basis_digest", "bytea", "not null, exactly 32 bytes"],
      ["action_revision", "bigint", "not null, positive"],
      ["pending_stewardship", "boolean", "not null"],
      ["last_observed_at", "timestamptz", "not null"]
    ],
    "unique": [["entity_name", "issue_key", "occurrence"]],
    "foreign_key": ["review_id", "retained mdm_internal.reviews.review_id"],
    "reader_access": "No PUBLIC grants. React gets USAGE on mdm_steward and SELECT on the policy-case and receipt relations only. MDM owns all writes. The initial single-scope profile does not use RLS.",
    "opening_time": "opened_at is publications.published_at for reviews.opened_revision. If unavailable, opened_at is null and opened_at_source is unknown; automatic SET_DUE_AT is denied until audited administrator backfill. resolved_at comes from the publication that resolved the occurrence when available.",
    "case_key": "Allocate once per review_id from mdm_internal.policy_case_key_seq. Gaps after rollback are valid. Resolved occurrences and keys are retained; recurrence creates a new review_id and key.",
    "approved_metadata_allowlist": [],
    "permitted_actions": {
      "open": ["ASSIGN_QUEUE", "ESCALATE", "SET_DUE_AT"],
      "resolved": []
    },
    "receipts": {
      "relation": "mdm_steward.policy_receipts_v1",
      "columns": [
        ["receipt_id", "uuid", "primary key, generated by MDM"],
        ["binding_id", "uuid", "not null"],
        ["request_key", "bytea", "not null, exactly 32 bytes"],
        ["request_digest", "bytea", "not null, exactly 32 bytes; digest of canonical request body"],
        ["request_body", "jsonb", "not null; canonical JSON for every API input except request_key; actor is captured separately"],
        ["actor", "name", "not null; captured from current_user by the invoker-facing wrapper before it calls privileged helpers; caller cannot supply it"],
        ["case_key", "bigint", "not null"],
        ["action_revision", "bigint", "not null"],
        ["outcome", "text", "not null"],
        ["reason_code", "text", "nullable"],
        ["control", "jsonb", "nullable"],
        ["resulting_publication_revision", "bigint", "nullable"],
        ["created_at", "timestamptz", "not null"]
      ],
      "unique": [["binding_id", "request_key"]],
      "reader_access": "React receives SELECT only. No PUBLIC grant. MDM alone inserts or changes receipts.",
      "retention": "Retain request bodies and receipts without automatic deletion in v1 and include them in logical dump."
    },
    "bindings": {
      "relation": "mdm_steward.policy_bindings_v1",
      "columns": [
        ["binding_id", "uuid", "primary key, generated by MDM and never reused"],
        ["entity_id", "uuid", "not null; owning entity"],
        ["binding_version", "bigint", "not null, positive; each new binding starts at one"],
        ["automation_role_name", "name", "not null; bound pg-react worker role"],
        ["policy_digest", "bytea", "not null, exactly 32 bytes"],
        ["allowed_actions", "text[]", "not null; sorted distinct subset of ASSIGN_QUEUE, SET_DUE_AT, ESCALATE"],
        ["allowed_queues", "name[]", "not null; sorted, duplicate-free queue allowlist"],
        ["max_due_interval", "interval", "nullable; positive and required when SET_DUE_AT is allowed"],
        ["max_escalation_level", "integer", "not null, nonnegative; positive when ESCALATE is allowed"],
        ["replaced_by", "uuid", "nullable; new binding ID when replaced"],
        ["replaced_at", "timestamptz", "nullable; set with replaced_by"],
        ["created_at", "timestamptz", "not null"],
        ["created_by_name", "text", "not null"],
        ["created_as_role_name", "text", "not null"]
      ],
      "runtime_relation": {
        "relation": "mdm_internal.policy_binding_runtime",
        "columns": [
          ["binding_id", "uuid", "primary key referencing a durable binding"],
          ["database_oid", "oid", "not null; must match current database"],
          ["automation_role_oid", "oid", "not null; must match the stored role name at intent time"],
          ["state", "text", "not null, active|paused"],
          ["runtime_version", "bigint", "not null, positive; optimistic concurrency token"],
          ["changed_at", "timestamptz", "not null"]
        ],
        "logical_dump": "Do not dump runtime rows; restore begins disabled."
      },
      "invariants": [
        "At most one unreplaced binding exists per entity and automation role name.",
        "The automation role must be NOLOGIN, NOSUPERUSER, and NOBYPASSRLS, have no membership path to the helper or entity execution role, and retain the same stored name and OID at intent time.",
        "Action and queue arrays are canonical and duplicate-free. ASSIGN_QUEUE requires a nonempty queue allowlist; SET_DUE_AT requires a positive max_due_interval; ESCALATE requires a positive max_escalation_level.",
        "Replacement creates a fresh inactive binding and permanently marks the prior binding replaced with replaced_by and replaced_at. Old receipts remain attached to the old binding and are replayable only after caller authentication.",
        "Logical restore leaves runtime activation absent or disabled. A physical clone fails the database OID check. Explicit entity-execution-role reconciliation is required before new intents apply."
      ],
      "administrator_surface": {
        "create": "mdm_admin.create_policy_binding(entity_name text, automation_role_name text, policy_digest bytea, allowed_actions text[], allowed_queues text[], max_due_interval interval, max_escalation_level integer) returns (binding_id uuid, binding_version bigint). Validates queue strings and stores canonical values in allowed_queues name[]. Creates a binding and active runtime row at version one.",
        "replace": "mdm_admin.replace_policy_binding(binding_id uuid, expected_version bigint, policy_digest bytea, allowed_actions text[], allowed_queues text[], max_due_interval interval, max_escalation_level integer) returns (binding_id uuid, binding_version bigint). Validates queue strings and stores canonical values in allowed_queues name[]. Marks the old binding replaced and creates a fresh inactive binding.",
        "state": "mdm_admin.set_policy_binding_state(binding_id uuid, expected_runtime_version bigint, state text, reason text) returns runtime_version bigint. Supports activation, pause, and explicit database/role OID reconciliation.",
        "authorization": "Only the owning entity execution role may create, replace, activate, pause, or reconcile its bindings through fixed-path MDM helpers with optimistic version checks.",
        "react_access": "React has no direct SELECT or DML on this relation; the bound role may call submit_policy_intent only. No PUBLIC grants."
      },
      "legacy_transition": "Revision 1 binding-administration functions are revoked and retired. Existing bindings and receipts are retained; existing runtime is paused. An old binding can be replaced with fully bounded revision 2 settings and explicitly activated. Existing request keys and receipts are never transferred.",
      "submit_behavior": "Authenticate the caller against the binding's stored role name and current role OID before receipt lookup. An identical authorized prior request returns its original receipt after pause or replacement; a new request on a paused or replaced binding receives BINDING_PAUSED or BINDING_REPLACED with no control change."
    }
  },
  "freshness": {
    "intent_inputs": [
      "review_version",
      "definition_version",
      "publication_revision",
      "stewardship_epoch",
      "evidence_basis_digest",
      "action_revision",
      "policy_digest"
    ],
    "stewardship_epoch_meaning": "The decision_epoch associated with the latest successful observation. It may be older than the current entity decision_epoch; pending_stewardship is true in that case.",
    "review_version_meaning": "The exact concurrency_version of the mdm_out.<entity>_review row for this case's review_id.",
    "pending_stewardship_rule": "If pending_stewardship is true at intent validation, deny the control with terminal outcome PENDING_STEWARDSHIP and make no control change. It may proceed only after a successful observation clears pending_stewardship.",
    "evidence_basis_fields": [
      "entity_name",
      "issue_key",
      "occurrence",
      "status",
      "reason_code",
      "subjects",
      "approved_metadata",
      "definition_version",
      "artifact_digest",
      "source_boundary_digest",
      "observed_decision_epoch",
      "semantic_versions"
    ],
    "action_revision": "Increment only when evidence or an action control can change policy eligibility or result. Observation timestamps, receipt writes, and unrelated publication advances do not increment it."
  },
  "intent": {
    "signature": "mdm_steward.submit_policy_intent(binding_id uuid, request_key bytea, case_key bigint, action text, arguments jsonb, expected_review_version bigint, expected_definition_version bigint, expected_publication_revision bigint, expected_stewardship_epoch bigint, expected_evidence_basis_digest bytea, expected_action_revision bigint, expected_policy_digest bytea, policy_revision text, evaluation_ref text, work_ref text)",
    "actor_capture": "The invoker-facing SQL wrapper captures current_user at entry and passes it to fixed-path privileged helpers. The public signature has no actor parameter.",
    "returns": [
      ["receipt_id", "uuid, null only for IDEMPOTENCY_CONFLICT"],
      ["outcome", "text"],
      ["reason_code", "text"],
      ["case_key", "bigint"],
      ["action_revision", "bigint"],
      ["control", "jsonb"],
      ["resulting_publication_revision", "bigint"]
    ],
    "request_key": {
      "length_bytes": 32,
      "unique_with": "binding_id",
      "encoding": "React derives the key from the request_key_vector using canonical_encoding.version. case_key identifies one immutable review occurrence. lifecycle_generation starts at 1 and increases only when React starts a new work lifecycle for that case; retries keep it unchanged. escalation_level is the target level for ESCALATE and zero for other actions.",
      "inputs": [
        ["binding_id", "uuid, canonical lowercase hyphenated text"],
        ["policy_revision", "non-empty UTF-8 text, at most 256 bytes"],
        ["case_key", "positive bigint"],
        ["lifecycle_generation", "positive integer"],
        ["action_revision", "positive bigint from expected_action_revision"],
        ["consequence_identity", "non-empty UTF-8 text, at most 256 bytes"],
        ["escalation_level", "nonnegative integer; zero except for ESCALATE"]
      ]
    },
    "policy_digest": {
      "length_bytes": 32,
      "owner": "React computes the digest; MDM treats it as opaque and compares the exact bytes with the active binding's policy_digest.",
      "preimage": "The canonical JSON object contains canonical_encoding_version, policy_revision, and the complete normalized policy_package used to derive routing, deadline, and escalation intents. Deployment metadata, evaluation_ref, work_ref, runtime timestamps, and secrets are excluded.",
      "domain_tag": "pg_react/mdm-stewardship-policy/v1",
      "vector": "canonical_encoding.policy_vector"
    },
    "references": "policy_revision, evaluation_ref, work_ref are non-empty text, each at most 256 UTF-8 bytes.",
    "arguments": {
      "ASSIGN_QUEUE": {"queue": "name"},
      "SET_DUE_AT": {"due_at": "PostgreSQL timestamptz input text"},
      "ESCALATE": {"level": "positive integer"}
    },
    "argument_keys": "Each action accepts exactly its listed keys; extra keys, null values, and wrong JSON types are rejected.",
    "outcomes": [
      "APPLIED_CONTROL",
      "NO_CHANGE",
      "STALE_CASE",
      "CASE_CLOSED",
      "ACTION_DENIED",
      "MANUAL_PROTECTION",
      "OPENED_AT_UNKNOWN",
      "LIMIT_EXCEEDED",
      "BINDING_PAUSED",
      "BINDING_REPLACED",
      "POLICY_MISMATCH",
      "PENDING_STEWARDSHIP",
      "IDEMPOTENCY_CONFLICT"
    ],
    "idempotency": {
      "authorization": "Authenticate and validate the binding before looking up a receipt.",
      "same_body": "For the same binding_id, request_key, and canonical request digest, return the original receipt without repeating the control change.",
      "changed_body": {
        "receipt_id": null,
        "outcome": "IDEMPOTENCY_CONFLICT",
        "reason_code": "REQUEST_KEY_BODY_MISMATCH",
        "insert_conflict_receipt": false,
        "existing_receipt": "unchanged"
      },
      "concurrent_insert": "After a unique-key conflict, read the existing receipt and compare request digests. Return that receipt for an equal body or the changed_body response for a different body. Never replace the existing row or retry with a new key."
    },
    "publication": "Every v1 intent has resulting_publication_revision null. Accepted control changes do not resolve identity or publish MDM output.",
    "authority": "The bound automation role may submit only the three typed actions. It cannot decide, override golden values, refresh, rebuild, merge, split, or approve.",
    "receipts": "Create one immutable receipt for each first authorized request, including terminal validation outcomes. Replays return that receipt. IDEMPOTENCY_CONFLICT is returned without a receipt row."
  },
  "canonical_encoding": {
    "version": 1,
    "json": "UTF-8 compact JSON; object keys sorted by UTF-8 byte order; array order preserved; strings use RFC 8259 escaping; numbers are base-10 integers without leading zeroes; floating point values are forbidden.",
    "digest": "SHA-256 over each part framed by an unsigned 32-bit big-endian byte length. First part is the UTF-8 domain tag, second part is the canonical JSON bytes.",
    "intent_request_body": "Contains every submit_policy_intent input except request_key. The request_key is the idempotency lookup key and is not included in the body digest.",
    "basis_domain_tag": "pg_mdm/policy-case-basis/v1",
    "intent_domain_tag": "pg_mdm/policy-intent/v1",
    "request_key_domain_tag": "pg_react/mdm-stewardship-request-key/v1",
    "policy_domain_tag": "pg_react/mdm-stewardship-policy/v1",
    "policy_vector": {
      "body": {
        "canonical_encoding_version": 1,
        "policy_package": {
          "routes": [
            {"queue": "priority", "reason_code": "POSSIBLE_DUPLICATE"}
          ]
        },
        "policy_revision": "policy-1"
      },
      "canonical_json_utf8": "{\"canonical_encoding_version\":1,\"policy_package\":{\"routes\":[{\"queue\":\"priority\",\"reason_code\":\"POSSIBLE_DUPLICATE\"}]},\"policy_revision\":\"policy-1\"}",
      "sha256": "741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614"
    },
    "basis_vector": {
      "body": {
        "approved_metadata": {},
        "artifact_digest": "3333333333333333333333333333333333333333333333333333333333333333",
        "canonical_encoding_version": 1,
        "definition_version": 3,
        "entity_name": "customer",
        "issue_key": "1111111111111111111111111111111111111111111111111111111111111111",
        "observed_decision_epoch": 8,
        "occurrence": 1,
        "reason_code": "POSSIBLE_DUPLICATE",
        "semantic_versions": {"candidate": 1, "clustering": 1, "normalization": 1},
        "source_boundary_digest": "2222222222222222222222222222222222222222222222222222222222222222",
        "status": "open",
        "subjects": [
          {"id": "40000000-0000-4000-8000-000000000001", "kind": "source_record"},
          {"id": "40000000-0000-4000-8000-000000000002", "kind": "source_record"}
        ]
      },
      "canonical_json_utf8": "{\"approved_metadata\":{},\"artifact_digest\":\"3333333333333333333333333333333333333333333333333333333333333333\",\"canonical_encoding_version\":1,\"definition_version\":3,\"entity_name\":\"customer\",\"issue_key\":\"1111111111111111111111111111111111111111111111111111111111111111\",\"observed_decision_epoch\":8,\"occurrence\":1,\"reason_code\":\"POSSIBLE_DUPLICATE\",\"semantic_versions\":{\"candidate\":1,\"clustering\":1,\"normalization\":1},\"source_boundary_digest\":\"2222222222222222222222222222222222222222222222222222222222222222\",\"status\":\"open\",\"subjects\":[{\"id\":\"40000000-0000-4000-8000-000000000001\",\"kind\":\"source_record\"},{\"id\":\"40000000-0000-4000-8000-000000000002\",\"kind\":\"source_record\"}]}",
      "sha256": "2b73c392653f05c5706f315fb0ec635037a342acd5ff2df374e0edcf7836280e"
    },
    "intent_vector": {
      "body": {
        "action": "ASSIGN_QUEUE",
        "arguments": {"queue": "priority"},
        "binding_id": "30000000-0000-4000-8000-000000000001",
        "case_key": 7,
        "expected_action_revision": 2,
        "expected_definition_version": 3,
        "expected_evidence_basis_digest": "abababababababababababababababababababababababababababababababab",
        "expected_policy_digest": "741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614",
        "expected_publication_revision": 5,
        "expected_review_version": 4,
        "expected_stewardship_epoch": 8,
        "evaluation_ref": "eval-1",
        "policy_revision": "policy-1",
        "work_ref": "work-1"
      },
      "request_key": "3ebd5539467befabbc0492e51e49fe2dc866a225cc73a36256d0a95a06b06d4e",
      "canonical_json_utf8": "{\"action\":\"ASSIGN_QUEUE\",\"arguments\":{\"queue\":\"priority\"},\"binding_id\":\"30000000-0000-4000-8000-000000000001\",\"case_key\":7,\"evaluation_ref\":\"eval-1\",\"expected_action_revision\":2,\"expected_definition_version\":3,\"expected_evidence_basis_digest\":\"abababababababababababababababababababababababababababababababab\",\"expected_policy_digest\":\"741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614\",\"expected_publication_revision\":5,\"expected_review_version\":4,\"expected_stewardship_epoch\":8,\"policy_revision\":\"policy-1\",\"work_ref\":\"work-1\"}",
      "sha256": "5d1c1af60b706e1e2e6b45b784836793f51fe38144caac815830d02fefa82f99"
    },
    "request_key_vector": {
      "body": {
        "action_revision": 2,
        "binding_id": "30000000-0000-4000-8000-000000000001",
        "canonical_encoding_version": 1,
        "case_key": 7,
        "consequence_identity": "assign_priority",
        "escalation_level": 0,
        "lifecycle_generation": 1,
        "policy_revision": "policy-1"
      },
      "canonical_json_utf8": "{\"action_revision\":2,\"binding_id\":\"30000000-0000-4000-8000-000000000001\",\"canonical_encoding_version\":1,\"case_key\":7,\"consequence_identity\":\"assign_priority\",\"escalation_level\":0,\"lifecycle_generation\":1,\"policy_revision\":\"policy-1\"}",
      "sha256": "3ebd5539467befabbc0492e51e49fe2dc866a225cc73a36256d0a95a06b06d4e"
    }
  },
  "conformance_fixture": {
    "file": "MDM-STEWARDSHIP-1-fixture.json",
    "sha256": "900f365533bab13480fcb88ab8e8b7956beb4f14a8cfc92cd46770b2e26ef3e4"
  },
  "shared_conformance_cases": [
    "React derives the same request key when it retries the same persisted work.",
    "The same binding, request key, and body return the original immutable receipt.",
    "A changed body with the same binding and request key returns IDEMPOTENCY_CONFLICT with a null receipt_id; it leaves the stored receipt unchanged and creates no row.",
    "Concurrent submissions with the same key return the original receipt for an equal body and the conflict response for a different body.",
    "The receipt actor is the authenticated effective database role captured by MDM; the caller cannot provide it.",
    "Stale review, definition, publication basis, stewardship epoch, evidence digest, action revision, or policy digest cannot apply a control.",
    "A newer unrelated publication does not stale an unchanged case basis.",
    "Manual assignment protection denies automatic queue replacement.",
    "Unknown opening time denies SET_DUE_AT.",
    "Pause, binding replacement, and policy mismatch create the specified terminal outcome.",
    "Receipt and control change commit atomically or both roll back.",
    "Resolved occurrences remain readable and recurrence gets a new case key.",
    "Restore preserves case keys, request bodies, and receipts.",
    "A case with pending_stewardship cannot receive control until a successful observation clears it.",
    "Only the entity execution role can create, replace, activate, pause, or reconcile bindings; automation role mismatch and replaced bindings fail closed."
  ]
}

Path: contracts/MDM-STEWARDSHIP-1-fixture.json
SHA-256: 900f365533bab13480fcb88ab8e8b7956beb4f14a8cfc92cd46770b2e26ef3e4

{
  "contract": "MDM-STEWARDSHIP/1",
  "revision": 1,
  "policy_vector": {
    "body": {
      "canonical_encoding_version": 1,
      "policy_package": {
        "routes": [
          {"queue": "priority", "reason_code": "POSSIBLE_DUPLICATE"}
        ]
      },
      "policy_revision": "policy-1"
    },
    "canonical_json_utf8": "{\"canonical_encoding_version\":1,\"policy_package\":{\"routes\":[{\"queue\":\"priority\",\"reason_code\":\"POSSIBLE_DUPLICATE\"}]},\"policy_revision\":\"policy-1\"}",
    "sha256": "741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614"
  },
  "basis_vector": {
    "body": {
      "approved_metadata": {},
      "artifact_digest": "3333333333333333333333333333333333333333333333333333333333333333",
      "canonical_encoding_version": 1,
      "definition_version": 3,
      "entity_name": "customer",
      "issue_key": "1111111111111111111111111111111111111111111111111111111111111111",
      "observed_decision_epoch": 8,
      "occurrence": 1,
      "reason_code": "POSSIBLE_DUPLICATE",
      "semantic_versions": {"candidate": 1, "clustering": 1, "normalization": 1},
      "source_boundary_digest": "2222222222222222222222222222222222222222222222222222222222222222",
      "status": "open",
      "subjects": [
        {"id": "40000000-0000-4000-8000-000000000001", "kind": "source_record"},
        {"id": "40000000-0000-4000-8000-000000000002", "kind": "source_record"}
      ]
    },
    "canonical_json_utf8": "{\"approved_metadata\":{},\"artifact_digest\":\"3333333333333333333333333333333333333333333333333333333333333333\",\"canonical_encoding_version\":1,\"definition_version\":3,\"entity_name\":\"customer\",\"issue_key\":\"1111111111111111111111111111111111111111111111111111111111111111\",\"observed_decision_epoch\":8,\"occurrence\":1,\"reason_code\":\"POSSIBLE_DUPLICATE\",\"semantic_versions\":{\"candidate\":1,\"clustering\":1,\"normalization\":1},\"source_boundary_digest\":\"2222222222222222222222222222222222222222222222222222222222222222\",\"status\":\"open\",\"subjects\":[{\"id\":\"40000000-0000-4000-8000-000000000001\",\"kind\":\"source_record\"},{\"id\":\"40000000-0000-4000-8000-000000000002\",\"kind\":\"source_record\"}]}",
    "sha256": "2b73c392653f05c5706f315fb0ec635037a342acd5ff2df374e0edcf7836280e"
  },
  "intent_vector": {
    "body": {
      "action": "ASSIGN_QUEUE",
      "arguments": {"queue": "priority"},
      "binding_id": "30000000-0000-4000-8000-000000000001",
      "case_key": 7,
      "expected_action_revision": 2,
      "expected_definition_version": 3,
      "expected_evidence_basis_digest": "abababababababababababababababababababababababababababababababab",
      "expected_policy_digest": "741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614",
      "expected_publication_revision": 5,
      "expected_review_version": 4,
      "expected_stewardship_epoch": 8,
      "evaluation_ref": "eval-1",
      "policy_revision": "policy-1",
      "work_ref": "work-1"
    },
    "request_key": "3ebd5539467befabbc0492e51e49fe2dc866a225cc73a36256d0a95a06b06d4e",
    "canonical_json_utf8": "{\"action\":\"ASSIGN_QUEUE\",\"arguments\":{\"queue\":\"priority\"},\"binding_id\":\"30000000-0000-4000-8000-000000000001\",\"case_key\":7,\"evaluation_ref\":\"eval-1\",\"expected_action_revision\":2,\"expected_definition_version\":3,\"expected_evidence_basis_digest\":\"abababababababababababababababababababababababababababababababab\",\"expected_policy_digest\":\"741ea9560a69ba3185eaa34760ba38d473aa43daa8e8c530c6c6c2ce867c2614\",\"expected_publication_revision\":5,\"expected_review_version\":4,\"expected_stewardship_epoch\":8,\"policy_revision\":\"policy-1\",\"work_ref\":\"work-1\"}",
    "sha256": "5d1c1af60b706e1e2e6b45b784836793f51fe38144caac815830d02fefa82f99"
  },
  "request_key_vector": {
    "body": {
      "action_revision": 2,
      "binding_id": "30000000-0000-4000-8000-000000000001",
      "canonical_encoding_version": 1,
      "case_key": 7,
      "consequence_identity": "assign_priority",
      "escalation_level": 0,
      "lifecycle_generation": 1,
      "policy_revision": "policy-1"
    },
    "canonical_json_utf8": "{\"action_revision\":2,\"binding_id\":\"30000000-0000-4000-8000-000000000001\",\"canonical_encoding_version\":1,\"case_key\":7,\"consequence_identity\":\"assign_priority\",\"escalation_level\":0,\"lifecycle_generation\":1,\"policy_revision\":\"policy-1\"}",
    "sha256": "3ebd5539467befabbc0492e51e49fe2dc866a225cc73a36256d0a95a06b06d4e"
  },
  "shared_conformance_cases": [
    "React derives the same request key when it retries the same persisted work.",
    "The same binding, request key, and body return the original immutable receipt.",
    "A changed body with the same binding and request key returns IDEMPOTENCY_CONFLICT with a null receipt_id; it leaves the stored receipt unchanged and creates no row.",
    "Concurrent submissions with the same key return the original receipt for an equal body and the conflict response for a different body.",
    "The receipt actor is the authenticated effective database role captured by MDM; the caller cannot provide it.",
    "Stale review, definition, publication basis, stewardship epoch, evidence digest, action revision, or policy digest cannot apply a control.",
    "A newer unrelated publication does not stale an unchanged case basis.",
    "Manual assignment protection denies automatic queue replacement.",
    "Unknown opening time denies SET_DUE_AT.",
    "Pause, binding replacement, and policy mismatch create the specified terminal outcome.",
    "Receipt and control change commit atomically or both roll back.",
    "Resolved occurrences remain readable and recurrence gets a new case key.",
    "Restore preserves case keys, request bodies, and receipts.",
    "A case with pending_stewardship cannot receive control until a successful observation clears it.",
    "Only the MDM administrator can register, pause, or replace bindings; role mismatch and replaced bindings fail closed."
  ]
}

[grove]

Proposed acceptance contract for issue #8. Approval pending; no implementation is authorized.

Path: work/v0-49-0-managed-deadlines-and-bounded-escalation.md
Contract revision: v1
SHA-256: f7c251c4b049f4ec07bed93733bfe19f4d5d59bbf1ca63593b1d3c5d31ba701b

Exact binding inputs are recoverable from the two accompanying planning-source comments for this contract hash. Their complete comment-body hashes are:

• Part 1: SHA-256 0a0c99134b64104abbb6877096d8d2a137b99cf748fb6f97a654f9c90e271d8e
• Part 2: SHA-256 7da1d20c01da0c7d45e92227cb75aa82dc1aa0b088f2687b715b7bfee764d4e3

Binding input manifest:

• specs/v0.49.0-issue-8.md: SHA-256 59c3f3e846d425ca119d7bf33576848f2b452a77fff1da53ee2659bf8a5929c6
• plans/v0.49.0.md: SHA-256 cc9b0345c80e10cecaf997b190e47d8a9173c768fc51cedcd270d69101866e9a
• docs/planning/RELEASE-GATES.md: SHA-256 70a14db53e0fa7575fbc4bf6b2c9c785be41e62caadf6e6663f9c8408fcb5d53
• plans/PLAN_PG_REACT_MDM_STEWARDSHIP.md: SHA-256 130a07066ba77fede81b580a8d110d2406e26e070cc1c6b9c77da8f4baf45d2e
• plans/PLAN_PG_MDM_STEWARDSHIP_INTEGRATION.md: SHA-256 fab1cdaa93e809bc0a75c58e1bd07f45c9a9093cd741491683b5f15a0a8403c0
• contracts/MDM-STEWARDSHIP-1-v3.json: SHA-256 fd6f5e6ceb7c65fc93924c004a24f348e4296f2d83e83ce4e82cea6493e77efe
• contracts/MDM-STEWARDSHIP-1-fixture.json: SHA-256 900f365533bab13480fcb88ab8e8b7956beb4f14a8cfc92cd46770b2e26ef3e4

# Acceptance contract: issue #8, managed deadlines and bounded escalation

Contract revision: v1
Source: [Issue snapshot](../specs/v0.49.0-issue-8.md)
Source attribution: https://github.com/trickle-labs/pg-react/issues/8, updated 2026-09-26T22:37:38Z, retrieved 2026-09-27; authoritative plan commit 843256fb465de69f172fb61e66c5f76d981f0670 and SHA-256 cc9b0345c80e10cecaf997b190e47d8a9173c768fc51cedcd270d69101866e9a.
Parent: None
Prerequisites: The v0.48.0 transaction, deduplication, binding and stale-work gates on the selected joint artifact; real MDM M2 ESCALATE and agreed exact receipt fixtures; W49.1 temporal audit and owner decisions Q1-Q4 before dependent implementation.

Intended outcome: An idle overdue review case receives permitted escalation within the qualified operating bounds, at most once per configured level in its MDM occurrence. Existing deadlines and human authority survive retries, feedback, restart and coherent restore.

Advisory learnings: None. No docs/retrospective-learnings.md register exists in the inspected checkout.

This is an unapproved initial proposal. It plans acceptance and establishes no candidate verdict. Source abbreviations below refer to plans/v0.49.0.md sections and T49 cases; C01-C12 and "gates" refer to docs/planning/RELEASE-GATES.md. S0 React and S0 MDM refer to the two linked stewardship plans. The imported issue reconciles all seven scope bullets into these rows. No existing acceptance IDs, checked criteria, parent contract, decomposition, comments or amendments were found.

## Acceptance matrix

| ID | Source | Requirement | Boundaries / counterexamples | Seam | Oracle | Planned evidence | Plan state |
|---|---|---|---|---|---|---|---|
| R1 | §§2,3.1; W49.1 | Map the installed public temporal registration, execution, ownership, granularity and recovery contract before dependent implementation. | Missing time-only mechanism stops W49.2+ for re-estimation. | pgreact_api.author_deadline_rule / author_temporal_rule; run; managed_cycle | Installed SQL signatures and documented deadline semantics | W49.1 API-map record plus planned idle test R2; inspect installed signatures against registration and recovery calls. | planned |
| R2 | T49.01; §§3.1,3.2 | An open idle case crossing its due time is evaluated and receives a permitted control within frozen detection and dispatch bounds. | No business-table writes or manual refresh to induce expiry; wakeup alone is insufficient. | Ordinary managed worker through MDM public receipt | Recorded due_at, sampled time and accepted receipt time against approved numeric limits | time/idle-managed: observe exact source rows unchanged and exact request/receipt/control output with bounded public-state synchronization; G1 and G3 missing. | gap |
| R3 | T49.02; §3.2 | Each evaluation unit uses one authoritative database-time sample with timezone-aware UTC elapsed-time semantics. | All decisions in the unit share the sample; before/equal/after and equivalent timezone representations. | pgreact_api.run(sampled_time); deadline frontier; public evaluation evidence | Fixed timestamp vectors; proposed equality-is-due rule awaits Q1 | time/boundaries: exact condition, work and temporal-history vectors at due minus 1 microsecond, due, due plus 1 microsecond; G1 missing. | gap |
| R4 | §3.2; T49.03,T49.07 | A later sample with unchanged eligibility does not create a new intended action or reset its deadline. | Sampled time is never a request-key salt. | Immutable adapter request store and public work/receipts | Same canonical request bytes and due_at before and after time-only repeats | time/sample-identity: compare complete persisted request and due-date vectors across repeated samples. | planned |
| R5 | §§2,3.3; T49.11 | MDM alone determines escalation eligibility and accepts only permitted typed ESCALATE requests within the active binding's level limits. | Closed, disallowed, pending stewardship, invalid level or inactive binding cannot cause a control change; protection follows MDM-owned action-specific rules. | mdm_steward.submit_policy_intent; policy_cases_v1; policy_receipts_v1 | MDM-STEWARDSHIP/1 v3 plus owner-approved escalation decision/receipt vectors | time/eligibility: exact public rows and receipts for each allowed and denied case; complete escalation-specific oracle G2 missing. | gap |
| R6 | §3.3; T49.06,T49.12 | Advance at most one next permitted level per case per evaluation, reevaluating committed MDM state before another level. | Proposed first profile; total level and per-cycle admission bounds required; no missed-interval burst. | Registered escalation condition and managed evaluation | Owner-agreed next-level/catch-up schedule and frozen bounds | time/level-schedule: exact ordered per-evaluation case/level/request/receipt vectors; G1-G3 missing. | gap |
| R7 | §3.3 | Emit at most one escalation condition row per case_key; level is payload, not an added ordinary semantic key. | Multiple configurations or due levels must not duplicate a case row; empty input gives exact empty output. | Escalation condition consumed by ordinary bigint-key rule | Explicit expected full relation keyed by MDM case_key | time/condition-identity: compare full sorted rows for empty, mixed and multi-level inputs. | planned |
| R8 | T49.03,T49.05; §3.3 | Apply each configured level at most once per MDM occurrence, even across distinct request keys. | New lifecycle/action revisions, human edits, binding replacement, retries and coherent restore cannot reissue an applied level. | MDM control/receipt interface and approved atomic level bookkeeping | Signed occurrence/applied-level invariant independent of request-key deduplication | time/cross-key-uniqueness: exact applied-level history under distinct keys, both concurrent orders and restore; G2 missing. | gap |
| R9 | T49.10; §3.3 | A genuine MDM recurrence can receive its permitted escalation with a new occurrence request identity. | Disappearance/reappearance or publication time alone never establishes recurrence; old work cannot affect new occurrence. | policy_cases_v1; request key codec; MDM receipts | MDM-owned review_id, occurrence and retained case_key mapping | time/recurrence: exact old/new occurrence rows, request bytes and accepted/stale receipts. | planned |
| R10 | T49.04; C06; gates §3 | Persist immutable canonical version, request key and complete body before first attempt and reuse them on retry. | Changed intended action creates new work; null/type/normalization and same-key/different-body rules remain binding. | Adapter request store; submit_policy_intent | Frozen canonical fixture bytes and v3 idempotency result | Extend v0.48-codec.sql and live replay cases with ESCALATE vectors; assert complete request bytes and unchanged original receipt. | planned |
| R11 | T49.04; C06; gates §3 | MDM control, receipt association and React completion commit or roll back together. | Crash/failure between each step, deadlock, concurrent claim and uncertain commit replay. | Existing transactional database consequence through MDM public API | Complete before/after database state and single committed immutable receipt | Extend v0.48-live.sql failure/connection-loss cases for escalation; exact control, receipt, request, attempt and completion state. | planned |
| R12 | §3.4; C06; gates §3 | Stale work terminates and triggers bounded fresh reevaluation without making the old payload valid. | New sample is not new authority; changed action uses new immutable work. | Adapter stale outcome and reevaluation path | Old terminal request unchanged; new work uses current MDM tokens | time/stale-reevaluation: compare complete old/new request and receipt vectors through ordinary runtime. | planned |
| R13 | C06; gates §3 | Domain outcomes retain their existing stop, no-op and bounded-retry meanings. | Denied, invalid, conflict and unknown outcomes fail closed; only classified transient failures retry. | Adapter outcome mapping and public intent status | Frozen v3 outcome table and existing bounded retry contract | Extend v0.48-live.sql outcome cases for ESCALATE, asserting full outcome/reason/work/attempt state. | planned |
| R14 | T49.07; §3.4; C08 | Audit, receipt, heartbeat and publication-only changes do not advance action-driving revisions or create commands. | Preserve observation metadata; relevant evidence/control changes still invalidate stale work. | Action-column mapping; policy_cases_v1; work view | Exact action-relevant snapshot unchanged after observation-only updates | time/observation-feedback: compare complete command/request vectors and action revisions before/after each metadata update. | planned |
| R15 | §3.4; C08 | MDM publication feedback converges to no-op once the desired permitted control state is reached. | Queue assignment and escalation publication must not create a self-sustaining command loop. | Independent MDM publication followed by managed evaluation | Expected stable MDM controls and exact empty new-work relation | time/convergence: repeat committed publication/evaluation cycles and compare full controls, requests and receipts. | planned |
| R16 | T49.08; §§1,3.4,7 | Preserve the original deadline through polling, delivery, feedback, retry, restart and restore. | Never recompute it from installation, publication or recovery time. | policy_cases_v1.due_at; existing due-date policy | Original timestamp fixture retained byte-for-byte as timestamptz instant | time/deadline-preservation: compare complete case and intended-control vectors through lifecycle and recovery. | planned |
| R17 | T49.08; §3.4; C07 | Only explicit reviewed policy replacement may change a deadline, and incompatible queued escalation cannot execute afterward. | Both binding-replacement lock orders; attempted work remains immutable. | Existing policy replacement plus MDM binding validation | Authorized replacement fixture and old/new binding digest expectations | time/deadline-replacement: exact before/after due_at, held/withdrawn work and stale/rejected receipts for both race orders. | planned |
| R18 | T49.09; C07 | Queued escalation cannot override a human closure, protection or relevant case/evidence change. | Both transaction orders; pending stewardship blocks control until successful observation. | Public human stewardship operation raced with intent acceptance | MDM authoritative state and exact terminal outcomes | time/human-races: barriers around acceptance; compare full control/receipt/work and final case rows. | planned |
| R19 | T49.11; C07; gates §4 | No new intent is accepted after the acknowledged pause barrier or from a stale/disabled/replaced binding. | Previously accepted control is not reversed; authenticated identical replay may return its old receipt. | mdm_admin.set_policy_binding_state; replace_policy_binding; intent worker | Barrier transaction order and approved v3 replay distinction | time/pause-races: exact receipt vectors for both lock orders and pre/post-barrier requests. | planned |
| R20 | T49.06; §7 | Restart across several deadlines resumes bounded catch-up without lost eligibility or repeated applied levels. | Recheck capabilities, bindings and current MDM facts; no new action per missed poll. | Managed worker restart; temporal recovery; MDM receipt state | Owner-approved outage/catch-up schedule | time/restart-catch-up: real worker outage and exact scheduled vs applied vectors within frozen recovery budget; G1-G3 missing. | gap |
| R21 | T49.12; C11 | A mixed due workload makes eventual progress within frozen per-cycle, backlog and latency limits. | Supported cohort/churn/burst must fit the selected mechanism; limit rejection must not masquerade as backlog drain. | Managed cycle, pending work and temporal limits | Signed numeric qualification workload and expected complete population | time/bounded-load: record every case's admission and receipt, queue progression and drain time; G1/G3 missing. | gap |
| R22 | §3.5; W49.6 | Public diagnostics expose original deadline, configuration version, sampled time, requested/applied level, no-op/protection reason, pending work, receipt and stale/rejected outcome. | Observe these without reading MDM private catalogs or disclosing unauthorized metadata. | pgreact_mdm.delivery_inspection_v1; temporal_status/history/explain; deadline preview | Fixed full diagnostic rows for delivered, protected, stale, pending and rejected cases | time/diagnostics: exact public output contract; agreed combined evidence path G4 missing. | gap |
| R23 | §3.5; gates §3 | Control delivery is distinct from case closure, publication and business resolution. | APPLIED_CONTROL is not proof of resolution; v3 control receipts have null resulting_publication_revision. | MDM receipts, React work status and public review output | v3 publication contract | time/delivery-not-resolution: exact open review plus completed control, then human decision and separate MDM publication. | planned |
| R24 | §7; C05 | Fresh installation and populated adjacent upgrade preserve request codecs, attempted requests, temporal configuration and applied levels. | Append migration SQL; retain published migration history; adapter-present and adapter-absent variants. | Packaged install and ALTER EXTENSION upgrade | Full pre-upgrade state and fresh/upgrade schema/API inventories | Extend v0.48-adjacent-upgrade.sql for selected actual predecessor and new temporal state, comparing exact inventories and rows. | planned |
| R25 | §7; C05,C10 | Upgrade cannot silently enable escalation for existing cases. | Pause barrier before temporal changes; effects stay disabled until explicit reviewed activation. | Adapter admission and MDM binding state | Exact accepted-control set unchanged until authorized enablement | time/upgrade-enablement: compare requests/receipts before upgrade, disabled boot and explicit activation. | planned |
| R26 | §7; C10; gates §7 | Coherent restore preserves deadlines, occurrence mappings, applied levels, requests and matching MDM receipts before deliberate resumption. | Never restore React request state independently; recheck artifacts/capabilities, roles and bindings. | Whole-database backup/restore and public reconciliation APIs | Complete pre-backup durable-state fixture plus approved applied-level storage | Extend v0.48-restore.sh and restore SQL with temporal/applied-level state; G2 missing for level history. | gap |
| R27 | §7; C10; gates §7 | A clone starts with effects blocked until an environment-specific operator activation check succeeds. | Copied overdue timestamps, enabled flags and physical database OIDs are insufficient isolation. | Actual clone startup procedure and runtime guard | Exact empty new-control/receipt delta before explicit activation | time/clone-startup: logical and physical clone boot with worker enabled and overdue rows; deployment guard/input G5 missing. | gap |
| R28 | C10; gates §7 | Failed upgrade recovers with coherent database state and matching prior artifacts. | Transactional rollback where supported, otherwise whole recovery point; no invented reverse migration. | Packaged upgrade/recovery procedure | Pre-upgrade exact state and artifact identities | time/failed-upgrade: inject migration failure and compare restored inventories, requests, receipts and disabled admission. | planned |
| R29 | §2; C01; gates §1 | Admit effects only on the exact qualified joint stack and recheck after capability or artifact changes. | Missing/disabled/unsupported capabilities reject before effects and leave inspectable blocked state. | Existing compatibility admission and worker entry | Recorded runtime/build/image identities and approved capability fixture | Extend v0.48-admission.sh and qualification manifest; exact rejection/status and unchanged controls for every variant. | planned |
| R30 | C02; gates §2 | Core policies remain functional with MDM absent or the optional adapter disabled. | No mandatory MDM dependency or MDM-specific generic evaluator language. | Fresh core installation and ordinary policy API | Existing ordinary-policy exact fixtures | Run core qualification and missing-MDM lane with ordinary policy outputs compared exactly. | planned |
| R31 | C03; gates §2 | Only approved least-privilege identities can observe or submit escalation, without human decision privileges. | Installer/author/runtime/observer/unauthorized roles; hostile search_path, cross-scope exposure, RLS and BYPASSRLS rejected. | Real managed worker identity and public adapter/MDM APIs | Explicit grant/denial matrix and unchanged protected state | Extend v0.48-security.sql with exact escalation outputs/errors and full no-effect state for denied paths. | planned |
| R32 | C04; gates §7 | Existing valid ordinary author/review/deploy/replace/inspect calls and stale-review rejection remain compatible. | Adjacent release preserves documented valid inputs and expected errors. | Ordinary pgreact API | Repository ordinary compatibility fixtures | Existing tests/qualification.sh ordinary lanes with exact results and API inventory. | planned |
| R33 | C09; gates §5 | Read-only comparison covers a fixed population exactly and changes no selected or unselected state. | Partial output is not complete coverage; no effects or frontier advancement. | Existing comparison and deadline-preview APIs | Independent full expected population and before/after state | time/comparison: exact full/partitioned coverage and complete relevant state checksums plus row vectors. | planned |
| R34 | C11; gates §6 | Measure the supported workload's queue, database writes, WAL, storage and receipt/key retention costs against signed limits. | Unavailable metrics are named; blank required thresholds block qualification; v3 has no automatic receipt deletion. | Qualification runner and PostgreSQL resource observations | Frozen workload-specific thresholds, retention policy and actual measurements | time/resource-envelope: retain numeric report, queue sequence and complete case coverage; G3 missing. | gap |
| R35 | C12; gates §§6,8 | Qualify the same packaged artifact intended for publication with machine-readable evidence and no required skips. | Retain source/contract/environment identity, expected/actual results, commands, logs and failures; zero unauthorized, duplicate, stale-binding or preactivation clone controls and omissions. | Existing core/adapter release workflow and evidence manifests | Exact artifact digest and full R/T49/C gate coverage | Extend qualification manifest and artifact chain; every requirement has actual separate proof evidence before release. | planned |
| R36 | W49.6; §§4,8; gates §8 | Document the qualified public temporal API, workload limits, timer/recovery procedures and release notes. | Procedures and support claims must match the qualified artifact and operating profile. | Operator documentation | Installed public API and frozen supported profile | Check documented examples and recovery steps against complete qualification evidence. | planned |
| R37 | S0 React §8; S0 MDM §7 | Demonstrate one published ambiguous case through queue/deadline control, idle escalation, human decision and separate publication to closure. | Automation must not record the human decision or infer closure from delivery. | Existing showcase/mdm-stewardship and public React/MDM interfaces | Independently specified full stage-by-stage public rows and request/receipt bytes | Extend the existing example with idle time advancement and exact final review state; G1-G3 missing for escalation stages. | gap |
| R38 | W49.6; gates §8 | Complete independent review with no open critical correctness or authorization defect. | Historical approval or review of a different candidate cannot substitute. | Independent review report | All current findings and their recorded disposition against the release candidate | Retain reviewer identity, reviewed candidate, findings and resolution evidence. | planned |
| R39 | §§4,8; gates §§1,8 | Keep React work within 30 person-days or obtain an approved re-estimation or split before exceeding it. | Include review, operations documentation and contingency; external MDM work is a separate dependency; do not cut required safety promises. | Release work estimate and dependency decisions | Source budget and named W49 work packages | Record estimated effort, discovered dependencies and any authorized scope/estimate decision at W49.1 and subsequent material changes. | planned |

## Unresolved gaps

- G1, R2-R3, R6, R20-R21 and R37: choose and document the installed temporal registration for this escalation condition and one evaluation-time path. Public deadline/temporal APIs and the managed worker exist, but current adapter routing uses statement_timestamp while deadline preview uses an explicit sample. The chosen path has no current-stack idle-case evidence or agreed evaluation-unit definition. Existing pass limits reject oversized populations; they do not establish incremental catch-up. W49.1 must settle the mapping and liveness feasibility before W49.2+.
- G2, R5-R6, R8 and R26, also prerequisite to R20 and R37: missing owner-approved escalation decision/receipt fixtures and the authoritative mechanism that remembers applied levels across new request keys and human changes. MDM contract v3 exposes current escalation_level, retained occurrences and same-key deduplication; those alone do not specify durable per-occurrence applied-level history. Preserve this requirement rather than assume it is already implemented. State retained atomically in MDM or approved minimal adapter bookkeeping requires a signed decision and coherent restore mapping.
- G3, R2, R6, R20-R21, R34 and R37: missing workload-specific numbers for cohort, churn, maximum level, due burst, per-cycle admissions, poll interval, detection/dispatch latency, backlog drain, outage/recovery budget, and database writes/WAL/storage. Record receipt/key retention and associated storage assumptions. The existing v3 no-automatic-deletion policy remains binding. Previous refresh-only pilot timings are not escalation latency bounds. Owners freeze these numbers after baseline measurements and before qualification.
- G4, R22: existing delivery_inspection_v1, temporal diagnostics and deadline preview provide parts of the evidence, but no agreed complete public row/output contract ties original deadline, configuration and one sampled time to requested/applied levels and protection/no-op reasons. Agree the output and fixtures through existing views/explanations, adding only missing fields.
- G5, R27: no qualified clone startup procedure or named clone test was found. Logical restore and database/role OID reconciliation are foundations, not proof against a physical clone with copied OIDs. Name an environment-specific launch/activation guard and retain a real CI launch test before claiming clone isolation.

## Open questions

- Q1, React temporal/runtime owner: approve the evaluation-unit definition and equality counting as due in the qualified UTC elapsed-time profile. Select the supported registration and managed sampling path during W49.1. If it cannot provide idle liveness, re-estimate the missing dependency before further implementation.
- Q2, MDM owner and policy owner: approve at most one next permitted level per case per evaluation, the next eligibility/catch-up schedule, action-specific protection semantics and what happens after a human lowers a level. Confirm how MDM recurrence and retained applied-level state enforce R8 even across binding replacement. Choose the authoritative mechanism and freeze exact receipts.
- Q3, joint owners: freeze the G3 numeric workload and operational limits. No achieved rates or arbitrary thresholds are proposed here.
- Q4, runtime/release owner: agree the G4 public evidence output and G5 clone activation procedure. Confirm the exact joint artifacts and actual adjacent predecessor; the v0.48 record uses a 0.46.0 core extension with the 0.48 adapter.
- Approval of this initial v1 proposal is pending. Resolving a material promise or boundary uses plan-acceptance revision rules and preserves this proposal. An audit may inspect the proposal before approval, but it cannot approve unresolved owner decisions.

## Out of scope

- Rolling/hopping event windows, business calendars, arbitrary event sequences, network alerts, human approval routing, generic temporal DSL, separate scheduler and broad temporal-engine rewrite.
- Human review ledger, identity resolver, automatic identity decisions, private MDM writes, nested MDM refresh, multi-tenant/RLS workarounds, cross-database delivery, Graph/Delta consumption and convenience metrics beyond required operational evidence.
- Later rollout and approval milestones. The inherited single-case demonstration remains required: published ambiguous case, permitted queue/deadline control, idle escalation, authenticated human decision, then separate MDM publication. This does not authorize a new human approval subsystem.
- No implementation, runtime qualification, staging, commits, PR, label changes or issue-body edits in this planning invocation.

## Change notes

- Initial v1, R1-R39. The direct plan-acceptance invocation authorizes local planning and its issue-comment handoff; it does not approve the proposed agreement.
- Preserve the authoritative v0.49 plan and common gates unchanged. Capture the issue body locally and retain the linked source text in the shared handoff. No new product promises are inferred from optional implementation file suggestions.
- The plan's MDM 0.11.0 limitation is historical. Current repository evidence selects MDM-STEWARDSHIP/1 v3 and pg-mdm extension 0.14.0, and the adapter already emits typed ESCALATE. The older shared-plan revision-1 binding pin and adapter README do not supersede the later approved v3 selection. The source snapshot records this reconciliation.
- Existing evidence is contextual only. No old verdict is imported into this contract. The latest v0.48 manifest reports all T48 gates and owner approvals, while earlier prose records earlier blockers. Recheck the exact selected stack for this release.
- Coverage: T49.01 maps to R1-R2; T49.02 to R3; T49.03 to R4/R8; T49.04 to R10-R11; T49.05 to R8; T49.06 to R6/R20; T49.07 to R4/R14-R15; T49.08 to R16-R17; T49.09 to R18; T49.10 to R9; T49.11 to R5/R19; T49.12 to R6/R21/R34. C01 maps to R29; C02 to R30; C03 to R31; C04 to R32; C05 to R24-R25; C06 to R10-R13; C07 to R17-R19; C08 to R2-R9/R14-R15; C09 to R33; C10 to R20/R25-R28; C11 to R21/R34; C12 to R35. R22-R23 and R36-R39 cover public evidence, outcome meaning, operations, the inherited full demonstration, independent review and the effort boundary.
- Draft refinement: R36's documentation, independent review and effort promises are separated into R36, R38 and R39. R37 makes the already inherited demonstration explicit. No promise changes; no IDs are reused. The prior uncommitted draft is retained in .p2p history.
- All added boundaries derive from the stated outcome or common gates. Empty relations test the absence of unintended escalation; cross-key uniqueness, atomicity, immutable state, bounded recovery and clone blocking are explicit source promises. No source requirement is dropped for the 30-person-day budget.

## Implementation handoff

Hand off to an explicitly authorized /implement-contract invocation after blocking gaps and owner decisions are resolved and the agreement is approved.
Implement the smallest complete solution inside the spec envelope.
Preserve requirement IDs and promised outcomes.
Capture the resulting candidate for separate /review-implementation and /prove phases.
Do not proceed beyond W49.1 if installed temporal liveness cannot be established.

## Proof handoff

Evaluate every requirement against this contract revision and one fixed candidate.
Record actual evidence and verdicts in a separate proof report under .p2p/work/v0-49-0-managed-deadlines-and-bounded-escalation/proof.md.
New time/* cases are planned under tests/integrations/pg-mdm/time/ and do not exist yet. Reuse the existing SQL/Docker runner patterns and v0.48 codec, live, security, admission, upgrade and restore suites.
Use exact complete expected rows, canonical bytes, receipts and state vectors. Counts alone do not prove identity or absence of unauthorized effects. Dynamically assigned IDs/times must be captured and checked against their public authoritative sources.
Use deterministic sampled-time fixtures for boundaries and at least one real managed-runtime test with unchanged business tables. Synchronize on public state with a bounded deadline, not a fixed sleep.
Retain the exact commands, environment, expected/actual outcomes and selected logs. Report only test summaries to the conversation, with details for failures.

Next steps:

1. Resolve G1-G5 and record owner decisions Q1-Q4 through W49.1 and the shared contract process. Current gap rows cannot proceed to implementation.
2. Optionally run /audit-acceptance work/v0-49-0-managed-deadlines-and-bounded-escalation.md against specs/v0.49.0-issue-8.md after those inputs are captured.
3. Approve the resulting exact proposal by its issue handoff URL and SHA-256. Retain approval on the issue for an issue-only delivery handoff.

Next steps:

1. Resolve G1-G5 and owner decisions Q1-Q4, retaining requirement IDs.
2. Approve the resulting exact proposal by this comment and its SHA-256. Publication is not approval.