product/composition: persist immutable generation and activation authority

[seonghobae]

Buyer-visible gap

#432/#433/#434 currently prove only process-local product-composition admission. OwnerApiRelease, CompositionRoute, CompositionGeneration, and AdmissionReceipt construction/issuance integrity disappears across GC/process restart and therefore cannot prove which exact generation/configuration/deployment was historically active.

This issue owns the next Orgmetra product-composition persistence slice under #432. It is not a new bounded context and does not own HR domain truth. It may persist only immutable composition generation/configuration/deployment/activation/audit coordinates needed to prove exact product-composition state. It must not copy owner schemas, query owner application tables, or move Keyverse/domain authorization/idempotency/concurrency/scientific truth into composition.

Dependency boundary

• Parent executable admission: feat(composition): admit exact released owner API routes #434, currently stacked on fix(ci): run setup-node on Node 24 action runtime #340.
• Architecture authority: docs(gateway): separate shared edge transport from Orgmetra product composition #433 / ADR 0432 remains Proposed; this issue must remain Draft/dependent and must not be called protected or release-ready before normal architecture admission.
• Canonical Foundation service discovery/runtime compatibility: ci: reconcile service Python runtime metadata and executable compatibility #260 after its declared prerequisites.
• Positive activation ultimately requires released Keyverse/Orgmetra ACL and released owner API/operation evidence; synthetic structural fixtures are insufficient for production activation.

No mutable sibling source copy, feature-local quality workflow, cross-service SQL, force-push/destructive rebase, self-approval, gate weakening, or routine administrator bypass is authorized.

Durable invariants

1. Generation identity is non-reassignable. One generation_id is bound permanently to one schema/configuration meaning. Re-registering the exact same canonical generation is idempotent; reusing the ID for a different config_sha256 or route material fails closed.
2. Canonical configuration is reconstructable. Durable rows retain enough normalized route and owner-release material to reconstruct OwnerApiRelease/CompositionRoute/CompositionGeneration, recompute the canonical configuration digest, and run the existing feat(composition): admit exact released owner API routes #434 admission evaluator. A stored digest without reconstructable semantic material is not authority.
3. No partial generation becomes eligible. Generation root + route/release material are written atomically. Incomplete route sets, split owner releases, invalid Path Item ownership, path-selection ambiguity, or hash mismatch fail before commit/activation.
4. Deployment identity is explicit and non-PII. Deployment/environment coordinates contain no credential, Person, tenant, or other HR data and are not inferred from caller labels that can be reassigned silently.
5. Activation is generation-atomic and append-only. Current deployment state is derived from an append-only activation event sequence under a per-deployment transaction lock. Concurrent activations cannot both claim the same next state.
6. Rollback is a new activation event. It may target only a previously persisted immutable generation and must re-run durable generation/configuration/release/owner compatibility checks; a stale in-process AdmissionReceipt is never rollback authority.
7. Mutation history is not rewritten. Generation semantic rows and activation events are update/delete denied after insertion except for explicitly modeled append-only successor evidence.
8. Recovery is reproducible. After process restart the active generation can be reconstructed and re-admitted from durable rows without relying on Python object identity or prior closure state.
9. Composition-only persistence. No HR application table, owner-service table, Keyverse table, or cross-service SQL is introduced.

Implementation order

Start with a narrow child of #434 that defines the immutable durable generation/configuration registry and its PostgreSQL adapter/contract tests. Then add deployment activation/rollback event semantics on the same owner path. Keep the issue open until both persistence and activation/recovery are exercised under canonical Foundation/PostgreSQL acceptance on a protected-base candidate.

Acceptance

GREEN requires executable RED coverage for generation-ID reassignment, partial writes, route-material/digest mismatch, forged stored release coordinates, concurrent activation conflict, stale rollback evidence, update/delete attempts, and restart reconstruction; exact-head 100% owned statement/branch/docstring/edge evidence; isolated PostgreSQL acceptance; failure/recovery evidence; normal Security/SAST/CodeQL/review governance; then protected integration and immutable Orgmetra release evidence. None of those are inferred merely from this issue or a Draft child PR.

