CONTROL ASSURANCE / CONTROL CONDITION VERIFICATION

Before AI goes to production or a customer, make the control explainable.

Before customer handoff, production release, audit, or review, organize what work may be delegated to AI, where it must stop, and when it must return to a person. When runtime evidence is needed, use the separate formal inspection to check the actual processing path without turning a successful observation into automatic delegation or runtime permission.

Freeze conditions firstSearch for counterexamplesKeep unobserved scope visible

Open free pre-screening →View public sample Japanese authority

This is not a complete guarantee or third-party certification. Claims remain bounded to the fixed target version, decision conditions, and observed cases.

CHOOSE FROM THE CURRENT STAGE

DURING DEVELOPMENT / ASYNCHRONOUS

Turn the current design into
implementation and QA conditions.

AI Agent Control Design Review

Introductory estimate: JPY 30,000 (excl. tax) per flow

For one flow, we organize control issues from documents and written clarification, then turn them into required control properties and post-implementation verification conditions.

DeliverableTwo-page Review SheetOne to two control conditions; normally up to two clarification rounds. Runtime inspection is not included.

See the review service

AFTER IMPLEMENTATION / PRE-RELEASE

Check whether the implemented
control holds under changed conditions.

Control Condition Gap Check

Freeze the target version and conditions, observe changed-condition behavior, and preserve the result, evidence, and unobserved scope.

DeliverableControl Verification Record and evidenceRuntime inspection is performed only within the agreed scope and can support recipient-side re-checking.

See the formal inspection

The free pre-screening is the common entry point. A review or formal inspection is selected only when its scope is actually needed.

BEFORE PRODUCTION / CUSTOMER HANDOFF

From “the AI works” to “we can explain the control before handing it over.”

For AI systems with external effects, performance is not the only question. A recipient may also need to know under which conditions the system stops and what was actually checked.

Before customer handoff

Before handing an AI system with external effects to a customer

Use this when you need to check whether approval, authority, external sending, tool execution, and related controls are implemented as described.

Before production release

Check the control path itself, not only whether tests pass

Use this when you need runtime evidence about whether abnormal input, reordered steps, retries, or target mismatches can bypass a condition that should stop the action.

Before audit or review

Show the exact target and basis instead of saying only that the system is safe

Keep target version, decision conditions, observations, and unobserved scope separate so a verification record can be referenced during audit, review, or counterparty explanation.

High-accountability work

External effects in finance, healthcare, public services, infrastructure, and similar domains

The focus is not model performance or the business decision itself. It is the implemented control path around sending, updating, payment, tool execution, and other external effects.

The formal inspection can also leave a route that another party can follow.

Target version, decision conditions, results, and evidence can be connected through a Verify ID so customers, counterparties, or auditors can inspect the same record. A Verify ID is not a certification badge.

View the public sample

AI AGENT CONTROL DESIGN REVIEW

Share the materials. Clarify in writing.
Receive two pages that implementation and QA can use.

We organize controls such as approval, authority, execution target, and retry on a document basis, one Control at a time. We separate what the materials establish from what remains unproven, then design the conditions implementation must satisfy and the QA conditions to test after implementation.

Meetings: None by default
Target: 1 flow
Control conditions: 1–2
Written clarification: Up to 2 rounds
Deliverable: 2 pages

How the review works

01
Freeze the scope
Fix the target flow, consequential effects, control concerns, and document version in writing.
02
Separate what the materials support
Keep source facts, customer-confirmed policy, and review inference distinct. Unknowns stay unknown.
03
Translate into implementation conditions
Organize Required Control Properties, improvement candidates, QA and negative-test conditions, and evidence to collect.
04
Return a two-page deliverable
Provide a review summary and Verification Condition table that implementation and QA teams can act on.

THE REVIEW DEFINES

Conditions handed to implementation and QA

Which control condition must hold under which circumstances
Required Control Properties the implementation should satisfy
Improvement candidates plus QA / negative-test conditions
Evidence to compare later and items still unresolved

THE REVIEW DOES NOT DEFINE

No runtime result is created

A runtime determination that the control is actually working
A safety determination, confirmed vulnerability finding, or formal inspection result
Execution, release, deployment, or permit authority
The customer's policy or final adoption decision

REVIEW → FORMAL INSPECTION

If you later need to know whether it actually stops at runtime, the Verification Conditions can become candidates for the formal inspection.

