[pdlug]

What was wrong

openProvenanceStore refused to upgrade a pre-marker provenance sidecar (a sidecar graph id holding Provenance rows and the pre-marker schema, but no ownership marker) whenever the revision-change journal was installed on the database. The refusal was ConfigurationError GRAPH_MERGE_PROVENANCE_ID_COLLISION with reason: "application-graph", whose remediation ("rename the colliding application graph") is wrong advice for a sidecar this library wrote itself.

The journal's triggers are installed per database, not per graph. They record every node write, so each Provenance row the pre-marker sidecar wrote left an entry (entity: "node", kind: "Provenance", id: <row id>) under the sidecar's own graph id. The occupancy probe treats every graph-scoped content relation other than the node table as foreign occupancy in both of its scopes, on the reasoning that a sidecar writes to none of them. That reasoning holds for every such relation except the journal, which the sidecar never writes but the database writes on its behalf.

What changed

In the probe's foreign scope (the scope used only to classify a pre-marker sidecar's contents) the journal is now narrowed the same way the node table already is. A journal entry is accounted for only when it records a node whose row is still stored under the same graph id and that (kind, id). The predicate does not name the Provenance kind itself: the probe reaches the journal only after its node-table lookup found no stored row of another kind, so a stored row an entry can match is a Provenance row, and that row is then verified by isOwnedProvenanceRow like every other row of the sidecar. An excused entry therefore says nothing the node table has not already said and been checked on.

Every other journal entry under the graph id still refuses: an entry for an edge, an identity assertion or a node of another kind records content a sidecar never holds, and an entry for a Provenance id with no row stored under the sidecar graph id records a hard-deleted row that nothing can verify, even when another graph id (a copied sidecar, a colliding application row) stores a Provenance row under the same id. A pre-marker sidecar whose Provenance row was deleted by hand on a journaled database therefore still refuses with the application-graph wording; that is deliberate, since the pre-marker release only ever upserted Provenance rows and never deleted one. The any scope, which decides whether an unregistered id is free to claim, is unchanged: any journal entry at all still refuses there.

The rule is one SQL predicate with one owner (unaccountedJournalEntryFilter), applied by the same probe on both the unfenced preflight and the fenced claim. No relation role, trigger or schema changed. The entity value the journal records per relation is now an exported constant (REVISION_JOURNAL_ENTITY in src/backend/revision-journal.ts) that both trigger builders pass as each trigger's target and the filter matches on; the generated trigger DDL is byte-identical. It is not yet the only spelling: the PostgreSQL trigger function body still compares against an inline 'identity' and the lineage reader in src/store/recorded-capture/lineage.ts still spells entity IN ('node', 'edge'). Moving those two onto the constant is a follow-up. The application-graph row in the error reference states the journal exception.

Cost

A sidecar whose journal entries are all accounted for no longer short-circuits on the first journal row: the probe visits every journal entry for that graph id and checks each against the node table (a per-entry key lookup on SQLite; on PostgreSQL a hashed or per-entry subplan at the planner's choice). It runs on the unfenced preflight and inside the claim's fence, on the one-time pre-marker upgrade only; an owned sidecar is recognized by its marker and never reaches the contents probe.

Revert check

The reproduction (upgrades a legacy sidecar whose own writes the revision triggers journaled) was written first and failed on SQLite, PGlite and server PostgreSQL with the application-graph collision before the fix; it also asserts the journal holds exactly the one (node, Provenance, <row id>) entry, so it cannot pass on a database where the triggers did not fire.

The refusal cases were each checked against a mutation of the predicate, since they pass trivially on unfixed code. Each mutation below was run on SQLite, PGlite and server PostgreSQL, and each named case went red on all three while the rest stayed green. Skipping the journal in the foreign scope turns all five refusal cases red. Dropping the stored-row EXISTS turns the hard-deleted, stored-under-another-graph and node-of-another-kind cases red. Deleting the kind correlation inside the EXISTS (nodes.kind = journal.kind, the predicate's only kind clause) turns only the "node of another kind under the stored row's id" case red. Deleting the entity test turns only the "edge under the stored row's kind and id" case red. Deleting the graph_id correlation inside the EXISTS turns only the "Provenance row stored only under another graph id" case red (the sidecar is upgraded instead of refused), which is why that case exists: the hard-deleted case uses an id stored nowhere and cannot tell a same-graph lookup from a database-wide one.