Developer manual · v3.4.2

Architecture

ENTITY separates sovereign authority from infrastructure custody and keeps identity, authorization, evidence, rights, usage, economic consequence and recovery auditable but distinct. v3.4.2 adds the Blackmore Technology Data Universe (BTDU) as an ENTITY-governed information substrate without changing those authority boundaries.

Current release: v3.4.2 is the sole current supported canonical release. v3.4.1 and earlier remain immutable historical provenance and are superseded for current deployment.

Core control path

Entity identity → scoped/revocable authority → applications/devices/nodes → assets + provenance + evidence → rights/policy/consent → licensing/usage/settlement evidence → portable state + recovery

No application, host, database, provider, router or storage system becomes sovereign authority merely because it possesses or operates infrastructure. Authority must be explicit and verifiable.

Five protocol primitives

ENTITY → AUTHORITY → RIGHT → EVENT → VALUE

ENTITY is the persistent identity root. AUTHORITY describes who may act and under what scope. RIGHT describes permitted/retained/transferable uses or entitlements. EVENT records state transition evidence. VALUE records economic consequences only when supported by the required evidence and terms.

Evidence and reality boundary

REALITY → OBSERVATION → CLAIM → EVIDENCE → ATTESTATION → VERIFICATION → AUTHORITATIVE ENTITY STATE

ENTITY deliberately separates cryptographic verification, protocol verification and reality/evidence verification. A valid signature can prove integrity and attribution within its scope; it does not automatically prove that an external-world claim is objectively true, legally owned, regulator-approved or fairly valued.

Global Passport layer

ENTITY state + rights + evidence → Global Passport envelope → composable profile stack → versioned profiles/mappings → continuous provenance/derivation → domain package

The Global Passport binds existing ENTITY state into a portable envelope. Profiles add context and constraints; they do not create sovereign authority and do not redefine external standards. Domain packages configure the same passport architecture for a domain rather than creating separate sovereignty systems.

BTDU in v3.4.2

BTDU is implemented in src/40_BTDU/canonical_btdu.py and is built over the existing ADAM state runtime. Its own implementation describes the boundary directly: ENTITY remains authority/rights/economics; ADAM remains the atom/bond state engine; BTDU adds governed information topology and derived query indexes; NIKI receives only bounded projections.

Information substrate

BTDU stores governed objects, atom/bond relationships, economic nodes/edges and repository manifests. It can materialize primitive byte atoms, construct exact-byte compounds and reconstruct original bytes.

Authorization

Mutation requires an ENTITY authorization receipt. The operator CLI signs a bounded BTDU_WRITE authorization receipt with the sovereign Entity identity and the BTDU runtime verifies it before changing state.

Provenance and rights

Ingest records source, controller, optional rights holder, evidence object and provenance reference. Topology alone does not create ownership, authority or economic entitlement.

Genesis invariants

BTDU preserves the five Genesis primitives and the market lifecycle while declaring itself additive. Rights and economic entitlements must still come from explicit ENTITY semantics.

Data-rights market lifecycle

DCO → Instrument → Listing → Disclosure → Order / RFQ / Auction → Price Discovery → Trade → Clearing → Settlement → Entitlement → Usage → Derived Output → Economic Consequence

The market graph is not a substitute for authorization. Listings, transfers, usage and downstream participation must remain connected to rights, evidence, lineage and explicit terms.

Major implementation surfaces

Surface	Responsibility
`src/01_Core_Runtime`	Identity, policy, permissions, contracts, usage and canonical runtime APIs.
`src/04_Entity_Registry`	Assets, events, provenance, relationships, rights claims and credentials.
`src/15_Operations`	Portable state, recovery/migration and runtime state machinery.
`src/22_Sovereign_Domain`	Entity-native domains, presence, resolution, portability and verification.
`src/33_Economic_Participation`	Economic participation and consequence surfaces.
`src/37_Verifiable_Reality`	Evidence, attestation, anchors, contestability and causal attribution.
`src/38_Global_Passports`	Passport envelope, profiles, registry, provenance and conformance.
`src/39_Implementation_Packages`	Deployable domain-package machinery.
`src/40_BTDU`	Governed atomic/bonded information topology introduced in v3.4.2.
`sdk/`	Provider-neutral application integration.

Architecture invariants

Identity is not an account.
Registration is not ownership.
Provenance is not truth.
Hosting, routing, storage and custody do not create sovereign authority.
Applications and agents act only through explicit scoped authority.
Recovery preserves authoritative continuity rather than manufacturing a new root.
Historical signed semantics are superseded explicitly, not silently reinterpreted.
Protocol origin does not transfer ownership of downstream user assets.
Canonical protocol origin creates no automatic BTG royalty; economic participation requires explicit terms.

Released evidence boundary

The v3.4.2 release states 203/203 regression PASS, repository safety 3/3 PASS, dependency review PASS, public conformance smoke PASS, protected-state recovery PASS, exact restore true, restored sovereign signing true and v3.4.1 origin continuity true. Post-release gates including RUST_COMPILED_QUALIFIED, REAL_WORLD_TRAINING, physical multi-host, hardware custody, certified-device pilot, 30-day operation, independent security audit and independent assessor receipt remain open.

v3.4.2 release Read BTDU implementation Back to Developer Manual