Decide how far AI can be trusted to act,
based on what has actually been verified.
Use human-defined delegation and stop conditions to inspect the actual path, preserving control-holds, counterexamples, UNDEFINED results, and unobserved scope. A working control is not treated as the same thing as a delegation decision or runtime permission.
If you want to organize design and QA conditions from documents, use the AI Agent Control Design Review; it does not include runtime inspection.
This is not a complete guarantee or third-party certification. It shows what was verified within a fixed target version, decision conditions, and test cases.
Before AI sends, writes, or executes, decide how far it may act.
When an AI Agent or automation sends email, updates data, calls an external API, or executes tools, people should define the delegation and stop conditions, then verify that the implementation preserves that boundary.
This is where you check not only AI performance, but whether approval, authority, and external-effect controls are implemented as described.
What is actually being observed?
Instead of treating one PASS as enough, change relevant conditions and replay the path to map where control is preserved and where counterexamples, undefined conditions, or unobserved scope remain.
This is an illustrative diagram. It is not a safety certification or an assessment result for a specific customer system.
From points to boundaries and an operating envelope.
- Control preserved
- Counterexample
- Evidence inconclusive
- Undefined
- Unobserved
AI Agent Control Design Review
From design documents, specifications, and QA policy, organize control issues, required conditions, improvement candidates, and what should be verified after implementation.
Control Condition Gap Check
Freeze the target version and delegation/stop conditions, then vary relevant conditions to separate control-holds, counterexamples, UNDEFINED results, and unobserved scope. Evidence supporting delegation decisions is recorded separately from actual runtime permission.
Turn identified control conditions into a pre-execution mechanism.
Conditions identified through review or Gap Check can, when needed, feed into Control API design. Stopping, recording reasons, mapping the usable range, and re-verifying later are treated as separate roles.
Public pages include evaluation and PoC-stage implementations. They do not mean a production API, safety guarantee, or certification.
Do not turn review or inspection conclusions into a black box.
Why did it stop? What evidence supported the decision? How can it be re-verified later? The design and verification methods behind those answers are also published.
Stop before it goes outside.
A design protocol for checking external effects such as publication, sending, deployment, and operation requests before execution, using structure, evidence, and approval conditions.
Make it possible for someone else to check later.
Bundle evidence, specifications, execution records, and verification procedures so the recipient can reproduce the check in their own environment. The goal is to replace “trust us” with “this is the scope you can independently re-check.”
Verify public claims while keeping protected material private.
Separate evidence that may be published from records that must remain protected, such as personal data, contracts, and internal logs. This separation discipline preserves what can be checked from the public rail without exposing the private rail.
We describe the mechanism that lets a third party recompute and compare hashes on the public surface as a digital counterpart of a cross-page seal.
This does not mean third-party certification or completed third-party verification. The RF pledge is a draft and is not in force. The Two-Rail paper is available on SSRN as a working paper.
Working demonstrations are available when you need to inspect them.
The top page prioritizes the service distinction; comparison and technical demos are collected on separate pages.
View Gap Check demonstrations
Entry point for seeing how control conditions are frozen and how runtime observations and evidence are preserved.
View the pre-execution control API (Japanese)
Public technical surface that separates decision, diagnosis, range mapping, and re-verification.
View other technical demos (Japanese)
Individual comparison, gate, and PoC demos are available from the demo index.
Support and public infrastructure
Support concept
Japanese source page for the support concept behind the public knowledge surface, verification paths, and conformance infrastructure.
Meaning and role
Japanese source page explaining the meaning and role of support.
Public registry
Japanese source page for the public registry of support facts.
Give people and AI the same primary source
Definitions, specifications, update records, and verification paths are maintained in machine-readable form. llms.txt, MIRP, and the sitemap are entry points.