release: implement site registry v0.4 trust pipeline

docs/adr/0001-typed-source-coverage.md

@@ -0,0 +1,26 @@
+# ADR 0001: Typed source coverage and supersession
+
+Status: Accepted, 2026-09-13.
+
+Source snapshots declare `full`, `partition`, or `delta` coverage. Partitions use
+stable disjoint coordinates. Deltas name one exact base, a consecutive sequence,
+and every directly superseded object. The build rejects ambiguous frontiers,
+cycles, missing bases, cross-source links, overlaps, and mixed legacy/typed active
+sets. Older objects and facts remain available for audit.
+
+Free-form scope strings were insufficient to distinguish replacement from
+composition. Explicit coverage makes selection reproducible and prevents a
+partial object from silently replacing unrelated source data.
+
+## Rejected alternatives
+
+Selecting the newest retrieval time repeats the v0.3 ambiguity and lets clock
+skew choose authority. Treating every object as additive retains deleted facts.
+Inferring overlap from source URLs or file names is source-specific and unsafe.
+
+## Compatibility
+
+V1 manifests remain isolated by exact provider and scope. A typed object may
+replace legacy evidence only by naming its exact manifest ID in `supersedes`.
+Readers that do not understand v2 must reject it. See the source-manifest and
+coverage contracts in [FORMATS.md](../FORMATS.md).

docs/adr/0002-granular-trust-subjects.md

@@ -0,0 +1,23 @@
+# ADR 0002: Separate names, website edges, and observations
+
+Status: Accepted, 2026-09-13.
+
+A name binding, entity-to-property edge, and crawler observation have separate
+identities and decisions. A resolver must admit the matched name and the selected
+website edge. Observations enter evidence bundles but never create ownership,
+identity, or regional roles.
+
+This prevents a new alias from inheriting an existing route and avoids invalidating
+an unchanged route when unrelated entity metadata changes.
+
+## Rejected alternatives
+
+One decision over the whole entity made harmless label changes invalidate every
+route and let an injected alias inherit old authority. Promoting observer signals
+directly would turn redirects or self-authored metadata into ownership claims.
+
+## Compatibility
+
+Legacy review rows remain auditable under the explicit compatibility policy.
+Strict v0.4 resolution requires separate name and edge votes. V2 edge fingerprints
+exclude unrelated entity revision metadata while retaining it in provenance.

docs/adr/0003-votes-revocations-and-publishers.md

@@ -0,0 +1,38 @@
+# ADR 0003: Signed votes, sticky revocations, and publisher separation
+
+Status: Accepted, 2026-09-13.
+
+Reviews are immutable signed votes compiled under a receipt-bound policy epoch.
+The reference policy requires two reviewer identities, two independent groups,
+and two physical SSH keys. One revocation blocks the exact subject until every
+approval in a fresh quorum explicitly references all active revocation IDs.
+Publisher identity and key must be separate from every reviewer vote.
+Changing the policy epoch never clears a retained revocation; a fresh quorum
+under the new policy must explicitly supersede it.
+
+Trusted writer acceptance time bounds validity. Reviewer timestamps cannot
+backdate eligibility or extend an approval beyond 90 days after acceptance.
+
+Risk-class thresholds may raise the base name, edge, or equivalence quorum for
+`source_conflict` and `dangerous_drift`. The reference policy also holds those
+edges in disputed or probationary state until the underlying risk clears.
+
+Emergency feeds are cumulative, use the separate
+`argand-site-registry-revocations` SSH namespace, retain superseded revocation
+IDs, and can be applied to a compatible pinned generation before its replacement
+arrives. Cross-generation feeds only add blocks. Reinstatement requires the exact
+full generation containing the signed superseding quorum, and feed artifacts must
+be refreshed at least every seven days.
+
+## Rejected alternatives
+
+Latest-decision-wins lets one later approval erase a revocation. Counting aliases
+of one key as separate reviewers does not provide independence. Letting a release
+publisher contribute approvals collapses review and publication into one actor.
+
+## Compatibility
+
+Legacy decisions remain available only under the explicit v0.3 compatibility
+policy. Strict receipts bind the policy and reviewer trust-root digests. A policy
+change creates a new epoch and old approvals become stale rather than being
+silently reinterpreted.

docs/adr/0004-active-and-audit-views.md

