Pergamum Pulse Governed-Object Contract Framework and Conformance Harness

Version 1.1 — Stage 7.14B planned-registration support

1. Purpose

Stage 7.14A converts the governance invariants proven through Governed Requirement Admission and Target-State Reconciliation into reusable infrastructure.

The framework SHALL prevent later Pergamum Pulse capabilities from independently reinventing:

• canonical identity and exact-version semantics;
• lifecycle and historical-resolution rules;
• authority ceilings;
• provenance and scope immutability;
• append-only governed persistence;
• serialization and fixed-snapshot requirements;
• topology ordering where topology protection is required;
• TrustGate transaction and callback-capability requirements;
• rollback-residue and historical-reproof expectations;
• exact closure and package-seal requirements.

The framework SHALL not define capability semantics that belong to the capability itself.

For example, Stage 7.14A does not define what constitutes a material impact or dependency. Those semantics belong to Stage 7.14B.

2. Architectural rule

A Pergamum Pulse capability SHALL no longer treat governance correctness as an informal collection of implementation conventions.

Every governed object brought under this framework SHALL have one canonical Governed-Object Contract in the Pergamum Pulse Governed-Object Contract Registry (PP-GOCR).

The contract SHALL state what the object is, what authority it may create, what authority it must never create, which historical and persistence guarantees apply, which serialization semantics are required, and which reusable proofs must pass before the capability can be sealed.

Capability-specific logic SHALL be implemented on top of that contract.

3. Canonical registry

The canonical registry is:

config/system/pergamum-pulse/governed-object-contract-registry.json

Its schema is:

schemas/pergamum-pulse/registry/0.2.0/governed-object-contract-registry.schema.json

The registry ID is PP-GOCR.

The Stage 7.14A registry SHALL retain all three required active reference contracts. Registry validation and proof planning SHALL reject a missing, inactive, renamed or object-type-altered reference contract. A successor requires an explicit reviewed update to the implementation-owned reference baseline; a candidate registry cannot approve its own replacement.

The required active reference contracts are:

Contract	Governed object	Reason included
PP-GOC-RAD	requirement_admission_decision / PP-RAD-	Authority-bearing reference object from Stage 7.12
PP-GOC-CDE	change_detection_event / PP-CDE-	Evidence-only fixed-snapshot reference object from Stage 7.13
PP-GOC-DIF	difference_record / PP-DIF-	Evidence-only exact-difference reference object from Stage 7.13

PP-IA and PP-DA SHALL be added as Stage 7.14B consumers after their capability semantics and dependency direction are frozen.

4. Contract dimensions

4.1 Identity

The contract SHALL bind exactly one object type, registered PP prefix, canonical schema ID and repository schema path.

Active contracts SHALL require exact object/version identity and immutable version identity.

4.2 Governance role

Canonical governance roles are:

observation assessment proposal decision projection generated_artifact validation release activation recovery

A governance role is descriptive. It does not itself grant authority.

4.3 Authority class and grants

The contract SHALL declare one authority class and an explicit grant vector.

Authority dimensions are:

requirement_registry change projection release runtime publication recovery

The initial class rules are:

Authority class	Authority that may be created
evidence_only	none
assessment_only	none
proposal_only	none
requirement_registry_authority	Requirement Registry admission only
change_authority	change authority only
projection_authority	projection authority only
validation_evidence	none
release_authority	release authority only
activation_authority	runtime/activation authority only
recovery_authority	rollback/withdrawal/recovery authority only

The harness SHALL reject any contract that enables an authority dimension outside its declared class.

The canonical JSON Schema SHALL encode the same class-to-grant ceilings as the TypeScript validator so schema-only and runtime validation cannot disagree on an authority boundary.

Each active contract SHALL pin both the PP-GOCF framework version and the code-derived framework-ruleset digest. A change to authority-class semantics, the generic-proof catalog, serialization strategies or mandatory TrustGate guarantees therefore requires an explicit contract migration rather than retroactively weakening existing registrations.