Refs #432 #433 #434 #260.

[seonghobae]

First dependent implementation lane opened as Draft #436. Current exact child head is 80932c808ef873b268217ef1b79b0d14fd8884f7, base #434 exact 68bdf2d984ca7686219c335a85a6574195675cbe, 6 commits / 3 files and mechanically mergeable.

The first commit 1603ed6... is source-deterministically RED because it imports a registry module absent from its parent. Current source adds normalized, reconstructable generation / owner-release / route / route-method record values, canonical receipt revalidation before projection, fresh #434 value reconstruction, configuration-digest recomputation, and fail-closed corrupt-reference tests. 7354287... removed unreachable branch debt; 80932c8... expands exact-type/reference/digest/split-owner edge coverage.

No migration or PostgreSQL adapter is claimed yet. Next causal increment remains the issue-defined persistence boundary: atomic registry tables/adapters, durable generation-ID non-reassignment, restart reload/reconstruction/re-admission, partial/tampered-state rejection, then append-only deployment activation/rollback.

[seonghobae]

2026-09-22 durable-registry increment currentization

Draft #436 has advanced from the persistence-neutral record contract to exact 04705a05f8e4fd58a39527f56dcb993fd4bb40cb (14 ordinary-forward commits / 8 files), still directly stacked on #434 exact 68bdf2d984ca7686219c335a85a6574195675cbe.

Implemented in the Draft source:

• normalized append-only PostgreSQL generation / owner-release / route / route-method persistence in migration 0018_product_composition_generation_registry.sql;
• one-connection atomic adapter registration with generation-PK conflict arbitration and exact-material-only idempotent replay;
• restart load -> fresh feat(composition): admit exact released owner API routes #434 value reconstruction -> canonical config_sha256 recomputation;
• fail-closed partial/tampered durable material;
• real PostgreSQL contract source covering registration, reassignment rejection, append-only UPDATE/DELETE rejection, and partial-transaction rollback. The contract is executable in Git mode.

Migration 0018 is deliberate because active unmerged migration-owner lanes already occupy 0014-0017; no number was stolen from those lanes.

This closes the Draft-source implementation gap for durable configuration material only. It does not close this issue. Deployment/environment identity, append-only activation sequencing, deterministic concurrent activation conflict, rollback-as-new-activation, restart derivation of the active generation, canonical PostgreSQL/Foundation execution, review/security gates, protected adoption and immutable release evidence remain open.

Exact #436 currently has zero PR-triggered workflow runs and no submitted review/thread evidence, so no GREEN/Ready/protected claim is made. Next causal increment stays on this owner path: activation/rollback/recovery over persisted generation authority, not another process-local admission micro-invariant.

[seonghobae]

Fresh owner-path update:

• feat(composition): persist reconstructable generation registry #436 advanced ordinary-forward to exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07. A persistence audit found that migration 0018's row-level UPDATE/DELETE guards did not protect PostgreSQL TRUNCATE, so its append-only claim was incomplete. 86c0bffe... adds static + real-PostgreSQL TRUNCATE RED contracts; 98b4b129... adds BEFORE TRUNCATE guards on all four generation-registry relations.
• The pre-existing feat/product-composition-activation-registry branch was reviewed rather than overwritten. It was already a direct descendant of feat(composition): persist reconstructable generation registry #436 and implemented migration 0019, per-deployment FOR UPDATE serialization, append-only activation sequence, rollback-as-new-event and restart reconstruction. After feat(composition): persist reconstructable generation registry #436 advanced it adopted the exact parent by ordinary two-parent commit 2ba5f65b... with no force/rebase.
• Draft feat(composition): persist deployment activation authority #437 now owns that activation slice at exact 692d679a2d4b7234003cd25111f0b4078214e397. 040daf34... -> 01cbb84a... closes the same TRUNCATE erasure path for deployment/event history. cde1fecf... -> 89b77496... closes valid-to-valid process-local DeploymentIdentity retargeting before database access; the durable composite key + row lock remains cross-process authority.

