Skip to content

[M1/Correctness] Make command idempotency tenant-scoped, content-bound, and result-complete #178

Description

@samovers

Parent: #167
Foundations: #169, #173, #174.

Authority programme: #175 remains the tracking epic, not a requirement to finish that whole programme before this Delivery. Depend on the exact authorization, identity, representation and source-authority capabilities required by the first consumer, not the remaining action evaluations, mutation integrations or human-finalization programme. Identify those concrete prerequisites and resolve producer/consumer ordering before implementation. Do not replace #175 with a blanket #353 dependency: the provider itself needs real transaction/read attempt producers, and that ordering must be settled without a cycle or invented proof.

Scope alignment (2026-09-11): Renewed canonical Phase A approval at exact PR #11 head 4494924998183fe3fa7bc1b63b76a85893335044. Only first-consumer integration is narrowed; common identity, atomic-outcome and reconciliation semantics remain.
Recovery follow-on: #193

Problem

Idempotency is not fully namespaced or result-complete; replay behavior differs across carriers, broad uniqueness-error handling can misclassify unrelated integrity failures as duplicate commands, and caller-key equality is not yet enforced identically across transport and PostgreSQL.

Outcome and primary trust boundary

Deliver shared production command identity, admission, atomic outcome and reconciliation with ASSERT_OPERATION_CLAIM as the first real state-affecting NOT_REQUIRED consumer. Primary trust boundary: durable command identity and atomic transaction outcome. This is one reusable protocol, not a private claim retry engine. The protected-effect validator/writer retains its separately reviewed owner and must have a usable interface before first-consumer completion can be proved. If the actual design needs independent capabilities inside this issue, reclassify/split under the existing Delivery rule before implementation.

Acceptance criteria

  • Scope the idempotency identity by tenant, authenticated principal, governed operation, and caller key as approved in [M1/ADR] Freeze tenancy and schema-migration architecture #169.
  • Treat caller_key as exact contract-validated bytes under ADR 0001's OFARM_ASCII_ID_V1 grammar and 1-255 byte bound. Never trim, fold case, normalize Unicode, or reinterpret punctuation.
  • Enforce the same equality in application validation and [M1/Security] Enforce tenant isolation and record-graph integrity in PostgreSQL #174's deterministic database domain/index. Variants are either distinct valid keys or explicit validation failures; hidden collation/normalization never merges them.
  • Bind the identity to a canonical semantic request digest, including carrier and relevant context/bundle identifiers.
  • Exact retries recover the same verified original durable operation outcome, including original IDs, decision, reasons, references, qualification and digest evidence, without repeating or re-authorizing the original protected write or its successful consumption. Disclosure of protected saved information is separately subject to current authorization and qualification; a protected response is not guaranteed merely because the original operation succeeded.
  • Same identity plus a different request returns governed RETRY_CONFLICT without mutation.
  • Catch only the named idempotency constraint for replay; preserve the real governed/integrity error for every other constraint.
  • Deliver the shared persistence/reuse/conflict protocol with ASSERT_OPERATION_CLAIM as its first real state-affecting NOT_REQUIRED consumer. The lookup namespace supports later admitted handlers without per-handler, mode, schema, result or profile namespaces that hide an existing operation. Other structure, operation, evidence, review, correction, authority and output consumer integrations remain explicitly open under [M1] Pre-deployment Kernel integrity hardening #167; closing this Delivery does not complete them.
  • Freeze caller-controlled decision time and other replay-sensitive inputs at first acceptance; a retry cannot manufacture a different command.
  • Define retention/expiry behavior without allowing a live key to be rebound silently.
  • Expose complete durable idempotency identities, request digests, results, and receipts for later [M1/Architecture] Define non-forking tenant-service recovery #193 recovery reconciliation.
  • Concurrent duplicate and equality-boundary tests prove one authoritative operation outcome and invariant stored result across workers. Outward redaction, qualification or refusal may change with current disclosure authority. Test successful disclosed claim, later access revocation and exact retry: preserve the original outcome, create no second effect or successful consumption, and release no currently forbidden information.

Required protocol and owner bindings

