Operation profiles
Define the program, participant roles, inputs, permitted outputs, and execution limits.
Define the program, participant roles, inputs, permitted outputs, and execution limits.
An operation profile defines one kind of work: the approved Wasm workload, required roles and inputs, limits, and what may be released to whom. Code, data, or model inputs must fit that workload and the supported runtime limits. The profile declares the work; it grants no access to data, code, tools, or recipients. Each owner authorizes its own part separately.
How Standard works shows example profiles, starting with software release verification, with each part highlighted.
| Part | What it defines |
|---|---|
| Program | The approved Wasm module the profile accepts, referenced by content hash. |
| Roles | The participant roles the work needs. Each role is filled by its own owner, and a profile can require that two roles are held by different principals. Declaring a role grants nothing. |
| Inputs | The slots each role contributes through. A participant contributes only through its own role’s slots; declaring a slot grants no access. |
| Steps | The program step that runs and which slot feeds each of its inputs. |
| Output contract | Each output that may be released, the recipient roles that may receive it and its size bound. Release still needs the owners’ authorization. |
| Limits | Memory, fuel, time and size bounds for the operation and each step. The runtime enforces them. |
Example: one organization's release owner accepts the verification workload, candidate input, checks, limits, and report recipient. The coding agent submits the candidate but cannot change the accepted checks.
When a function needs an independent owner, the same profile model names that owner's contribution and authority. Example: vendor diagnostics combines the vendor's approved program with the customer's telemetry window. The customer receives permitted findings and the vendor receives a narrower service summary.
A profile definition declares reusable work. A Space governance revision accepts an exact profile and binds the required owners, roles, and policies. An operation request supplies concrete participants and assets under those accepted rules. One owner cannot bind another owner’s role or assets.
Each accepted profile revision has exact provenance and a digest. Older revisions stay resolvable so a past result can be verified against the version it used. Changing the program, a role, an input, or an output requires a new revision and the affected owners’ authorization before use.
A Space accepts an exact profile revision. An operation request proposes one instance: the program and input references, requested result, recipients, and resources. Standard checks it against the accepted profile, owner authority, supported formats, and account limits before admitting the operation. See Operation requests and Formats and limits.