Cryptographic provenance for files, teams, and evidence.
MadeMark turns local macOS workflows into independently verifiable audit trails and exposes them through App Intents, Siri, Shortcuts, Spotlight, Apple Intelligence-ready summaries, and MCP. The action surface is native; the proof model remains signed, witnessed, and independently verifiable.
- native actions
- App Intents
- AI summaries
- macOS 27-gated
- agent tools
- MCP + auditmcpd
What MadeMark 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.
MadeMark-native revisions bind snapshot digests, parent revision IDs, changed paths, and signer identity into signed records.
Prompt/response exchanges, model metadata, human contribution notes, linked paths, and transcript hashes can be recorded as signed evidence.
App Intents and App Entities expose local proof workflows to Siri, Shortcuts, Spotlight, and Apple Intelligence-ready system experiences without changing the signed audit boundary.
Named refs move through signed append-only update records, so reviewers can see which revision a workflow pointer selected.
A live folder can be compared against a signed ref or revision without requiring a .git directory.
Diff records classify changed paths as added, modified, or removed between signed MadeMark revisions.
Local restores materialize file bytes from content-addressed object storage and record a signed revision-restored audit event.
Divergent same-path file states can be recorded as explicit conflict records instead of being hidden inside Git-only metadata.
Human contribution evidence for AI-assisted invention.
Patent-sensitive teams need more than a chat export. They need a signed timeline that shows how humans framed the problem, evaluated AI output, revised the work, and tied the final artifact to those decisions.
Current USPTO guidance treats AI systems as tools, not inventors. A U.S. patent record still needs natural-person inventorship, and AI assistance does not erase a human inventor's contribution when the human conceived the claimed invention.
MadeMark does not declare who legally invented a claim. It preserves the evidence a reviewer needs: the human prompt, the AI response, the selected files, contribution notes, transcript hashes, and the surrounding signed audit chain.
USPTO AI resources →Question, answer, model, and session
AI exchanges are recorded as signed context events with provider, model, tool name, session ID, exchange digest, linked paths, and optional human contribution notes.
Native and CLI transcript files
Transcript files can be registered with ai-monitor. Future scans hash changed bytes, store transcript material as content-addressed evidence, and append aiTranscriptCaptured events.
AI tools can log as they work
auditmcpd exposes auditfinder://ai-collaboration-instructions plus log_ai_collaboration, ai_collaboration_for_path, register_ai_transcript_monitor, and scan_ai_transcript_monitors.
auditctl ai-log /path/to/file \ "What should change?" \ "Use this design constraint." \ session-1 --provider=OpenAI --model=gpt-5 --tool=Codex auditctl ai-monitor <rootID> ./codex-session.jsonl \ "Codex session" --linked=/path/to/file auditctl ai-monitor-scan <rootID>
The record can prove that a particular AI exchange or transcript hash was logged into a signed timeline before or around a file revision. It cannot prove that every undisclosed AI interaction was captured, that the AI output was true, or that a named person is legally an inventor. Those remain review questions.
That conservative boundary is intentional: MadeMark creates verifiable provenance evidence for human and legal review instead of pretending to replace that review.
Deep macOS integration without weakening the proof model.
MadeMark now exposes the signed audit engine through Apple's native automation and intelligence surfaces while keeping raw contents and private transcripts out of the index.
Proof workflows as native actions
Open audited folders, mark folders, show provenance, show activity, log AI collaboration, export proof bundles, submit witness checkpoints, and create secure shares from App Intents.
Provenance that can be found
Audited roots, notable events, witness state, and AI collaboration metadata are projected as App Entities and Spotlight semantic donations using redaction-safe fields.
Summaries without raw disclosure
macOS 27-gated FoundationModels intents summarize provenance and activity digests from metadata, timestamps, linked paths, provider/model labels, and short snippets.
Agent tools stay explicit
MCP remains a separate query and logging surface with its own transport and permissions. App Intents do not turn the app into an unfettered platform MCP server.
Semantic donations are metadata-only: root names, event summaries, timestamps, provider/model labels, linked paths, and short question snippets. Raw file contents, AI answer bodies, Mail bodies, Messages bodies, and full transcripts stay outside the platform index.
What MadeMark 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 decide patent inventorship, authorship, ownership, or claim scope.
- ✕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, branch negotiation, rebasing, packfiles, or CI workflows.
- ✕It does not expose App Intents as a general third-party MCP server.
- ✕It does not feed raw file contents, AI answer bodies, private transcripts, Mail bodies, or Messages bodies to Spotlight or Apple Intelligence summaries.
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 recordsFoundation deterministic JSON
- L3hash-chained append-only feedH(n) commits to H(n-1)
- L4sealed segment filesowner-restricted payload 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
- L9AI collaboration contextprompt + response + transcript hashes
- L10MadeMark revisionssigned snapshot digests + parents + paths
- L11signed ref updatesappend-only workflow pointers
- L12working-tree statuslive folder vs signed ref/revision
- L13revision diffsadded / modified / removed paths
- L14revision restoreobject-store materialization
- L15conflict recordslocal vs incoming file states
- L16Git interop recordsattributed merge lifecycle bridge
- L17selective proof commitmentsevent + artifact Merkle roots
- L18exported proof bundlepedigree-proof-bundle/v1 JSON / .pdg
- L19browser-side Pedigree Inspectoroffline verifier
- L20App Intent action surfaceopen / mark / proof / witness / share
- L21Spotlight/App Entity indexredaction-safe provenance metadata
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.
MadeMark has native versioning. Git stays interoperable.
Developer teams can keep Git for source code while MadeMark records provenance, local revisions, approvals, evidence, and proof bundles for the folders Git was never designed to explain.
Developer workflow interop
MadeMark 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.
Folder-native revisions
For non-code folders, MadeMark records signed revision snapshots, signed ref movement, working-tree status, revision diffs, local restore operations, and explicit conflict records without requiring a .git directory.
Git remains for remotes and CI
MadeMark does not claim native fetch, push, pull, branch negotiation, rebasing, packfiles, or CI ecosystem replacement. Git remains the right tool for source-code collaboration and developer remotes.
The product boundary is deliberate: Git describes developer source history; MadeMark records verifiable chain-of-custody around files, approvals, evidence, secure shares, native folder revisions, and proof export. A verifier can inspect Git-related activity as attributed events without trusting Git as MadeMark’s storage layer.
The native API exposes working-tree status, revision diffs, and restores as structured results: PedigreeWorkingTreeStatus, PedigreeRevisionDiffEntry, and PedigreeRestoreResult. Restore operations can be scoped by path or run with extra-file cleanup, then enter the audit trail as a signed revisionRestored event.
auditctl revision-status <rootID> main auditctl revision-diff <rootID> <toRevisionID> <fromRevisionID> auditctl revision-restore <rootID> <revisionID> --delete-extra
Hybrid quantum-safe signatures
MadeMark production quantum-safe mode signs with a protected P-256 primary lane and an ML-DSA-65 lane over the same canonical payload. Verifiers resolve both keys through the key directory 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 for platform verification and existing PKI.
ML-DSA-65 (FIPS 204)
ML-DSA-65 anchors long-lived evidence against future cryptanalytic capability. Required when quantum-safe verification is selected; 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-proof commitments.
MadeMark exports STARK/FRI-ready commitment 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. |
| ▲ AI inventorship overclaiming | AI records are labeled as provenance evidence and contribution context, not legal authorship or inventorship conclusions. |
| ▲ Metadata overclaiming | Conservative evidence labels and proof interpretation. |
macOS trust anchor
MadeMark’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 are generated by the bundled ARK-compatible signer and stored through Keychain where Security is available.
APFS sealed segments
Owner-restricted segment files with signed closure manifests. Segment hashes are 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 shared by the browser-side Pedigree Inspector and the `auditctl verify` CLI used for local or air-gapped proof-bundle checks.
▸ 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 required
- ·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, and witness signatures carried in the bundle.✓
- 05Check ML-DSA-65 signatures in quantum-safe mode.✓
- 06Recompute selective-proof event and artifact Merkle commitments.✓
- 07Reject malformed STARK/FRI public-input commitments or transcript hashes.✓
- 08Compare local checkpoint against witnessed head.✓
- 09Reject missing subject artifacts or hash mismatches.✓
- 10Warn when proof is local-only and unwitnessed.✓
$ auditctl verify ./proof-bundle.pdg \
--witness="MadeMark Witness" \
--pq-required \
--artifact=./deliverable.wav
[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.
Signed prompt/response records, transcript hashes, linked files, and human contribution notes for patent-sensitive AI workflows.
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 MadeMark’s infrastructure.
Expose audit timelines via MCP and let AI clients log their own collaboration records into verified history.
Use Siri, Shortcuts, Spotlight, and Apple Intelligence-ready summaries to reach App Intent workflows backed by the same signed audit engine.
For verifiers
A reviewer can validate a proof bundle without trusting MadeMark’s cloud, without installing the macOS agent, and without contacting the original signer.
- 01Load a `pedigree-proof-bundle/v1` export in Pedigree Inspector (browser-side, offline).
- 02Verify signatures and hash chains in-browser via WebCrypto and the ML-DSA-65 verifier.
- 03Confirm witness receipts against published witness directory.
- 04Check subject artifact hashes against the included or supplied files.
- 05Review AI collaboration records for linked prompts, responses, transcript hashes, and human contribution notes.
- 06Read 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 MadeMark a blockchain?+
No. MadeMark 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 signed event, checkpoint, segment, and witness records to carry a valid ML-DSA-65 (FIPS 204) lane in addition to the protected P-256 primary lane. Selective proof exports use transparent hash-based STARK/FRI commitment envelopes rather than pairing-based SNARK assumptions.
?How does MadeMark handle AI-assisted invention work?+
AI prompt/response pairs can be logged as signed context events with provider, model, tool, session, linked paths, exchange digest, and human contribution notes. Native or CLI transcript files can also be registered, hashed, stored as content-addressed evidence, and re-scanned for changes.
?What Apple platform functionality is built?+
MadeMark ships App Intents for opening audited folders, marking folders, showing provenance, showing activity, logging AI collaboration, exporting proof bundles, submitting witness checkpoints, and creating secure shares. It also donates AuditedRootEntity, AICollaborationEntity, ProvenanceEventEntity, and WitnessServiceEntity records for system discovery.
?Is App Intents the same as MCP?+
No. App Intents is the Apple-native action and entity surface used by Siri, Shortcuts, Spotlight, and Apple Intelligence-ready experiences. MCP is a separate agent tool surface with separate transport, permission, and query semantics.
?What does Apple Intelligence see?+
Only redaction-safe provenance metadata and short summaries. Raw file contents, AI answer bodies, full transcripts, Mail bodies, and Messages bodies are excluded from the App Entity and Spotlight donation path.
?Does MadeMark prove patent inventorship?+
No. MadeMark does not make legal inventorship, authorship, ownership, or claim-scope determinations. It preserves provenance evidence that can help a reviewer assess human contribution around AI-assisted work.
?Is this zero-knowledge?+
MadeMark exports a quantum-safe selective-proof commitment envelope today: STARK/FRI public inputs, transcript hashes, and Merkle commitments that Inspector and auditctl 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 — MadeMark 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 `pedigree-proof-bundle/v1` JSON record contains the claim, subject artifact digests, sync envelope feed slices, optional snapshot bundle, secure-log segments, key-directory entries, witness receipts, studio witness receipts, and optional selectiveProofs commitment envelopes.
?What does MadeMark 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.