From intent to evidence
1
Make capabilities available
Your organization registers options Solver may select. The API calls each
option an
arm: a model, an agent endpoint, or a reusable skill.2
Send a task and limits
Describe the outcome. Declare the allowed data, maximum cost, maximum
runtime, routing preference, and any response allowed after a check.
3
Remove what cannot run
Solver keeps options that are ready and permitted for every declared data
class.
4
Choose and run
Solver deterministically ranks the eligible options and starts the selected
route. The run is asynchronous, so the application follows its status to a
final outcome.
5
Check within the rules
Solver applies the selected verifier or its basic output check. Fallback or
a repair proposal can happen only when the run explicitly allows it.
6
Return two useful records
When live work completes, the result contains the output for the application.
The receipt records the route, recorded usage, check, and any bounded action.
Task and output content stay separate.
One unit of work
The docs call this a run. The API resource is anexecution. They are the
same thing: one submitted, tracked unit of work.
The execution and receipt schemas are slice-shaped. The current public request
creates one placeholder slice for one clear objective and one run.
What the application owns
Your application still owns the product decision: the task, the permitted data, the budget, the runtime boundary, and whether a returned result is fit for its users. Solver makes the execution path inspectable. Product judgment stays with your application.Build the lifecycle
Implement polling, final states, cancellation, and retention.
Understand the evidence
See what belongs in a result and what belongs in a receipt.