Required Control Properties, Verification Conditions, and evidence candidates from the review can be fixed in a separate work stage and used as inputs to the Control Condition Gap Check. A review result never becomes a formal result automatically.

See the formal inspection →

Open the review request form

PUBLIC SAMPLE OF THE TWO-PAGE REVIEW SHEET

Example: external sending protected by Human Approval.

This is an explanatory sample showing what a document review can say and what must remain a post-implementation Verification Condition. It is not an inspection result from a real engagement and does not assert a confirmed defect.

PAGE 1 / REVIEW SUMMARY

Does what was approved remain the same as what will actually be sent, all the way to the external effect?

Supported by the materials: The specification states that a Human Approval node and sending node exist.
Customer-confirmed policy: Changing the destination after approval is not allowed.
Not established from the materials: How the approved object and outgoing object remain bound as the same object until the external effect.
Required control condition: Keep the approved destination and runtime destination bound as the same object until the external effect.
Improvement candidates: For example, re-check an approval-time digest immediately before the effect, and return to re-approval if the content changes.
Unresolved: Whether an existing approval can be reused on retry.

PAGE 2 / VERIFICATION CONDITION TABLE

After implementation, what should QA test and preserve as evidence?

Explanatory Verification Conditions, not runtime results.
Case	Expected behavior / evidence
Approved=A / Runtime=A	Agreed normal path. Record the approved object, runtime object, decision result, and external effect.
Approved=A / Runtime=B	Do not send externally based only on the existing approval. Record the object difference and decision result.
Retry after denial	Do not execute the denied request as-is. Record approval reuse and retry state.
Retry after unknown result	To avoid duplicate effects, fix the conditions for checking any prior effect and for retry.

The review designs Verification Conditions. It does not perform runtime observation or generate a formal Gap Check Result.

Review → implementation / QA → formal inspection only if needed.

Clarify the specification, implement the control, hand it to QA, or request more materials. Move to the separate Control Condition Gap Check only when runtime behavior and evidence are needed.

Each service can be requested independently. Moving from review to formal inspection is optional and never automatic.

DELEGATION-CONDITION VERIFICATION

A control working is not the same as deciding that the work may be delegated to AI.

In the formal inspection, we keep three layers separate: what was actually observed, what evidence can support a delegation decision, and whether runtime permission is actually granted. A C³ verification result does not automatically issue a runtime Permit, release authority, or deployment authority.

1 / OBSERVED CONDITION

What actually happened?

Preserve what proceeded correctly, what stopped correctly, counterexamples, and unobserved scope without upgrading or filling the gaps.

2 / DELEGATION-DECISION SUPPORT

Does the evidence support delegating this work?

Consider required blocking tests, related controls, target identity, counterexamples, and unobserved scope—not only successful allow-side observations.

3 / RUNTIME PERMISSION

Leave the final execution authority separate.

Execution, deployment, release, and runtime Permit remain separate authority decisions. Verification does not generate them automatically.

Observed control ≠ delegable scope ≠ runtime permission

A correctly blocked cell is not reinterpreted as a cell where the external action may be delegated. UNOBSERVED, UNDEFINED, and counterexample-bearing scope are not inferred into a delegable operating region.

View the delegation-condition samples →View the demonstration registry →

These explanatory mappings do not create a new canonical result, safety guarantee, certification, or runtime Permit.

WHY THIS EXISTS

For formal inspection, a control being present is not the same as giving decision-makers inspectable evidence.

Internal tests may pass while missing approval, alternate routes or evidence gaps still create uncertainty. The formal inspection connects the exact version, the declared control, the observed route and the evidence boundary instead of asking the recipient to trust a summary.

Common gap

The provider understands the control internally, but the recipient cannot inspect the same basis.

A passing test suite does not by itself tell a customer which version was tested, which control was declared, which changed-condition cases reached the target, or which routes remain unobserved.

Needed state

Version, control, observations, evidence and re-verification procedure are connected in one traceable route.

That makes it possible to decide what authority to delegate without generalizing beyond the checked scope.

CONTROL MAP

From repeated observations to a bounded operating envelope.

The diagram is illustrative. It separates per-execution observations from a conditional boundary, supported envelope, undefined area and unobserved area; it is not an actual assessment result or safety certification.

Change conditions and replay repeatedly

From points to boundaries and an operating envelope.

Illustrative diagram

Declared controlExternal effect requires approval

Authority · State · Sequence · Target · Payload · Retry / Recovery

