One canonical object. Adapters in, standards bridged.

A small, structured, canonicalizable record.

The current satsignal.provenance.v1 shape is seven top-level keys, three required, four optional, no unknown keys permitted. The record is canonicalized with Satsignal Canonical JSON v1 (SCJ-v1): every string (keys and values) is UTF-8 NFC-normalized, object keys are sorted by Unicode code point, the JSON is serialized with minimal separators and no whitespace, integers are bare decimals, and floats are rejected rather than rounded. The result is hashed with sha256 and the digest is committed to the public Bitcoin SV chain. The full canonical record ships back inside the .mbnt bundle so anyone can re-derive the bytes and verify the anchor without calling Satsignal again.

SCJ-v1 is deliberately not RFC 8785 (JCS). The two rules diverge in two places — SCJ-v1 sorts keys by code point where RFC 8785 sorts by UTF-16 code unit (they differ for supplementary-plane keys), and SCJ-v1 NFC-normalizes strings where RFC 8785 does not — so an off-the-shelf JCS library will compute a different hash on some inputs and a valid anchor will appear to fail. The normative rule, reference implementations, and the cross-language byte-parity corpus live at /spec-provenance §3. (RFC 8785 is used only by the separate satsignal.json.field.v1 selective-disclosure profile — a distinct canonicalization context.)

{
  "schema":  "satsignal.provenance.v1",
  "source":  { "type": "gitlab", "id": "acme/widgets" },
  "subject": { "type": "commit", "digest": "sha256:9f86d0..." },
  "identity":     { "actor": "ci-bot", "repo": "acme/widgets", ... },
  "attestations": [ { "type": "slsa", "digest": "sha256:1b4f0e..." } ],
  "claims":       { ... },
  "privacy":      { ... }
}

Status: draft 1, 2026-05-16. The implementer spec lives at /spec-provenance; the JSON Schema and the conformance suite (backward-compatibility rules, versioning policy, and test-vector layout) ship alongside in the spec directory.

Same canonical packet, many ways in.

The judgement rule for any adapter is one line: does it produce the same satsignal.provenance.v1 object as every other adapter? If yes, it’s a thin ingestion route. If it invents its own proof shape, that’s a bug against this page.

• Direct API — POST /api/v1/anchors (and the structured wrapper POST /api/v1/provenance/anchor).
• CLI / Python helper — satsignal-cli and the stdlib agent_anchor.py helper.
• MCP — satsignal-mcp server exposing anchor_* / lookup_hash / verify_bundle over stdio.
• OpenTelemetry — satsignal-otel processor emitting anchors for marked spans.
• LangChain — langchain-satsignal helpers for the policy-snapshot / commitment / evidence-bundle pattern.
• GitHub Action — Steleet/satsignal-action@v0; analogous bash adapters for GitLab CI, Bitbucket Pipelines, Docker BuildKit, npm, PyPI.
• Webhook — raw-body anchoring with per-source signature verifiers (Stripe, GitHub, Langfuse).
• Object storage — satsignal-blob writes .mbnt + .proof.json sidecars next to objects in S3 / R2 / GCS / Azure Blob.

None of the above is a Satsignal product category. They are capture paths. The product is the canonical model on this page.

Integrity. Timing. Inclusion. Commitment. Nothing more — unless precommitted.

The four things this model establishes — and the things it deliberately does not — are documented as the canonical scope statement on what a proof proves. That page restates the same claims the verifier’s own “what this verifies” panel makes, so neither page can read as a stronger claim than the verifier itself makes.

The single line worth re-reading: a proof binds bytes, not truth. Wider claims (completeness, capture-policy adherence, authority) are possible only when the manifest precommitted them via run_scope, capture_policy, or policy_snapshot_digest before the run began.