Workflow and states
Inputs, systems, people, and models involved at each step of the workflow.
The operating model
Model the work once. Govern capital, execute approved work, and prove what happened.
TokenOps and RunTime aren't two separate methodologies bolted together. They read from the same diagnostic foundation — the same map of a workflow drives what gets funded and what gets executed.
Diagnostic foundation
Everything downstream starts with one workflow model.
Decisions and rules
The decisions being made, the rules governing them, and the approvals required.
Authority and evidence
Permitted actions and authority; costs, outcomes, and risks; exceptions, escalation, and the evidence each one leaves behind.
The three-step pattern
Model the work. Compile the control. Execute under authority.
1 · Model
Capture the workflow
States, inputs, systems, decisions, rules, approvals, permitted actions, exceptions, and evidence — usually starting with order exceptions, promotion execution, or close and reconciliation.
2 · Compile
Generate the control
Create a compiled workflow: typed schemas, classifiers, guard predicates, action templates, and parameterized queries. Experts review and version every artifact before release.
3 · Execute
Run under authority
Validate the case, apply approved artifacts, use models only for bounded interpretation, execute permitted APIs, escalate exceptions, record outcomes.
The RunTime architecture
The LLM is the compiler—not the computer.
Offline, frontier models may analyze approved policies, historical cases, schemas, and workflow examples. People then review, version, test, and promote classifiers, schemas, guard predicates, action templates, and query bundles like software. Online, authoritative workflow decisions execute through those approved artifacts and deterministic controls, without an open-ended frontier-model decision in the hot path. Optional models may interpret or generate language only within a constrained boundary; they cannot expand their own action authority. Low-confidence, unfamiliar, or prohibited cases escalate instead of triggering unconstrained reasoning.
- 1 · Compile
Approved knowledge → artifacts
Policy: business owners define the source policy; frontier models may assist offline.
- 2 · Compiled Workflow Registry
Review, release, govern
Authority: human release owners approve, version, test, and promote what may run.
- 3 · Run
Decide, act, prove
Execution & evidence: deterministic controls execute permitted actions, log outcomes, and escalate exceptions.
Proverify workflow autonomy framework
Advance authority only when the workflow earns it.
This six-level framework turns the Diagnostic foundation into a buyer-readable path from manual work to defined-workflow autonomy. The three-step pattern supplies the model, controls, and RunTime evidence used to set — and validate — target autonomy.
The unit of certification is the workflow envelope.
A certification applies only to a named workflow, versioned controls, permitted actions, systems, data, operating conditions, and escalation path. It does not certify an enterprise or an AI model in the abstract. Change that authority envelope materially and it must be evaluated again.
L0
Manual work
People decide and perform every step.
Manual work
People decide and perform every step.
- Entry
- The workflow is performed manually or has not yet been reliably mapped.
- Decision
- A human operator.
- Action
- A human operator.
- Evidence
- Existing tickets, approvals, system records, outcomes, and manual notes.
- Exception
- The operator follows the current management or specialist escalation path.
- Advance when
- Owners can demonstrate a stable workflow, baseline results, decision rules, exceptions, and evidence requirements.
L1
AI assistance
AI retrieves, summarizes, or drafts; people remain in control.
AI assistance
AI retrieves, summarizes, or drafts; people remain in control.
- Entry
- The L0 workflow and baseline are documented, with approved data access for assistance.
- Decision
- A human, informed by AI-produced context or drafts.
- Action
- A human.
- Evidence
- Inputs, AI output, source references, edits, final human decision, and outcome.
- Exception
- The human disregards the output and uses the manual path; unsafe or unsupported output is flagged.
- Advance when
- Shadow evaluation shows accurate, traceable assistance and defined failure classes across representative cases.
L2
AI recommendations, human execution
AI proposes a decision and action; a person chooses and acts.
AI recommendations, human execution
AI proposes a decision and action; a person chooses and acts.
- Entry
- L1 evidence shows reliable assistance, and recommendation boundaries and approval roles are explicit.
- Decision
- A human accepts, changes, or rejects the AI recommendation.
- Action
- A human executes in the system of record.
- Evidence
- Recommendation, rationale, policy version, human disposition, executed action, and result.
- Exception
- Low confidence, policy conflict, or missing data routes to the named reviewer with no automated write.
- Advance when
- Teams demonstrate recommendation quality, reviewer agreement, complete logs, and safe handling of known exceptions.
L3
Bounded execution, required human review
The system acts inside narrow limits; every action requires review.
Bounded execution, required human review
The system acts inside narrow limits; every action requires review.
- Entry
- L2 performance meets agreed thresholds, and permitted APIs, limits, rollback, and review timing are tested.
- Decision
- The system decides only inside encoded bounds; a human reviews each decision before or immediately after execution, as specified.
- Action
- The system executes the permitted action.
- Evidence
- Case state, rule and artifact versions, decision, API action, human review, outcome, and undo status.
- Exception
- Execution stops or is reversed and the case enters a staffed queue; timeouts default to the defined safe state.
- Advance when
- Production evidence proves policy adherence, review completeness, reversible actions, and acceptable exception and outcome rates.
L4
Supervised autonomy
Autonomous operation within a certified workflow envelope.
Supervised autonomy
Autonomous operation within a certified workflow envelope.
- Entry
- The specific workflow and authority envelope pass certification review, including controls, monitoring, security, failure tests, and accountable owners.
- Decision
- The system decides within the certified envelope; supervisors set policy and may intervene.
- Action
- The system executes without case-by-case approval inside that envelope.
- Evidence
- End-to-end traces, control versions, authority checks, actions, outcomes, monitoring alerts, and sampled supervisory reviews.
- Exception
- Out-of-envelope, anomalous, or high-risk cases fail closed, pause, or escalate to the designated human owner.
- Advance when
- Sustained production operation demonstrates control effectiveness, stable outcomes, timely escalation, recovery, and coverage of the defined workflow.
L5
Defined-workflow autonomy
Autonomous operation with monitoring and exception escalation.
Defined-workflow autonomy
Autonomous operation with monitoring and exception escalation.
- Entry
- L4 evidence shows the complete defined workflow can operate safely across its certified conditions, including tested degradation and recovery.
- Decision
- The system makes all in-envelope operational decisions; humans govern the envelope and its objectives.
- Action
- The system executes the end-to-end defined workflow.
- Evidence
- Continuous decision and action traces, outcomes, control health, drift signals, exceptions, interventions, and recertification history.
- Exception
- The system contains or pauses the affected path and escalates novel, out-of-envelope, or policy-level issues to accountable humans.
- Maintain when
- Continuous monitoring, periodic challenge tests, change control, and recertification show the workflow remains inside its approved envelope.
Terminology note. The L0–L5 progression is Proverify’s workflow autonomy framework. Its terminology is inspired by familiar driving-automation levels for ease of communication; it is not an NHTSA framework, endorsement, or formal NHTSA certification.
Entry engagement
A focused first engagement, not an open-ended project.
Pick one workflow. Baseline its economics with TokenOps. Define the authority envelope and evidence a RunTime would need. Leave with a decision-ready plan — fund, redesign, or build — not a slide deck of possibilities.
Week 1
Workflow and baseline
Map the workflow, its states, and its current cost and cycle time.
Week 2
Authority and evidence
Define permitted actions, escalation rules, and the evidence a RunTime would record.
Output
Decision-ready plan
Cost baseline, target autonomy, and a build/fund/redesign recommendation.