This is the reusable authority-escalation barrier for Stages 7.14 through 7.22.

4.4 Authority carrier

Authority may be carried either directly in an exact document field or by the governed contract registry where the object is structurally evidence-only and carries no authority field itself.

Every governed-object schema SHALL expose a closed x-pp-authority-grants schema annotation covering all canonical authority dimensions. The annotation SHALL equal the PP-GOCR grant vector exactly.

Every contract SHALL bind every authority dimension exactly once. A document-field carrier SHALL additionally bind each authority-bearing document field to its dimension and exact schema constant. A registry carrier SHALL declare no document-field paths. Undeclared fields have no authority semantics and SHALL NOT be consumed as authority by downstream services.

The schema annotation, class ceiling, grant vector and exact field bindings form one closed authority surface; disagreement fails conformance.

Authority checks SHALL traverse the resolved schema graph at the logical document property path, including referenced fragments and composed schemas. The same local reference resolver SHALL construct the executor subject's transitive schema closure. Same-file fragments, relative references within the governed schema tree and canonical ZAYAZ schema references SHALL resolve exactly; missing files, missing fragments, unsupported reference forms and paths escaping that tree SHALL fail conformance. Explicit false property constraints in a conjunction SHALL continue to prohibit inherited authority fields.

Authority classification SHALL inspect every resolved logical property path against the implementation-owned field catalog. Every field SHALL be classified explicitly as authority, evidence reference, container or recorded data. New fields SHALL fail closed independently of their vocabulary; schema-owned annotations SHALL NOT supply a default classification. Literal property names containing logical-path separators SHALL fail conformance.

Only fields classified as authority may appear in the authority inventory. Containers SHALL NOT exempt descendants, and evidence references SHALL retain their exact resolved shape requirements. Names such as admin, role, veto, can_write, execution_enabled or an unfamiliar neutral spelling SHALL NOT bypass classification. Existing actor-role metadata remains descriptive data at its explicitly reviewed path. Schema/profile migrations SHALL review every new path and migrate the immutable runner.

Governed namespaces SHALL admit only finite, explicitly named properties. Nonempty patternProperties, open additionalProperties or unevaluatedProperties, and implicitly open object schemas SHALL fail conformance. Object closure SHALL be established after resolving references and conjunctions; partial allOf refinements may rely on the closed base schema. Every alternative and conditional schema SHALL be checked. Array items, tuple positions and contains schemas SHALL preserve this closure, and unconstrained array tails or recursive property namespaces SHALL fail closed. Replacing a property-name pattern with a wildcard in the logical-path inventory SHALL NOT establish authority closure.

The existing reference contracts retain these exact opaque data profiles:

Contract	Logical path	Fixed schema
PP-GOC-RAD, PP-GOC-CDE, PP-GOC-DIF	object_version.applicability.conditions[]	{"type":"object"}
PP-GOC-DIF	previous_value, current_value	{}

These fields carry applicability data or observed difference values and SHALL NOT be consumed as authority. An opaque-data exception SHALL match the exact logical path and literal fixed schema declared by the immutable framework. It SHALL NOT exempt added children, patterns, references, compositions or other changed constraints from the normal authority checks. New opaque data profiles require a reviewed immutable proof-runner migration and fresh source proof.

The following existing evidence paths may remain outside the grant inventory only under these exact profiles:

Logical path	Closed evidence profile
identity.external_identifiers[].issuing_authority	String with minLength: 1; no object or added children
object_version.provenance.projection_manifests	Unique array of exact Core 1 object-ID strings or exact versioned-object references
object_version.provenance.change_decisions	Unique array of exact Core 1 object-ID strings or exact versioned-object references
RAD semantic_review_decision	Exact canonical versioned-object reference narrowed to review_decision
RAD decision_class	Constant requirement_admission
RAD authorization	Required string decision_id and constant permission_code of pp.knowledge.admit; no additional fields
RAD trustgate	Required string event_id, hexadecimal SHA-256 policy_set_hash and constant decision of pass; no additional fields

