One evidence record, one clear route through the site.
A single evidence record helps prevent the same event being described differently on different pages. We then ask a simpler question: does it actually change our understanding?
To keep the site coherent as it grows, each consequential development has one main evidence record in Research. It is reflected elsewhere only where the evidence genuinely changes the picture.
ROUTINE PUBLISHING RULE
Every thesis change starts with evidence, not our conclusion
Once classified, evidence has to propagate through connected branches without becoming duplicated. That is why the thesis is treated as recursive rather than a linear stack.
All future research runs use the same seven-part record so a reader can separate observation from interpretation and see what would change our mind.
- What happened — event date and factual development.
- Evidence — primary source, source type and direct link; company claims remain labelled as claims.
- What changed in our understanding — the inference added to or removed from the previous thesis.
- Why it matters to the system — causal links across architecture layers and relationships.
- Thesis effect — strengthens, weakens, extends, complicates, contradicts or unchanged.
- What we still don’t know — explicit evidentiary boundary.
- Next confirm / falsify — observable evidence that would strengthen or invalidate the interpretation.
Company updates additionally separate architecture relevance → evidence of value capture → investment/valuation effect. Relationship changes must retain the evidence categories used in the relationship register and are never upgraded by inference alone.
New evidence can change earlier conclusions.
Because later evidence can change an earlier conclusion, every important development needs one clear source record. The next section explains that control.
Each evidence record produces a provisional interpretation. If later evidence changes that interpretation, the site shows the revision rather than quietly replacing the old view. We distinguish global AI trends from genuinely China-specific divergence, and technical architecture from economic proof.
Observe
Record primary evidence, company claims, standards, deployments and measurable operating data without forcing a narrative.
Classify
Separate observed fact, company claim, external analysis, inference and thesis-to-test.
Connect
Map the evidence across architecture layers and companies. Convergence is not automatically causality.
Update earlier conclusions
Ask whether new evidence changes earlier questions. Preserve the revision rather than silently overwriting it.
Falsify economically
Engineering scale is not enough. Test utilisation, portability, reliability, watts, capex and ultimately RMB per useful token.
Evidence is the substrate, not a competing navigation layer.
Good evidence discipline is still insufficient if the architecture has poor economics. The audit therefore ends by testing useful output, utilisation, pricing, capital and cash returns.
Evidence now surfaces primarily inside company and relationship drill-downs. The full ledger remains available for audit, but the main experience starts from the system or an interaction and lets the reader inspect why the edge exists, what it means and what remains unknown.
Six tests turn infrastructure claims into a system thesis.
The original research began as a sequence of numbered questions. Those questions remain useful internally, but the public thesis has matured into one continuous audit. Every consequential development is now tested against the same six gates.
Is the capability real?
Does the technology, infrastructure or service actually exist and operate, rather than merely being announced or targeted?
Can it connect?
Can compute, memory, networking, software, AIDC and power work together through usable interfaces rather than remain isolated assets?
Can workloads actually use it?
Compatibility, latency, software adaptation, data rules and geography can turn nominal capacity into unusable capacity.
Can it operate at system scale?
Can resources be discovered, provisioned or scheduled across clusters, sites, operators or regions rather than remaining separate islands?
Is there real paid demand?
Are customers deploying workloads and consuming the resulting capacity—not merely reserving it, testing it or discussing it?
Does it create economic value?
Follow the chain through utilisation, realised pricing, margins, capital intensity and cash returns. Technical integration is not the endpoint.
What the accumulated evidence currently says
What still has to be demonstrated?
These are not missing chapters in a numbered sequence. They are live tests that remain open as new evidence enters the system.
Abstraction is improving. The key test is whether heterogeneous resources become reliably schedulable for real workloads without excessive adaptation or complexity.
Compute-energy coordination and workload geography are real directions. Routine cross-region optimisation still needs evidence on latency, settlement, savings and repeatability.
Commercial inference, MaaS, agents and production workloads support the need for more infrastructure. The open test is how consistently that demand becomes paid utilisation.
Architecture may improve utilisation and reduce dependence on scarce resources, but system-level cost superiority is not established. The comparison remains total system cost per useful completed task and the cash returns generated from it.
22 SEPTEMBER 2026 · RESEARCH UPDATE
New research questions for Alibaba and KC
Resolve Alibaba’s capacity baseline and procurement mix; seek confirmation and delivery economics for the KC lease. Preserve the distinction between an announcement, a media report and analytical inference.