Control preserved
Counterexample
Evidence inconclusive
Undefined
Unobserved

Control Operating EnvelopeThe operating conditions supported for this declared control and evidence class.The amber band is not a one-execution result; it is a conditional boundary summarized from multiple observations. Undefined and unobserved areas are not filled in as safe or unsafe. A preserved observation does not establish universal safety, and a counterexample does not establish system-wide danger.

What an AI provider gains

Make authority-delegation decisions only for the scope that was actually observed.
Give customers, counterparties and auditors one Verify ID that leads back to the same evidence path.
Separate counterexamples, UNDEFINED and unobserved scope instead of making an oversized safety claim.
Re-run the same case after remediation and preserve the before/after evidence.

Human decision boundary

C³ does not decide whether your organization should deploy the system, accept the risk, or delegate the authority. We structure evidence that can support that human decision.

SEE → TEST → RE-CHECK

From an inspection result to a re-checkable evidence route.

We connect version freeze, declared control, runtime observation, comparison, evidence packaging, Verify ID and BYOV. If a step cannot be established, it is not silently presented as confirmed.

MIL is the description foundation connecting conditions, decision reasons, and evidence references. Its role in the gap check and the public materials are explained in the MIL overview (Japanese).

01
Freeze the target version
Fix the exact release or version under review so later changes cannot be mixed into the result.
02
Freeze the protected control condition
State the condition that must remain true, such as: an external effect must not execute without the required approval.
03
Observe the normal path
Run the satisfied condition through the actual processing path instead of inferring behavior from documentation alone.
04
Change one control-relevant condition
Introduce cases such as missing approval, expired authority, target mismatch, alternate route, retry, or recovery.
05
Compare under the same rule
Compare normal and changed-condition observations using the same declared control and comparator.
06
Separate UNDEFINED and unobserved scope
Do not convert missing evidence or untested routes into a PASS. Keep evidence insufficiency and unobserved scope distinct.
07
Re-run the same case after remediation
When a counterexample is found, use the same case after the fix to confirm whether the behavior actually changed.
08
Bind evidence to Verify ID and BYOV
Package the target, condition, observations, scope limits and evidence so a recipient can trace and re-check the result.

EVIDENCE → VERIFY ID → BYOV

Package the basis so the recipient can trace it.

01 / Freeze evidence

Evidence Bundle

Bind the target version, control, observations, evidence and unobserved scope.

02 / Bind identity

Verify ID

Give the evidence route an identifier that points to the exact subject and result.

03 / Re-check

BYOV

Let the recipient trace and re-check the supplied materials and procedure.

Verify ID is an evidence-path identifier, not a certification badge. BYOV is recipient-side re-verification, not third-party certification.

PUBLIC SAMPLE

A real before/after control record, with the claim boundary preserved.

Published sample C3-CAV-2026-0001 records the declared rule “PASS requires approval_present=true.” and the same missing-approval witness before and after remediation.

Before remediation

Permit issued without approval

Permit issued

The protected missing-approval case reached PASS, with permit_token_issued=true.

Same witness after remediation

Missing approval is held

No permit issued

The same case reached HOLD, with permit_token_issued=false and reason_code=EAG_APPROVAL_MISSING.

Fix PR #127. This is an observation record from C³’s own development, published as a sample. It is limited to its fixed target version, declared control and witness set. Permit issuance does not establish that an external effect occurred. Public JSON and evidence can be rechecked; this does not rerun the original target system.

Open the technical verification record

RE-CHECK THE PUBLISHED RESULT

Let the recipient verify the published record and evidence binding in the browser.

The integrity check recalculates the published record fingerprint. The BYOV check compares the published test result with the evidence bundle. Neither check re-runs the original target system.

PUBLISHED RECORD INTEGRITY

Check whether the published record changed

Recalculate the SHA-256 fingerprint of the published verification record in your browser and compare it with the value bound to this page.

This confirms whether the published record bytes changed. The right-hand check compares the test result with the evidence bundle.

BYOV — BRING YOUR OWN VERIFICATION

Check the evidence-to-result binding

An AI provider can give this page to a customer or auditor, who can then compare the published evidence with the published test result in the browser. The same procedure can be repeated against the same public materials.

Evidence JSON Technical details

This button checks the relationship between the published evidence and test result. It does not re-run the original system and it is not third-party certification.

DELIVERABLES

More than a PDF: a re-checkable evidence package.