Important remaining #435 gap from exact source review: #437 reconstructs a persisted generation before activation/recovery, but that only proves internal durable configuration integrity. It does not yet bind a positive activation/recovery decision to fresh released Keyverse/Orgmetra ACL evidence plus fresh observed owner-API/operation evidence. Therefore #437 remains structural durable activation state, not production activation authorization.

Next causal increment should integrate those released/versioned authorities fail-closed while keeping external/network resolution outside the per-deployment transaction lock, then bind the exact evidence used for the decision so restart/recovery can re-admit rather than merely reconstruct. Do not solve this by copying Keyverse/owner schemas or by calling remote owners while holding FOR UPDATE.

No hosted exact-head GREEN or independent approval is claimed for #436/#437; #260 still owns canonical service/PostgreSQL discovery and runtime acceptance.

[seonghobae]

2026-09-22 currentization: #437 has advanced beyond structural activation and now represents transaction-bound external evidence persistence/freshness plus durable recovery lineage and a product-surface boundary. Exact child head is 60e184fd1edc3e16ee5637929015769cb3e01855, stacked on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07, fresh compare 44 ahead / 0 behind.

Two fresh authority defects were repaired ordinary-forward. First, structural activation events intentionally may have evidence_bundle_sha256 = NULL for migration/fault testing, but product-facing recovery could previously obtain fresh external allow evidence and promote that unauthorised durable history. Sequence d4b768fc... -> 28fef4b4... -> 10898ab5... -> fe6be5ad... -> 270a2b70... -> faaee012... -> 7d936963... now carries the historical digest through ActivationEvent, rejects NULL-evidence history before any remote verifier call, and keeps fresh restart evidence separate from historical transition evidence.

Second, the structural PostgresActivationRegistry was still re-exported from the root package, making the evidence-bypassing migration/fault primitive look like a supported product entrypoint. Sequence f7dbfdeb... -> 8ca291cd... -> 39e39676.../68ac1091.../5ba4d343... -> 60e184fd... removes it from the package product API, leaves structural tests on the internal module, and documents AuthorizedPostgresActivationRegistry as the positive product entrypoint. This is API-boundary hardening, not a hostile-code sandbox claim.

The earlier transaction-time gap is no longer the next implementation gap: migration 0019 persists/verifies exact non-PII evidence under the activation transaction and uses clock_timestamp() after row-lock wait to reject expired/incomplete owner-operation coverage. Keep #435 open because buyer-ready acceptance is still absent: canonical #260 execution of this package/PostgreSQL roots, protected exact-head coverage/security/review evidence, actual immutable Keyverse/Orgmetra/owner releases, deployable HTTP composition host, and end-to-end performance/recovery evidence remain outstanding.

[seonghobae]

Fresh #437 owner-path update: exact head is now 54a61d0673a2b9702f9c8306473543598c755288, 46 commits / 16 files, still directly stacked on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07 with merge-base equal to the parent and 0 behind.

Fresh review found a local-authority boundary defect in the external re-admission path. PostgresGenerationRegistry.load() reconstructs a canonical CompositionGeneration, but the caller-supplied evidence provider receives that object before activation. ActivationAdmissionEvidence.validate_for() previously checked only its exact type/current fields. A provider could therefore use low-level object.__setattr__ to retarget the loaded generation to another individually valid generation ID while returning matching evidence, allowing external verification code to redefine the local durable target before structural activation.

Ordinary-forward repair:

• d480d4628b264ba69282efa6da8432b61054d645 adds the RED contract: requested generation_one retargeted by the provider to valid-looking generation_two must fail before the structural registry is reached.
• 54a61d0673a2b9702f9c8306473543598c755288 revalidates the canonical generation construction snapshot before invoking the provider and again from ActivationAdmissionEvidence.validate_for() after provider return.

