Current pilot status#
This is an evidence-backed pilot, not a complete market audit. It contains 44 current fact observations across eight hosted-AI services. All 44 are provider-stated and zero are interface-observed. The comparison defines 17 dimensions, producing 136 possible service-by-dimension fields. Of those, 45 fields contain at least one current scoped record; 91 contain no current scoped record. These are inventory counts, not a completeness percentage or a claim that every scope was studied.
What this dataset records#
The basic unit is an atomic fact observation for one service, attribute, lifecycle stage, and applicable scope. Lifecycle stages are registration, continued use, payment, recovery, and deletion. An observation can record the provider’s stated requirement, how information is collected or checked, what it becomes linked to, its recipient, the region, plan, platform, or signup method to which it applies, its dates, and supporting evidence.
Starting July 26, 2026, the dataset is append-only. A policy change adds a new observation that explicitly supersedes the earlier one; a correction points to the observation it corrects. The initial 44 records form a legacy baseline, and we do not claim that they preserve a complete pre-boundary change history. Current comparison views are derived from the history; they do not replace it.
What it deliberately does not measure#
- Network anonymity. IP addresses, device fingerprinting, Tor/VPN treatment, and site analytics are a separate layer. A provider’s published network-data claim may be recorded under a separate label, but no cell establishes that a user is anonymous on the wire.
- Payment-intermediary exposure. A provider may state that it accepts a payment method; what an intermediary learns about the payer remains outside this dataset.
- Legal-process access. We can record the provider’s stated entity and jurisdiction. We do not turn that into a claim about what a court order or national-security process can reach.
- Backend enforcement. A policy can show what a provider published. It cannot demonstrate that the product or backend followed those words.
Where values come from#
Provider documents and controlled interface runs are parallel evidence roles, not ranks in one source hierarchy:
- Provider documents answer what a provider published in its policies, terms, or help material. A provider-stated fact is limited to the document’s wording and scope.
- Controlled interface runs answer what one defined product path did under recorded conditions such as date, region, plan, platform, and signup method. An interface-observed fact requires a retained run artifact whose digest is bound into the release manifest. It does not generalize beyond that run’s scope.
- Provider support, archived interface copies, and third-party reports can identify questions or corroborate a record, but they do not become a displayed value unless registered as qualifying evidence in the appropriate role.
Neither role silently overrides the other. Under the current P0 release path—the first implementation stage—a disagreement within comparable scope defers that release. Provider and interface evidence remain in separate streams for adjudication, but P0 does not publish a new conflicting state. Once P1 implements an append-only structured conflict relation, the two records can be published side by side without either overwriting the other. The current pilot is provider-only: it contains provider documents and zero controlled interface-run facts.
Collection and requirement are also kept separate. A privacy policy saying that a provider may collect a phone number does not establish that registration requires one. A provider-stated value is marked required only when the provider’s own material uses mandatory language. An interface-observed value is marked required only when the controlled run shows that its defined flow cannot proceed without it.
Controlled vocabulary and blank-zero rule#
Cells use a controlled vocabulary, including required · optional · conditional · available · collected-if-provided · may-collect · not-assessed · conflicting · region-dependent · plan-dependent · not-applicable.
- not-assessed means there is no current scoped record for the service and dimension shown.
- conflicting is reserved and unused in the current pilot. P0 rejects a new conflicting value and defers release when evidence disagrees within comparable scope. The value can be used after P1 implements an append-only structured conflict relation that can bind both records without overwriting either one.
- not-disclosed is reserved and unused in the current pilot. It would require a registered assessment of a defined document corpus; absence from the facts collected so far is not enough.
No cell is left blank. Silence in a document and absence from our research are different states, and neither is evidence that a requirement does not exist.
Evidence, dates, and integrity#
For provider documents:
- Archive-first. Provider pages are captured through web archives. The archived copy, not a fresh direct request from our infrastructure, is the cited record.
- Content check. A capture counts as current supporting evidence only when every quote used by its current facts remains present in the decoded archived body. The source capture and the latest supporting re-check are displayed separately.
- What sha256 does. The sha256 value fingerprints the decoded archived body. It lets us compare a retained copy and detect a change in bytes. It does not prove when those bytes existed.
- Where capture time comes from. The capture date comes from the Wayback record. Cryptographic timestamping is not yet implemented, so existing captures must not be described as carrying a capture-time cryptographic proof.
- Quotes and retention. Short sanitized excerpts remain in the source language. Relied-upon bodies are retained locally so a broken archive link does not erase the record.
For controlled interface runs, the evidence record must state the run conditions and result, retain the designated artifact under the repository-controlled interface-run path, and bind that artifact’s digest into the release manifest. Document archives and interface artifacts therefore have different integrity checks and remain separate evidence streams.
A date is labeled effective date only when the provider explicitly states that the policy or term takes effect then. A page’s “last updated” date is a document date, not an effective date. A capture date or observation date is never promoted silently into either one.
Claim source, integrity, enforcement, freshness, and conflict#
These are separate labels because they answer different questions:
- Claim source identifies whether a value is provider-stated or interface-observed.
- Evidence integrity reports the applicable document-archive or interface-artifact checks.
- Enforcement remains untested unless a separate controlled test supports it. Archived policy text never earns that label by itself.
- Fact checked-through follows every evidence stream cited by the fact to its current supporting successor, then uses the oldest latest-check date across those streams.
- Dataset checked-through is the oldest checked-through date among current facts. A partial refresh therefore cannot advance the date for the whole pilot.
- Conflict is a reserved display label. The current pilot publishes no such state; a comparable-scope disagreement instead defers the P0 release until P1 implements a structured conflict relation that can bind both records.
None of these labels is a composite confidence score.
Drift, corrections, and disputes#
A policy change is dated only as precisely as the evidence permits. A snapshot date is not silently promoted into an effective date. Editors do not make a disagreement disappear by choosing one source: P0 defers the release while the evidence remains in separate streams. After P1 implements the append-only structured conflict relation, both records can remain publicly visible side by side.
Errors in this dataset are corrected publicly. A provider or reader can write to editor@cypherpunkguide.com. We normally aim to acknowledge a dispute within 14 days and mark the affected value while it is reviewed. That is an operating target dependent on the monitored correction channel, not a guaranteed response time.
Update target and current limit#
The intended operating cadence is a monthly re-check of the source set followed by human adjudication of detected changes. That cadence is not yet an active SLA. It becomes a service commitment only after the capture, validation, diff, adjudication, and release pipeline completes two consecutive production-equivalent cycles with every gate GREEN and an observable heartbeat. Until then, updates and corrections are manual. The displayed checked-through dates remain the authoritative freshness boundaries.
Why there are no scores#
A composite privacy score would embed one threat model in every reader’s decision. A phone requirement, downstream routing, account linkage, and retention period are not interchangeable units. KYC Drift therefore publishes facts, dates, scopes, missing fields, and sources without turning them into a quality order or recommendation. Once P1 implements structured conflict relations, unresolved disagreements can also be published as parallel records; the current pilot publishes none.
Selection and licensing#
The current eight services form a convenience pilot selected because at least one content-verified primary provider source was available for each without creating an account. The set is neither exhaustive nor representative of the whole hosted-AI market. Metadata and annotations are licensed under CC BY 4.0; quoted provider text remains the provider’s. The machine-readable export is available at /en/data/kyc-drift/index.json.
Cite as: Cora Aegis, “KYC Drift: Hosted AI Identity & Data Practices — Pilot” (v2026.07), https://cypherpunkguide.com/en/data/kyc-drift/, CC BY 4.0