The engagement complements existing tests and audits. It does not replace them.

View Verify ID sample record

Target & control-condition matrix

What version, execution route, protected condition and observation scope were fixed.

Normal / changed-condition comparison record

Observed behavior under the same comparator, including remediation re-runs where applicable.

Unobserved & UNDEFINED register

Routes not tested and areas where evidence was insufficient are recorded separately.

Evidence Bundle, Control Verification Record & Verify ID

A traceable package connecting the version, control, result, evidence and re-verification procedure.

POSITIONING

Separate the work by what part of the AI project is being checked.

Organization-wide governance, responsibility design, AI quality, and external-effect control verification answer different questions. C³ primarily focuses on controls and evidence around the point where AI causes an external effect.

Organization-wide

AI governance / certification support

Organization-wide policies, management systems, governance structures, and external certification programs.

Engagement decision

Responsibility / operating design

Who decides, where approval is required, and how responsibility and operating conditions are divided.

AI quality

Performance / task-success evaluation

Accuracy, reproducibility, task success, and other measures of how well the AI performs the intended work.

Primary C³ scope

External-effect control verification

Observe whether controls around sending, updating, payment, tool execution, and other external effects work in the implementation, and preserve target version, conditions, and evidence.

These are not mutually exclusive choices. Control Assurance can be combined with organization-wide governance, responsibility design, performance evaluation, security assessment, and audit. This is a difference in what is being checked, not a ranking of those approaches.

CHOICE / PRICE / PROCESS

Choose the work you need now.

Start with free pre-screening to organize the work you may want to delegate to AI, the conditions under which it must stop or return to a person, and what remains undecided. Use the review when the conditions themselves still need to be defined; use the formal inspection when the conditions are fixed, the implementation exists, and runtime behavior and evidence need to be checked.

Scope and deliverables
Item	Control Design Review	Control Condition Gap Check
Standard scope	1 flow; 1–2 control conditions	Quoted per engagement: target version, conditions, cases, evidence and runtime environment
Primary materials	Design documents and explanations	Target version, implementation, and inspection conditions
Process	Asynchronous; normally up to 2 written clarification rounds	Execution environment and evidence conditions are agreed
Runtime inspection	Not included	Performed within the agreed scope
Deliverable	Two-page Review Sheet	Control Verification Record, evidence, and unobserved scope
Result meaning	Designs implementation and QA conditions from materials	Runtime observation result for the specified scope
Recipient-side re-check	No BYOV or Verify ID in the standard review	BYOV, Two-Rail, and Verify ID are handled according to delivery conditions

AI AGENT CONTROL DESIGN REVIEW / ASYNCHRONOUS

Introductory price estimate

JPY 30,000 (excl. tax) per flow

Standard scope is one flow and one to two control conditions.

The work proceeds through materials and written clarification, normally up to two rounds. The basic deliverable is a two-page review summary and Verification Condition table.

Material volume, complexity, or scope may require a separate quote. Suitability is checked before material sharing; delivery timing, contracting party, price, and tax treatment are presented and agreed before work begins.

A consultation does not automatically become a paid review. Runtime processing, code changes, certification, and a formal Gap Check Result are outside the standard review scope.

Discuss the review scope →

FORMAL INSPECTION / INDIVIDUAL QUOTE

Control Condition Gap Check

From JPY 200,000 (excl. tax; quoted individually)

This is not a fixed-price plan. We estimate each engagement from the target, control complexity, runtime environment, accessible evidence and required work. Case counts, duration and retesting are agreed per engagement.

For an agreed version and control, we compare observed execution behavior, record counterexamples, indeterminate outcomes and unobserved scope with supporting evidence. Deliverables, any retesting, timeline and the total price are confirmed before work begins. No runtime permission is issued.

Discuss formal inspection →

RESPONSE AND STATE-LOG REVIEW

One control for a delegation decision

JPY 50,000 (excl. tax)

One flow, one target version, one delegation condition and one declared control. Compare existing responses and customer-provided state logs with expected behavior agreed in advance, for up to 20 cases. Receive a one-page control record with observations, counterexamples, missing evidence and unobserved scope. Response logs alone do not establish that external operations stopped. Runtime setup and adapter development are outside this separate service.

Explore the small-scope plan

Formal inspection starts from JPY 200,000 (excl. tax) and is quoted by actual scope and work, not a fixed set of case-count or add-on plans. Any extra work or retesting requires agreement before proceeding. A verification result never issues delegation approval or runtime permission.

