Submitting work and retrieving results
Development status: Planned — Planned experience, not instructions. The planned developer experience would allow applications to submit confidential jobs and retrieve results through language SDKs; no SDK is publicly available. The design being explored includes long-running confidential jobs that could be tracked, cancelled and refunded. Confidentiality is simulated in the internal experimental implementation, nothing on this page can be run, and exact installation commands and released tooling are not yet available.
Before you read: Confidential jobs: tracking, cancelling and retrieving results.
How would an application submit confidential work and get results back through language SDKs? This preview describes the planned experience of submitting confidential work, keeping track of it, cancelling it and retrieving its result, and what an application developer would design for, with a conceptual walkthrough of a fictional application. The job concepts themselves are explained on Confidential jobs: tracking, cancelling and retrieving results, and this page does not redefine them.
Planned experience, not instructions. No SDK exists, and nothing on this page can be run.
What this preview covers
- The application’s side. What an application would do with confidential work through the planned language SDKs — not how the network would process it.
- Documentation stage words. Stage words in italics come from Lifecycle stages used in this documentation; they are documentation terms, not SDK states.
- What is not described. SDK structure, method names, parameters, result formats and supported languages are not described and are not settled.
Before submitting
Status of this section: Planned — a conditional description; none of these arrangements can be made today.
- Decide on entitlement. Decide which data is sensitive and who should be entitled to see results; see Visibility controls and selective disclosure.
- Arrange identity, keys and approvals. Arrange the identity, keys and any approvals the work would require; see Identity, keys and access: concepts.
- Do not rely on confidentiality today. Confidentiality is simulated in the experimental implementation and must not be relied on; see Known limitations of the experimental prototype.
The intended experience
Status of this section: Planned — the SDK experience is planned and the job lifecycle is being explored; none of it is available.
- Submit. The application would hand the work over through an SDK for its programming language. The work would then be submitted.
- Keep track. The application would keep a way to refer to the submitted job and could check its progress: whether it is in progress, has completed, has been cancelled or has failed.
- Cancel. The application could cancel work it no longer needs, and the job would then be cancelled. A cancelled job could be refunded; the conditions and amounts of any refund are not described.
- Retrieve. Once the work has completed, an entitled party would retrieve the result, and the job would then be retrieved. Results are intended to be available only to the parties entitled to them.
These are documentation-level actions, not a list of SDK methods. SDK structure, method names, parameters and result formats are not described.
Designing for asynchronous work
Status of this section: Planned — design practices described conditionally; they apply once SDKs are released.
Once SDKs are released, applications would be expected to be designed around these practices:
- Do not block on a result. Confidential work may run for a long time, and the application should stay usable meanwhile.
- Store references durably. Store the reference to each submitted job durably, so that progress can still be checked after the application restarts.
- Show honest states. Show users honest states using the documentation’s stage terms, such as submitted, in progress, completed and cancelled.
- Handle cancellation and failure explicitly. Tell users what happened in each case; the categories are on What can go wrong: failure and error concepts.
- Keep recorded and final apart. Where an outcome is recorded, keep recorded and final separate when presenting it. Today nothing is reported as final, because finality is not connected, and whether and when a job’s outcome would become final is not described; see Agreement and finality status.
A conceptual walkthrough
The walkthrough below follows a fictional application, demoReports, used by a fictional organisation, Demo Org. It shows the application’s decisions at each moment, not the network’s processing, and contains no code; How illustrative examples work in this documentation explains how to read it.
Illustrative local demo — not a released Cubane API, protocol schema or live-network result.
Table: a fictional application’s handling of confidential work, as illustrative documentation text only.
| Moment | What demoReports would do | What it would hand over or get back, in words | What the developer designs for | Status today |
|---|---|---|---|---|
| Before submitting | Demo Org decides which figures are sensitive and which staff may see report results; demoReports is set up with the identity, keys and approvals the work needs | Nothing yet | Explicit entitlement decisions before any submission | Not available; confidentiality is simulated internally |
| Submitting | A staff member requests a summary report from Demo Org’s sensitive figures; demoReports hands the work over through a planned language SDK | Hands over the work; gets back that it is submitted, and a reference to it | Storing the reference durably; telling the user the report is requested, not ready | Not available; no SDK exists |
| While work is in progress | The staff member carries on with other tasks; demoReports checks progress using the stored reference | Hands over the reference; gets back that the work is in progress | Not blocking; showing progress honestly; assuming nothing about timing | Not available |
| The user cancels a second piece of work | A second report was requested by mistake; demoReports cancels it | Hands over a request to stop it; gets back that it is cancelled and that a refund could follow | Telling the user what was cancelled; promising no refund amount or timing | Not available; no fees are charged anywhere |
| Work completes | On a later check, demoReports finds the first report’s work completed | Hands over the reference; gets back that a result exists for entitled parties | Treating a failed ending with equal care; telling entitled staff the report is ready | Not available |
| Showing the result | An entitled staff member opens the report; the result is retrieved through demoReports, and the job is retrieved | Hands over a request from an entitled party; gets back the result, in a format not described | Showing it only to entitled staff; not presenting it as final; taking no irreversible action on it | Not available; encrypted processing is simulated internally |
The walkthrough is hardcoded documentation text written for this page, not output from any system; demoReports and Demo Org are fictional. It demonstrates the application-side design of asynchronous confidential work: keeping a reference, showing progress honestly, handling a cancellation and a possible refund, retrieving a result and not presenting it as final. No SDK was used; no work was submitted, processed, cancelled, refunded or retrieved; nothing was encrypted, decrypted, checked or recorded; and no authorisation, proof, agreement between nodes or network was involved. Stage words are documentation terms, not states of any implementation, and column names are not interface fields. The table on Confidential jobs: tracking, cancelling and retrieving results lists the same actions one by one; this walkthrough places them in a scenario.
What exists today
- No SDK is publicly available, and no confidential job can be submitted on any network.
- Confidentiality is simulated in the internal experimental implementation: its encrypted-computation interfaces simulate the behaviour and perform no real encrypted computation.
- Nothing on this page can be run.
Assumptions, trust and limitations
- How an application could check the integrity of a result is not described, and this page makes no claim about it.
- The walkthrough is documentation text and does not show real SDK behaviour.
- The trust placed in the parties that would process jobs is not yet specified publicly; see Trust assumptions and responsibilities by participant.
Not yet available, and how this page will grow
Exact installation commands and released tooling are not yet available. Once SDKs are released, this page would link to versioned SDK reference, list supported languages and show examples checked against the released interface. The real guide is intended to replace this preview at the same address, and the change would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- that any SDK exists, or any supported language, method name, parameter or result format;
- any job state, time limit, fee or refund term;
- any assurance of result integrity, confidentiality or finality;
- that the walkthrough reflects a released interface.
Anything not stated here as available should be treated as unavailable.
Related pages
- Confidential jobs: tracking, cancelling and retrieving results — the job concepts this page builds on.
- Local development environment — where this experience would first be tried.
- How illustrative examples work in this documentation — how to read the walkthrough.
- Lifecycle stages used in this documentation — the stage terms used here.
- Visibility controls and selective disclosure — deciding who is entitled to results.
- Identity, keys and access: concepts — the identity, keys and approvals work would need.
- Known limitations of the experimental prototype — why confidentiality must not be relied on today.
- What can go wrong: failure and error concepts — cancellation and failure categories.
- Agreement and finality status — why nothing is reported as final today.
Glossary
References
No approved public references yet.