This keeps authority directional: external released ACL/owner evidence may evaluate Orgmetra's exact durable generation, but it may not redefine which generation Orgmetra is activating. The change is process-local integrity hardening, not a Python hostile-code sandbox claim.

No exact-head hosted pytest/PostgreSQL/coverage/Foundation/Security/SAST/CodeQL or independent review is inferred from these commits. #437 remains Draft; real immutable Keyverse/Orgmetra/owner release evidence and canonical execution remain open acceptance requirements.

[seonghobae]

Fresh #437 authority finding/repair handoff: predecessor 54a61d0673a2b9702f9c8306473543598c755288 bound external re-admission to deployment + target generation but did not structurally bind the external decision to transition kind or durable state version. A fresh evidence bundle could therefore be semantically replayed as activate vs rollback, or after another writer advanced the deployment, until the structural sequence guard rejected only the state race; the external decision itself remained generic. Ordinary-forward sequence now starts with RED fb34eb2b693f0033311050f2a6958db917dd79d1, adds provider/evidence action+state binding in fc3308640a732e63867fc99630158af5598b4140, adds durable PostgreSQL enforcement in e928a1c0560fd4d0058edade0d785036f6d20590, updates existing/recovery contracts and a native PostgreSQL wrong-action rejection, and currentizes docs/public API through exact #437 79a109acd91b38f58371eb5f8174dda3e2423009. Provider probes remain outside FOR UPDATE; DB event insertion now requires evidence action == event kind and evidence authorized-state-sequence == activation-sequence - 1, then rechecks expiry/owner coverage. Keep #435 open: exact-head canonical execution/review and real immutable Keyverse/Orgmetra/owner release evidence remain absent; this is not shipment authority.

[seonghobae]

Fresh #437 review found that predecessor 79a109acd91b38f58371eb5f8174dda3e2423009 still left product_composition_activation_event.evidence_bundle_sha256 nullable. That meant direct durable activate/rollback rows could be appended without external authorization evidence even though the product API used AuthorizedPostgresActivationRegistry.

Ordinary-forward repair now on #437:

• e128da1be750dc3c0ed121981ed6208c351d1ea5 — RED contract for current-schema mandatory evidence.
• 501dbfb23e1b9d30aa2846d4fcbbacb2f8bb6b1a — migration 0020_product_composition_activation_authority_enforcement.sql; fails closed if historical NULL-evidence events exist, then sets evidence_bundle_sha256 NOT NULL.
• 333cd76a9cfb683550e8fcf6b20dbe954ed60234 + db91f4ff6bd554434f7faaf6b3dd82833d0eda56 — executable native PostgreSQL contract proving unauthorised NULL-evidence activation is rejected while evidence-bound activation remains admissible.

Owner invariant for #435 is therefore stricter: structural NULL-evidence transitions may exist only as predecessor-schema/unit/migration/fault fixtures; the current durable production schema must require exact evidence attribution on every activation event. Existing prerelease databases with such rows must stop migration for explicit reconciliation rather than silently grandfathering them.

[seonghobae]

Fresh owner-path update: Draft #437 advanced ordinary-forward from db91f4ff6bd554434f7faaf6b3dd82833d0eda56 to exact 2cc217bf07dedb9ebd61bfa95d776b0062b319d6 (61 commits / 21 files), still directly stacked on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07.

Fresh review found a separate process-local evidence-integrity defect. ReleasedAuthorityEvidence, OwnerOperationObservation, and ActivationAdmissionEvidence were frozen dataclasses but could still be valid-to-valid retargeted with low-level object.__setattr__ after construction; current validation checked their current shape/coverage/freshness, not their original construction identity. That allowed an already-created external authorization object to be reinterpreted as another syntactically valid authority release, observation, or authorization-decision digest before durable attribution.

Ordinary-forward repair:

• eaeab4941da0169551dc27e0dc3cf6570a325f60 adds RED regressions for released-authority, owner-observation and activation-evidence retargeting.
• 2cc217bf07dedb9ebd61bfa95d776b0062b319d6 adds closure-private weak-reference construction snapshots for all three value types and revalidates nested evidence at admission, digest projection, row projection and durable persistence boundaries.

This is deliberately process-local integrity only; PostgreSQL rows, immutable release coordinates and transition/coverage constraints remain cross-process authority. A new semantic authorization decision must be a new value object/content-addressed bundle rather than mutation of an existing one.

#435 remains open. Exact #437 still has zero PR-triggered workflow runs and no qualifying independent review, so pytest/PostgreSQL/coverage/Security/SAST/CodeQL GREEN is not claimed. #260 remains the canonical package/service/PostgreSQL execution owner.

[seonghobae]

2026-09-22 currentization: #437 is now exact ed766da25564fea961e2076882599bac9085f07e, stacked 71 ahead / 0 behind on #436 exact 98b4b129073a2afc70f8a533e34c31fdcc15ab07.

Fresh durable-authority finding: the Python re-admission layer already rejected OwnerOperationObservation.observed_at_unix_ms values later than its current clock, but predecessor PostgreSQL truth (through 0020) did not. A direct database writer could therefore persist an exact owner-operation observation claiming knowledge from the future and retain it as activation evidence.

#437 repairs this ordinary-forward with migration 0021_product_composition_activation_observation_wall_clock.sql: fresh owner observations are rejected when observed_at_unix_ms > PostgreSQL clock_timestamp() or when already stale at insertion. The migration also refuses to upgrade predecessor history containing impossible future-dated observations instead of silently grandfathering them. Historical rows that are merely expired are retained as immutable history; current event admission already prevents reuse after expiry.

Current schema order for this owner path is now 0018 -> 0019 -> 0020 -> 0021. Native current-schema and upgrade contracts are tests/test_product_composition_activation_observation_wall_clock_postgres.sh and tests/test_product_composition_activation_observation_wall_clock_upgrade_postgres.sh, both executable at the current head. This remains Draft implementation evidence, not protected/buyer-ready authority: canonical #260/#311 execution, exact-head coverage/gates, qualifying review, and real immutable Keyverse/Orgmetra/owner release evidence are still required.

[seonghobae]

Fresh #437 review found a durable recovery-lineage gap: predecessor recover_active() obtained fresh authorization_action='recover' evidence and rejected concurrent state change, but the successful restart re-admission existed only in the returned Python value. It vanished on process exit, so durable history proved the historical activation decision but not which fresh external evidence re-admitted that state.

Ordinary-forward owner repair is now on #437 exact 27b82cc74a60838d57d31aa0a2ed3a131b243b95: RED e34c207...; migration 0022 f6e6d17... adds append-only product_composition_recovery_attestation; 5a61fa0... adds locked structural recover_active_authorized(); 60f0928... wires product recovery to persist fresh evidence + attestation only after exact active sequence/generation recheck; regressions 34174aa.../6d2ce43...; native PostgreSQL contract bddaec1..., executable-mode 94accd7...; static DB contract 27b82cc....

Current schema lineage is now 0018→0019→0020→0021→0022. Remote verification remains outside the deployment lock; the DB lock is used only for exact-state recheck, evidence persistence and attestation append. Keep #435 open: no hosted exact-head GREEN, real immutable external release evidence, protected integration or buyer-path acceptance exists yet.

[seonghobae]

Fresh durable-authority finding repaired on #437.