Every exception SHALL match its fixed resolved constraint tree, including required fields, object-ID/version/type patterns, array uniqueness, the exact branch set and digest alternatives. Expected profiles SHALL be declared in the immutable framework implementation and SHALL NOT be derived from candidate schema bytes. References and conjunctions may express the same profile; removing constraints or adding otherwise reference-like children SHALL fail.

These profiles identify prior evidence; they do not grant runtime authority. Boolean grants, open objects, altered field constraints and new children under these paths SHALL fail conformance, including when introduced through references or composition. Changing a closed profile requires a reviewed immutable proof-runner migration.

4.5 Lifecycle

Active contracts SHALL declare payload immutability, historical resolution, retroactive-mutation prohibition and tombstone semantics where applicable.

The framework SHALL distinguish lifecycle policy from capability semantics.

4.6 References

Active governed references SHALL be exact object/version references.

The contract SHALL declare whether reference types are checked and whether declared digests are rebound to canonical persisted digests.

4.7 Provenance

Active contracts SHALL require immutable provenance and exact source versions.

The contract SHALL also state whether scope is bound and timestamps use the canonical timestamp profile.

4.8 Persistence

The contract SHALL declare append-only treatment, canonical payload mirroring, the canonical payload column, required persistence relations, implementation files responsible for persistence, and post-persist reproof.

Repository inspection SHALL verify that the declared implementation closure resolves, but string presence is not persistence proof. canonical_persistence, lifecycle, historical-reproof, rollback-residue and exact-closure claims SHALL bind to an executable database proof executor that exercises the canonical persistence boundary.

4.9 Serialization

Every active contract SHALL declare its serialization requirements.

This requirement is universal even where serialization.required is false.

The framework SHALL NOT require Stage-7.13 topology mechanics for objects that do not need them.

A contract that declares fixed_snapshot=true SHALL also declare serialization is required and one or more serialization domains.

A contract that declares topology protection SHALL require serialization, declare at least one exact conflict domain and choose an explicit strategy. Canonical strategies include parent_first, canonical_total_order, single_domain and commit_revalidation. Parent-first acquisition is required only when the selected strategy is parent_first; topology protection is not synonymous with Stage-7.13 parent-before-child locking.

Lifecycle-writer symmetry and a pre-transaction marker remain separately declared mechanisms.

4.10 TrustGate

A TrustGate-governed persistence contract SHALL declare an exact operation profile, TrustGate transaction ownership, callback capability revocation, immutable scalar parameter snapshots, in-flight query drain before transaction settlement and prohibition of arbitrary callback SQL.

The trustgate_capability proof SHALL bind to and execute the confined Atlas TrustGate test executor; profile-name string presence is not conformance evidence.

A non-TrustGate contract SHALL not retain a latent operation profile or transaction/callback authority.

5. Generic versus capability-specific proof

5.1 Generic proofs

The baseline generic proof set is:

registered_identity schema_identity_binding authority_ceiling exact_version_references lifecycle_immutability provenance_immutability canonical_persistence serialization_contract historical_reproof rollback_residue exact_closure package_seal

Conditional generic proofs include:

fixed_snapshot_serialization trustgate_capability

A capability cannot remove a required generic proof merely because its own tests already cover similar behavior.

5.2 Capability proofs

Capability proofs remain owned by the capability.

Examples from Stage 7.13 include:

stage713_reconciliation_deterministic difference_set_exact difference_property_claim_enforced pretransaction_marker_identity_attested observation_only_authority

The generic framework SHALL not redefine what these capability-specific terms mean.

