Verified Web

Verified Web is a public-surface design that lets AI-era public information be followed while keeping the reference surface and the verification surface distinct. It connects human-readable pages, machine-readable APIs, history, observation points, and record boundaries, making it easier to track which information is being referenced and in which state.

In the current MVP, the Verify ID Registry functions as the canonical registry surface for C3-issued Verify IDs. Each record holds a Human URL, API URL, target URL, observation point, Snapshot Hash, Evidence Status, and Claim Boundary.

Verify ID Registry is the canonical registry surface for C3-issued Verify IDs.

The Verify ID Registry is a registry surface that indicates the current state of Verify IDs that C3 has issued for target pages or external targets. Verified Web places reference paths on the public page side so that both humans and machines can reach that registry surface without confusion.

For example, VID-WEB-2026-0001 is the first external-target record, and C3-REF-2026-0001 is the first C3 self-issued reference record.

The Human URL is the URL for a person to inspect a record; the API URL is the URL for a machine to fetch the same record. Human URL and API URL expose the same registry record for people and machines.

An external-target record observes and records a target URL or public target outside C3. A self-issued record is one in which C3 itself records the observation/reference state of a public or reference page that C3 manages.

• VID-WEB-2026-0001: first external target record.
• C3-REF-2026-0001: first self-issued C3 reference record.
• C3-REF-2026-0002 through C3-REF-2026-0004 extend across Signal Report, the Verified Web specification, and the ITS API as self-issued references.

Snapshot hash records an observed or source-derived snapshot. It records the hash of an observed or source-derived snapshot; it does not embed a content_hash into the page body.

Evidence may remain private. External review status may be not_performed. Evidence Status indicates the state of publicly available evidence, but not all supporting materials are necessarily published.

The Claim Boundary makes explicit the scope a Verify ID record does and does not mean. This does not validate target content accuracy.

This does not indicate outside assessment, endorsement, mark grant, compliance result, operational readiness, investment return, priority rights, exclusive rights, or specification authority.

Going forward we will expand the target pages, automate the snapshot update procedure, present history diffs more legibly, and distinguish external-target records from self-issued records in the display. This does not newly assert any external assessment or mark grant.

• Definition pages
• Specification pages
• FAQ
• Update history
• Verification paths
• Version management
• Time management

These are separated as surfaces with distinct roles, yet published so they remain mutually reachable.

In Verified Web, it is important to be able to trace the current, history, revoked, and superseded states.

Rather than simply deleting old versions, it assumes you can see which is the current location, which is past, and which is on hold.

Verified Web is both an explanatory surface for humans and a public surface structured so that AI and search can reference it easily.

What matters is not mere summarizability, but that versions, procedures, and verification paths are easy to trace.

For organizations and implementers, Verified Web is a foundation for organizing what to publish, which version to present, where to place the verification path, and how to keep the update history.

It means moving the public surface closer to a traceable public surface, rather than a mere PR page.

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

Verified Web is a public-surface design for operating, as a whole, the safe publication of statements, the structuring of definitions and specifications, the publication of verification paths, version and time management, and the estimation-measurement of external responses. Its aim is not merely to add pages, but to arrange — in a form easy for both humans and AI to follow — which version is currently valid, where the update history is, and where verification can begin.

C³ Anchor does not merely explain Verified Web; this site itself applies the approach. It publishes update history, verification examples, verification kits, version/history surfaces, the various registries, Signal Report, and machine-readable resources in a mutually traceable form, aiming to keep the public surface itself traceable.

This is positioned not as a self-declaration of "Verified Web conformance," but as an implementation example of public-surface operation aligned with the approach.

• Update history/updates
• Verification example — current/verify/current/example
• Verification example — history/verify/history/example
• Verification kit example/kit/example
• Release Registry/registry/release
• Conformance Registry/registry/conformance
• Supporter Registry/registry/supporter
• Signal Report/signal-report

Signal Report is the measurement surface of Verified Web. It does not obtain AI internal logs; from external output responses it estimates which version is being referenced and how much of the old version remains. The indicators shown there are therefore not proof of internal behavior, but estimates from external responses.

Verified Web is not complete with a human-facing explanatory surface alone. C³ Anchor aims for a state where, through machine-readable entry points, both humans and AI can reach the same authoritative public source. These paths are not auxiliaries to the public surface; they are entry points to the authoritative public source.

• llms.txt
• robots.txt
• sitemap.xml
• mirp/index.json

• Site map
• Signal Report
• Update history
• Verification example — current
• Verification example — history
• Verification kit example
• Release Registry
• Conformance Registry
• Supporter Registry
• Verify ID definition
• Two-Rail implementation specification
• ECHO-VERIFY specification