Evidence API

ENTITY treats evidence as support for a claim, not as automatic truth. v3.3 introduced explicit evidence, attestation, external-anchor and causal-attribution surfaces; v3.4.2 preserves those boundaries and BTDU can attach exact content evidence to governed objects.

Verification boundary

There are at least three separate questions: is the record cryptographically intact, does it conform to ENTITY protocol semantics, and does the evidence adequately support the real-world claim? A positive answer to one does not force a positive answer to the others.

Evidence objects

Evidence should be immutable or content-addressed where possible, include media/type metadata, identify the submitting/source Entity, and retain enough context to evaluate what claim it supports. BTDU ingestion uses the ADAM evidence subsystem to ingest raw bytes, records the SHA-256, and bonds the governed BTDU object to the resulting evidence object.

Attestation

An attestation is a signed statement by an identified authority or witness. Verification must check the attester's identity and authority for the claim. An attester can be authoritative for one scope while having no authority for another.

External anchors

External registries, timestamps, public ledgers or other anchors may strengthen evidence but do not become general sovereign authority over the Entity. Store the exact anchor reference and the interpretation applied at the time.

Contestability

Evidence-backed systems must support contrary evidence, revocation, supersession and dispute without rewriting the historical signed record. A later conclusion can supersede an earlier operational conclusion while retaining both records and the reason for change.

Economic causality

When evidence is used to justify contribution or value attribution, record the actual causal link and terms. ENTITY deliberately permits zero monetary value and zero contribution weight when no evidence supports a value; provenance readiness is not the same as realized revenue.