C³社会デザインセンター

Search this site

Search pages, Verify ID...

日本語
日本語
← Japanese authorityTechnical record

AI AGENT CONTROL DESIGN REVIEW / CONTROL CONDITION GAP CHECK

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

Before customer handoff, production release, audit, or review, organize approval, authority, execution targets, retries, and other control conditions from the materials. When runtime evidence is needed, use the separate formal inspection to check the actual processing path.

See the Control Design ReviewView current Japanese page

HOW TRUST TRAVELS

See — control route & boundary

Keep observed scope, counterexamples, UNDEFINED and unobserved routes visibly separate.

Test — compare the actual path

Observe normal and changed-condition cases under the same rule, then re-run after remediation.

Re-check — Verify ID / BYOV

Bind the evidence and procedure so customers, counterparties and auditors can trace the same basis.

GOAL

A bounded evidence basis that another party can inspect before relying on the AI system.

DURING DEVELOPMENT / ASYNCHRONOUS

Turn the current design into
implementation and QA conditions.

AI Agent Control Design Review

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

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

  1. 01
    Freeze the scope

    Fix the target flow, consequential effects, control concerns, and document version in writing.

  2. 02
    Separate what the materials support

    Keep source facts, customer-confirmed policy, and review inference distinct. Unknowns stay unknown.

  3. 03
    Translate into implementation conditions

    Organize Required Control Properties, improvement candidates, QA and negative-test conditions, and evidence to collect.

  4. 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 (Japanese)

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.
CaseExpected behavior / evidence
Approved=A / Runtime=AAgreed normal path. Record the approved object, runtime object, decision result, and external effect.
Approved=A / Runtime=BDo not send externally based only on the existing approval. Record the object difference and decision result.
Retry after denialDo not execute the denied request as-is. Record approval reuse and retry state.
Retry after unknown resultTo 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.

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
Repeated observations that map a control operating envelopeIllustrative observations across authority, state, sequence, target, payload, retry and recovery conditions. Each point is one execution observation: green circles show control preserved, red crosses show counterexamples, triangles show inconclusive evidence, squares show undefined conditions, and dashed grey circles show unobserved conditions. The amber band is a conditional boundary inferred from multiple observations, not one execution result. The green outline is the supported operating envelope for this declared control and evidence class. This is not a safety certification or an actual customer assessment result.Supported envelopeCounterexamples clusterConditional boundaryUndefinedUnobservedAuthority: Control preserved (PRESERVED)Authority: Control preserved (PRESERVED)Authority: Control preserved (PRESERVED)Authority: Counterexample (COUNTEREXAMPLE_OBSERVED)Authority: Counterexample (COUNTEREXAMPLE_OBSERVED)State: Control preserved (PRESERVED)State: Control preserved (PRESERVED)State: Control preserved (PRESERVED)State: Control preserved (PRESERVED)State: Counterexample (COUNTEREXAMPLE_OBSERVED)Sequence: Control preserved (PRESERVED)Sequence: Control preserved (PRESERVED)Sequence: Control preserved (PRESERVED)Sequence: Counterexample (COUNTEREXAMPLE_OBSERVED)Sequence: Counterexample (COUNTEREXAMPLE_OBSERVED)Target: Control preserved (PRESERVED)Target: Control preserved (PRESERVED)Target: Counterexample (COUNTEREXAMPLE_OBSERVED)Target: Control preserved (PRESERVED)Target: Counterexample (COUNTEREXAMPLE_OBSERVED)Payload: Undefined (UNDEFINED)Payload: Undefined (UNDEFINED)Payload: Undefined (UNDEFINED)Retry / Recovery: Undefined (UNDEFINED)Retry / Recovery: Unobserved (UNOBSERVED)Retry / Recovery: Unobserved (UNOBSERVED)Retry / Recovery: Unobserved (UNOBSERVED)Control
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.

Baseline → Perturb → Replay → Observe → Compare → Next

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.

  1. 01

    Freeze the target version

    Fix the exact release or version under review so later changes cannot be mixed into the result.

  2. 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.

  3. 03

    Observe the normal path

    Run the satisfied condition through the actual processing path instead of inferring behavior from documentation alone.

  4. 04

    Change one control-relevant condition

    Introduce cases such as missing approval, expired authority, target mismatch, alternate route, retry, or recovery.

  5. 05

    Compare under the same rule

    Compare normal and changed-condition observations using the same declared control and comparator.

  6. 06

    Separate UNDEFINED and unobserved scope

    Do not convert missing evidence or untested routes into a PASS. Keep evidence insufficiency and unobserved scope distinct.

  7. 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.

  8. 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

Missing approval still passed

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. The published sample is limited to its fixed target version, declared control and witness set. It is not a system-wide safety claim.

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 current Verify ID sample

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 what should be checked. Use the review for implementation and QA conditions during development; use the formal inspection for runtime observation and evidence after implementation or before release.

Scope and deliverables
ItemControl Design ReviewControl Condition Gap Check
Standard scope1 flow; 1–2 control conditions1 release; 1–2 control conditions
Primary materialsDesign documents and explanationsTarget version, implementation, and inspection conditions
ProcessAsynchronous; normally up to 2 written clarification roundsExecution environment and evidence conditions are agreed
Runtime inspectionNot includedPerformed within the agreed scope
DeliverableTwo-page Review SheetControl Verification Record, evidence, and unobserved scope
Result meaningDesigns implementation and QA conditions from materialsRuntime observation result for the specified scope
Recipient-side re-checkNo BYOV or Verify ID in the standard reviewBYOV, Two-Rail, and Verify ID are handled according to delivery conditions

AI AGENT CONTROL DESIGN REVIEW / ASYNCHRONOUS

Individual quote; 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, scope, delivery timing, contracting party, price, and tax treatment are presented before material sharing and commencement.

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 (Japanese form) →

FORMAL INSPECTION / STANDARD

Control Condition Gap Check

JPY 900,000 (excl. tax)

Standard scope: one release, one to two control conditions, and five to ten business days. The final estimate is fixed after confirming the target and evidence conditions.

Includes target and condition freeze, runtime observation and comparison, Control Verification Record, re-verification materials, same-case post-remediation re-check, and one report meeting. Publication scope and Verify ID handling are agreed before commencement.

Discuss formal inspection (Japanese form) →
Formal inspection options
Additional control condition
From JPY 300,000 each (excl. tax)
Re-verification
JPY 250,000–350,000 (excl. tax)
Additional release / urgent engagement
Quoted separately
  1. 01Free pre-screening

    Use public information or a simple non-confidential overview to identify two or three important paths or candidate checks and decide whether review or runtime inspection is the appropriate next step.

  2. 02Confirm scope and quote

    Only if you proceed to a paid service, agree the materials, deliverable, timing, confidentiality, and engagement conditions.

  3. 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 / about 30 minutesOpen 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.

C3-WEB-CONTROL-ASSURANCE-EN-0.1 · v1.4.0 · active

This English representation does not mean quality assurance, system-wide safety assurance, third-party certification, conformity certification, or legal-compliance assurance. BYOV is a recipient-side re-verification mechanism using supplied verification materials.