China is giving every AI use case a dossier

Officials discuss industrial policy for the 15th Five-Year Plan at a State Council Information Office press conference in Beijing on August 26, 2026. The briefing supplied the phrase ‘one industry, one map; one scenario, one dossier’ at the center of this field signal. Photograph by Li Xulun/Xinhua.[6]

An AI demonstration begins with what the supplier can show. A deployment begins with what the user can expose: a real workflow, a responsible owner, usable data, a place to test, a budget, and a definition of failure. China is starting to package that second set of ingredients as an object in its own right—the application scenario.

On August 26, the Ministry of Industry and Information Technology said it would explore a model of “one industry, one map; one scenario, one dossier” while cultivating application-service providers and lighter, cheaper solutions for manufacturers.[1] The phrase is compact, but it points to a larger change. Beijing is separating scenario demand, technical capability, and completed demonstrations into three lists. Guangzhou's Haizhu district is publishing scenario “orders,” assigning scene managers, and reporting how many matches become contracts. A national transport plan is dividing trials by maturity and linking successful validation to standards.[2][3][4]

Taken together, these are not evidence of a single national marketplace or a common dossier format. They are a field signal: model supply is abundant enough that the scarce work is moving to the buyer side. Someone has to turn an experienced operator's problem into a testable brief, make the operating environment available, match it to a supplier, and preserve enough evidence for a pilot to become a repeatable purchase.

A scenario is more than a use-case label

English-language technology writing often uses use case to mean a sentence such as “AI for rail inspection.” The Chinese policy term changjing can carry more physical and institutional weight: the actual track, inspection schedule, sensor history, maintenance crew, safety rule, data permission, and organization that owns the result.

Beijing's June call for three scenario lists makes that weight explicit. It defines a demand scenario as either a government department, state-owned enterprise, or large company seeking to buy or try a product against a core operational problem, or a technology company needing a real market environment in which to validate a product. Crucially, the scenario owner is expected to provide the resources required for joint innovation—space, funds, equipment, and data—rather than merely invite vendors to pitch.[2]

That requirement changes the unit of work. “Detect defects with AI” is an aspiration. “Detect these defects on this line, from these cameras, under this cycle time, with these escalation rules” is a scenario a supplier can price and test. The owner must reveal the constraint that makes the problem difficult, while the vendor must show that its capability survives contact with that constraint.

This is also why a scenario dossier can be commercially important even when it contains no novel model. It can convert tacit operating knowledge into a portable demand specification. A factory veteran may know which reflection looks like a crack, when a line can be paused, and which false alarm causes the costly reinspection. Unless those facts enter the brief, the most impressive vision model is being evaluated on the wrong job.

Beijing's three lists separate promise from proof

The architecture of Beijing's call is unusually clear. A demand list records problems and resource-bearing owners. A capability list records technical solutions and test resources, including roads, waterways, gardens, datasets, computing capacity, and buildings. A demonstration-project list is reserved for work that has been completed or has made substantial progress and can support replication.[2]

That separation prevents three different claims from collapsing into one. A published demand proves that an organization is willing to expose a problem. A capability entry proves that a supplier or test site is available. A demonstration entry is intended to show that something has actually been built and exercised. None alone establishes sustained operating value.

It also creates a possible learning loop. A demand can recruit several competing approaches. A real environment can reveal which one works and where it fails. A completed project can then supply the evidence and operating pattern for another owner. In the strongest version, the dossier travels through those stages and accumulates decisions: why a metric was chosen, what data were withheld, when a human overrode the system, what changed after deployment, and which parts are transferable.

The public notice does not yet establish that such a common evidence record exists. It asks for reasonable indicators, clear expected results, real-world validation, and replicability, but those are selection requirements rather than a published national reporting schema.[2] “One scenario, one dossier” will matter only if the dossier becomes more than a directory card.

Haizhu has exposed a conversion funnel

Guangzhou's Haizhu district offers an early look at what happens after a scenario is listed. Its AI scenario platform opened on May 9 with sections for opportunities, capabilities, and investment. By August 18, the district said it had posted 159 scenario orders, collected 353 capability entries, arranged more than 400 matching contacts, and associated the orders with more than RMB 200 million in intended cooperation. It also reported eight signed orders worth RMB 8.269 million.[3]

Those figures are valuable precisely because they are not one triumphant total. Eight signed orders are roughly 5 percent of 159 posted orders. The signed value is less than 4.2 percent of the stated intention value. Neither ratio is a valid cohort conversion rate: the orders were posted at different times, “intended cooperation” is not the same accounting category as signed value, and some orders may still be moving through the pipeline. But the gap makes the handoff visible. Publishing demand and producing a contract are separate achievements.

