CHAPTER 02
One Platform, Connected Systems
The roles of identity, wallets, storage, evidence, applications, and integration—and the boundaries connecting them.
- Identity
- Wallets
- Data Vault
- Policy
- Evidence
- Applications
Hybrid-Chain can be understood as a set of cooperating capabilities with different responsibilities. The public architecture is a logical map: it shows what a module contributes to a workflow, without prescribing physical placement, internal network topology, or the mechanisms used to coordinate infrastructure.
| Capability | Primary responsibility | Connection to the wider platform |
|---|---|---|
| Identity, authority, and policy | Establish who is acting and under which permissions. | Provide the context in which protected information and actions may be requested. |
| Wallets and digital assets | Support the authorized management of assets and wallet operations. | Connect financial intent to the relevant asset, network, and execution boundary. |
| Data Vault and agent context | Protect information and organize its permitted use. | Supply authorized records and reviewed context to people and applications. |
| Evidence and verification | Expose appropriate records, commitments, and lifecycle evidence. | Support integrity checks, traceability, and reconciliation across workflows. |
| Business applications and AI | Apply the platform to specific operational tasks. | Combine context and permitted capabilities into user-facing workflows. |
| APIs and event integration | Define how external systems interact with platform capabilities. | Connect existing software, partner applications, and automation. |
A public component map
The platform can also be read as a set of logical service roles. This map explains the path an application follows without prescribing deployment topology or exposing signing internals. A user interface is not the ledger, an index is not execution authority, and a notification is not the source of finality.
| Component role | What it contributes | Boundary to preserve |
|---|---|---|
| Application and API boundary | Accepts documented requests with identity, resource, and permission context. | Authentication does not authorize every operation. |
| Product services and policy evaluation | Apply the rules and lifecycle of a wallet, asset, document, or proposal. | A favorable decision does not itself execute a financial action. |
| Authorized execution and signing participants | Perform an enabled operation under its own authority and current conditions. | A request or queue entry is not a completed transaction. |
| Ledger and validator evidence | Retain authoritative state and applicable finality evidence. | Check the specific record and confirmation model. |
| Protected storage | Retains protected content and permitted object metadata. | A public commitment does not grant access to the content. |
| Public indexing and Explorer | Make published records searchable and understandable. | An indexed view can lag; reconcile with the responsible service. |
FIND THE IMPLEMENTATION SURFACE
From capability to product
Each row connects a responsibility in the architecture to a product, its API module, and an inspectable public interface. Product names and API module names can differ; the links preserve that distinction.
Connections without collapsed responsibilities
A protected document may be relevant to a payment, but permission to read the document does not confer permission to move money. A governance decision may approve a proposed change, but recording that decision is distinct from executing it. A public evidence record may identify a completed stage without exposing the private inputs that supported it. These distinctions are the foundation of composability: a module can participate in a larger workflow without silently inheriting all of its powers.
Applications use the public contracts of the modules they need. That lets an organization retain an existing business interface while adding a capability such as protected information, wallet policy evaluation, or event evidence. A broader deployment can connect several modules around a common operational objective. Modular adoption therefore concerns both software interfaces and the distribution of responsibility between organizations, operators, and users.
WHY THE CONNECTIONS MATTER
The advantage of combining the capabilities
The architectural benefit is the relationship between the modules. The public interfaces below make each connection concrete without claiming that the integration happens automatically.
Verification with selective disclosure
Protected object metadata and public evidence offer different views of a related question. An integration can expose an appropriate integrity reference while retaining the content's access boundary.
Protection and evidenceUseful AI with bounded authority
Reviewed context can inform an agent's proposal, while a separately authorized evaluator considers the proposed action. Knowledge and action remain independently controlled.
Agents, context, and policyConnected outcomes that can be explained
Funding observations, settlement posture, and evidence records let an application explain stages and unresolved conditions instead of collapsing the entire workflow into one success label.
Annotated workflowsAn illustrative relationship
In a reviewed procurement workflow, identity establishes the participants; Data Vault protects supporting material; agent context makes selected information available for analysis; policy evaluation checks a proposed action; and separately authorized payment or wallet services handle an enabled financial stage. Evidence records make the relevant outcomes reviewable. This is a logical composition, not a claim that one unrestricted call performs every stage.
The advantage is continuity. The organization can reason about the relationship between input, decision, action, and evidence while maintaining a separate boundary around each. Interfaces remain specific enough for engineers to implement and outcomes remain understandable enough for operational teams to review.
Hybrid-ID connects the participant to the platform
Hybrid-ID supplies a concrete identity entry point for this logical architecture. A participating application can recognize a returning person through the registered OpenID Connect flow, then apply the organization, workspace, and resource permissions relevant to its service. Hybrid-Chain is already a relying application. The business benefit is a familiar starting point for several kinds of workflow without requiring every application to reproduce the same sign-in experience.
The connection to the wider platform remains explicit. Data Vault governs protected information; Agentic Memory Exchange governs reviewed context; policy services evaluate permitted proposals; and commerce and wallet services retain their own execution authority. Hybrid-ID does not automatically move private context among them or turn authentication into permission to spend. Unified agent access belongs to the product's developing direction, while current workload integrations must be established separately.
The four public parts of the Hybrid ecosystem
The wider ecosystem separates platform capabilities, identity, public inspection, and the planned coordination of independently operated networks. These roles give a reader four useful entry points. They are not four interchangeable sources of authority, and a link between their websites does not establish an enabled connection between their underlying services.
| Public entry point | Role in the ecosystem | Availability and responsibility |
|---|---|---|
| Hybrid-Chain | Platform products, applications, and integration contracts for information, actions, and value. | Confirm the permissions and enabled operations of the specific product and deployment. |
| Hybrid-ID | Identity and sign-in for registered applications. | Each application retains its own access decisions; signing in does not authorize an agent or financial action. |
| Hybrid Explorer | Public, read-only discovery and inspection of published records and supporting evidence. | An indexed record supports only the checks its evidence permits; private content and execution authority remain elsewhere. |
| Hybrid Federation | The published model for consortium governance and planned sister-network coordination. | Connecting infrastructure is planned and detailed governance arrangements are still being developed. |
- Hybrid-Chain
- Hybrid-ID
- Hybrid Explorer
- Hybrid Federation
From ecosystem roles to a business workflow
A participating application can use Hybrid-ID to recognize an authorized buyer and use enabled Hybrid-Chain products for a business task. A reviewer can then inspect an appropriate public record in Hybrid Explorer, where one has been published, while private business material remains in its protected context. These connections must be implemented and authorized for that application. Federation describes how independent organizations could coordinate selected services in the future; it is not a required live transport for this example.
The practical advantage is a clearer division of work. Application teams can integrate the capability they need, reviewers can follow public evidence without obtaining private operational access, and organizations can evaluate future collaboration while retaining responsibility for their own services. The Federation chapter describes that intended organizational model separately from the technical authority of any current operation.