We built Hivra as a reference implementation where the Capsule is the continuity anchor of a person. Capabilities are replaceable plugins that use host APIs, while transports and providers stay behind adapter boundaries.
Current architecture in one line: person continuity first, bounded capability context, explicit trust setup. Persistent Capsule Replaceable capabilities Scoped evidence Trust as extension layer
Hivra does not start from a social graph or protocol stack. It starts from a person runtime that must remain stable while everything around it can evolve.
Capsule stores person continuity and remains durable across app and transport changes.
Core semantics define accepted state transitions and the bounded context available to capabilities.
Chat, AI, and trading modules can be replaced without rebuilding person or Capsule continuity.
We keep Capsule minimal and composable so it can survive protocol updates and application churn.
Persistent authenticated history and Core state that stay anchored to the person.
Evidence and transitions that describe how continuity changed over time.
Boundaries where security, acceptance, and capability context are resolved.
External effects remain outside Core truth unless accepted through a defined capability or effect boundary.
All capability calls are matched against explicit context rather than implicit privilege.
Person continuity remains local-first and recoverable across installations without promising protocol lock-in.
Capsule can use accounts, but it is not a provider account itself.
Relationships are not implicit privilege surfaces by default.
Money modules are capabilities, not the continuity core.
Protocol endpoints and networks are interchangeable adapters.
We describe only behavior already present in the current stack.
Capsule is the single continuity anchor.
Slots, Starters, Invitations, and Relationships belong to Core/Ledger domain truth.
Request, decision boundary, adapter execution, and evidence handling are explicit.
This is roadmap language, not current semantics.
Agent execution and local planning move earlier in the stack.
Blockchain is used where audit and settlement need it, not as universal truth.
Autonomous service execution remains research direction, not current Core semantics.
A goal enters one capability owner. The owner decides within its bounds, an adapter executes, and the capability reconciles the receipt before returning a result.
Core and Ledger remain the domain-truth boundary. External observations, decisions, and receipts stay with their capability unless a real Core use case accepts a domain transition.
About page now follows the same architecture framing. This page stays close to the product reality and avoids invented semantics.