Exact head is now 012c90889ea78db4baa18a2a7973717d00301be1 (84 ahead / 0 behind #436). Review found migration 0021's predecessor-history check was not atomic with installation of its permanent wall-clock INSERT guard: the DO preflight and later CREATE TRIGGER ran as separate autocommitted statements, so a concurrent predecessor-schema writer could insert future-dated owner evidence after the scan and commit while trigger creation waited.

Ordinary-forward repair: 0c4e497... RED requires an explicit transaction + writer-conflicting fence; e61fdcc... wraps 0021 in BEGIN/COMMIT and takes SHARE ROW EXCLUSIVE before the scan through trigger creation; 012c908... converts the native upgrade contract into a concurrent-writer case that distinguishes the fenced migration from the predecessor behavior.

The policy itself did not change: future-dated owner observations remain impossible durable authority. This repair makes the upgrade path enforce that claim under concurrency. Keep #435 open: exact-head canonical execution/review, actual immutable external releases, deployable composition, recovery/fault/security and buyer-path performance acceptance are still outstanding.

[seonghobae]

#437 fresh owner handoff: exact 03eb4b0861a4f1de07c9b66c20f71ab28d378559 adds a source-deterministic RED (7d4ef88e...) and causal repair for migration 0022 publication atomicity. The recovery-attestation table previously became visible after CREATE TABLE before its INSERT/append-only/TRUNCATE guards were installed because 0022 used separate autocommitted DDL statements. A concurrent session could therefore grandfather durable recovery rows that current 0022 policy would reject. 0022 is now wrapped in one explicit BEGIN/COMMIT, so external sessions see either no relation or the fully guarded relation. This hardens upgrade authority only; #435 remains open until canonical exact-head PostgreSQL/coverage evidence, immutable external release evidence, protected integration, and release evidence exist.

[seonghobae]

Owner handoff after fresh durable-authority review: configuration parent #436 advanced ordinary-forward to 6ebe5ec72ddb5d13b8550064cfc33ff1861d39e3 after RED 2c26cbf... proved migration 0018 could publish generation tables before append-only/TRUNCATE guards under autocommit. 0018 is now one explicit BEGIN/COMMIT publication unit. Child #437 was non-force restacked on that exact parent, then advanced to c8886e605e65779f38c813635954546f3e4431a4 after RED a28882e... proved the same publication gap in 0019 activation/evidence/event schema; 0019 now publishes tables/functions/lineage+append-only+TRUNCATE guards atomically. Fresh compare #436→#437 is 91 ahead / 0 behind, merge base exactly #436. Keep #435 open: these are Draft hardening changes, not protected/released activation authority.

[seonghobae]

Fresh #437 authority finding/repair: predecessor 0020 (product_composition_activation_authority_enforcement.sql) scanned for NULL-evidence activation history and published evidence_bundle_sha256 NOT NULL as separate autocommit statements. A predecessor-schema writer could therefore cross the scan/publication boundary; the ALTER still failed closed on a NULL row, but the preflight no longer represented the state being promoted. #437 ordinary-forward commits cc8486c896725b3421a8f43e10658f786c78daa5 (RED) -> fb362d554ab5c0cb2b3c2611aa0d4fa7314e1b32 (fix) now wrap 0020 in one transaction and acquire SHARE ROW EXCLUSIVE on product_composition_activation_event before preflight, held through SET NOT NULL. Keep #435 open: this is migration-authority hardening, not canonical exact-head PostgreSQL/coverage/release evidence.

[seonghobae]

2026-09-22 durable-authority handoff: #437 ordinary-forward exact 035826c9ddb1534290d8ed7957da3c5a45b80da4 adds migration 0023_product_composition_deployment_write_serialization.sql. Fresh review found DB DML was weaker than the application adapter: activation-event INSERT and recovery-attestation INSERT validated different target tables without first contending on one shared deployment-row lock, so concurrent direct SQL could validate against the same predecessor deployment state. RED 2d1d63b...; causal migration d2d78584...; deterministic PostgreSQL lock-wait contract f96798f...; executable-mode successor d8bbf748...; current-schema recovery contract 035826c9.... Current migration order is 0018→0019→0020→0021→0022→0023. Keep #435 open: this closes one serialization gap only; protected exact-head execution, real immutable external authority, HTTP host, recovery/security and buyer-path evidence remain missing.