Every declared generic and capability proof SHALL bind exactly once to a registered proof executor. A proof label without an executable binding is invalid. Each executor owns an explicit proof-ID set and, where capability-specific, an exact governed subject profile. Binding an arbitrary proof label to an executor is invalid, and changing the subject's schema, persistence target, authority class, serialization strategy/domains or TrustGate profile invalidates the executor binding until the executor profile is explicitly migrated.

Repository/static proofs execute inside the registry guard; source-phase deterministic, database, concurrency and integration executors run before sealing. A successful source run writes a local source-proof receipt keyed to the exact source commit, framework-ruleset digest, executor set, contract versions and proof IDs. The receipt separates a deterministic claim digest from the non-deterministic run timestamp.

Each source executor SHALL receive an exact request containing the source commit, framework-ruleset digest, contract/version, full blob-bound subject profile and requested proof IDs. Its test implementation SHALL admit only the concrete subjects it exercises. It SHALL emit a fresh subject/proof attestation after its assertions complete. The harness SHALL reject absent responses and missing, extra, duplicated, substituted or mismatched attestations. An invocation, exit status or catalog profile alone SHALL NOT count as proof. Registering a new PP-IA or PP-DA catalog profile SHALL NOT extend a Stage 7.13 test implementation.

The local receipt is not itself trusted evidence. Pull-request CI SHALL invoke an immutable, commit-pinned reusable workflow whose implementation is separate from the candidate source. The called workflow SHALL check out its own implementation through its job workflow identity, install its pinned dependencies without lifecycle scripts, compile only the immutable runtime and dispatch absolute entry points from that immutable tree. The complete loader runtime, imported Atlas TrustGate and Pergamum policy runtime, package/module configuration and executable tests SHALL belong to the frozen inventory. Before any worker launch, candidate bytes and inventory SHALL match the reviewed runtime snapshot. Candidate working directories bind the measured source subject; they SHALL NOT select executable imports, tests, providers or configuration. Candidate npm proof commands and candidate-created aggregate receipts SHALL NOT be consumed as evidence. The trusted parent SHALL reconcile every subject/proof result and independently construct the complete canonical claim, including the actual trusted-runner commit, before comparing both that claim and its digest with the committed seal. Proof executors SHALL NOT receive the expected claim digest. CodeBuild/Aurora SHALL remain the live database proof host with verified TLS.

The Aurora credential SHALL be available only to immutable orchestration and the immutable database worker, never to candidate entry points or candidate runtime modules. Candidate code SHALL NOT be compiled or executed in the secret-bearing replay job. Altered runtime blobs, module configuration or import-time credential readers SHALL fail before worker launch. Arbitrary candidate execution requires a separate disposable environment with least-privilege database credentials and enforced network/database confinement; the existing Aurora replay SHALL provide no fallback to such execution. The reviewed immutable runtime remains the privileged code boundary.

Every action executed by the reusable replay workflow SHALL use a full commit SHA from its official repository. .github/pp-gocf/action-pins.json SHALL record the exact reviewed action inventory, and immutable policy checks SHALL reject movable tags, changed SHAs or unreviewed actions. The replay Node runtime SHALL also be an exact version. Changing these pins requires an immutable runner migration and fresh source/seal proof.

The immutable replay SHALL authenticate its requested head against GitHub’s caller pull-request context before reading candidate files. Both checkout and executor input SHALL derive from github.event.pull_request.head.sha, never from caller-selected commit inputs. Missing or mismatched head identity, a different repository or a non-pull-request event SHALL fail. A valid older seal SHALL NOT prove the current PR head. Hosted replay SHALL always verify the seal and reconcile the complete claim; the caller SHALL NOT be able to select a source-only mode.

The immutable runner pin is recorded in .github/pp-gocf/trusted-runner.json. Test-driver, proof-policy, frozen-runtime or new-subject changes require an independently reviewable runner migration and a new immutable pin; changing the candidate catalog cannot mutate an existing trusted executor. Changes to executable runtime dependencies SHALL NOT borrow a prior privileged driver snapshot. SQL changes continue to require the normal framework-ruleset repin and fresh source/seal proof against the installed database closure. The root of trust is the reviewed immutable workflow selection; arbitrary changes to that selection require review.

