Model Task Execution
Execute exactly what the user approved. A valid plan is necessary but not
sufficient: explicit user consent must appear in the current conversation.
Preflight
- Validate the plan against the model-task plan schema.
- Compute a SHA-256 plan hash over canonical JSON and show it with the consent
summary.
- Confirm
consent.required and consent.status match the operation.
- Show provider, model, operation, transmitted inputs, retention evidence,
cost estimate status, maximum approved cost, and fallbacks.
- Check whether the selected provider/model requires a credential. If it does,
verify only that provider-native login or the named host environment variable
is available; never print or persist its value. If missing, stop and route
to
setup-ai-operations.
- Ask for explicit user consent. Do not invoke a paid, externally visible,
state-changing, or data-transmitting provider tool before approval.
- Store the approved plan hash in memory for this execution only. Do not write
credentials, raw secrets, or private inputs to an execution manifest.
Material-Change Gate
Any change to the provider, model, data boundary, or cost ceiling invalidates
the plan hash and requires renewed consent. The same applies when a fallback
adds a new provider, transmits additional data, or changes output visibility.
Dispatch
- Mark the next step
approved.
- Invoke only the provider tool named in the step.
- Capture the provider job ID, exact model/version, start time, and immediate
response.
- Poll status through the provider's own read operation. Do not submit a second
job merely because the first is slow.
- If the provider fails, stop and report the error. Apply only an already
approved fallback whose plan hash still matches.
- Download or attach outputs before provider retention removes them.
- Mark the terminal status and capture duration, available usage/cost evidence,
output identifiers, and any data-retention note.
Cancellation
Cancellation is separately permitted when the user asks to stop active work or
when an approved maximum cost or duration guard fires. Use the provider's
cancellation tool and verify the terminal status.
Execution Manifest
Return a sanitized manifest containing:
- Plan ID and approved plan hash
- Provider, model, operation, and provider job ID
- Start and completion timestamps
- Terminal status
- Actual usage or cost evidence when the provider returns it
- Output paths or provider URLs
- Fallbacks used
- Errors and cancellations
Never persist API keys, bearer tokens, raw private prompts, or uploaded file
contents.
Anti-Patterns
| Anti-pattern |
Correction |
| Treat plan creation as consent |
Ask after showing the final plan. |
| Switch providers silently |
Re-plan and obtain renewed consent. |
| Retry by creating a second paid job |
Poll the existing job first. |
| Claim actual cost from an estimate |
Label estimates and provider usage separately. |
| Record credentials for reproducibility |
Record provider IDs and evidence, never secrets. |
| Ask for every API key before execution selection |
Set up only the selected provider through native login, the host environment, or approved secret storage. |
Would Revise If
Revise immediately if any paid or data-transmitting call occurs without
explicit consent. Revisit by 2026-11-11 if provider status models cannot be
represented without unsafe retries or if execution manifests omit load-bearing
provider evidence twice.
1---2name: model-task-execution3description: Execute an approved model task plan through Microsoft Foundry, Hugging Face, or ElevenLabs and record provider evidence. Use after model-router emits a valid plan and the user wants to run it, monitor jobs, cancel work, download outputs, or apply an approved fallback.4---5
6# Model Task Execution
7
8Execute exactly what the user approved. A valid plan is necessary but not
9sufficient: explicit user consent must appear in the current conversation.
10
11## Preflight
12
131. Validate the plan against the model-task plan schema.
142. Compute a SHA-256 plan hash over canonical JSON and show it with the consent
15 summary.
163. Confirm `consent.required` and `consent.status` match the operation.
174. Show provider, model, operation, transmitted inputs, retention evidence,
18 cost estimate status, maximum approved cost, and fallbacks.
195. Check whether the selected provider/model requires a credential. If it does,
20 verify only that provider-native login or the named host environment variable
21 is available; never print or persist its value. If missing, stop and route
22 to `setup-ai-operations`.
236. Ask for explicit user consent. Do not invoke a paid, externally visible,
24 state-changing, or data-transmitting provider tool before approval.
257. Store the approved plan hash in memory for this execution only. Do not write
26 credentials, raw secrets, or private inputs to an execution manifest.
27
28## Material-Change Gate
29
30Any change to the **provider, model, data boundary, or cost ceiling** invalidates
31the plan hash and requires **renewed consent**. The same applies when a fallback
32adds a new provider, transmits additional data, or changes output visibility.
33
34## Dispatch
35
361. Mark the next step `approved`.
372. Invoke only the provider tool named in the step.
383. Capture the provider job ID, exact model/version, start time, and immediate
39 response.
404. Poll status through the provider's own read operation. Do not submit a second
41 job merely because the first is slow.
425. If the provider fails, stop and report the error. Apply only an already
43 approved fallback whose plan hash still matches.
446. Download or attach outputs before provider retention removes them.
457. Mark the terminal status and capture duration, available usage/cost evidence,
46 output identifiers, and any data-retention note.
47
48## Cancellation
49
50Cancellation is separately permitted when the user asks to stop active work or
51when an approved maximum cost or duration guard fires. Use the provider's
52cancellation tool and verify the terminal status.
53
54## Execution Manifest
55
56Return a sanitized manifest containing:
57
58- Plan ID and approved plan hash
59- Provider, model, operation, and provider job ID
60- Start and completion timestamps
61- Terminal status
62- Actual usage or cost evidence when the provider returns it
63- Output paths or provider URLs
64- Fallbacks used
65- Errors and cancellations
66
67Never persist API keys, bearer tokens, raw private prompts, or uploaded file
68contents.
69
70## Anti-Patterns
71
72| Anti-pattern | Correction |
73| --- | --- |
74| Treat plan creation as consent | Ask after showing the final plan. |
75| Switch providers silently | Re-plan and obtain renewed consent. |
76| Retry by creating a second paid job | Poll the existing job first. |
77| Claim actual cost from an estimate | Label estimates and provider usage separately. |
78| Record credentials for reproducibility | Record provider IDs and evidence, never secrets. |
79| Ask for every API key before execution selection | Set up only the selected provider through native login, the host environment, or approved secret storage. |
80
81## Would Revise If
82
83Revise immediately if any paid or data-transmitting call occurs without
84explicit consent. Revisit by **2026-11-11** if provider status models cannot be
85represented without unsafe retries or if execution manifests omit load-bearing
86provider evidence twice.
gabrielmoreira