The Guangzhou Metro round shows the intermediate work. Haizhu said 19 orders posted in early July attracted more than 100 proposed technical plans; scene managers screened them to 18 for an in-person meeting one month later.[3] The manager's role is telling. The bottleneck is not only discovery—putting buyers and vendors on one website—but translation and triage: deciding whether a response addresses the actual operating problem, whether the owner can support a trial, and whether the participants are ready to negotiate a project rather than stage a demo.

The district also connected its algorithm competition to the scenario platform, inviting teams to inspect orders and pursue commercial work after competition validation. That can shorten the distance between benchmark talent and a buyer. It can also expose the difference between winning a bounded contest and integrating with a metro, hospital, factory, or service desk. A scene manager who preserves that difference is more valuable than one who merely accelerates introductions.

Transport policy adds a maturity ladder

The June national action plan for “AI + transport” supplies another missing dimension: not every scenario should ask for the same kind of proof. Its stated path runs from technical breakthrough, through scenario validation and industrial application, to system upgrade.[4]

The plan divides trials into three categories. Application-promotion projects are for mature technology and clear demand. Innovation-demonstration projects integrate mature components in high-value settings and are generally led by the scenario owner with AI companies and research organizations. Breakthrough projects use the real setting to develop and test core algorithms or intelligent equipment and are generally led by the technology organization with an industry user.[4]

This distinction sounds administrative, but it fixes a common evaluation error. A research-stage system should not be sold on the adoption metrics of a finished product; a mature product should not be excused from operating outcomes because its model is novel. The leader, evidence, risk allowance, and exit condition should change with the maturity lane.

The same plan says validated products, technologies, and scenarios can feed pre-standardization work and, eventually, national or industry standards. It also calls for employment-impact monitoring around autonomous driving and delivery.[4] In other words, successful validation is not only a score. It can change purchasing rules, technical interfaces, work organization, and the acceptable pace of rollout. A credible dossier must retain those consequences alongside accuracy and latency.

The dossier must remember what the launch stage forgets

A useful scenario record would begin before vendor selection. It would name the owner and the existing baseline; inventory the available data, equipment, integration points, people, and budget; identify the population and conditions in which the system will be tested; and state the costs of false positives, false negatives, abstention, delay, and human review.

It would also continue after the pilot. The record should say which model and configuration ran, who could override it, what evidence an output returned, how performance drift was monitored, what the supplier was allowed to retain, and what would trigger expansion, retraining, suspension, or exit. These fields are an analytical extension of the Chinese notices, not a format the government has already published. They align with mature public-sector AI procurement guidance elsewhere, which emphasizes data assessment before purchase, multidisciplinary evaluation, explicit acceptable performance, lifecycle testing, knowledge transfer, and protection against vendor lock-in.[7]

Without that continuity, scenario programs can produce a gallery of winners. With it, they can produce comparable operating evidence. The distinction is especially important when public data or public services are involved. On August 25, China's National Data Administration said the fifth batch of its public-data demonstration program selected 50 scenarios across 23 directions from 703 applications.[5] That shows a large intake and a selective administrative funnel; because the program spans far more than AI, it does not measure AI adoption. Nor does selection establish that a project improved a service. The next evidentiary step is a result that can be inspected after the ceremony.

What would prove the signal

Three artifacts would show that the dossier idea is becoming infrastructure rather than vocabulary.

The first is a real, public per-scenario record with a problem owner, baseline, resource commitment, maturity lane, evaluation conditions, risk boundary, and status history. The second is cohort reporting: how many demands received qualified responses, entered paid pilots, reached acceptance, remained in use, expanded to a second site, or stopped—and why. The third is a post-pilot evidence package that can support procurement or standards without erasing local conditions and failures.

The absence of those artifacts would be a falsifier for the stronger thesis. If lists multiply while contracts, operating metrics, and repeat deployments remain opaque, “scenario cultivation” is mainly a lead-generation and showcase system. If the records become comparable and travel with projects, China will have built something more consequential: a buyer-side compiler that turns industrial experience into tasks the AI market can actually attempt.

The model race does not disappear in that system. It becomes one layer. A model still has to recognize the defect, plan the route, or retrieve the rule. But the dossier determines whether the test resembles the job, whether the buyer supplied the conditions needed to learn, and whether a success can survive outside its first room. That is the handoff that turns an AI capability into an operating market—and it is now becoming visible enough to measure.

cronfeed.work