CounterpediaExplore knowledge. Follow the sources.

/method/source-identity-reconciliation

Source-Identity Reconciliation

Source-identity reconciliation is the public-safe name for a settled internal architecture decision about how Counterpedia names planes, object families, and source identity without claiming authority it does not have. This page explains the decision. It renders no live data, admits nothing, and verifies nothing; it is documentation prose over an already-recorded architecture, not a new capability.

Three planes, not one product

The reconciliation names three separate planes so that no one surface has to overclaim authority over the others.

Semantic / product hub
Counterpedia. Owns Counterpedia-native publication semantics only. It is not universal contract authority.
Data / custody
counterpedia-corpus and the object store. Holds the bytes and custody chain the semantic plane refers to.
Independent proving-ground sidecar
test-corpus. Runs independently of the product hub so proving work does not borrow the hub's authority.

Counterpedia is not universal contract authority. DAGR owns admission, SRS owns receipts, Countergraph owns the graph, and Counterplayer owns research; Counterpedia consumes and references those owners rather than redefining them.

Object families

The object-family registry records which publication object families Counterpedia owns and which it only references. Counterpedia owns counterpedia.content/v0.1, the publication family, plus two newly registered families: counterpedia.claim/v0.1 (CLAIM1, identifier shape cp:claim:<uuid>) and counterpedia.claim_source_binding/v0.1 (ADJ1). Upstream-native srs.editorial.* families are referenced, not owned, by Counterpedia.

Registry status for the two newly registered families is candidate, pending operator ratification. This page does not claim the registry entries are ratified.

Claim disposition C

Claim disposition C settles a routing question, not a new family decision: Stage claim-bindings point toward the already-existing CLAIM1/ADJ1 owner. Disposition C does not create a new claim family; it directs Stage output at the family that already owns claims and claim-source bindings.

Three source-identity axes

Three axes are ratified as the load-bearing distinctions for source identity. Collapsing any of them together is the failure mode this reconciliation exists to prevent naming.

F1 — declared vs resolved locator
declared_locator is not resolved_locator. What a source declares as its location is a separate fact from where that location actually resolved.
F2 — capture-event vs captured-byte identity
A capture event's identity is not the identity of the bytes it captured. Replay binds to captured_bytes_ref and its sha256, not to the capture event.
F3 — work/source to edition to capture to bytes
The chain runs work/source, then edition/version, then capture/artifact, then bytes. Edition is not a source-identity namespace on its own.

The load-bearing invariant across all three axes: never collapse source_candidate, member_source_declaration, resolution_group, locator, digest, and capture into one another. Each stays a distinct fact.

Promotion path — an honest boundary, not a capability

The current, honest promotion path runs: a Stage claim-binding, then an explicit promotion request, then the existing CLAIM1/ADJ1 owner, then governed downstream consumers. A Stage binding is never, by itself, an admitted claim.

That path is not usable end to end. Its claim, SourceEdition and locator resolvers exist (gates G3, G4, and G5), but it also requires a governed issuer for adjudication capabilities (gate G7), which is recorded as an unmet governance prerequisite. This section names a boundary that has not been built yet. It does not describe a capability that exists today.

Durable non-claims

Related method pages