We call it a reference implementation of a Person-First Runtime. The Capsule is not an account, platform, or social profile. It is a stable continuity layer where a person’s state, memory, and trust context are anchored.
We do not model an abstract social graph first. We model a person as the source of continuity, and then connect applications, transports, and services to it through controlled, inspectable surfaces.
Capsule is the personal runtime anchor: persistent, stateful, and not an account in a platform sense.
Capsule continuity remains stable across installations and sessions; runtime processes can start, stop, and recover around it.
Core does not own a fixed app surface. Capabilities can evolve and rotate while continuity remains intact.
Only the continuity layer: data that should stay stable with the person even when capabilities change.
A durable thread that ties person-owned state and authenticated history over time.
Evidence that records state transitions and key decisions in the trust layer.
Stable anchors used as a root for local validation and reconciliation.
Current state defines which capability calls can be accepted from which source.
Ports for external services are not merged into Core truth; they are attached as replaceable interfaces.
Core accepts domain truth through defined transitions; external receipts and journals remain owned by their capability or effect boundary.
Not an account A Capsule can use accounts, but it is not itself a provider account.
Not a social graph node We do not treat every relation as a social edge with implicit privilege.
Not a wallet Financial modules are capabilities, not the continuity core.
Not a transport identity Network protocols and endpoints are pluggable, not canonical.
Not an app container Applications are clients of the runtime and can be replaced without replacing a person.
Trust setup is part of the Core/Ledger domain, but it is not the whole definition of Hivra. These mechanisms establish explicit trust paths without turning Hivra into a universal control relay.
Structured positions in Starter-related state, tracked by Core/Ledger semantics.
Concrete setup artifacts used to initiate an explicit relationship path.
Ledger-backed outcomes of trust establishment, not a default social graph with implicit privilege.
Capabilities are composable plugins or modules. Transport and provider integrations are replaceable adapters behind them.
Chat, AI, trading tools, and similar capabilities are loaded as modules.
Capabilities can rotate if they keep host API contracts and do not break continuity.
Effects and receipts stay tied to the provider or capability boundary and are not merged back as person continuity by default.
Protocols and providers are interchangeable adapters as long as they respect capability contracts. Core truth remains person-bound.
Wiring for protocols, APIs, and networks stays replaceable.
Activity logs, proofs, and attestations stay at explicit capability or provider boundaries.
Loss of a transport does not erase person continuity.
This section intentionally describes implemented behavior only.
Implemented in current stack
Intended but not implemented as core semantics
These are forward-looking assumptions, not claims of current implementation.
Autonomous execution remains research direction around the runtime, not current Core semantics.
Human intent resolves through runtime composition before UI and provider choices.
On-device stacks move toward first-class planning, safety, and context operations.
Not every interaction must be on-chain; settlement and audits can stay selective.
Product semantics stay with the capability. Adapters execute bounded requests; verified receipts return to the same owner for reconciliation.
The same owner survives retry, restart, and reconnect. Core/Ledger receives only accepted domain truth; an external effect does not become Capsule history merely because it occurred.