Run your first task

The operation profile names the roles, the input slots, the output contract and the limits. Operation profiles describes each part; How Standard works shows the release example with every field highlighted. Publish the function with its profile from the CLI:

The same call from code is standard.deploy('./release-checks.wasm', { profile: 'profile.json' }). Publication records the accepted workload revision and profile revision; nothing runs yet.

The coding agent cannot substitute a different function, change the accepted checks or request arbitrary fields. The release rules permit the validation report to the release agent; raw source is not a permitted output.

3. Authorize

The release owner prepares and encrypts the candidate and any private checks in its environment, retains the expected input digests and configures key access for the accepted confidential runtime. Requests carry encrypted-input references, never private contents in agent conversations or tool arguments. See Inputs and permissions.

Each required owner approves in the Console with a passkey: per operation, or under a standing permission with a use count and expiry that covers routine verification runs within the accepted scope. Standard checks current authority on every operation; changed scope or expired permission needs fresh authority. No interface approves on an owner’s behalf: an operation without the required approvals or a current standing permission waits or is refused.

The release agent is the permitted recipient, even though the coding agent requests the checks. Its identity must be bound and authorized; declaring a recipient role in a profile grants nothing.

4. Run

Request the operation with the accepted profile and your inputs. Inputs are encrypted on your host and contributed only after the runtime passes appraisal.

From an application or a CI/CD job, the SDK submits the same operation:

From an agent, connect through MCP, ask the agent to discover the operations available to its identity and request the release-verification operation using the identifiers and fields its tool schema supplies. The example manifest above is sample data, not a tool request. Whichever entry point sends the request, Standard checks the same authority and runs the same accepted workload.

5. Receive and verify the result

The permitted recipient receives the result. The CLI and the SDK verify Standard Proof before they write or return anything:

Example report for the candidate above:

The actual result format follows the accepted output contract. The release agent also receives Standard Proof. Its trusted integration verifies the runtime, workload revision, candidate and result bindings, required authority and recipient against independently accepted references. Configure those references and the verification policy before accepting results. Verification can run automatically in the recipient’s environment.

Valid evidence can still report failed checks. The release agent evaluates the report and applies its own deployment policy to the exact candidate. Accepted evidence does not prove the code has no defects or authorize deployment. See Verification checks.

Handle refusals and failures

Execution, delivery and cleanup are separate statuses. Retain the operation identifier and safely redacted failure information for diagnosis. See Results and lifecycle.

Add owners when the function needs them

The same process can involve a vendor’s program or a partner’s records. Each required owner authorizes its own contribution and result release. An invitation, account connection or payment grants no authority over another owner’s assets. See Join a Space.