Add PM4 operation-tail provenance audit and first-incompatible-sequence diagnostics

[jacksenpierce]

Status

The reported YHX4 database and YHX5 forensic reconstruction are unavailable, so the claimed sequence numbers and tail diagnosis remain unverified. The current PM4 source independently confirms the diagnostic gap: ComposableWorkspace.validate() checks SQLite integrity, foreign keys, the active snapshot's stored-vs-actual state fingerprint, operating mode, and conflicts. It does not walk the operation history or report the first transition that violates PM4's deterministic derivation rules.

Field report: YHX5 non-native PM4 mutation-tail recovery

Problem

A direct writer can satisfy PM4 foreign keys and populate plausible semantic operations, objects, revisions, memberships, snapshots, and a head while bypassing invariants implemented in _mutate() and native mutation methods. Current validation can correctly reject the resulting active fingerprint without explaining where compatibility first failed or which native recipes diverged.

This turns an actionable custody failure into a manual database-forensics exercise.

Proposed contract

Add a read-only PM4 provenance audit command/library method with bounded-tail and full-history modes. It should verify every invariant that can be reconstructed without guessing, including:

• canonical payload_json and its payload_hash;
• snapshot UUID derivation from operation UUID;
• snapshot/operation linkage and parent topology;
• operation-kind-specific object, alias, revision, and membership UUID derivation;
• revision content hashes;
• creation-operation and assertion-operation relationships;
• request/operation receipt relationships, while distinguishing legitimate imported/composed history from missing local mutation receipts;
• local-sequence and head-transition consistency;
• stored snapshot fingerprints where a historical state can be reconstructed safely.

Results should identify the first incompatible operation/sequence, all checked rules, evidence for each mismatch, audit coverage, and whether the likely class is corruption, unsupported historical version, external materialization, or inconclusive. The validator must avoid claiming motive or authorship from invariant failure alone.

Because PM4 composition lawfully incorporates operations originating in other replicas/workspaces, absence from the active replica's local_requests table cannot be treated as a standalone error. Receipt checks must respect origin replica, composition/import contracts, schema/release version, and the boundary between locally emitted and inherited operations.

Acceptance tests

• Native single-parent mutation history passes the full audit.
• Native fork and multi-parent composition histories pass without demanding local receipts for inherited operations.
• Tampering with each deterministic UUID/hash/linkage rule identifies the correct first incompatible transition.
• A structurally valid synthetic tail with a wrong active fingerprint receives useful operation-level diagnostics.
• Unknown future/legacy operation kinds are reported as unsupported coverage, not falsely corrupt.
• Bounded-tail mode reports its examined range and never implies whole-history validation.
• The audit is read-only and produces a stable machine-readable report suitable for a recovery receipt.

Related work

• Add cold-validated resource-thin PM4 handoff publication #47 covers cold-validated PM4 handoff publication so invalid/stale authorities are less likely to travel.
• Replay/recovery of a diagnosed tail should be a separate custody-sensitive feature.

[jacksenpierce]

Recovery implementation is tracked separately in #51. This issue should remain read-only diagnosis: identify the first incompatible transition, report checked versus unsupported invariant coverage, and produce evidence suitable for—but not authorization to perform—recovery.