The package-manifest generator and verifier SHALL share one inventory implementation, which SHALL also belong to the immutable driver inventory. Only generated directories dist, node_modules and .local at the object-loader root, and the root .DS_Store file, may be excluded. Nested paths with those names SHALL remain sealed. Symlinks and nonregular entries SHALL fail inventory construction.

The guard workflow SHALL trigger for every semantic-closure and frozen-driver file on both pull requests and pushes to main. .github/pp-gocf/guard-paths.json SHALL maintain the canonical filters; node .github/pp-gocf/trusted-source-proof.mjs --sync-guard-paths SHALL materialize both workflow path lists. Policy regression checks SHALL require exact list equality and complete semantic/frozen inventory coverage.

The package-manifest verifier SHALL be part of the immutable driver inventory. Hosted orchestration SHALL import the verifier and its shared inventory helper from the immutable checkout and pass the candidate repository only as the measured data root. It SHALL NOT start the candidate verifier script. A modified or missing verifier SHALL fail proof validation even when the candidate has repinned its framework digest and supplied a replacement seal.

6. Conformance lanes

The conformance planner maps generic proofs to reusable execution lanes.

Lane	Typical purpose
static	registry/schema/authority/contract structure
deterministic	deterministic algorithm or digest proof
database	canonical persistence, historical reproof, lifecycle integrity
concurrency	fixed-snapshot or serialization race proof
integration	TrustGate/Atlas/runtime-boundary behavior
seal	exact source-to-package provenance
capability	capability-owned semantic proof

The framework may add new generic proof IDs only by explicitly registering their execution lane, an executor-owned proof ID and a compatible executor path. Serialization strategies other than none SHALL require a strategy-specific concurrency proof; Stage 7.13's executor currently attests serialization_strategy_parent_first only.

Unknown generic proof names, unknown executors, missing bindings and lane/executor mismatches SHALL fail closed.

The GitHub PP-GOCF Contract Registry Guard is deliberately a repository guard, not a claim that live database/concurrency/integration proofs ran on a hosted runner. Full source proof closure is produced by the executable source phase before sealing; exact package provenance is then proven by the seal phase.

7. Harness implementation

The initial implementation is located in the Governed Object Loader because the loader is the canonical Pergamum Pulse persistence boundary:

code/infrastructure/pergamum-pulse/object-loader/src/governed-object-contract.ts code/infrastructure/pergamum-pulse/object-loader/src/governed-object-conformance.ts code/infrastructure/pergamum-pulse/object-loader/src/governed-object-contract-selftest.ts code/infrastructure/pergamum-pulse/object-loader/src/governed-object-proof-runner.ts

The repository guard runs with:

npm --prefix code/infrastructure/pergamum-pulse/object-loader run test:stage714a:registry

The executable source proof closure runs before resealing with:

npm --prefix code/infrastructure/pergamum-pulse/object-loader run test:stage714a:source

After the source proof succeeds, prepare the governed closure seal while still on the proven source commit:

npm --prefix code/infrastructure/pergamum-pulse/object-loader run prepare:stage714a:seal

Then regenerate the object-loader package manifest from that same source commit, commit exactly the two seal artifacts, and run:

npm --prefix code/infrastructure/pergamum-pulse/object-loader run test:stage714a:seal

The seal verifier SHALL require the proven source to be the direct and only parent of the seal commit; merge commits, sibling commits and merely-count-equivalent histories are invalid. The seal commit SHALL change exactly:

• the object-loader package manifest; and
• the PP-GOCF conformance seal.

