CHAPTER 11
What the Combined Platform Enables
A worked purchasing scenario and supporting workflows connect protected information, policy, assets, AI, and evidence.
- Context
- Decision
- Value
- Reviewable trail
The platform's broader significance becomes clearest when its modules are considered together. The following scenarios illustrate possible compositions of supported capabilities. They are not customer case studies, performance results, or assertions that every stage is enabled in a single deployment.
An agent assists with a protected purchasing decision
A business holds confidential supplier information and internal purchasing rules. An authorized team prepares the context that an assistant is allowed to use. The assistant compares the permitted information and proposes a purchase. A policy-oriented evaluation can help explain whether the proposal fits the relevant authority and budget. A separately authorized process handles any financial action.
Data Vault provides the protected-information context; Agentic Memory Exchange supports reviewed context sharing; AI Wallet Control supplies the policy-evaluation perspective; and the chosen commerce or wallet integration governs its own action. The business can retain relevant decision and outcome records without publishing supplier documents. The combined benefit is a more capable assistant with an understandable scope.
A merchant payment from order to reconciliation
A merchant journey makes the role distinctions concrete. An order, its payment, settlement to treasury, and any digital-asset delivery are related records with separate completion conditions. The sequence below is an integration pattern; the target deployment must enable each operation before it can be relied on.
| Stage | What happens | What the application must verify |
|---|---|---|
| 1 · Prepare the order | Record the items, amount, asset, network, and relevant expiry or reservation. | The order terms and inventory state match what the customer accepted. |
| 2 · Establish collection | Associate checkout with the merchant's designated rotational wallet where supported. | The wallet belongs to the correct workspace and network; discovery alone does not prove readiness. |
| 3 · Observe payment | Retain the transaction and its confirmation context. | An observed transfer is not yet proof of accepted payment or usable balance. |
| 4 · Reconcile payment and settlement | Match accepted payment to the order and follow authorized settlement to treasury. | Amount, asset, fees, authority, and finality reconcile; unmatched or partial payments remain explicit. |
| 5 · Fulfill and retain evidence | Deliver the service or confirm the separately governed asset ownership transition. | Payment confirmation, treasury settlement, and delivery each have their own authoritative outcome. |
For a timeout or lost response, inspect the existing order and operation before retrying. Expiry, underpayment, duplicate observations, refunds, and failed delivery need documented handling rather than an assumption that another payment resolves them. A refund is a new authorized financial operation; a delivery failure does not automatically reverse a settled payment. Retain the linked references while keeping customer and payment context within their permitted disclosure boundaries.
ILLUSTRATIVE PUBLIC WORKFLOW
From protected context to a reviewed proposal
An application coordinates these steps under separate permissions. The arrows indicate a logical review sequence, not automatic data transfer or a built-in payment pipeline.
- Data Vault
Inspect the permitted source
Identify an authorized source record and the evidence exposed about it.
GET/api/v2/data-vault/objects/{object_uuid}Result: Source metadata and a defined content-access boundary.
- Agentic Memory Exchange
Consult reviewed context
Read an existing collection approved for the recipient. Its owner separately prepares and reviews what may be shared.
GET/api/v2/context/memory-collections/{collection_id}Result: Permitted context for the assistant; no automatic publication of the source file.
- AI Wallet Control
Evaluate the proposal
A separately authorized application maps the proposal into the documented evaluation request.
POST/api/v2/ai-wallets/{binding_id}/intent-evaluationsResult: A dry-run policy decision and reasons, without funds movement.
- Pilot guide
Review the decision
The named reviewer examines the proposal, permitted context, and evaluation result.
Result: A reviewable business proposal. This stage is a human process, not a claimed API operation.
The sequence ends at review. Payment preparation, approval, reservation, signing, and broadcast require their own enabled and authorized workflow.
WORKED EXAMPLE · ILLUSTRATIVE
Follow one purchasing decision from context to reconciliation.
Consider a buyer reviewing a supplier proposal while keeping its supporting documents private. An assistant prepares a candidate action, a policy evaluation informs the review, and a separately authorized process may handle payment. This is an integration design example—not a customer transaction, an executed demonstration, or a claim that these modules form an automatic payment pipeline. Each stage has a specific input, retained artifact, and acceptance check.
- Protected source
- Approved context
- Policy evaluation
- Payment handoff
- Reconciliation
Identify the protected source
The buyer's authorized application inspects the supplier object's metadata through Data Vault. It records the object and version identifiers and the evidence actually returned. The source owner separately arranges any required content access. An object metadata response is not a document download or a decryption operation.
- Retain for review
- A private source-reference entry with object_id, version_id, observation time, and permitted evidence fields.
- Acceptance check
- The source belongs to the intended workspace and review. Missing evidence is recorded as missing, not filled in from assumptions.
Give the assistant reviewed context
A publisher has prepared an approved collection containing the information this workload may use. The agent reads it under the documented publication, audience, binding, scope, and signed-request checks. The application records the relationship to the business review only when that relationship is supported; the system does not infer it from similar names.
- Retain for review
- The approved collection reference, available provenance, and the application's private review identifier.
- Acceptance check
- The assistant receives only the approved material. Supplier secrets and unrestricted source access are not needed simply to prepare a proposal.
Evaluate the exact proposed action
A separately authorized evaluator maps the proposal to the typed AI Wallet request: action type, native asset, positive decimal-string amount, and destination. For a non-production evaluation, 25.00000000 DHYBRID can be an illustrative amount—not a supplier quote or an exchange-rate conversion. Preserve the returned state, decision_code, policy_uuid, policy_version, policy_commitment, and budget context.
- Retain for review
- The submitted evaluation inputs and returned decision, including dry_run=true and execution_created, reservation_created, and event_created=false.
- Acceptance check
- An allowed evaluation has not reserved money, created an approval, or submitted a transaction. Re-evaluate when relevant policy, budget, destination, or proposal state changes.
Make an explicit business decision
The named reviewer compares the proposal with permitted supplier context and the evaluation reasons. The organization records its review privately and decides whether to stop, amend, or proceed. This human decision is not an API side effect and should not be presented as a cryptographic authorization unless the chosen execution contract actually establishes one.
- Retain for review
- Reviewer identity, exact reviewed terms, decision time, and the references supporting that decision.
- Acceptance check
- A changed destination, amount, asset, or scope returns to evaluation and review instead of inheriting an earlier favorable result.
Cross the separately authorized payment boundary
Only an integration with an enabled financial route and the required authority proceeds. For a funding route, creating a settlement intent records an authorization-required subject; creation alone neither reserves collateral nor signs, broadcasts, or moves funds. Subsequent authorization and execution must follow the selected route's own contract. Without that route, the example ends as a reviewed proposal.
- Retain for review
- If a handoff occurs, its actual authoritative intent reference and current stage, alongside the business review reference.
- Acceptance check
- Credentials, destination, network, currency, and approvals are confirmed independently. No funds-moving call is included in this whitepaper example.
Reconcile the observed outcome
The integration reads authoritative settlement state and follows only returned or explicitly established relationships. It distinguishes authorization, reservation, signing, broadcast, and finality. It closes the business task only when the chosen completion criteria are supported; an unresolved or denied outcome remains visible. Customer records retain the permitted evaluation and review artifacts because the dry-run evaluator creates no audit event of its own.
- Retain for review
- A private review bundle linking supported source, context, decision, and outcome references, with pending stages and observation times.
- Acceptance check
- The final explanation says what happened, which service reported it, and which questions remain open. Public evidence excludes confidential source content and credentials.
The value of the connected platform is continuity across these handoffs: the buyer can explain why an action was proposed, which authority governed it, and what outcome was actually observed. The application coordinates the journey; each module keeps its own permissions and responsibilities.
An organization investigates an asset operation
A customer sees an external deposit but cannot yet use the expected balance. An operator needs to explain the difference between observation and availability. Funding and settlement records can provide the relevant history, while wallet capability and policy context identify which subsequent actions are supported. The operator reviews evidence rather than assuming that an external transaction implies a completed internal stage.
The same approach applies when a response is delayed or an outcome is unclear. Reconciliation starts with the responsible service's authoritative state. Relevant records help distinguish pending work, a denied condition, and an established outcome. The combined benefit is a clearer operational explanation across systems, which can improve both application behavior and customer communication.
ILLUSTRATIVE PUBLIC WORKFLOW
From an observed deposit to an explained settlement stage
A reconciliation application combines permitted reads and the relationships actually returned by the services.
- Funding & Settlement
Establish route context
Inspect readiness for the authorized funding context and preserve unmet conditions.
GET/api/v2/funding/readinessResult: A view of the route's readiness rather than an assumed active route.
- Funding & Settlement
Inspect the deposit
Read the owner's observations and the available lifecycle information.
GET/api/v2/funding/depositsResult: An explanation of what was observed and which conditions remain unresolved.
- Funding & Settlement
Reconcile settlement posture
Review settlement-intent stages and correlate only records with supporting references.
GET/api/v2/funding/settlement-intentsResult: A supported explanation of the current stage, or an explicit unresolved relationship.
All three operations are reads. The workflow neither advances settlement nor turns a visible deposit into spendable value.
A protected document supports a governed review
A team needs to review a confidential document and retain evidence of the subject considered. Data Vault protects the record and exposes permitted metadata and integrity evidence. Authorized reviewers receive access through the applicable workflow. Governance can associate decisions with a defined proposal, while evidence records support later inspection of relevant stages.
A public reference may allow another party to inspect a narrowly scoped integrity or publication claim without receiving the document. Retention requirements and actual retrieval remain governed by their own responsibilities. The combined benefit is a review process that can be explained without turning the supporting material into public data.
ILLUSTRATIVE PUBLIC WORKFLOW
From a protected record to an accountable review
The application and reviewers establish which document and proposal belong together; the modules do not infer that relationship from matching names.
- Data Vault
Identify the protected record
Inspect owner-scoped metadata and the relevant commitment-oriented evidence.
GET/api/v2/data-vault/objects/{object_uuid}Result: An identifiable source record. Any retrieval still needs its separately authorized route.
- Governance
Inspect the governed subject
Review the proposal, authority, recorded approvals, and retained evidence.
GET/api/v2/governance/proposals/{proposal_uuid}Result: A decision history associated with the actual reviewed proposal.
- Governance review guide
Assemble the review record
An authorized reviewer records which references match, which checks were performed, and which questions remain open.
Result: A scoped review report. No new publication or execution API is implied by this human step.
Do not place confidential document contents in a public proposal or evidence record. Approval of a proposal remains distinct from execution.
Applications built on the same foundation
Other product families apply these principles to pricing, digital assets, strategy records, contract preparation, execution evidence, and event automation. A pricing publication can retain relevant source context; an asset journey can connect issuance and ownership records; a contract workflow can distinguish review from signing and broadcast. Each product has its own semantics, but the relationship between context, authority, action, and evidence remains useful.
The opportunity is cumulative. A protected information service becomes more useful when it can participate in an authorized review. A policy decision becomes more useful when its reasons can be inspected. An AI assistant becomes more useful when it has relevant context and clearly bounded capabilities. Hybrid-Chain's architecture is intended to make those connections practical.