Use the exact promoted counterpart of canonical PR #26's identity/comparison rules, including represented Party or exact null, original caller-submission projection, bind-once complete intent and original online assertedAt. Preserve #169/ADR 0001 exact key equality; reconcile database representation and named-constraint handling before implementation, without changing the key contract.

Retry comparison uses the original caller-submission projection and exact lookup tuple, not the complete intent recomputed with a fresh timestamp. Preserve the original full binding and assertedAt. A new attempt time must not manufacture a conflict or replace the original operation.

Prove complete atomic success, at most one successful consumption/result, conclusive NO_EFFECT consequences, truthful OUTCOME_UNKNOWN, independent effect-versus-failure-evidence reconciliation, partial-set quarantine, current admission precedence, concurrent exact retries and original-result recovery. No current handler/policy change may hide an unresolved or completed operation. Completion requires a real first protected-effect consumer through production composition, not a fixture effect or standalone interface.

Governed read is not admitted to this NOT_REQUIRED write protocol. Lookup/replay cannot release protected saved information without the current separately owned disclosure checks. Keep source-history qualification, retention/proof limits and the unresolved CP2A-DEP01 obligations; inactive writing, empty lookup or permanent UNAVAILABLE does not close them. Canonical candidates must be governed, bound, promoted and extracted before executable use.

Non-goals

Exactly-once external delivery, infinite receipt retention, recovery orchestration, restored-history key reservation, law/contract changes, or capability claims. #193 owns recovery reconciliation. Domain result mapping, human finalization, new authorization or grant/bootstrap authority, governed-read/disclosure implementation, public activation, custody and deployment remain separate boundaries. No runtime implementation is authorized by this scope alignment.

Previous issue body — superseded scope history, captured 2026-09-11

This is the complete previous body. Its scope, source pins and next-step wording are historical; the amended current text above controls. Prior decisions and approvals remain attached to their original revisions.

Parent: #167
Depends on: #169, #173, #174, #175
Recovery follow-on: #193

Problem

Idempotency is not fully namespaced or result-complete; replay behavior differs across carriers, broad uniqueness-error handling can misclassify unrelated integrity failures as duplicate commands, and caller-key equality is not yet enforced identically across transport and PostgreSQL.

Acceptance criteria

  • Scope the idempotency identity by tenant, authenticated principal, governed operation, and caller key as approved in [M1/ADR] Freeze tenancy and schema-migration architecture #169.
  • Treat caller_key as exact contract-validated bytes under ADR 0001's OFARM_ASCII_ID_V1 grammar and 1-255 byte bound. Never trim, fold case, normalize Unicode, or reinterpret punctuation.
  • Enforce the same equality in application validation and [M1/Security] Enforce tenant isolation and record-graph integrity in PostgreSQL #174's deterministic database domain/index. Variants are either distinct valid keys or explicit validation failures; hidden collation/normalization never merges them.
  • Bind the identity to a canonical semantic request digest, including carrier and relevant context/bundle identifiers.
  • Same identity plus same request returns the complete original durable result, including stable IDs, decision, reason, references, qualification, and digest fields.
  • Same identity plus a different request returns governed RETRY_CONFLICT without mutation.
  • Catch only the named idempotency constraint for replay; preserve the real governed/integrity error for every other constraint.
  • Use one carrier persistence/reuse/conflict protocol for structure, operation, evidence, review, correction, authority, and output commands.
  • Freeze caller-controlled decision time and other replay-sensitive inputs at first acceptance; a retry cannot manufacture a different command.
  • Define retention/expiry behavior without allowing a live key to be rebound silently.
  • Expose complete durable idempotency identities, request digests, results, and receipts for later [M1/Architecture] Define non-forking tenant-service recovery #193 recovery reconciliation.
  • Concurrent duplicate and equality-boundary tests prove one authoritative emission and byte/semantic-equivalent complete responses across workers.

Non-goals

Exactly-once external delivery, infinite receipt retention, recovery orchestration, restored-history key reservation, law/contract changes, or capability claims. #193 owns recovery reconciliation.

What is next: settle concrete producer/consumer prerequisites and the first-consumer Phase A within the transaction boundary before implementation. The obsolete native whole-#175 predecessor has been removed without adding a cyclic #353 replacement; every substantive authority and disclosure gate remains.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    deliveryOne independently reviewable capability and primary trust boundary; one live implementation PR.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions