What should a data provenance protocol actually prove?
A useful provenance system must answer where an object came from, what evidence supports that claim, who controlled the relevant action, what rights were asserted, and what happened after derivation—without pretending those facts automatically establish objective truth or legal ownership.
The core problem
Many systems collapse several different questions into a single metadata field: who supplied the bytes, who owns them, whether they are true, whether a downstream user has permission, and whether a derived result owes economic participation to an originator. ENTITY keeps those questions separate.
The ENTITY separation
| Concept | Question |
|---|---|
| Source | Where did the object or evidence enter the system? |
| Controller | Which ENTITY had authority over the relevant operation? |
| Rights holder | Which ENTITY is associated with the asserted rights state? |
| Evidence | What cryptographic or documentary material supports a claim? |
| Provenance | What sequence of events, transformations and relationships led here? |
| Economic participation | What explicit terms, if any, create economic entitlement? |
Why this matters
A hash can prove that bytes match previously observed bytes. A signature can prove that a key signed a payload. Neither alone proves that the payload is true, that the signer owned the underlying asset, or that a downstream derivative creates a royalty. ENTITY treats those as separate verification and policy boundaries.
Derived outputs
ENTITY's data-rights lifecycle extends provenance beyond initial ingestion: a governed object can be used by a process, produce a derivative, and later participate in a revenue or settlement event. The important architectural point is that each relationship is explicit and inspectable rather than inferred merely because two objects are connected.
BTDU does not erase these boundaries
BTDU adds governed topology over reusable atoms, bonds, compounds and repository manifests. Its topology can describe relationships efficiently, but the existence of a bond does not itself create authority, ownership or economic entitlement. ENTITY remains the authority and rights layer.
Evaluate it yourself
Inspect the released v3.4.2 source and try to find a path where topology, provenance or infrastructure possession silently becomes sovereign authority or ownership. If you find one, the project explicitly asks you to publish the counterexample.