This is the multi-page printable view of this section. .
Evidence Archive
The archive supports a bounded claim: concentration and lock-in risk already have an observable record. It is not a prediction that every centralized service will fail, and it is not a feed of every technology incident.
Three collections
- Outages — incident chronology with source, impact, uncertainty, and follow-up.
- Lock-in — mechanisms, affected layer, exit symptom, and verification test.
- Claims — a public statement placed beside observable evidence and status.
Evidence discipline
Every record separates occurrence date from publication date, observed fact from inference, and primary source from commentary. Corrections append a revision note. Disputed or unknown facts remain visible instead of being forced into a confident narrative.
The existing Chinese essay archive at vonng.com/cloud is a seed source, not the database itself. Records are extracted, normalized, linked back to the original, and given an English abstract before publication here.
1 - Outage chronology
Collection skeleton ready. Incident records have not yet been imported.
Record contract
Each incident stores event start and end, detection time, provider and service, regions, customer-visible impact, dependency chain, status-page timeline, provider report, SLA remedy, corrective action, primary and secondary sources, confidence, dispute state, and revision history.
Inclusion rule
Include an incident when it materially affects service availability, integrity, confidentiality, customer control, or the ability to recover—and when at least one checkable source exists. Popularity alone is not an inclusion rule.
What this collection should answer
- What failed, for whom, and for how long?
- Which dependency expanded the blast radius?
- What did the provider know and communicate at each point?
- What remedy and corrective action followed?
- Which facts are still unknown or disputed?
2 - Lock-in catalog
Taxonomy ready; named examples require evidence review before publication.
Mechanism classes
| Class | Typical symptom | Exit test |
|---|---|---|
| Data gravity | Transfer time or charge dominates the move | Export full data and price elapsed transfer |
| Proprietary semantics | A compatible API loses required behavior | Replay the critical operation set elsewhere |
| Identity coupling | Accounts, policies, or keys cannot be reconstructed | Rebuild authorization from exported declarations |
| Control-plane dependence | Operations require provider-only orchestration | Execute recovery without the original control plane |
| Commitment lock | Unused spend or credits become stranded | Price exit at multiple dates |
| Organizational dependency | Skills and procedures exist only inside the provider path | Run an independent recovery drill |
Records name the mechanism before the vendor. The same provider can reduce one kind of lock-in while increasing another, and the same service can behave differently by feature or plan.
3 - Claims ledger
Record schema ready. No named claim has been adjudicated in v0.1.
Record shape
| Field | Purpose |
|---|---|
| Exact claim | Quote or faithful bounded paraphrase, with date and URL |
| Claim type | Price, availability, portability, security, performance, or market statement |
| Applicability | Product, region, plan, workload, and time window |
| Test | Observation or calculation that could confirm or falsify it |
| Evidence | Primary data first, then reproducible or independent sources |
| Status | Supported, mixed, contradicted, unresolved, stale, or withdrawn |
| Response | Provider correction, context, or dispute, linked in full |
This collection is intentionally symmetrical: a provider claim that survives a hard test deserves the same visibility as one that fails. The target is accountability, not a permanent adversarial posture.