Integrating an application end to end

Development status: Planned — Planned experience, not instructions. This preview shows how the documented concepts are expected to fit together in an integration. It combines capabilities at different stages — some with experimental internal implementations, others planned or being explored. No end-to-end integration is possible today, nothing is publicly available for live use, and exact installation commands and released tooling are not yet available.

Before you read: Future developer experience: what a supported release would add.

What would a complete integration involve: identity, submission, checking results and monitoring? This preview is a conceptual storyboard. It walks through the concerns an integration would address — identity and approvals, visibility decisions, submitting work, checking results and monitoring — and links each to the page that explains it, with that concern’s status. It then lists the prerequisites a release would need to provide and the responsibilities that would remain with the integrator. The concerns are presented in a reading order, not as a protocol sequence, and the page describes no interfaces, payloads or sequencing.

Planned experience, not instructions. No end-to-end integration is possible today.

Identity and approvals

Status of this section: Being explored — not implemented; nothing enforces approval by several parties.

• Identity separate from keys. A participant’s identity is intended to be separate from the keys and wallet that sign for it, so that keys could change without changing the participant; see Participant identity.
• Several approvers. Approving a sensitive action could require several authorised approvers, separate from the key used for day-to-day signing; see Approving actions: authority and multi-party approval.
• The integrator’s decision. An integration would need to decide which identities act for it and who approves what.

Visibility decisions

Status of this section: Being explored — no access-controlled data exists in the experimental prototype.

• Owners decide. Data owners are intended to decide who can see which data; see Visibility controls and selective disclosure.
• Metadata remains observable. The design acknowledges that some protocol metadata remains observable even with confidential execution, and is exploring ways to bound and reduce it; see What remains observable.
• Classify first. An integration would classify its data and decide entitlements before submitting anything.

Submitting work

Status of this section: Planned — no SDK is available; an experimental submission and validation layer and a node interface exist for internal testing only.

• Transactions. Transactions pass through the stages described on Transaction lifecycle: from submission to result. An experimental transaction-submission and validation layer exists in an internal prototype.
• Confidential work. Confidential work would be submitted through planned language SDKs; see Submitting work and retrieving results. No SDK is publicly available.
• Node interface. An experimental developer-facing node interface exists for internal testing only; the broader developer API design is being explored. See Interfaces and their status.

How submitted work would move through the network is not described on this page.

Checking results

Status of this section: Experimental implementation exists — internal only; finality is not connected.

• Inclusion in committed state. An experimental implementation commits node state under a cryptographic root and can return proofs that a value is part of that state; see Committed state and inclusion proofs. An inclusion proof shows that a value is part of committed state; it does not show that the value is final.
• Finality status. An experimental finality status query exists, but it reports nothing as final, because finality is not connected; see Agreement and finality status.
• Not final means not final. An integration would treat results as recorded but not final, and would not trigger irreversible actions elsewhere on them.

How an application would obtain the root to check against, and on what basis it would trust that root, is not yet described.

Monitoring

Status of this section: Experimental implementation exists — internal only; broader monitoring is planned.

• Basic surfaces. An experimental implementation exposes basic node status and metrics surfaces for internal use; broader operational monitoring is planned. See Node monitoring and observability.
• Alerting and objectives. Alerting and service-level objectives are planned; no objective values or metric names are published.
• The integrator’s own monitoring. An integration would also monitor its own components and the progress of the work it has submitted.

The integration at a glance

The storyboard below gathers the concerns above, with one row per concern.

Illustrative local demo — not a released Cubane API, protocol schema or live-network result.

Table: integration concerns in reading order, as illustrative documentation text only.

Concern	What the integrator would decide or do, in words	Page that explains the concept	Status today
Establish identities and approval arrangements	Decide which identities act for the application and who approves which sensitive actions	Participant identity; Approving actions: authority and multi-party approval	Being explored; not implemented
Decide visibility	Classify the application’s data, decide who is entitled to see which data and results, and allow for metadata that remains observable	Visibility controls and selective disclosure; What remains observable	Being explored; no access-controlled data exists
Submit work	Hand over transactions, or confidential work through planned language SDKs	Transaction lifecycle: from submission to result; Submitting work and retrieving results	Planned; experimental parts are internal only; no SDK is available
Follow progress	Keep a reference to each piece of submitted work and show users honest stages	Lifecycle stages used in this documentation; Confidential jobs: tracking, cancelling and retrieving results	Being explored for confidential jobs
Retrieve and check results	Retrieve results for entitled parties, check where appropriate that a value is part of committed state, and treat results as not final	Committed state and inclusion proofs; Agreement and finality status	Experimental implementation exists, internal only; nothing is reported as final
Monitor	Watch the application’s own components and the progress of its submitted work, alongside whatever node status is available	Node monitoring and observability	Basic status and metrics exist internally; broader monitoring is planned

The storyboard is hardcoded documentation text written for this page, not output from any system. Its rows are a reading order of concerns, not a sequence of protocol interactions; the real order of interactions would be documented with a release. It demonstrates which concerns an integration would address and where each is explained. No identity was created; nothing was approved, submitted, processed, proven or monitored; no node or network was involved; and no encryption, authorisation, proof checking or agreement between nodes took place. The column names are not interface fields.

Prerequisites from a release, and the integrator’s own responsibilities

From a release — none exists today:

• versioned interface reference and supported SDKs; see Interfaces and their status and Tools, SDKs and wallet availability;
• an environment to integrate against; see Networks and environments;
• a compatibility and deprecation policy applied to real versions; see Versioning, compatibility and deprecation.

Already available at documentation level: stage terms on Lifecycle stages used in this documentation and failure categories on What can go wrong: failure and error concepts.

The integrator’s own responsibilities:

• handling its keys;
• classifying its data and deciding entitlements;
• telling users honestly when results are not final;
• monitoring its own systems.

Assumptions, trust and limitations

• The storyboard is a reading order of concerns, not a protocol sequence; the real order of interactions would be documented with a release.
• Parts at different maturities cannot be combined today, and experimental parts are internal only.
• Confidentiality is simulated in the experimental implementation, which provides no confidentiality protection.

Not yet available, and how this page will grow

Exact installation commands and released tooling are not yet available. When a supported release exists, this page is intended to become an integration guide at the same address, with steps checked against the released interface, and the change would be recorded in the Documentation change log.

What this page does not claim

This page does not claim:

• any interface, payload, message order, endpoint or timing;
• a working end-to-end flow, today or in the experimental implementation;
• any assurance of confidentiality, integrity or finality;
• compatibility with any other platform.

Anything not stated here as available should be treated as unavailable.

Related pages

• Participant identity — identity kept separate from keys and wallets.
• Submitting work and retrieving results — the planned submission experience.
• Committed state and inclusion proofs — checking that a value is part of committed state.
• Node monitoring and observability — status and metrics surfaces.
• Interfaces and their status — which interfaces exist experimentally.
• Agreement and finality status — why nothing is reported as final today.
• Approving actions: authority and multi-party approval — approvals by several parties.
• Visibility controls and selective disclosure — deciding who may see which data.

Glossary

• Participant identity
• Multi-party approval
• Selective disclosure
• Observable metadata
• Inclusion proof
• Finality
• Monitoring
• SDK

References

No approved public references yet.