The PP-GOCF conformance seal SHALL embed the source-proof receipt and deterministic source-proof claim digest and hash the complete active contract/framework implementation closure. Executor subjects SHALL bind the canonical schema path plus its transitive local $ref blob closure and every declared implementation file path/blob. The framework ruleset SHALL include the entire tracked object-loader src/**/*.ts tree, all Atlas TrustGate runtime sources, TrustGate tests, governed SQL, package manifests and lockfiles, trusted-runner policy and CI wiring, validator/proof machinery and normative framework semantics. Imported loader runtime changes therefore invalidate the framework pin. The loader package manifest remains the object-loader sub-seal.

The harness SHALL, at minimum:

1. validate PP-GOCR against its JSON Schema;
2. prove registry IDs, object types and prefixes are unique;
3. bind every active contract to the canonical Object & Prefix Register;
4. reject authority escalation outside the declared authority class;
5. reject incomplete active lifecycle/reference/provenance baselines;
6. reject fixed-snapshot contracts without serialization domains;
7. reject incomplete TrustGate contracts;
8. prove schema ID, prefix and object type constants match the contract;
9. prove the closed schema authority annotation and all declared document-field authority constants match the contract;
10. prove every declared generic and capability proof has exactly one compatible executor binding;
11. prove canonical persistence is assigned to a source-phase database executor rather than a string-presence check;
12. prove TrustGate capability is assigned to the confined Atlas executor with scalar-parameter, drain and arbitrary-SQL protections;
13. prove topology contracts identify a real serialization boundary and explicit strategy;
14. prove each contract pins the exact framework ruleset semantics;
15. execute source-phase proof executors before sealing and the exact manifest verifier after resealing.

8. Stage 7.14A non-goals

Stage 7.14A SHALL NOT:

• change Requirement Registry authority;
• change Stage 7.13 PP-CDE or PP-DIF semantics;
• create PP-IA or PP-DA;
• define impact categories;
• define dependency direction or dependency risk;
• create Change Candidates;
• create Change Decisions;
• create projection, release or runtime authority;
• replace capability-specific tests with generic assertions;
• force every future object to use Stage-7.13 topology or marker mechanics.

9. Stage 7.14B entry criterion

Stage 7.14B may begin capability implementation only after PP-IA and PP-DA have governed-object contracts that declare, at minimum:

• identity and prefix;
• assessment-only authority class;
• exact upstream evidence requirements;
• lifecycle/provenance treatment;
• canonical persistence relations;
• serialization requirements;
• TrustGate requirements, if any;
• generic proof plan plus exact executor bindings;
• per-contract PP-GOCF framework/ruleset pin;
• PP-IA/PP-DA capability-specific proofs.

The framework SHALL reject PP-IA or PP-DA if either attempts to create Requirement Registry authority, Change Decision authority, projection authority, release authority, publication rights or runtime activation authority.

PP-GOCR schema 0.3 distinguishes executable proof bindings from planned proof proposals. A contract with status: planned SHALL have an empty conformance.proof_bindings array. Its exact future executor mapping MAY be recorded only under planned_registration.proposed_proof_bindings, where it is non-executable data bound to the reviewed proposal. The planned-registration flags for schema, persistence and proof execution SHALL remain false. The referenced payload schema SHALL reject every instance. Registry loading SHALL verify the exact review-package bytes and declared schema, and every conformance entry point SHALL reject planned contracts.

The planned PP-IA and PP-DA entries satisfy the registration boundary only. They do not implement payload validation, persistence, capability proofs or admission. Changing either entry to active, accepting payloads, or adding an executable proof subject requires a separately reviewed framework/trusted-runner migration, implemented schemas and persistence, and fresh source, seal and independent proof evidence.

10. Later-stage reuse

Stages 7.15–7.22 SHALL extend the registry rather than invent parallel governance rules.

The intended authority progression is:

7.14 PP-IA / PP-DA assessment-only 7.15 PP-CC / CCP / CCF proposal-only 7.16 PP-CD / DCO change authority 7.17 PP-PRJ projection authority / eligibility 7.18 PP-CEX / PP-GA generated artefact; no self-release 7.19 PP-VR validation evidence 7.20 PP-REL release authority 7.21 PP-ACT runtime activation authority 7.22 PP-RBK/PWD/CIN recovery / withdrawal / incident governance

