---
id: USER-WP-0009
type: workplan
title: "Postgres Durable Store Consumer Requirements"
domain: netkingdom
repo: user-engine
status: proposed
owner: codex
topic_slug: netkingdom
planning_priority: high
planning_order: 9
created: "2026-06-05"
updated: "2026-06-05"
depends_on:
  - USER-WP-0007
---

# USER-WP-0009 - Postgres Durable Store Consumer Requirements

## Goal

Define, from the `user-engine` consumer perspective, what a durable
Postgres-backed store must provide before user-engine depends on it in
NetKingdom. This workplan is requirements-only: it should not implement the
Postgres adapter, provision databases, create tenant infrastructure, or choose
the final provider repository design.

## Scope Direction

`user-engine` should be able to consume a NetKingdom-provided, tenant-aware,
security-integrated Postgres capability through an adapter boundary. The
future Postgres/provider repository should own provisioning, credentials,
network policy, tenant isolation primitives, backup/restore, platform
observability, and operational security. `user-engine` should own its domain
schema, migrations for its own tables, store semantics, and conformance tests.

## Non-Goals

- Do not implement a Postgres store adapter in this workplan.
- Do not add database dependencies to the package in this workplan.
- Do not provision Postgres, schemas, roles, credentials, certificates, or
  network access from this repository.
- Do not decide the final independent infrastructure repository layout.
- Do not move audit-platform, IAM, secrets, or authorization ownership into
  user-engine.
- Do not change the public service surface unless the requirements reveal a
  missing durable-store contract.

## Tasks

```task
id: USER-WP-0009-T1
status: todo
priority: high
```

Inventory the current in-memory store behavior and document the durable
persistence semantics user-engine consumers already rely on: users, accounts,
tenant accounts, external identities, applications, bindings, catalogs,
profile values, memberships, audit records, outbox events, readiness, and
schema version reporting.

```task
id: USER-WP-0009-T2
status: todo
priority: high
```

Create a consumer-facing requirements document for a Postgres durable store.
Cover connection handoff, tenant context, schema ownership, migrations,
transactions, isolation, constraints, query behavior, audit/outbox durability,
security, observability, backup/restore expectations, and acceptance tests.

```task
id: USER-WP-0009-T3
status: todo
priority: high
```

Define the boundary between user-engine and the future NetKingdom Postgres
provider repository. Specify which responsibilities belong to the provider,
which belong to the user-engine adapter, and which must remain external IAM,
secrets, authorization, or audit-platform concerns.

```task
id: USER-WP-0009-T4
status: todo
priority: medium
```

Identify required changes, if any, to the existing store protocol or migration
contract so durable implementations can satisfy the same service behavior as
the isolated MVP without leaking Postgres concepts into domain code.

```task
id: USER-WP-0009-T5
status: todo
priority: medium
```

Define conformance scenarios and failure-mode tests the future Postgres store
must pass. Include transaction rollback, duplicate identity prevention,
tenant-boundary enforcement, outbox exactly-once handoff semantics, migration
readiness, and redacted diagnostics.

```task
id: USER-WP-0009-T6
status: todo
priority: medium
```

Record open questions for the independent provider repository, including
tenant isolation model, credential lease model, schema-per-service or
database-per-tenant strategy, migration runner ownership, backup unit, PITR
expectations, encryption, and operational runbooks.

## Acceptance Criteria

- `docs/postgres-durable-store-consumer-requirements.md` exists and is clear
  enough for an independent NetKingdom Postgres provider repo to implement
  against.
- The document describes user-engine as a consumer of a secure Postgres
  capability, not as the owner of Postgres provisioning or platform security.
- Requirements cover domain persistence, transactions, migrations, tenant
  isolation, security, audit/outbox durability, operability, and acceptance
  tests.
- The provider-repo boundary is explicit and avoids duplicating IAM, secrets,
  authorization, audit-platform, or infrastructure ownership.
- No Postgres implementation code is added as part of this workplan.

## Expected Outputs

- `docs/postgres-durable-store-consumer-requirements.md`
- Store-boundary notes suitable for a future provider repo.
- Follow-up implementation workplan inputs for a Postgres adapter.