UCE Verification & Conformance Status

Live Reference-Implementation Example

View a Live UCE Verification Example

This exact record is a live hosted convenience interface from the CbyUCE reference implementation. It currently displays UCE Record Information; Platform-Recorded Upload Date; Manifest Arweave Block Date; exact UTC technical details; manifest hash; platform public-key reference; raw-manifest access; block-explorer access; and JSON verification data.

The inspected example does not currently display a file Arweave block date or a derived Complete UCE Record Date, so this page does not claim that it demonstrates those fields.

• View the example's raw Evidence Manifest on Arweave
• View the example's manifest transaction in a block explorer
• View the example's JSON verification data

Live Lens and WebMCP Capabilities

UCE Evidence Lens provides browser-based verification for supported public evidence profiles. It can recompute covered manifest hashes and check supported platform signatures instead of relying only on a hosted verification label. Each result distinguishes completed checks, publisher statements, unsupported checks, and incomplete retrieval.

• Private local-file comparison: SHA-256 hashing takes place in the browser. The selected file's contents are not uploaded or exposed to agent tools.
• Public demonstration artifacts: an original demonstration file and its manifest JSON are available for inspection and comparison.
• Signing-key provenance: supported ES256 checks identify the reviewed public key, its thumbprint, review date, and public verification material. This is useful provenance, not a complete historical key and revocation registry.
• Arweave chronology: Lens checks available metadata for the manifest and explicit file-storage reference. Direct Layer 1 membership can be checked; bundled-item parent relationships remain gateway-reported. Missing or retryable results are not counted as verified.
• Dated inspection reports: unsigned JSON and browser-print reports preserve completed checks and limitations. They are inspection snapshots, not UCE Certificates or independent audit reports.
• Eight read-only WebMCP tools: compatible browser agents can load public records, obtain summaries, run verification checks, inspect chronology and rights declarations, list assertions, compare an already selected local file's digest, and request a dated report. Agent tools cannot select or receive the local file's contents.

Current Record-Profile Coverage

• Standard 1.0.0: reviewed ES256 signature checks and, on an exact match, manifest-hash recomputation for the narrow reviewed public projection. This projection includes file byte count and digest, Merkle root, identity assurance and its exact timestamp, attestations, schema/version, and optional source. It excludes work/title, rights policy, AI disclosures, filenames, and other unlisted fields. Older non-matches remain unresolved where original preimage timestamps may be missing.
• Extended 1.1.0: independent manifest-hash recomputation and critical-profile ES256 signature checks for the reviewed profile.
• Hybrid 2.0.0 and 2.1.0: readable and displayable; hybrid signatures and manifest-hash recomputation are not independently verified in the released runtime. Qualification remains pending for real publisher-issued records.

A successful hash check covers only the profile's stated fields. It does not protect every displayed field or establish the truth of recorded assertions. Readable format support does not mean complete cryptographic verification.

Lens is currently delivered as a static browser application. Core hash and supported signature checks run locally; live record retrieval and network chronology require connectivity. A standalone offline distribution is not currently claimed.

Browser recomputation is a meaningful part of independent verification. WebMCP exposes these capabilities to compatible agents; tool discovery or marketplace availability does not establish standards-body approval, an independent implementation, or an external security assessment.

What Technical Verification Determines

A result determines only the checks actually performed with the inputs available at that time. A successful check may determine that:

• a presented file's exact bytes produce the content hash recorded in the manifest;
• the profile-defined manifest fields produce the recorded manifest hash under the supported canonicalization and preimage rules;
• the platform signature validates for the referenced public key and signed payload;
• checked storage references resolve to the data reported by the verifier;
• recorded transaction references and available network-reported dates are internally consistent; and
• specified claimant, work, rights, and creation-date statements are present in the recorded package.

A valid platform signature authenticates the platform-signed payload under the checked public key. For signatures over a manifest hash, the separate recomputation result determines whether the covered manifest fields reproduce that hash. The signature does not, by itself, establish that every displayed field is protected, that the claimant personally signed, or that the claimant's statements are true.

What Technical Verification Does Not Determine

Technical verification does not independently determine legal ownership, authorship, identity truth, originality, copyright eligibility, non-infringement, priority over every other work or claimant, license validity, enforceability of an AI opt-out declaration, admissibility, evidentiary weight, or a legal outcome. Creator, claimant, ownership, creation-date, and rights statements remain recorded assertions unless a separately documented attestation process verifies the relevant fact.

Chronology Labels

• Platform-Recorded Upload Date: the date CbyUCE recorded receiving the upload. The value is included in the signed manifest later submitted to Arweave; it is not Arweave-confirmed.
• File and Manifest Arweave Block Dates: network-reported dates for two separate transactions, when available.
• Complete UCE Record Date: when both block dates are available, the later date may be displayed to indicate when both components had network-reported block dates.

The practical plain-language claim is proof of upload date. Exact UTC values remain available for technical examination. UCE and CbyUCE are not RFC 3161 timestamp authorities, qualified electronic timestamp providers, eIDAS trust services, governmental authorities, or authoritative time sources.

Artifact and Review Status

Current position: UCE provides live browser-based verification and agent-accessible inspection for supported profiles. These capabilities address a meaningful part of independent verification. A complete, versioned provider-independent release, documented outside reproduction, and an independent security assessment remain assurance milestones.

Full provider-independent reproducibility would require an outside reviewer to obtain the original test bytes, manifest, specification, verifier, and authenticated public verification keys; reproduce supported hash and signature checks without UCE services; and separately check the file and manifest Arweave references through another access route. Offline cryptographic results and live network results must remain distinct.

UCE remains designed for independent verification, with supported browser checks available today. Complete continuity and external assurance are not yet claimed. None of these milestones establishes legal ownership, institutional endorsement, or a legal outcome.

Abuse, Competing Claims, Corrections, and Key Compromise

UCE does not adjudicate disputes, validate the truth of authorship claims, prevent infringement, enforce rights declarations, remove immutable Arweave records, or guarantee that no earlier creator or work exists.

The public process for suspected unauthorized uploads, impersonation, competing claims, correction requests, legal requests, or possible key compromise is documented in the UCE and CbyUCE Case-Handling Policy. Historical Arweave records cannot be silently altered or removed; where technically and legally appropriate, a later notice or superseding record may provide additional context without rewriting the historical record.