01 / SIGNED RECORDS
Signed records
Each signature can be checked on its own. The path between records is not yet visible.
OPEN SOURCE / SELF-HOSTED
Trust is not a guarantee of truth. It is the attributability of lies.
Leave a trail your data can prove — the issuer, input, and output of every data handoff, recorded as a signed path recipients can verify themselves.
— A claim you can run beats a claim you can read.
TAMPER DEMO
The forgery stops
at the next boundary
Three organizations, one forged payload. It never reaches downstream — below is the real output of a run.
provin tamper demo — three organizations, one forged payload
[1/6] starting three organizations (manufacturer / distributor / retailer), each with its own registry …
[2/6] manufacturer ingests lot LOT-2026-08-06: signed FirstDrop credential issued (did:dplaax:mfg.poc.dplaax.dev:org:mfg:pipeline:lot-emissions:process:reporter)
credential hash sha256:fdd3e6684bfa495ca0c2e08468260f417000dfb05983b45735f610f3d245029d
[3/6] distributor transforms and delivers → retailer verifies the chain and ACCEPTS
retailer delivery records: 1 (bound to verified evidence view sha256:4da4cd872f35ae635c6ec666d2d2e1266a2345f57193477180a9ec3bdb7b8fd4)
[4/6] adversary republishes the manufacturer envelope with a FORGED payload (lot swapped)
[5/6] relay HALTS at the next boundary — signature no longer matches the recorded output
retailer delivery records: 1 (unchanged — the forged payload never arrived)
[6/6] evidence survives: exported bundle re-verifies offline → PASS
done in 12s — trust is not a guarantee of truth; it is the attributability of lies.
All you need locally is Docker:
git clone https://github.com/provin-line/e2e
cd e2e
make demoThe first run includes the image build (a few minutes); after that it completes in about 20 seconds. The assertion-grade version lives in scenarios/supplychain.
MANIFESTO
The truth of content
can never be proven
Not a technical immaturity — a limit in principle.
The rise of AI turned that limit from an exception into the default.
Unverifiable stages — model inference, human judgment — became standard pipeline components, and the cost of forging a plausible artifact collapsed toward zero. The old path of inferring trust from how convincing the artifact looks has closed.
If content cannot be guaranteed, one lever remains: raising the after-the-fact cost of a lie. That cost cannot arrive without attribution — a lie that cannot be pinned to anyone cannot be punished, sued, or priced into a reputation. And between organizations, without a single operator, attribution holds in exactly one form: a chain of signatures at every boundary the data crosses.
This deterrence has preconditions: it reaches only parties who hold an identity worth protecting, and on whom consequences can land. In the economy of firms, those preconditions are already met. A firm is accumulated credibility it cannot afford to lose, and inter-firm commerce has always run on promises staked on a name. Contracts, audits, bookkeeping — none of them prove content true. They make lies attributable.
Trust in the age of AI, then, is not proof that content is correct. It is the state in which every claim is non-repudiably attributable to an entity with something to lose. provin is the choice to establish that attribution — with data pipelines, across organizations, without an operator, cryptographically.
— Attribution becomes a decision-making tool — refuse at the gate, trace after the fact.
WHAT YOU CAN DO
Turn provenance from stored logs
into evidence you can act on
provin creates signed, connected, re-verifiable evidence while data moves, keeping it ready for both admission decisions and later review.
- Decide before data is used Verify signatures and continuity at receipt, then apply the recipient’s policy to pass the data onward or record a rejection.
- Trace where a problem entered the path Walk backward from an output to find where continuity failed and identify who signed each recorded segment.
- Reuse the same evidence Re-verify retained provenance as shared material for explaining origin and handling.
- Verify beyond one organization Let recipients and third parties carry an evidence bundle into their own environment and evaluate the same records under their own policy.
— "Cannot be in there" is only sayable because someone warranted "this is everything."
CLAIM SEMANTICS
Exclusion comes from the claim,
not the signature
Every record carries a declaration of what the processing was — the transformationClaim. Pinning what that declaration warrants is the job of the provin wire profile.
What a verifier often needs is not “is it included” but “can it be excluded” — could this lot have reached that output? What licenses that inference is neither the signature nor the hash chain. It is the issuer’s warranty that the declared inputs are the output’s complete information source — the claim’s closed world.
| label | closure |
|---|---|
provin:filter | closed — declared inputs are the complete information source |
provin:convert | closed |
provin:filter-convert | closed |
provin:aggregate | closed fold over the declared input set |
provin:enrich | conformant-closed — exclusion holds for conformant flows only |
provin:generate | open — information beyond the declared inputs is acknowledged |
provin:sink-receipt | identity — a receipt, not a transformation |
- Same shape, different warranty —
provin:enrichandprovin:aggregateshare the same N:1 shape, but an enrich joins side-fetched data no chain covers, so exclusion inferences hold for conformant flows only. The shape cannot tell them apart; the claim is what does. - AI inference is open — the dominant information source of
provin:generateis the model’s weights, hence its training corpus. Declaring a synthesis as an aggregate would falsely license a closed-world reading of an output nothing closed over. Treating an unverifiable processing stage honestly in the provenance vocabulary is the manifesto’s problem answered at the level of vocabulary. - A false warranty stays attributed — the closed-world guarantee holds when the declaration is honest. A wrong declaration licenses a wrong exclusion — and that warranty remains non-repudiably attributed to the entity that signed it. That asymmetry is not a gap in the design; it is the design.
supplychain additionally confirms, across three organizations, a strict profile requiring source-set binding (SOURCE_SET_BINDING) beside the linear one, with exact-view delivery bound to the verified evidence view. — The cost of a lie lands only in concrete settings.
USE CASES
Follow the same evidence
across separate systems
provin is useful when data has crossed an organizational or system boundary and the recipient can no longer verify who handled it, what went in, and what came out.
At every handoff, provin records the claim “who says they produced which output from which input” in a signed credential. The recipient can take that evidence into its own environment and check it under its own policy. provin does not replace an existing lineage or industry system; it adds verifiable evidence at the point where that system’s management boundary ends.
-
Trace the impact of a faulty input
In a manufacturing recall or cross-service ETL/ELT flow, teams need to know which downstream outputs a faulty input reached.
provin connects signed provenance records so teams can follow a faulty input to its declared descendants.
Public E2E note:recallconfirms traversal from a signed FirstDrop record to its declared linear descendants;branchingconfirms fan-out and filter delivery. -
Check a handoff between organizations
In a supply chain, data space, or inter-company API, the recipient needs to check which organization declared the input and output at each handoff.
provin connects those handoff records with signatures so recipients can verify the provenance in their own environment.
Public E2E note:supplychainconfirms verification across handoffs modeled on three organizations. -
Verify evidence after the original system is gone
An audit or retention period may outlive the original service or resolver, making it important to preserve a verifiable record of the original processing path.
provin packages the required records as evidence that can be verified again outside the live system.
Public E2E note:archiveverifyandaggregatebundleconfirm offline verification from retained records;auditsurvivalconfirms restart durability. -
Record a delivery failure as a failure
In IoT and event pipelines, processing can succeed even when downstream delivery fails. Teams need a record that preserves the difference.
provin records processing and emission separately so the “processed but not delivered” state remains traceable.
Public E2E note:losswindowconfirms that a delivery loss remains visible in the emission record. -
Check which inputs went into an aggregate
Sensor aggregation, feature, and analytics pipelines need to identify the input set from which an output was produced.
provin records a signed commitment to that input set and lets a verifier check whether a specific input was included.
Public E2E note:sensoraggregateandaggregatebundleconfirm the signed input-set commitment and inclusion check.
— A chain of signatures can only be built the moment data moves.
HOW IT WORKS
Extend the provenance line
as each process runs
Receive, verify, process, sign, and pass on — all as part of the running data pipeline.
01
Receive
Accept input and its preceding record
02
Verify
Check signature and continuity
03
Process
Evaluate or transform the data
04
Sign
Bind input and output in a new record
05
Pass on
Send data and provenance onward
At each producing boundary, the process signs a record of which input it received, what operation it declares, and what it emitted — the signature proves attribution of the claim, not the correctness of the declared operation. The next process verifies the record it received and issues its own record as the next segment.
Provenance is created when data moves, rather than inferred later. When downstream systems retain the evidence set — the records plus the key and controller material verification needs — verification does not depend on the issuer’s database remaining unchanged.
CURRENT INTERFACES
Where it connects today
and what runs with it
Interfaces and dependencies confirmed in the current 0.x implementation. Planned adapters are not included.
- HTTP push — Ingest a JSON payload into a Source Process and issue a signed FirstDrop credential.
- Core NATS — Carry process events, using operator/account JWTs and subject grants to form organization boundaries.
- ConnectRPC + Protobuf — Expose the five service APIs: DID, schema, chain, credential/resolver, and audit.
- JSON processing — Validate inputs and outputs with JSON Schema (2020-12 by default), then run JSONata filters and one-to-one conversion.
- Custom Process contract — Connect use-case-specific I/O through the shared pipeline contract.
Protocol and implementation
dPLaaX defines what is recorded at a boundary, how records connect, and how they are verified. provin is its reference implementation, providing the provin wire profile, runtime, services, and operator CLI. did:dplaax and dplaax.*.v1 are the protocol’s identity and API namespaces.
Current building blocks
- provin node — Two binaries —
cmd/network(control plane) andcmd/pipeline(data plane) — running on the same host or separate hosts, interacting over the wire only. Evidence stores are file-backed; the current reference stores use YAML and files. - NATS — Carries process events when the data plane is enabled.
- PDP and authentication — API authorization selects o3co, OPA, Cedar, or an in-process static backend (backend implementations come from a companion library). Static is an allow-list, not authentication.
The provin node can run without a database. Storage and PDP boundaries are replaceable interfaces, but a database-backed registry or a specific database integration is not shipped. The selected auth provider, PDP, or adapter may have its own database and external-service requirements.
— One proof alone cannot attribute a lie.
WHY THE COMBINATION
Why one proof mechanism
is not enough
Point signatures, append-only logs, and authorization inside a trust boundary prove different things. provin combines evidence with different roles into one verification path.
Verification
- Signature Checked
- Issuer Checked
- Continuity Checked
Signed records The records exist. The path is still unknown. Each signature can be checked on its own. The path between records is not yet visible.
Connect adjacent records The input and output records now form a visible path. Bind the preceding record and adjacent input and output hashes into a processing path.
Verify in another environment The receiver verifies the path in its own environment. The receiver carries the evidence away and checks signatures, issuers, and input-output continuity locally.
- Point proof — strong for the integrity of one record A signature shows who issued a record and whether its signed content changed. On its own, it does not show what came before or after, or whether an intermediate processing boundary is missing.
- Transparency Log — strong for detecting changes after registration An append-only order fixes the presence and sequence of registered records, making later deletion or substitution easier to detect. On its own, it does not establish that adjacent records are input and output for the same data, or that a received payload matches a record.
- Single trust boundary — strong for authentication and authorization within it One organization or system can share identities, policies, and audit infrastructure internally. Once data leaves, those controls do not travel with it; recipients need evidence they can evaluate under their own trust decisions.
The provin combination
- Sign at every processing boundary — Record the issuer, operation, input, and output at that point.
- Turn points into a line with hashes — Bind the predecessor credential and adjacent input/output hashes so continuity can be verified.
- Fix the line in append-only evidence — Retain credentials, emissions, receipts, and audit verdicts so gaps and later changes can be investigated.
- Carry it into the verifier’s boundary — Export the required records as a bundle and re-verify away from the issuer’s runtime and policy context.
provin keeps point proofs, connects them into a line, and makes that line portable evidence.
— Verification is replaying someone else's claim in your own environment.
VERIFICATION
Verify the connected path,
not just one signature
A standalone signed record cannot show how final data relates to its source. provin links adjacent records into a path a verifier can follow.
- Record integrity Confirm who issued a record and detect whether its signed contents changed afterward.
- Data-flow continuity Check predecessor references and adjacent input/output hashes to verify that the declared processing path remains connected.
- Independent re-verification Export the required records and authority material, then reproduce the verification result away from the live network.
EVIDENCE
Measured, not promised.
Every number below was measured on snapshots pinned to public commits — independently auditable.
Tamper stop (public E2E)
0
downstream deliveries of a tampered payload
injected mid-chain in the three-organization E2E (single host, process-separated) — relay halts, downstream delivery records stay flat
Performance (bench)
~123 µs
acceptance-path cost per credential
linear in chain depth — measured to depth 512 with in-memory resolution
186 ms → 45 ms
depth-32 delivery with the resolution cache
measured with an imposed 1 ms/call resolution delay — opt-in, TTL- and byte-bounded
Measured with transport replaced by in-process stores — a lower bound on a networked deployment. Each benchmark documents what it does not model.
— Naming what is not guaranteed is part of attribution, too.
SCOPE
What the verification result
tells you
provin verifies the records left at data handoffs and turns them into an explainable path.
- Who issued each record — Check the signature to identify the issuer at every processing boundary.
- Whether a record changed later — Detect changes made after signing and confirm the integrity of the record you received.
- Whether adjacent processes connect — Compare predecessor references and input/output hashes to follow the declared processing path.
- Whether the same evidence works elsewhere — Carry the required records into a recipient or third-party environment and verify them again.
GET STARTED
Start with the code
Go 1.25. Build and run the tests, then inspect the concrete credential and verdict sample in the specifications.
git clone https://github.com/provin-line/oss
cd oss
make build
make testThe repository contains the authenticated end-to-end stack, CLI, and configuration walkthrough. The specifications also show a fixed input, credential, and verification-result sample.
STATUS
A public 0.x PoC
you can inspect yourself
The first public release and its E2E evidence are available. This is not production certification; it is a reproducible snapshot of how the mechanism behaves under the published test conditions.
The current public snapshot is the line evaluated in the systems paper — provin OSS v0.3.0, provin e2e v0.2.0, provin auth v0.2.1, and the dPLaaX spec at v0.1 (draft). Eleven E2E scenarios complete under both the process and Docker Compose runtimes, covering three-organization transfer, branching, aggregation, recall, restart, transport loss, and offline verification.
Authentication (provin auth) defaults to LEGACY_DID_LOGIN@1 — it does not verify DID Document relationships (authentication / assertionMethod). The OWNER contracts (relationship check, three-way kid match, audience required) are wired on main and ship with the next release; the current v0.2.1 release is LEGACY-only.
provin is a 0.x proof of concept. See the public E2E, the technical specifications, and the systems paper (forthcoming) for detailed test conditions and scope.