Cryptographic provenance for files, teams, and evidence.
Pedigree turns local macOS workflows into independently verifiable audit trails: hash-chained events, signed checkpoints, sealed log segments, witness receipts, hybrid post-quantum signatures, and STARK/FRI-ready selective proof commitments.
- signature lanes
- P-256 + ML-DSA-65
- ZK posture
- STARK/FRI-ready
- key custody
- Secure Enclave
What Pedigree proves
Each claim below maps to a check a third-party verifier can run independently against an exported proof bundle.
The included subject artifact matches its committed hash.
The event sequence has not been silently mutated, reordered, or truncated relative to its signed checkpoints.
The checkpoint was signed by the recorded device key bound in the key directory.
In production mode, signatures include a classical P-256 lane and an ML-DSA-65 post-quantum lane covering the same canonical payload.
A witness receipt proves an off-device service observed a checkpoint head at a specific sequence.
Conflicting or older heads can be detected when compared against witnessed state from independent observers.
Pedigree-native revisions bind snapshot digests, parent revision IDs, changed paths, and signer identity into signed records.
Named refs move through signed append-only update records, so reviewers can see which revision a workflow pointer selected.
Divergent same-path file states can be recorded as explicit conflict records instead of being hidden inside Git-only metadata.
What Pedigree does not pretend to prove
A useful provenance system is defined as much by what it refuses to claim as by what it can verify.
- ✕It does not prove that a statement is true.
- ✕It does not prove a file was never generated by AI.
- ✕It does not make local disk bytes physically immutable.
- ✕It does not require a blockchain.
- ✕It does not expose private file contents to a witness.
- ✕It does not replace Git remotes, branches, checkout, or CI workflows.
Proof architecture
Each layer commits cryptographically to the layer beneath. Verification recomputes the chain top-down and rejects any mismatch.
- L1subject artifact hashingSHA-256 over canonical bytes
- L2canonical event recordsdeterministic CBOR / JCS
- L3hash-chained append-only feedH(n) commits to H(n-1)
- L4sealed segment filesfsync + commit hash
- L5signed segment closure manifestsP-256 + ML-DSA-65
- L6signed feed checkpointshead, root, seq, time
- L7device key directorybinds keys to identities
- L8witness receiptsoff-device observed heads
- L9Pedigree revisionssigned snapshot digests + parents
- L10signed ref updatesappend-only workflow pointers
- L11conflict recordslocal vs incoming file states
- L12Git interop recordsattributed merge lifecycle bridge
- L13selective proof commitmentsevent + artifact Merkle roots
- L14exported proof bundle.pdg portable archive
- L15browser-side Pedigree Inspectoroffline verifier
H(n) = Hash(
seq
|| timestamp
|| canonicalPayload
|| H(n-1)
)Each event commits to the previous head. Checkpoints commit to the feed state. Sealed segments commit to local written bytes. Witness receipts commit to checkpoint heads observed off-device.
Verification recomputes the chain end-to-end and rejects any divergence in hashes, signatures, segment closures, or witnessed heads.
Git stays a bridge. Pedigree owns the proof.
Developer teams can keep Git for source code while Pedigree records provenance around non-code folders, approvals, evidence, signed revisions, and proof bundles.
Developer workflow interop
Pedigree keeps Git merge bridge records for developer workflows: branch names, base and merge-head revisions, resolution state, and committed Git hashes can be attributed in the audit timeline.
Business-file revisions
For non-code folders, Pedigree now records signed revision snapshots, signed ref movement, and explicit conflict records without requiring a .git directory.
Not a full Git replacement
Pedigree does not claim Git checkout, remotes, branch negotiation, rebasing, packfiles, or CI ecosystem replacement. Git remains the right tool for source-code collaboration.
The product boundary is deliberate: Git describes developer source history; Pedigree records verifiable chain-of-custody around files, approvals, evidence, secure shares, native business-file revisions, and proof export. A verifier can inspect Git-related activity as attributed events without trusting Git as Pedigree’s storage layer.
Hybrid quantum-safe signatures
Pedigree production signatures are hybrid by default. Both lanes cover the same canonical payload, and the verifier checks key-directory bindings rather than trusting public keys embedded in signatures.
P-256 (Secure Enclave)
Secure Enclave or non-exportable Keychain P-256 acts as the classical compatibility lane. Wide ecosystem support for HSM-style enforcement, attestation, and existing PKI.
ML-DSA-65 (FIPS 204)
ML-DSA-65 anchors long-lived evidence against future cryptanalytic capability. Required in production quantum-safe mode; classical-only mode exists for ecosystem migration.
canonical payload
Both signatures cover the identical canonical-encoded payload. A divergent payload between lanes fails verification.
key directory
Verifiers resolve signer identity through the device key directory rather than embedded public keys, enabling key rotation and revocation.
witness receipts
Witnesses can themselves sign hybrid receipts, extending PQ assurance through the observation layer.
“Classical where ecosystems need it. Post-quantum where long-lived evidence demands it.”
Quantum-safe selective disclosure.
Pedigree now exports STARK/FRI-ready proof envelopes: public inputs, transcript hashes, and Merkle commitments over event-feed prefixes and subject artifacts. The construction avoids pairing-based SNARK assumptions in the long-term evidence path.
- · Each export can include a pedigree-selective-zk-proof/v1 record.
- · Public inputs bind root, feed, checkpoint hash, sequence, subject paths, artifact hashes, and predicate.
- · Inspector recomputes event and artifact Merkle roots and rejects transcript mismatches.
- · Witnesses still observe only signed metadata, never plaintext payloads.
- · Attach a transparent STARK/FRI proof transcript to the same public-input envelope.
- · Prove policy predicates like approval before T or artifact in witnessed state.
- · Keep verifier assumptions hash-based and post-quantum; avoid Groth16, KZG, pairings, and elliptic-curve commitments for long-lived evidence.
Threat model
Concrete adversary actions and the cryptographic primitives that make them detectable.
| threat | mitigation |
|---|---|
| ▲ Mutation | Hash chain and signature verification. |
| ▲ Insertion / reordering | Sequence numbers and previous-head commitments. |
| ▲ Truncation | Checkpoint comparison and witness latest-head tracking. |
| ▲ Rollback | Witness receipts and peer-observed heads. |
| ▲ Equivocation | Witness rejects conflicting heads for the same root/feed/sequence. |
| ▲ Key compromise | Key rotation, historical public-key records, witness directories. |
| ▲ Metadata overclaiming | Conservative evidence labels and proof interpretation. |
macOS trust anchor
Pedigree’s production macOS runtime uses protected signing keys. Secure Enclave is used for key protection and signing when available; otherwise non-exportable Keychain P-256 is used. The log itself remains on APFS. Security comes from signed checkpoints, sealed segments, and external witness receipts — not from pretending the enclave stores the log.
Secure Enclave / Keychain
Non-exportable P-256 private keys. ML-DSA-65 keys held under Keychain ACLs with biometric or passcode gating where supported.
APFS sealed segments
Append-only segment files with closure manifests. fsync + segment hash captured before signing the closure.
Off-device witnesses
Witness services observe checkpoint heads. Local rollback is detectable against any independently observed head.
“Secure Enclave signs the checkpoints. APFS stores the log. Witness receipts prevent silent rollback.”
Proof bundle verification
The verifier checklist is identical whether you run the Pedigree Inspector in your browser or the pedigree CLI on an air-gapped workstation.
▸ live · pedigree inspector
tamper an event or stale the witness — the failing check turns redevent log · canonical payloads
head: …- seq=0001 · artifact.createH=…subject="design-spec.pdf" sha256=3a9f…b21e2026-04-22T09:14:02Z
- seq=0002 · share.grantH=…recipient="alice@acme.io" scope=read ttl=72h2026-04-22T09:18:41Z
- seq=0003 · approval.signH=…approver="device:enc1.A93F" decision=approve2026-04-22T11:02:17Z
- seq=0004 · checkpoint.emitH=…seq=4 root=<chain-head>2026-04-22T11:02:18Z
verifier checklist
- ·Canonical event encoding
- ·Hash chain recurrence H(n)=Hash(seq‖ts‖payload‖H(n-1))
- ·Chain head matches checkpoint root
- ·ECDSA P-256 checkpoint signature
- ·ML-DSA-65 lane present
- ·Witness receipt observed head
- ·No rollback / equivocation
Hashes computed via crypto.subtle.digest. Signature verified via crypto.subtle.verify against a non-extractable P-256 key. No network calls.
- 01Recompute artifact hashes.✓
- 02Validate event hash chain.✓
- 03Validate sealed segment hashes.✓
- 04Verify event, checkpoint, segment, witness, and bundle signatures.✓
- 05Check ML-DSA-65 signatures in quantum-safe mode.✓
- 06Recompute selective-proof event and artifact Merkle commitments.✓
- 07Reject malformed STARK/FRI public inputs or transcript hashes.✓
- 08Compare local checkpoint against witnessed head.✓
- 09Reject missing subject artifacts or hash mismatches.✓
- 10Warn when proof is local-only and unwitnessed.✓
$ pedigree verify ./bundle.pdg \
--witness=notary.eu1 \
--pq-required
[ok] artifacts: 4/4 hashes match
[ok] chain: 612 events, head=9f82…7d11
[ok] segments: 3 sealed, manifests valid
[ok] sig: P-256 ✓ ML-DSA-65 ✓
[ok] checkpoint @ seq=612 signed by
device:enc1.A93F (key-dir bound)
[ok] witness: notary.eu1 observed
head=9f82…7d11 at t+0.84s
[ok] no rollback, no equivocation
verdict: VERIFIED · 0 warningsUse cases
Concrete deployments where verifiable provenance materially changes the cost of disputing a record.
Provable workflow history for source files: edits, exports, approvals, releases.
Auditable share events with claim receipts, expiration, and recipient acknowledgements.
Cryptographic approval trails suitable for SOX, HIPAA, and ISO 27001 evidence packs.
Link emails (Mail), messages (Messages exports), and manual evidence into the chain with attributed hashes.
A third-party analyst can verify a proof bundle without contacting Pedigree’s infrastructure.
Expose audit timelines via MCP for AI-assisted forensic queries against verified history.
For verifiers
A reviewer can validate a proof bundle without trusting Pedigree’s cloud, without installing the macOS agent, and without contacting the original signer.
- 01Load proof bundle in Pedigree Inspector (browser-side, offline).
- 02Verify signatures and hash chains entirely in-browser via WebCrypto + WASM.
- 03Confirm witness receipts against published witness directory.
- 04Check subject artifact hashes against the included or supplied files.
- 05Read warnings for local-only proofs or missing evidence.
Technical FAQ
Answers in the same voice we’d use in a security review, not a sales call.
?Is Pedigree a blockchain?+
No. Pedigree is a hash-chained, signed, append-only local feed with off-device witness receipts. There is no consensus, no distributed ledger, and no token. Optional anchoring to external transparency logs or public ledgers is a future extension, not a dependency.
?What does the witness see?+
Signed checkpoint metadata: feed root, sequence number, head hash, timestamp, and signer reference. The witness never receives plaintext file contents or full event payloads. It records the latest observed head and signs a receipt.
?What happens offline?+
The local feed continues recording with full hash-chain and device-key signatures. The result is a tamper-evident append-only history. Witness-based rollback and equivocation protection only applies once a checkpoint is observed by a witness.
?What makes a proof quantum-safe?+
Production quantum-safe mode requires every checkpoint, segment closure, and bundle signature to include a valid ML-DSA-65 (FIPS 204) signature in addition to the P-256 lane. Selective disclosure uses transparent hash-based STARK/FRI proof envelopes rather than pairing-based SNARK assumptions.
?Is this zero-knowledge?+
Pedigree exports a quantum-safe selective-proof envelope today: STARK/FRI public inputs, transcript hashes, and Merkle commitments that Inspector can recompute. A full hidden-witness STARK verifier is the next integration step before policy predicates should be marketed as complete ZK proofs.
?Can a privileged attacker delete local files?+
Yes — Pedigree does not claim physical disk immutability. What it does claim is that any deletion, mutation, or rollback becomes detectable when compared against signed checkpoints, sealed segment manifests, and any witness-observed heads.
?How are keys rotated?+
Device keys are bound through the key directory with explicit historical records. Rotation events are themselves signed and chained. Verifiers resolve the signer-of-record at the checkpoint’s time, not at verification time.
?What does a proof bundle contain?+
A canonical manifest, relevant event records, sealed segment manifests, signed checkpoints, witness receipts, key-directory entries, optional subject artifacts or committed hashes, and optional selectiveProofs records for STARK/FRI-ready disclosure.
?What does Pedigree mean by chain-of-custody?+
An attributed, ordered, append-only history of operations on a subject artifact, where each step is cryptographically committed to the previous step, signed by an identifiable device key, and (in production mode) externally observed by a witness.