No later-stage object may obtain a stronger authority merely because an earlier object exists.

Each authority-bearing transition SHALL be explicit in the object's Governed-Object Contract and proven by the Conformance Harness.

11. Stage 7.14A closure condition

Stage 7.14A is complete when:

1. PP-GOCR is schema-valid;
2. PP-RAD, PP-CDE and PP-DIF conform as active reference contracts;
3. adversarial contract mutations fail closed;
4. the object-loader TypeScript build passes;
5. test:stage714a:registry passes;
6. test:stage714a:source executes the bound deterministic, DB/concurrency and TrustGate proof closure successfully;
7. package-manifest provenance is resealed only after the source proof set is green;
8. test:stage714a:seal executes the exact package-manifest provenance verifier against the sealed head;
9. review finds no material unresolved governance gap.

The objective is not fewer proofs.

The objective is that later capabilities inherit the proofs automatically instead of rediscovering the governing invariants during review.

Reviewed field semantics and installed SQL reconstruction

Every resolved property path in RAD, CDE and DIF must have an explicit, implementation-owned classification in governed-field-classifications.ts: authority, evidence reference, container or recorded data. Unknown paths fail closed regardless of spelling, including paths introduced through references and composition. Containers do not exempt descendants. Evidence references retain their exact shape checks, and authority fields must match the declared surface. A schema/profile migration must review added fields and migrate the immutable runner; candidate annotations cannot classify their own permissions.

Database evidence requires complete migration-014 and postflight bytes to match the immutable runner's reviewed SQL profile before connecting. The database executor verifies installed definitions both before the integration probes and before issuing attestations. Within an unconditionally rolled-back transaction it fences PP table writers, reconstructs the migration-owned tables, sequences, view and added column, applies the reviewed migration and postflight, then compares PostgreSQL's canonical definitions with the installed catalog. Functions, triggers, columns, constraints, indexes, views, sequences, policies and rules are compared as complete definitions, not substring inventories. Function and relation comments from pg_description are included, covering all nine migration-owned function/view comments. Rollback-only live probes require both changed text and removed comments to fail the exact comparison. Reconstruction prevents IF NOT EXISTS from treating an altered installed object as its own expected definition.

This verification takes exclusive PP table locks with a bounded timeout and must run against the integration proof database without conflicting workload. It does not commit schema or backfill changes. A replay, catalog or rollback failure withholds the executor response, and the reconstruction backend is destroyed. Migration inputs are also frozen by the privileged replay driver: changes require an independently reviewed runner migration, not only a new candidate ruleset digest or seal.

Migration-owned function ownership and ACLs SHALL be checked independently of reconstruction, because PostgreSQL preserves them during CREATE OR REPLACE FUNCTION. The reviewed Stage 7.13 deployment profile requires owner zayaz_admin and exactly the default EXECUTE ACL entries for PUBLIC and that owner, granted by that owner without explicit grant options. NULL ACLs are expanded with PostgreSQL's default function ACL before comparison. Missing or extra grants, changed grantors, grant options and owners fail closed; no installed values define the expected profile. Changing the deployment security profile requires review and an immutable runner migration. Live rollback-only probes revoke the PUBLIC and owner entries and require rejection.

The package manifest SHALL preserve every non-generated field from the exact proven source manifest, including authority, lifecycle, description and any future metadata. Only files, source_repository_commit, manifest_generated_from_worktree, source_worktree_dirty and manifest_generated_at may be regenerated; generated flags and timestamp syntax are validated independently. The generator, standalone manifest verifier and full seal verifier SHALL enforce this shared policy. Adding, removing or changing a safety claim in the seal commit fails; a metadata change must first belong to the source commit that undergoes proof execution.