@@ -0,0 +1,29 @@
+# ADR 0004: Separate active and audit views
+
+Status: Accepted, 2026-09-13.
+
+Normal export contains only selected, nonrejected facts. Audit export preserves
+active, superseded, and rejected facts with an explicit state and rejection
+reason. Neither export bypasses resolver policy.
+
+Operational consumers need an unambiguous current evidence view, while
+investigators and publishers need conflicting and superseded evidence. One
+ambiguous export could be mistaken for an approved route list.
+
+Version 0.4 keeps the complete audit history inside each generation so rollback,
+diff, and incident inspection remain self-contained. Separating a compact runtime
+projection from content-addressed cold audit bundles is deferred to v0.5 until
+size and latency measurements justify the extra recovery surface.
+
+## Rejected alternatives
+
+Deleting superseded facts loses conflict and replacement evidence. Shipping only
+the audit view makes accidental use as current state too easy. Splitting storage
+before authenticated bundle verification exists risks publishing a runtime index
+whose supporting evidence cannot be recovered.
+
+## Compatibility
+
+The normal JSONL envelope is v2 and contains active assertions only. Audit mode
+uses the same envelope version with explicit active, superseded, rejected, and
+tombstoned rows. V1 consumers must reject the new schema and migrate explicitly.

docs/adr/0005-full-delta-release-identity.md

@@ -0,0 +1,30 @@
+# ADR 0005: Full and delta release identities
+
+Status: Accepted, 2026-09-13.
+
+Each source object has its own digest. The selected coverage graph, including
+every active full, partition, base, and delta object and its precedence, has a
+separate digest bound into the generation receipt. A future distributed dataset
+delta must name exact base and target generation identities and preserve
+revocation continuity.
+
+An unauthenticated `latest` locator can be a convenience pointer, but never the
+trust root. Consumers authenticate a full receipt pin or publisher signature.
+
+Version 0.4 implements source-level full/partition/delta identity and cumulative
+publisher-signed emergency revocation overlays. General downloadable registry
+deltas remain a v0.6 distribution task because they also need mirror-independent
+base/target authentication and consumer transaction semantics.
+
+## Rejected alternatives
+
+Mutable releases and unpinned `latest` URLs permit substitution and rollback.
+Signing only a compressed archive makes alternate packaging unverifiable. Calling
+a source delta a registry delta would hide changes introduced by review policy,
+normalization, observations, or another provider.
+
+## Compatibility
+
+V2 receipts bind the selected coverage digest. Current pointers retain every
+legacy and vote revocation across activation. Emergency feeds apply only when
+their rules, policy, and reviewer-trust digests match the cached generation.

docs/adr/0006-source-lineage.md

@@ -0,0 +1,24 @@
+# ADR 0006: Source lineage and independence
+
+Status: Accepted design; implementation scheduled for 0.5.
+
+Corroboration must describe the direct provider, upstream dataset, transformation,
+and snapshot. Two providers that copied the same upstream assertion do not count
+as independent evidence merely because their URLs differ. Unknown lineage stays
+unknown.
+
+Version 0.4 preserves provider-native provenance and never combines popularity or
+same-domain evidence into ownership confidence. Version 0.5 will add explicit
+lineage fields and independence-aware corroboration without rewriting history.
+
+## Rejected alternatives
+
+Counting provider names as independent evidence rewards copied datasets. Guessing
+lineage from matching text creates another unsupported inference. Dropping a
+source because lineage is unknown destroys useful conflicting evidence.
+
+## Compatibility
+
+The v0.4 policy does not award quorum from source count, so absent lineage cannot
+inflate reviewer authority. Future lineage fields must be additive provenance;
+old assertions remain byte-identifiable and are never rewritten as independent.

docs/adr/0007-distribution-and-embedding.md

@@ -0,0 +1,27 @@
+# ADR 0007: Distribution and proprietary embedding
+
+Status: Accepted, 2026-09-13.
+
+The project prioritizes a standalone AGPL-3.0-or-later CLI and Rust library plus
+signed data artifacts. Broad proprietary embedding is not a 0.4 goal. Consumers
+must assess AGPL obligations for their deployment and comply independently with
+every provider data license and attribution term.
+
+The supported integration paths are the native CLI, reusable Rust reader, signed
+generation format, and documented subprocess protocol. A future change to code
+licensing, dual licensing, hosted APIs, or proprietary linking requires a separate
+governance and legal decision; this ADR does not grant one.
+
+## Rejected alternatives
+
+A second permissively licensed verifier crate was considered for v0.4. It would
+duplicate format and signature policy before the contracts have deployment data,
+and could imply that provider datasets inherit the verifier's license. A network
+API would add account, availability, and traffic-trust requirements to an offline
+dataset component.
+
+## Compatibility
+
+Rust and subprocess consumers use the same receipt and JSON contracts. Broad
+proprietary embedding is outside the supported v0.4 surface. Dataset users must
+still follow each source license regardless of how they invoke the verifier.