The estimate identifies the inspection scope, required effort, evidence and deliverables. No fixed add-on fee or automatic upgrade applies.

01Free pre-screening
From one workflow, identify two or three important routes or candidate checks, optionally decompose them into up to eight cells, and keep undecided conditions explicit. Decide whether the next candidate is design review or runtime inspection without automatically changing the service requested.
02Confirm scope and quote
Only if you proceed to a paid service, agree the materials, deliverable, timing, confidentiality, and engagement conditions.
03Start and receive the deliverable
Request the review, the Gap Check, or both in sequence when needed. No paid transition is automatic.

If C³ has participated in the design of the same target, that involvement is disclosed in any later inspection. Changing the contracting entity alone does not make the inspection independent.

COMMON ENTRY

Start free by organizing
what should be checked.

Free pre-screening is the common entry point for the Control Design Review and Control Condition Gap Check. Using public information or simple non-confidential materials, we identify two or three important paths or candidate checks.

Common entry / materials and written exchangesOpen free pre-screening →I need implementation / QA conditions during developmentDiscuss a Control Design Review →I need runtime evidence after implementation or before releaseDiscuss a Control Condition Gap Check →

Free pre-screening stops at identifying important paths or candidate checks and determining the appropriate next step. It does not include detailed improvement design, definition of Verification Conditions, or runtime inspection. Material-transfer and confidentiality conditions are confirmed before non-public materials are shared for a paid engagement.

PARTNERS

For referral and implementation partners

The design review organizes issues, required conditions, improvement candidates, and Verification Conditions; implementation and remediation remain with the customer or implementation partners. The formal inspection compares declared conditions with actual behavior and preserves the checked scope and evidence. If C³ participated in the design, that involvement is disclosed during inspection.

We do not decide whether a control condition is desirable, choose the customer's design policy, make the customer's final adoption decision, or decide the value judgment of whether authority should ultimately be delegated to AI.

Before AI goes to production or a customer, make the control explainable.

Turn the current design intoimplementation and QA conditions.

Check whether the implementedcontrol holds under changed conditions.

From “the AI works” to “we can explain the control before handing it over.”

Before handing an AI system with external effects to a customer

Check the control path itself, not only whether tests pass

Show the exact target and basis instead of saying only that the system is safe

External effects in finance, healthcare, public services, infrastructure, and similar domains

Share the materials. Clarify in writing.Receive two pages that implementation and QA can use.

How the review works

Conditions handed to implementation and QA

No runtime result is created

If you later need to know whether it actually stops at runtime, the Verification Conditions can become candidates for the formal inspection.

Example: external sending protected by Human Approval.

Does what was approved remain the same as what will actually be sent, all the way to the external effect?

After implementation, what should QA test and preserve as evidence?

A control working is not the same as deciding that the work may be delegated to AI.

What actually happened?

Does the evidence support delegating this work?

Leave the final execution authority separate.

For formal inspection, a control being present is not the same as giving decision-makers inspectable evidence.

From repeated observations to a bounded operating envelope.

From points to boundaries and an operating envelope.

From an inspection result to a re-checkable evidence route.

Freeze the target version

Freeze the protected control condition

Observe the normal path

Change one control-relevant condition

Compare under the same rule

Separate UNDEFINED and unobserved scope

Re-run the same case after remediation

Bind evidence to Verify ID and BYOV

Package the basis so the recipient can trace it.

Evidence Bundle

Verify ID

BYOV

A real before/after control record, with the claim boundary preserved.

Let the recipient verify the published record and evidence binding in the browser.

Check whether the published record changed

Check the evidence-to-result binding

More than a PDF: a re-checkable evidence package.

Target & control-condition matrix

Normal / changed-condition comparison record

Unobserved & UNDEFINED register

Evidence Bundle, Control Verification Record & Verify ID

Separate the work by what part of the AI project is being checked.

AI governance / certification support

Responsibility / operating design

Performance / task-success evaluation

External-effect control verification

Choose the work you need now.

Introductory price estimate

Control Condition Gap Check

One control for a delegation decision

Start free by organizingwhat should be checked.

For referral and implementation partners

Turn the current design into
implementation and QA conditions.

Check whether the implemented
control holds under changed conditions.

Share the materials. Clarify in writing.
Receive two pages that implementation and QA can use.

Start free by organizing
what should be checked.