Definition · Translation review candidate
What is Verify ID
When an AI-made decision is questioned in an audit a year later, can you state which rule, which version, and under whose authority the AI was operating?
Rules are revised. Versions accumulate. The AI reads the latest version. But the decision happened in the past.
Verify ID is an anchor that fixes the context of the moment a decision was made, so it can still be traced from the future.
Verify ID is a verification identifier that fixes the entry point to a document's version, procedure, verification path, and history, so the reader can reach them without getting lost.
This is a definition page that explains the basic concept of Verify ID. What matters is not the name or label itself, but that it functions as the entry point connecting the public surface and the verification surface.
Position of this page
This is a public definition page that explains the basic concept of Verify ID.
What matters is not that it is a name or label, but that it functions as the entry point connecting the public surface and the verification surface.
Why it is needed
When public pages, specifications, history, verification kits, and revocation information are scattered, it becomes hard for users to tell which is current, which is past, and which is on hold or revoked.
Verify ID is needed to organize that dispersion at the entry point, so the current location and the history can be traced without getting lost.
With and without a Verify ID
❌ Without a Verify ID
March 2025: AI makes a credit decision on rule A v1.2 → ALLOW
September 2025: rule A is revised into rule B
February 2026: audit
→ "What was the basis of the March decision?"
→ rule A no longer exists
→ no answer
→ cannot withstand the audit
✅ With a Verify ID
The March 2025 decision
→ Verify ID: C3-VID-20250312-003 is issued (illustrative example)
The February 2026 audit
→ reference the Verify ID
→ rule A v1.2, the decision rationale, and the auth footprint all appear
→ the replacement history to rule B can also be traced
→ can be answered
What a Verify ID points to
Verify ID does not represent a single guarantee of truth.
It is an entry point for reaching the currently valid version, history, revocation state, and verification-kit references.
Relationship to the public surface
Verify ID is the anchor point that connects definitions, specifications, FAQs, update history, and verification paths across the public surface.
This makes it easier for both humans and AI to track which version they are looking at.
Relationship to history
Verify ID assumes that not only the current version but also the history, revocation, and superseded states can be traced.
What matters is not deleting old versions, but being able to trace the relationship between the current location and the history.
The path a Verify ID travels
Verify ID → Release Registry → Current / History / Kit → proof → Conformance
What you can do with a Verify ID
- See the current version — check the verification state and verdict of the current version a Verify ID points to
- See the history — follow the lineage, superseded, and revoked states of versions
- See the verification kit — open a kit that allows independent verification via BYOV
- See the verdict — check the aggregated surface of Verify ID → Kit → Verdict → History
- See the state in the public ledger — check publication state and revocation records in the Release Registry
What it means for organizations and implementers
For organizations and implementers, Verify ID is a practical entry point for organizing what to publish, which version to present, and where to connect the verification path.
It means moving the public surface closer to a traceable surface, rather than a mere explanatory page.
Microsoft's Agent Governance Toolkit controls "safety in the present moment." Verify ID controls "the ability to verify a past decision from the future." They address problems on different time axes.
Difference from conventional version control
| Aspect | Conventional control (e.g. Git) | Verify ID |
|---|---|---|
| What is managed | Diffs of code and documents | Decision context, revocation state, verification path |
| Time axis | Present-time management | Past decisions traceable from the future |
| Handling of AI | AI can only see the current version | Which version the AI decided on is fixed |
| Third-party verification | Requires repository permissions | Anyone can recompute via BYOV |
Verify ID naming system
| Form | Example | Purpose | Resolves at |
|---|---|---|---|
| C3-WEB-* | C3-WEB-ABOUT-0.1 | Page-specific identifier, assigned to each page of the site. | Referenced under /verify/* |
| C3-REF-* | C3-REF-2026-0007 | External reference identifier: a hash-bearing reference to an API or specification, for AI-agent preflight. | Resolved at registry.c3-anchor.jp |
C3-REF-* values are resolved at registry.c3-anchor.jp/api/verify/{id}. An AI agent is recommended to fetch the artifact_url before an API call, compute the sha256, and compare it with the content_hash. If they do not match, or the artifact cannot be fetched, treat it as HOLD.
Difference from adjacent concepts
| Concept | Role | What it helps with |
|---|---|---|
| Verify ID | The address of a target (a traceable anchor) | Trace, after the fact, which version of the rules the AI decided on |
| ECHO-VERIFY | Management of versions, revocation, and history | Detect and record when an old version keeps being referenced |
| GVD Bridge | External data connection | Make the connection between external data and internal specifications traceable |
| IX | Interchange conditions between systems | Publish the conditions required to interoperate with other systems |
| Two-Rail | The public/non-public boundary | Separately manage information that may be public and information that must stay private |
| proof / Verdict | The bundle of verification results | Preserve why a decision was made in a form a third party can recompute |
| BYOV | The idea that the recipient brings their own verification means | Verify independently with your own AI or CLI, rather than relying only on the issuer's explanation |
What it does not mean
Verify ID does not mean a guarantee of truth, a quality guarantee, an investment return, or an exclusive right.
Nor does it, on its own, complete a conformance judgment or the issuance of a certification.
Concrete resolution methods, revocation management, kit references, and history management are delegated to the relevant specification pages and institutional documents.
Related pages
- Higher concept — What is C³/definition/c3
- Public surface — Verified Web/spec/verified-web
- Lifecycle — ECHO-VERIFY/spec/echo-verify
- External data connection — GVD Bridge (Draft)/spec/gvd-bridge
- Boundary management — Two-Rail (applied)/definition/two-rail
- Public ledger — Release Registry/registry/release
- Verification-result bundle — proof (sample)/proof/example
- Independent verification — BYOV/definition/byov
Source documents for this page
C draft (version-history resolution and revocation-managed verification-identifier management system)
Primary source corpus • Verification identity management specification
Time layer
Status: Draft Concept
Version: 1.0
Last Updated (source): 2026-05-21
Source Doc Version: C draft
Document lineage ID: C3-DEF-VID-01
Source semantic revision: sr-0.1.0
Verify ID and Registry snapshot of this document
The authoritative Japanese page /definition/verify-id carries the Registry snapshot Verify ID C3-REF-2026-0001. A Registry snapshot Verify ID is locale- and artifact-specific: it is not shared between the Japanese page and this English page.
A Registry snapshot Verify ID is a reference to the target URL, the observation time, and the current state; it does not indicate content correctness, external assessment, mark grant, or operational readiness.
This English translation candidate does not carry a Registry snapshot Verify ID of its own, and none is issued for it. Its translation status (review required) is tracked separately from any Verify ID.