Define the boundary.
Map the workflow, its model and tool calls, and the actions the controller could mediate. Identify existing provider accounts and the owner of each policy.
AGREED OUTPUTWorkflow map & success criteria
THE PLATFORM / PILOT SCOPESet the rules.
Set the rules.
Keep control as work moves.
Choose where AI work may run, what it may spend, and what needs approval. Bring those decisions into the workflow at the points where the next action can still change.
See it in the demo ↗PROPOSED ENACTMENT ARCHITECTUREConcept
01 / REQUEST
▤Your workloadInputs · requirements · budget
02 / CONTROL
⌘numericspace controllerCurrent policy · eligible route
Policy versionsEnactment ledger
03 / EXECUTE
▧Approved workersLocal · cloud · model API
Dispatch, retries, transfers, and result release create a connected decision record.Explore evidence ↓
CONTROL THE NEXT DECISIONFour checkpoints.
Four checkpoints.
The current policy.
A workflow can change after it starts. The proposed controller evaluates the next protected action against the policy active at that point.
DISPATCH / CURRENT AUTHORIZATION
Check eligibility before the first action.
Evaluate the chosen model, worker, permissions, and budget before dispatching the workload.
{
"checkpoint": "dispatch",
"policy_version": "v12",
"worker": "approved-local",
"decision": "allow"
}Illustrative record format · not a published APIYOUR INFRASTRUCTURE, CONNECTEDChoose where
Choose where
the work belongs.
Define which steps may use local workers, approved cloud services, or either. Evaluate how routing responds when those conditions change.
Explore the workloads ↗AN EXPLANATION YOU CAN FOLLOWMake every important
Make every important
decision inspectable.
Connect a result to the policy version, worker, and enactment decisions behind it. Keep estimated spend separate from reported usage, including attempts that need reconciliation.
- Version and context of each policy decision
- Linked retries, handoffs, and release decisions
- Estimated, reported, and unresolved costs
- Explicit status for uncertain external outcomes
EVIDENCE / JOB_1042Sample
A result has a history.
- Policy checked
Dispatch allowed under version v12.
- External attempt submitted
Cancellation support recorded.
- Policy changed
Version v13 restricts external processing.
- Next action held
Result release requires review. Prior transfer remains recorded.
FROM DESIGN TO EVALUATIONA focused pilot.
A focused pilot.
A decision you can make.
Start with one workflow and up to two enactment endpoints. Agree on the boundaries, the policy changes, and the evidence that would support a next step.
Connect the checkpoints.
Implement the agreed checks at supported enactment points. Record policy versions, attempt status, and the cancellation behavior each endpoint actually exposes.
AGREED OUTPUTScoped reference workflow
Evaluate what changes.
Introduce policy changes during controlled runs. Inspect decisions, added latency, cost estimates and reported usage, including outcomes that remain unresolved.
AGREED OUTPUTEvidence & evaluation summary
BEFORE CONNECTING AN ENDPOINT
Use the planning resources Know what the worker can tell you.
Confirm its permission model, usage reporting, cancellation support, and completion signal. These determine the pilot’s control boundary and how uncertain outcomes are represented.
A CLEAR CONTROL BOUNDARYControl the next action.
Control the next action.
Represent the past accurately.
A policy change can block the next action numericspace controls. Stopping work already running depends on the worker or provider’s cancellation support.
A cancellation request is not confirmation that enactment has stopped. Work may finish, create side effects, or incur charges. A policy change cannot undo an external action that has already completed. Withholding a result controls release through numericspace; it does not erase data already sent.
DEFINE. CONNECT. EVALUATE.Start with a workflow
Start with a workflow
your team can inspect.
A proposed $7,500 pilot, with scope and acceptance criteria agreed before kickoff.