Exchange governed data between organizations
This scenario shows two organizations using ENTITY to exchange bounded data rights while keeping identity, disclosure, execution, entitlement, usage and settlement evidence distinct and recoverable.
Scenario
Organization A controls a governed telemetry dataset. Organization B needs 90-day query access and a limited derivation right for an internal planning model. Raw redistribution is prohibited. The parties want price discovery, evidence of the transaction, auditable usage and portable recovery if the venue or storage provider disappears.
1 · Establish organizational identities and controller evidence
Each organization should have a persistent Entity identity. The dataset should already be governed with source/controller/rights evidence. The venue may host listings and execution but does not become controller merely because it operates the infrastructure.
2 · Define the rights instrument
underlying_object: TELEMETRY_DATASET_REF issuer/controller: ORG_A rights: [QUERY, DERIVE] forbidden: [RAW_REDISTRIBUTE] duration: 90 days purpose: internal-planning transferability: non-transferable quantity/capacity: explicit if applicable jurisdiction / compliance conditions: explicit
3 · Publish a listing and disclosure
The listing should bind the instrument to venue rules, price/lot constraints and a disclosure package. Disclosure can include provenance/evidence references, known limitations, licence terms, jurisdiction constraints and any material conditions needed before execution.
4 · Choose an execution path
| Path | Use when |
|---|---|
ORDER_BOOK | Standardized instrument with continuous bids/offers. |
CALL_AUCTION | Batch price discovery under venue policy. |
RFQ | Negotiated or bespoke rights terms require signed request/quote/acceptance. |
For this scenario, an RFQ is a natural fit because the duration/purpose/derivation constraints are specific.
5 · Create entitlement only from valid execution
The resulting entitlement should reference the instrument, holder, quantity/capacity, validity window and rights. A position or entitlement is not ownership of the underlying bytes unless that is explicitly established elsewhere.
6 · Govern access and usage
Each query or derivation should evaluate authority and entitlement state before execution. Record the actor, action, purpose, source object, entitlement, time, usage amount and derived output reference.
7 · Keep payment evidence scoped
If external money movement is part of the transaction, keep the obligation separate from payment verification. Only an authorized settlement verifier should move the recorded state to verified settlement based on acceptable evidence.
8 · Monitor and cancel safely
Use cancellation/revocation rules for still-open market intent and entitlement controls for post-trade usage. Historical trades/uses remain evidence; cancellation should not rewrite history.
9 · Prove portability
Export the market/economic state logically—not merely as database bytes. Recovery should preserve venues, instruments, balances, listings, disclosures, orders/RFQs, trades, clearing, entitlements, usage, revenue rules, settlement-verifier authorizations and payment attestations with semantic hashes and identity evidence.
Negative tests
- Organization B requests RAW_REDISTRIBUTE → deny.
- RFQ quote expired before acceptance → reject.
- Venue tries to replace Org A as issuer/controller → reject authority change.
- Payment attestation comes from unauthorized verifier → do not mark settlement verified.
- Recovery package omits entitlements or usage state → fail closed rather than call the restored market complete.
What this scenario demonstrates
ENTITY can wrap an enterprise data exchange in explicit rights and economic state without requiring the exchange operator, cloud provider or database to become the authority root.