ENTITY Documentation Portal
For operators, architects, data leaders and technical evaluators

Evaluate ENTITY for your organization

Start with the problem, not the protocol. ENTITY is open-source infrastructure for persistent digital authority, provenance, rights, evidence, recovery and portable state. This page gives organizations a bounded way to decide whether those capabilities are relevant before investing engineering time.

No procurement or endorsement claim: evaluation can be performed entirely from public source, documentation, releases and test material. Negative conclusions are valid outcomes.

When ENTITY may be relevant

Authority that must survive providersYou need identity and delegated authority to remain verifiable without making a single platform account the permanent source of truth.
Provenance that affects decisionsYou need to know where data, evidence, software or outputs came from, who controlled them, and what changed before relying on them.
Rights over non-rival dataYou need machine-readable access, usage, derivation or commercialization rights without pretending that copying bytes transfers ownership like a physical asset.
AI and agent governanceYou need explicit authority, evidence and lineage around systems that read data, make decisions, derive outputs or act through delegated permissions.
Portable recoveryYou need signed state, identity and authority to survive backup, restoration, migration or provider failure without silently widening privilege.
Independent verificationYou prefer public schemas, reproducible evidence and independently testable semantics over vendor assertions that cannot be challenged.

A 30-minute evaluation path

  1. Define one problem. Choose authority, provenance, data rights, evidence, recovery or governed AI—not all of ENTITY at once.
  2. Read the matching domain or protocol page. Confirm whether the semantics match your real requirement.
  3. Inspect the public release and evidence. Treat published tests as BTG-controlled evidence unless independently reproduced.
  4. Try one verification or operator workflow. Use fictional or non-sensitive data only for initial evaluation.
  5. Record the mismatch. If ENTITY does not fit, document why. Ambiguity, missing semantics and negative results are useful.

Questions an evaluator should ask

Authority

Who can authorize what, within which scope, and what happens after revocation or recovery?

Evidence

What proves an event or claim occurred, and where does the evidence stop supporting a stronger conclusion?

Rights

Are access, use, training, derivation, redistribution and commercial rights explicit instead of inferred from possession?

Portability

Can the state move or recover without changing the authority model or depending permanently on one provider?

Interoperability

Can another implementation reproduce the same public semantics from sealed material rather than copying BTG code?

Claim boundaries

Which results are internally produced, independently reproduced, externally audited, or still unverified?

Common evaluator roles

ENTITY may be evaluated by enterprise architects, security engineers, data-governance teams, AI-governance teams, identity architects, research-data infrastructure teams, software-assurance teams, legal/rights engineering teams and operators responsible for durable recovery or cross-provider state.

Continue