Does it do the job?
Assess the business outcome—not just whether the response looks plausible.
PLATFORM / ASSURANCE
Prove the work.
Govern the
next action.
Build the evidence to approve AI services and agents for production—with accuracy, cost and control in view.
Test the intended job. Apply your policy to the result. Keep a record your reviewers can inspect.
Criteria set before the runNot assessed is never a passMeasured, not certified
GovernorAI / Assurance
Interactive exampleFINANCIAL DOCUMENT SERVICEA small error.
v7A small error.
A consequential result.
Source amount$10,500
Extracted amount$1,050
Amount exactnessFail
One missing zero changes the business result. The pack catches the critical mismatch.
Illustrative data · no live system is called
At an acceptable cost?
Account for execution, evaluations, retries and review per accepted completion.
What may happen next?
Connect the finding to an approved policy and a supported action or release control.
In the product
See Assurance in the console.
Recorded on a demo tenant: the snapshot that was assessed, each domain scored against its preset bar, what could not be measured and why, and the bundle an auditor receives.
Assurance, step by step
Four screens from a recorded run on a demo tenant.
Recorded against a demo tenant with seeded activity. Real product screens, not a mock-up.
FOUR RECORDS, KEPT APART
A result is not an approval.
An approval is not an effect.
Know what was measured, who reviewed it, which control was connected, and what actually happened. One green state cannot answer all four questions.
What was measured.
The tests, their original acceptance criteria, the result and any missing evidence. An assessment never approves itself.
Evidence from the assessmentWho approved its use.
An authorized reviewer’s decision, with any conditions, bound to the exact snapshot, pack version and run.
Authority stays with your reviewerWhich control was connected.
Not connected, configured, verified or degraded. A connection is not confirmation that a deployment or output was blocked.
Capability and scope recordedWhat actually happened.
Released, withheld, denied, alerted after release or unknown. An effect is recorded separately, from the consumer’s receipt.
Confirmation, not an assumptionTrace one output from finding to effect. Institutional approval is not represented in this example.
WORKFLOW ASSURANCE PACKS
Start with the work.
Not a generic score.
A good summary, an exact amount and an authorized refund are different jobs. Give each one its own tests, evidence and acceptance criteria.
BUILT AROUND YOUR PROCESS
Start from a reusable pack. Validate it against your examples, failure modes and operating requirements.
These are example pack configurations, not benchmark claims.EXAMPLE PACK / AI service
v1.2Financial document extraction
Extract the right facts before they become a downstream record.
Exact amounts and currenciesDeterministic
Required fields and schemaDeterministic
Source-to-field consistencySource checks
When the requirement is not met
Deny release of a known critical mismatch. Hold uncertain output only on a supported path.
Service adapter + source document
TASK TESTSEvaluation owner
Versioned scenarios, methods and criteria.
REVIEW REQUIREMENTSRisk & review owner
Required evidence and approval questions.
RUNTIME POLICYPolicy owner
Authorized responses, replay and rollout.
One connected workflow.
Clear separation of authority.Only approved policy bindings are distributed for enforcement. Evidence signing is separate.
Clear separation of authority.Only approved policy bindings are distributed for enforcement. Evidence signing is separate.
TASK SUCCESS + SIX ASSURANCE DOMAINS
What we assess.
What your environment needs.
Measurability is computed before the run, never inferred from it. See which tests can run in your deployment—and the exact prerequisite behind every gap.
Task success is defined by your pack; it is not a seventh domain.Scroll the table horizontally on smaller screens →
| Domain | What the evaluator exercises | Prerequisite in your deployment | When the prerequisite is absent |
|---|---|---|---|
| Task success | Scenarios with ground truth for the job: exact-match on identifiers and amounts, required fields, abstention, cost per accepted completion. | An execution target and a validated pack with a ground-truth set. | Not assessedThe missing pack, source data or execution target is named. |
| Permissions | Preregistered authority probes replayed through the real runtime policy path: instruction adherence, delegated-authority boundary, unsafe-tool refusal, approval escalation. For services without tools: source access, tenant boundary, output release. | A runtime policy decider on the evaluation path. | Not assessed "no runtime policy decider configured" |
| Grounding | Source attribution and citation validity, abstention where support is absent, rejection of stale documents, escalation on conflicting sources. No model is ever the sole blocking signal. | An execution target able to run the subject and capture its outputs. | Not assessed "no execution target configured" |
| Robustness | Repeat consistency, degradation under padded context, duplicate and conflicting input handling, schema conformance, behaviour under bounded concurrent load. | An execution target. | Not assessed "no execution target configured" |
| Security | The same deterministic detector battery the gateway enforces with — prompt injection, jailbreak, indirect injection, prompt extraction, secret and regulated-identifier exfiltration, unsafe destination — run read-only, with no dispatch and no side effect. | A configured security inspector and access to the effective security policy. | Not assessed "no inline security inspector configured" |
| Privacy | Isolation: a rolled-back transaction per crown-jewel table that seeds one synthetic tenant and asserts a second cannot read, update, delete or write into it, against the real isolation policies. PII: whether the subject's own outputs disclose sensitive data. | Isolation needs the database carrying the real policies. PII needs an execution target. | Partial or not assessedPartial only when one component has evidence. Neither measured means not assessed. Both required components must pass. |
| Efficiency | Latency, provider-metered token and cost consumption, task-success-adjusted cost, bounded consumption. Only usage carrying explicit provenance is counted. | An execution target supplying metered usage with provenance. | Not assessed Projected or unprovenanced usage is never promoted to a measurement. |
ASSESSMENT OUTCOMES
PassFailInsufficient evidenceNot assessedExecution error
COMPOSITE COVERAGEPartialMissing required evidence prevents automatic qualification. A component’s passing result never fills a gap in another. Readiness means a measurement can be attempted—not that it will pass.
THE BAR IS SET BEFORE THE RUN. SO IS THE SAMPLE.
All 11 probes passed.
The evidence was still insufficient.
Under this sampling plan, it is the lower confidence bound—not the raw pass rate—that must clear the threshold. Eleven clean probes support a bound of 0.7412. The result is Insufficient evidence.
The planner shows the gap before you run: at zero failures, this 0.99 threshold needs 381 total observations. It does not offer a lower threshold as the fix.
Stated assumptions, not a safety guarantee.
Two-sided 95% Wilson, independent probes. This is a best-case planning calculation—not a guarantee that 381 prompts establish safety. Coverage instruments carry no interval.
Security / criticalIllustrative calculation
- Probes passed
- 11 / 11
- 95% lower bound
- 0.7412
- Acceptance threshold
- 0.99 Locked before run
Insufficient evidence
No unsafe outcome was observed.
The sample cannot support the threshold.
ZERO-FAILURE PLANNING CASE381 total observations
Minimum total for 0.99 under the stated calculation.
Eleven probes support about 0.74.
NEXT ACTIONS
Review sampling plan
Expand validated coverage
Request acceptance-policy change
The threshold on this run does not change.
CONTINUOUS ASSURANCE
Don’t stop at a score.
Decide the next action.
Evaluate live outputs, then apply an approved policy at the point the integration can control. See the difference between detecting an error and preventing its release.
INTERACTIVE EXAMPLE Document extraction
What does the service return?
Source documentIllustrative vendor request01 / 01
Please prepare the record for the amount below. Release only after required checks.
Amount in source$10,500.00 USD
Service output$1,050.00 USDOne zero lost in extraction.
This example retains the output until the approved release policy permits it.
GOVERNORAI DECISIONDeny
The wrong amount goes no further.
The exactness check found a critical mismatch. The approved release policy denies this output; correction requires a new evaluation.
- Output evaluation
- Fail
- Output review
- Not overridable
- Release policy
- Document release · v5
- Control timing
- Before output release
- Observed effect
- Withheld
Withheld · example effectExample receipt: output retained; nothing released downstream.
Runs in your browser with illustrative data. No real output, approval or system action is performed.
Known critical errors are withheld for correction. Uncertain results can enter an authorized, expiring review path. Corrected outputs are evaluated again before release.
EVALUATION METHOD
Deterministic checks first; a judge only where no deterministic check exists, and never as the sole blocking signal.
FROM FINDING TO CONTROL
A failed probe can become a rule.
Not by itself. Not untested.
In this illustrative USD refund workflow, a $4,800 request should wait for approval above $1,000. Investigate the cause, then test a scoped candidate—not a blanket deny.
- 01
Establish the cause
Missing rule, wrong assignment, precedence, or test data.
- 02
Scoped candidate
Draft from the finding’s field, operator, value and intended scope.
- 03
Replay
Test failing probes and legitimate allowed cases on the real policy engine, without consequential actions.
- 04
Approve the tested candidate
The policy owner reviews the tested version. An edit invalidates the dependent approval.
- 05
Signed, staged
Distribute only approved policy. Stage rollout and record the consumer’s acknowledgement.
- 06
Effect verified
Link the observed result to the original finding. Preserve the failed evidence.
REFUND APPROVAL / ILLUSTRATIVE CANDIDATENot active until approved
# Illustrative USD-only workflow — not a production policy schema.
# Source: example-refund-review / case-02
- id: approve-amount
match:
tool: finance.process_refund
condition: { field: args.amount, operator: ">", value: 1000 }
action: require_approval
reason: "Refunds over $1,000 need manager approval"A proposal, not permission.
Review and safe replay happen before rollout. A drafted rule does not change what production may do.
Synthetic example, unrelated to any staging incident. No policy is signed, pushed or activated by this page. The actual native schema and supported distribution path are verified during implementation.
REVIEW-READY EVIDENCE
Give reviewers
more than a score.
Turn scattered tests, approvals and runtime findings into a record of what was assessed, what was decided and what actually happened.
See the result, review decision, assessment coverage, integrity, currentness, connected control, and observed effect—each with its own evidence and limitations.
↗
The exact version. The original criteria.
Pin the subject, pack, evaluator and policy references. Preserve the original run when anything changes.
↗
A review decision—not self-approval.
Keep assessment findings separate from the authorized reviewer’s decision and any conditions.
↗
Evidence that travels.
Export a readable review report and machine-readable evidence. Verify signed artifacts outside the console when signing is configured.
Illustrative HTML report · unsigned · no customer data
GovernorAIMODEL REVIEW / EXAMPLE
Financial extraction service
An evidence packet. Not an automatic approval.
Subject v7 · Pack v1.2 · Policy v5
Critical amount checkFail
Source amount$10,500.00 USD
Extracted amount$1,050.00 USD
Observed effectWithheld
One illustrative output. Not a complete assessment of the model, service or deployment.
Illustrative record · unsigned
Result, review, assessment coverage, integrity, currentness, connected control and observed effect remain distinct.
FOR MODEL RISK & INTERNAL AUDIT
Organize evidence around your review requirements, with versioned profiles and explicit gaps.
THE GOVERNORAI LIFECYCLE
One thread, from discovery
to the action record.
Your assessed version, approved policy and observed decisions stay connected. Change the configuration or a relevant dependency, and the need for a new assessment becomes visible.
Fix the criteria. Test the work.
Evaluate the actual service or agent against a versioned task pack. Show readiness first, then results, gaps and the evidence required for review.
SUBJECTSnapshot v7
TASK PACKExtraction v1.2
CRITERIAAcceptance v3
MEASURE THE PILOTBusiness outcomes.
Business outcomes.
Not a universal trust score.
Measure performance and review effort
against your workflow’s requirements.
- Critical errors missed
- Missed critical-error cases ÷ all adjudicated critical-error cases.
- Unnecessary holds
- Acceptable outputs unnecessarily withheld ÷ acceptable outputs evaluated.
- End-to-end latency
- p95 across measured workflow completions; sample count and window stated.
- Cost per accepted completion
- Execution, evaluation, retries and attributable human-review cost ÷ verified acceptable completions.
- Reviewer effort
- Reviewer minutes per 100 reviewed outputs.
Output-review effort is not production-approval effort. Record evidence-preparation and institutional-review effort separately. Missing measurements stay unmeasured.
A FEW IMPORTANT DISTINCTIONS
Built for real
approval decisions.
Is this only for autonomous agents?
No. Assess a service, an agent or a supported workflow. A document service can be governed at output release; an agent can be governed at a tool or action boundary. Each requires the right execution adapter and context.
Does a passing assessment approve deployment?
No. Assessment, institutional approval and deployment admission are separate. A configured gate checks the required, current evidence and authorization. The record distinguishes a policy decision from confirmation that the deployment was stopped.
Does GovernorAI replace our risk reviewers?
No. GovernorAI prepares traceable evidence and supports your review process. Your authorized reviewers decide what is acceptable, including limitations and permitted use. A report is not a compliance certification.
Can every integration hold an output?
No. Withholding requires a verified pre-release or pre-action control. Post-release events and unbuffered streaming paths provide observation, not retroactive prevention. The interface states which behavior is available.
Do we need to replace our agent framework or policy engine?
Start with the service or agent you already run. Use supported execution adapters and retain your existing policy workflow, including native policies or supported Rego/OPA paths. Confirm compatibility and control coverage for the selected workflow during setup.
START WITH ONE WORKFLOW
What stands between
your AI and production?
Bring the workflow. We’ll map the acceptance criteria, evaluation plan, control points and evidence your reviewers need.
Request a briefing Focused on your use case.
Built around your existing stack.
Built around your existing stack.
Continue
Platform overviewFive stages, seven product surfaces, one policy object Discovery & Shadow AIInventory the AI activity nobody registered Policy & GovernanceOne policy, from intent to evidence Runtime EnforcementDecide at the action boundary Evidence & ComplianceHash-chained audit record, mapped to controls RiskScore the action, and act on the score