Decide before data is used
Apply policy to verified evidence at receipt: accept, quarantine, or deny before data reaches a warehouse, training corpus, or other external system.
Continuous, verifiable data provenance
dPLaaX
Verify how data was handled before acting on it.
dPLaaX ("data PipeLine as a X") is a protocol for data provenance via the data pipeline: it keeps a tamper-evident record connected as data moves across systems and organizations. A recipient can evaluate the handling path at the moment of use; when something goes wrong, the same record shows where to investigate and which organization signed the record for each step.
What continuous provenance makes possible
A connected record is more than evidence kept for a future audit. It becomes an input to decisions made while data is still moving.
Locate failures and identify each signer
Trace an output back through its declared sources and processing steps, find where continuity failed, and identify the organization that signed each segment.
Reuse provenance evidence across audits
For questions about origin, handling, and who signed each segment, use the same retained chain instead of collecting a new set of screenshots and logs for every audit.
Verify beyond one organization
Partners, auditors, downstream services, and AI agents can evaluate the same portable records under their own trust policies without sharing one audit database.
Why the record has to be continuous
One signed record can show only what one party attested at one boundary. It cannot show how the final data relates to its source or what happened between organizations. Linking the records turns separate claims into a path a system can follow — for a decision before use, an investigation after an incident, or evidence during an audit.
Create evidence while data is moving
dPLaaX does not wait for an audit to reconstruct provenance. When data crosses a process boundary, it issues a signed credential recording who received what, what action was performed, and what was passed on. Where downstream systems retain the records they receive, the evidence does not depend on the issuer’s database remaining unchanged.
How dPLaaX makes the chain verifiable
01
Detect record tampering
Each boundary record is cryptographically signed. A verifier can confirm the issuer and detect changes to the signed data.
02
Verify data-flow continuity
Each record identifies its predecessor, while input and output digests bind adjacent steps. A verifier can check whether the declared flow remains connected.
03
Verify across organizations
Shared wire schemas and verification rules let each organization run its own system while third parties evaluate the same evidence.
How to read the verification result
- It checks the signed record: issuer, integrity, predecessor link, and declared input/output continuity.
- It does not prove that a value is true or that a transformation was semantically correct. A valid signature can still cover incorrect data.
- It does not reveal a boundary that produced no record. Completeness requires operational controls in addition to the protocol.
The verifier still decides which identities and authorities to trust. dPLaaX supplies portable, checkable evidence for that decision; it does not make the trust decision on the verifier’s behalf.
dPLaaX does not replace domain-specific standards. It adds a common protocol for keeping provenance connected across process boundaries.
Research behind the design
The design builds on established provenance research: connected provenance supports trust decisions, error investigation, responsibility tracing, audit, and reproducibility.
Cryptographic Provenance Attestation in Data Pipelines
The dPLaaX foundation: signed process-boundary records for independently verifiable, cross-organizational data provenance.
DOI 10.5281/zenodo.20042030
W3C PROV Model Primer
A standard foundation for using provenance to assess trust, verify processes, reproduce results, inspect errors, and identify responsible parties.
w3.org/TR/prov-primer
Decision Provenance
Research on exposing cross-system data flows to support oversight, audit, compliance, risk mitigation, and accountability.
DOI 10.1109/ACCESS.2018.2887201
Ecosystem
Specification
Behavioral rules, JSON Schemas, and conformance vectors that let independent implementations produce and verify the same wire records.
github.com/dplaax/spec
provin
Go reference implementation for issuing, carrying, and verifying dPLaaX records in a distributed data pipeline.
github.com/provin-line
Status
v0.1 is a draft. Wire rules and schemas may change as feedback from the reference implementation is incorporated. Development is public, and review and contributions are welcome.