Expected outcome
You can distinguish a bounded model proposal inside a workflow from the separate private access and usage policy that permits it
You can use this public guide without a Tempera account, product credential, or private workspace. Product access begins only after private onboarding.
Before you start
- A workflow step where a model may propose or transform information
- A named owner for the policy, budget, and evidence boundary around model use
Steps
- 01
Name the model’s job
Name whether the model proposes, classifies, transforms, or explains. The model does not own the workflow’s authority
- 02
Keep the proposal visible
Place the model step beside deterministic transforms and the explicit signal gate so the workspace can inspect what the model may propose and what stays outside model control
- 03
Set access separately
Private model access uses its own read, invoke, and usage-reservation scopes. A workflow reference does not grant an unrestricted provider credential
- 04
Hold a consequential outcome behind authority
When the proposal could lead to a consequential action, preserve the configured authority signal. The workspace may bind that explicit signal gate to human or policy review
What success looks like
- The model’s role is bounded and readable in the workflow record
- Model access and usage remain a distinct private policy surface
- The public guide names the policy boundary; it does not promise a provider, automatic routing, BYOK, or execution
If something is blocked
- If a model needs broad credentials or an undefined budget, keep the step in planning until the private policy is explicit
- If the model appears to own the final action, move the decision back to the workflow’s authority boundary