China’s 6G Research: How to Read the Pilot, the Standard, and the Proof Gap

AI-generated editorial illustration by China Made & Tech. It depicts no real network, operator, device, coverage area, technical result, or commercial deployment.

By China Made & Tech Team. Independent English field guide to China’s niche hardware brands, hidden champions, founders, factory towns, and supplier clusters.

China’s 6G research is already a useful subject, but not for the reason suggested by a typical technology-race headline. The useful question is not who has “won” a future network. It is what a dated record actually allows a reader to say today.

China’s Ministry of Industry and Information Technology (MIIT) issued a provincial 6G pilot-action notice in June 2026. Its stated scope includes technical research, standardisation, industrial ecology, and application scenarios. That is meaningful public evidence of a coordinated programme. It is not an announcement of a commercial 6G service, a spectrum allocation, a network performance result, a supplier qualification, or a factory deployment outcome. The distinction is explicit in the kind of record being read: the MIIT notice sets a programme and its objectives rather than reporting a live service.

The international process is also still a sequence. The International Telecommunication Union (ITU) records draft IMT-2030 technical-performance requirements completed in February 2026 and draft evaluation guidance completed in June, with a stated December 2026 Study Group 5 approval step. Those milestones make the subject more concrete, not less. But draft requirements and evaluation guidance are not a commercial product test. They are evidence about how a future system could be assessed. The ITU-R IMT-2030 status page is therefore a standards-process record, not a readiness certificate.

This is a guide to reading that gap. It is designed for a supplier wondering whether a China 6G reference belongs in a roadmap, an industrial user trying to distinguish a pilot invitation from a deployable service, and an analyst trying to avoid turning a policy date into a market date. The guide does not rank Chinese companies, predict spectrum, estimate a launch date, or recommend a network purchase. It supplies a better handoff: match the claim to the record that can support it.

The short version is simple:

The discipline is familiar from the evidence problem in China’s 5G network. A national infrastructure statistic, an operator disclosure, a supplier claim, and a factory result are connected but not interchangeable. With 6G, the same discipline matters earlier in the cycle because the temptation to fill missing facts with a future narrative is stronger.

The first correction: research is not a softer word for deployment

“China 6G research” can describe several activities at once. It can describe government programme design, university or laboratory work, corporate research, a standards contribution, a proposed use case, a field trial, a component prototype, or a commercial offer. Those activities may be related, but they answer different questions.

Research asks whether a concept can be explored, structured, measured, or developed. Deployment asks whether a defined service or system has been installed and operated in a stated environment. Commercial readiness asks an even narrower question: whether an identified buyer can obtain, integrate, support, and accept a defined product or service under terms that meet the buyer’s need. A policy pilot can be strong evidence of the first question while providing no answer to the last two.

This is not a semantic complaint. It changes the next action. If a company treats “research” as “deployment,” it may put an assumed connectivity capability into an equipment roadmap. If an analyst treats a standards-stage milestone as a market date, a forecast may silently replace a published fact. If a factory treats an application scenario as an outcome, it may skip the workload, integration, fallback, and acceptance evidence that its operations team needs.

The proper reading is neither dismissive nor promotional. A programme can matter precisely because it coordinates people, questions, local directions, and eventual evidence collection. It can lower the cost of learning and create a reason for organisations to organise their own research. None of that requires a reader to pretend that a product has already crossed the next gate.

The useful verb is “indicates,” not “proves.” The MIIT action indicates that 6G is being organised as a provincial research-and-application programme. It does not prove that an unnamed network is operating. An ITU requirement indicates that an evaluation framework is being formalised. It does not prove that an implementation has passed it. A company announcement may indicate an intent or prototype. It does not prove that a buyer can reproduce an outcome.

This guide uses four evidence files to keep those verbs honest:

1. The programme file records what a public authority has initiated and how it has bounded the activity.
2. The standards file records what a formal technical process says is draft, approved, or under study.
3. The named-system file records an identified component, device, operator service, or integration, with a configuration and a responsible party.
4. The acceptance file records a defined workload in a real operating context, including test conditions, exceptions, and a decision to accept or reject it.

The first two are already possible to discuss from current public records. The last two are what a reader needs before making a concrete technology, supplier, or factory assertion. The four-file model is an editorial evidence framework, not engineering or legal advice. Its purpose is to make the missing file visible before the claim becomes too large.

What MIIT actually put on the table in 2026

MIIT’s June 2026 notice starts a coordinated provincial pilot action. Its stated tasks span technical research, standardisation, industrial ecology, and application scenarios. That wording matters. It makes the action broader than a single laboratory project and narrower than a commercial-network announcement. The document describes an organised pathway for work; it does not identify a universally available service.

The notice also asks a participating region to select one to three distinctive directions. An approved implementation period is generally three years. These are programme-design details, not market measures. A region choosing one, two, or three directions does not reveal the number of users, commercial customers, connected devices, deployed radios, or participating manufacturers. A three-year term does not make a promise that a buyer will receive a service after three years. It says that the approved programme has a stated working horizon. The exact terms appear in the MIIT action notice.

That regional structure is easy to misread in two opposite ways. The first error is to treat it as a national rollout map. It is not. The notice establishes a selection framework, so no reader should replace an application process with a list of selected regions, projects, products, or operating networks unless a later official decision actually names them. The second error is to dismiss the programme because it does not announce a service. That misses the point of a pilot. The work is intended to organise research, paths to standards, industrial participation, and scenarios where later evidence may emerge.

For a supplier, the programme file has a precise use. It may justify asking whether a prospective partner, university, carrier, integrator, or regional authority is participating in a named direction. It may justify creating a research-facing product brief that separates current shipping capabilities from exploratory capabilities. It does not justify presenting an unqualified “6G-ready” label to a buyer. That label would need a product scope, interface status, supported environment, evidence of interoperability, and a clear statement of what is actually available.

For an industrial user, the programme file has a different use. It may identify a reason to investigate whether a problem is a candidate research scenario. But the plant’s first question should remain operational: what workflow would be changed, what data or control path is involved, what happens during loss of connectivity, who owns the integration, and what outcome would count as acceptance? A programme reference cannot answer those questions in advance.

For an analyst, the programme file is a time-stamped governance record. It can support a sentence such as “China initiated a coordinated provincial 6G pilot action in June 2026 with the stated research, standardisation, ecology, and scenario scope.” It cannot support “China has deployed 6G” or “a given company will capture a share of a future 6G market.” The first sentence identifies the issuer, date, and object. The latter sentences add claims the notice does not contain.

This is the practical difference between a signal and a verdict. A signal tells a reader which inquiry may be worth opening. A verdict tells the reader that the inquiry has been resolved. The MIIT notice is a strong signal. It is not the verdict for any named product, carrier, component, factory, or region.

One to three directions is a selection rule, not an industry ranking

The “one to three directions” language deserves its own pause because it is the kind of compact number that turns quickly into a headline. It describes how a participating region is asked to focus the programme. It does not identify which directions will win commercially, which location has the most capability, or which research team has produced the best technical result.

It is useful to separate three things that could otherwise get collapsed:

• A direction is a programme focus. It gives a local effort a reason to concentrate rather than attempting every possible topic.
• A project is a named body of work, with participants, a budget or resources, a timetable, and a defined output. The current notice does not make every possible project public.
• A deployment is an operating system or service at a named location. It requires a configuration, a customer or user context, operational responsibility, and evidence of what happened.

Readers should not infer the second or third object from the first. If a regional announcement later names a project, preserve the project’s exact scope and date. If a carrier later names a network or service, preserve its technical and commercial boundary. If a factory later presents a result, ask for the workload and acceptance record. Each new document can add a layer; it cannot retroactively turn the programme notice itself into a deployment report.

The same caution protects legitimate comparative work. There may eventually be a reason to compare particular pilots, component lines, interfaces, operators, or industrial cases. Such comparison begins only after the objects are named and their records are sufficiently alike to compare. It does not begin with the fact that each belongs somewhere in a national programme.

Editorial evidence map. A public pilot notice is a programme record, not a service, coverage, supplier, or procurement conclusion.

Read 2029 as a programme objective, not a launch calendar

The most tempting number in the MIIT notice is 2029. The notice sets an objective to form technical solutions, application scenarios, and terminal products that support later commercial implementation by that point. The important wording is “support.” It marks the target as a programme objective that is intended to enable later commercial work; it is not a date at which the document promises a national service, a particular device, or a specific buyer outcome. The official text should be cited whenever the number is used.

That interpretation is not hedging. It is the literal difference between an objective and an operating result. A useful newsroom or boardroom sentence therefore keeps three fields together: the issuing body, the object, and the verb. “MIIT’s 2026 pilot notice sets a 2029 objective to form solutions, scenarios, and terminal products that support later commercial implementation.” The sentence says something real. It does not upgrade the objective into a launch date.

Readers should be equally careful with a roadmap supplied by a company. A company may use “2029,” “6G,” or “commercialisation” in a presentation, but the questions remain: commercialisation of what, where, under which regulation, with what device, and to whom? Is the date a product prototype target, a standards milestone, a trial milestone, a customer-availability date, or a revenue expectation? A date without its object is a narrative device, not decision evidence.

A simple test catches most overreach: remove the future adjective. If the present-tense claim cannot be supported now, it should not be treated as a completed fact merely because a future target exists. “The programme has a 2029 objective” is supportable from the notice. “The network will be commercially available in 2029” adds a promise not made by that record. “This factory will use 6G in 2029” adds a location, customer, and outcome that require their own evidence.

This distinction is especially important for long-lead manufacturing. A component maker may need to decide whether to fund research capacity; a systems integrator may need to decide whether to explore a design path; a plant may need to decide whether to reserve a test environment. These are legitimate decisions under uncertainty. They do not become safer when uncertainty is disguised as a service date. They become safer when the decision is explicitly tied to a gated next record: a named research partner, a current interface, a test plan, a standards release, a site workload, or an acceptance condition.

The IMT-2030 process is a sequence, not a finished product

The term “6G standard” can hide more status than it reveals. It may refer to a vision document, a requirements document, an evaluation method, a work item, a contribution, a specification, a radio interface, a test method, a national implementation, or a product certification. Those are not the same thing.

ITU-R’s IMT-2030 material supplies a useful status anchor. Its current page records that Working Party 5D completed draft technical-performance requirements in February 2026 and draft evaluation guidelines in June 2026, and that both were submitted for a December 2026 Study Group 5 approval step. The status itself is important: draft, followed by a stated later approval step. Readers can inspect the ITU-R process record rather than relying on a simplified retelling.

The ITU’s March 2026 explanation of the draft requirements describes six proposed usage scenarios, including immersive communication, high-reliability and low-latency communication, massive communication, ubiquitous connectivity, AI-and-communication, and integrated sensing and communication. These categories describe the range of conditions the framework is trying to address. They do not certify that a product, operator, or country has delivered them in a commercial environment. The ITU update expressly frames the work as technical requirements and evaluation groundwork, not a real-world performance guarantee.

The word “evaluation” is the clue. An evaluation framework tells people how an asserted capability may eventually be examined. It does not supply the result for an unnamed device. A bicycle race rulebook does not prove that a bicycle has won a race; a factory acceptance template does not prove that a machine is producing good parts. Similarly, a future-network evaluation framework is not a throughput report, latency result, coverage map, energy measurement, interoperability certificate, or industrial business case.

This is why standards work should be treated as enabling evidence. It can be highly consequential. It lets parties organise research and test language around a more common frame. It gives engineers and suppliers a way to distinguish a demonstrator from a claim that could eventually be compared. But a buyer still needs the relevant instance of the evidence: which version, which implementation, which interface, which testing conditions, which integration, which service terms, and which exceptions.

An ITU-T work item gives another useful boundary. A framework work item on IMT-2030 network considerations is listed as under study with a 2028-Q1 timing, and names China Mobile, China Unicom, China Telecom, and CAICT among supporting members. That establishes participation in a formal work item. It does not establish that those members have an equivalent product, a deployed commercial network, an interoperable service, or a buyer-ready offer. The source is the ITU-T work-programme entry, not a performance or procurement record.

Participation is often misread because it is easy to name and easy to compare. But a participant can contribute to a work stream without selling a finished product; a standard-setting body can record a work item without approving a commercial specification; and a listed timing can be a planned completion point without being an operating date. When an article, pitch deck, or product brochure uses a participant list as proof of readiness, the reader should ask which of those three conversions has been made without evidence.

An independent industry-process check points in the same direction. The GSMA’s May 2026 progress report discusses 3GPP Release 21 work and future specification milestones. It is useful as a separate industry-status source, but it still reports a process. It is not a product certification or a launch register. Its relevant context is in the GSMA 6G community report.

Editorial status framework. The stages distinguish types of evidence; they do not form a product roadmap or commercial timetable.

Editorial evidence sequence. The arrows show the order in which stronger deployment claims need additional records; they are not a commercial timetable.

A standards milestone changes what to watch, not what a buyer can assume

Once readers see a standards milestone in the correct lane, they can use it more effectively. It may change what a research team watches for: revisions, final approval, a named specification release, a relevant test method, a component interface, or a proposal from a current supplier. It may change how a company words its own roadmap: “research aligned with a stated IMT-2030 direction” is a bounded statement, whereas “meets 6G standards” is not bounded unless a version, requirement, and evidence are supplied.

It should not change a buyer’s assumptions about coverage, price, reliability, security, interoperability, regulatory approval, or factory outcome. Each of those is a different claim with its own record. The strength of the standards process is that it helps make those later records more legible. The weakness of bad commentary is pretending that legibility is the same thing as completion.

The four files a real 6G claim needs

The following model is intentionally mundane. It turns a large future-technology story into a set of requests that can be answered or left open. The reader does not need all four files for every early research conversation. But the more concrete the claim becomes, the more the missing files matter.

File 1: the programme file

Use this file when the claim is: “China is organising 6G research,” “a provincial pilot exists,” “the programme has a stated objective,” or “a regional effort is eligible to pursue a defined direction.” The right sources are an issuing authority’s dated notice, a later named selection decision, and any official implementation update.

Record the issuer, date, legal or administrative character, geography, stated objective, selection rule, duration, and exclusions. Keep the wording of the objective intact. If the record says it supports later commercial implementation, do not shorten that to “commercial launch.” If it says a region may select directions, do not report those directions as completed deployments.

The programme file is sufficient for a contextual sentence and for a research-planning conversation. It is insufficient for an implementation commitment. It cannot tell a buyer whether their application is eligible, whether their location is selected, which network layer will be used, which supplier is involved, what a product costs, or whether a local service will be maintained. Those are not failures of the programme; they are questions outside its object.

File 2: the standards file

Use this file when the claim is: “a requirement is draft,” “an evaluation method is moving through approval,” “a work item is under study,” or “a named body is participating in a technical process.” The relevant sources are the formal body’s current status page, the versioned document, a work item, and—where applicable—a specification or approved recommendation.

The first check is status. Is the material a vision, a study, a draft, a completed recommendation, a pending approval, or a frozen specification? The second is scope. Does it describe radio performance, network architecture, a scenario, an interface, evaluation, or another layer? The third is application. Does it attach to a named product or deployment? If it does not, do not let the standards statement masquerade as a product statement.

The standards file is enough to explain where a formal process stands. It is not enough to conclude that a manufacturer’s component interoperates with another component, that a carrier will offer a service, or that a plant workload will meet an operational target. A purchaser should expect the supplier or operator to supply the named implementation record as well.

File 3: the named-system file

Use this file when the claim is: “this operator supports this service,” “this device implements this capability,” “this component is compatible with this interface,” or “this integrator can deliver this configuration.” This file must be named. It should identify the legal or commercial party, the product or service, the version, the configuration, the intended geography, the interface or network layer, the date, the support boundary, and the evidence source.

The named-system file is where generic language becomes accountable. A supplier can no longer rely on a national programme, an industry event, or a slide with a technology label. It must explain what it is offering now, what it is researching, what it expects to change, and what it cannot yet promise. An operator should identify whether the material describes a laboratory, a field trial, a public service, a managed enterprise offer, or a proposed arrangement. An integrator should state where its responsibility ends and which other parties control the remaining layers.

For a buyer, the most important question is usually not “Is it 6G?” but “What exact outcome is being proposed, by whom, in which configuration, and how will we know it works?” The first question can help label a long-term technology direction. The second lets the project team set an acceptance process.

File 4: the acceptance file

Use this file when the claim is: “this deployment works,” “this factory use case improved,” “the service meets the agreed need,” or “the system is ready to hand over.” This is the most concrete and most commonly skipped file.

An acceptance file should identify the workload, site, connected equipment, relevant software and integration points, test period, conditions, success measures, failures, mitigations, and the person or organisation accepting the result. If the application relates to production, it should make clear whether the measure is a laboratory demonstration, a limited pilot, a shift-level result, or a sustained operating result. If the application relates to safety, control, or security, the relevant assurance process must be appropriate to that claim; a generic communications story is not enough.

The acceptance file is not a demand for an impossible universal test. It is a refusal to let a generic concept stand in for the work a named project must still perform. A small, well-scoped acceptance record can be more decision-useful than a large collection of future-network slides because it says what was attempted, how it was evaluated, and where the result stops applying.

Editorial evidence map. These files are distinct proof layers, not a telecom architecture, compliance checklist, or supplier ranking.

How different readers should use the China 6G record

The same public record means different things to different readers. Good analysis does not force all of them into one conclusion.

A component or equipment supplier

Treat the programme and standards files as a research-planning signal. They may tell you which questions customers, carriers, labs, or integrators could begin asking. They do not make a marketing claim true. Separate your material into three labels: shipping now, demonstrated in a defined environment, and research direction. Do not merge those labels because the market is interested in 6G.

For each proposed customer conversation, prepare a named-system file before using a readiness phrase. Name the part number or product version, the interface, the test state, dependencies, known limits, and the next evidence gate. If another party supplies a crucial network, device, or software layer, say so. A buyer who sees those boundaries can decide whether the opportunity is a research engagement, a proof of concept, or a future roadmap discussion. A buyer who does not see them is likely to hear more certainty than the supplier can deliver.

An industrial user or factory team

Treat the China 6G pilot as background for an investigation, not a replacement for an operating case. Start with a workflow that is difficult today: inspection data transfer, mobile equipment coordination, sensor visibility, remote support, or another defined task. Then write what a better result would look like and what a failure would cost. Only after that should the team ask whether a future-network research path is relevant.

The question to an operator, integrator, or vendor is not “Can you do 6G?” It is “Can you support this workload in this location, during these conditions, with this fallback and this acceptance method?” The answer may be a current system, a research proposal, a not-yet-available capability, or a combination. All are valid answers if labelled accurately. The invalid answer is a broad technology label used to hide which of those four it is.

This is consistent with the way manufacturing claims should be read elsewhere on the site. Smart manufacturing is not a property that automatically transfers from a national technology narrative to a given plant. It requires a named workload and an observable result. The future-network label does not change that burden.

A buyer evaluating a product or service offer

Ask the seller to complete the missing files in writing. First, identify whether the statement relies on a China pilot, a standards document, a company research announcement, or an operating deployment. Second, identify the exact product or service that the seller is offering today. Third, agree on a test and acceptance approach that resembles the buyer’s conditions. Fourth, write down what happens if the external dependency—the carrier, a component supplier, spectrum authorisation, a lab partner, or an integration interface—does not arrive on the assumed schedule.

Avoid an all-or-nothing response. A proposal can be useful even if it is research-stage, provided that price, scope, ownership, data handling, exit terms, and claims are appropriate to a research engagement. The buyer’s risk rises when a research-stage proposal is priced, supported, and represented as though it were a generally available production service.

An analyst, journalist, or policy reader

Make the object visible in the first sentence. Attribute the source. Preserve the date and status. Then name the missing proof before drawing a conclusion. This is especially important when numbers appear. “One to three directions,” “three years,” “2029,” and “2028-Q1” are all bounded programme or standards-process numbers. They are not measures of market size, service availability, revenue, adoption, technical performance, or supplier share.

The cleanest China 6G writing may sound less dramatic than a race metaphor, but it is more useful. It can say that a coordinated Chinese programme exists, that international requirements and evaluation work are advancing, and that commercial assertions still need product, operator, and site records. That is not an incomplete story. It is the story that the public records actually support.

A practical review workflow before repeating a 6G claim

When a 6G statement arrives in a presentation, article, press release, or supplier discussion, run it through this short workflow.

1. Underline the noun. Is the claim about a policy programme, a standard, a company, a device, a network, a factory, or a future market? If the noun is absent, ask for it.
2. Underline the verb. “Studies,” “plans,” “targets,” “supports,” “tests,” “demonstrates,” “deploys,” and “sells” are not synonyms. Use the verb the source can actually support.
3. Check the date and status. Is it a 2026 notice, a future objective, a draft document, an under-study item, or an operating record? Do not flatten a timeline into present tense.
4. Open the source. A headline may compress away the very limitation that determines whether it can be used. Prefer the issuer’s notice, standards body’s page, named company filing, or signed project record.
5. Ask for the next file. If the claim is about a product, request the named-system evidence. If it is about an industrial result, request the acceptance evidence. If the next file does not exist, label the claim as research or proposal.
6. Record the decision use. A source can be good enough to justify monitoring, too weak for a forecast, and wholly inadequate for a purchase. Write which decision it is being used for.

The workflow does not slow down serious work. It prevents a team from spending months clarifying a claim that could have been correctly scoped in one conversation. It also lets a team say yes to an exploratory step without saying yes to an unsupported conclusion.

Editorial checklist. It is a reading aid, not technical, legal, compliance, or procurement advice.

Common translations to avoid

These are not merely writing choices. Each unsafe translation changes who carries the burden of proof. The safe version leaves the burden with the party making the more concrete claim. That is where it belongs.

What would justify updating this page

This page has a deliberately short shelf life because its central sources describe an unfinished process. It should be reviewed if MIIT names selected pilot regions or projects, changes the programme terms, or publishes an implementation record. It should also be reviewed if ITU-R Study Group 5 approves, changes, or replaces the IMT-2030 material described here, or if a formal standards body publishes a later status that changes the draft or under-study language.

Even then, a standards update will not automatically answer the named-system and acceptance questions. A meaningful product or operator update would need its own records. A meaningful industrial outcome would need a site, workload, method, period, and acceptance result. The content should grow by adding those new files, not by using a later process milestone as a shortcut around them.

Method and limitations

This is desk research based on the June 2026 MIIT pilot notice, current ITU-R and ITU-T process records, and a GSMA industry-process report. It does not claim first-hand network engineering, laboratory testing, carrier operation, spectrum expertise, certification, security assessment, supplier qualification, or factory deployment experience.

The article does not assess network performance, coverage, spectrum allocation, vendor readiness, cybersecurity, commercial launch timing, commercial terms, or investment value. It also does not use patent counts as a proxy for commercial readiness. Readers making a technical, regulatory, procurement, or safety decision should obtain evidence appropriate to the specific product, jurisdiction, configuration, and operating environment.

Frequently asked questions

Has China launched commercial 6G in 2026?

The records used here do not support that statement. MIIT’s June 2026 notice creates a coordinated provincial pilot action for research, standards, industrial ecology, and application scenarios. The notice is a programme record, not a commercial-service announcement. A claim about an actual service would need a named operator, service scope, geography, conditions, and current operating evidence.

Does MIIT’s 2029 objective mean China will have 6G service in 2029?

No. The notice sets a 2029 objective to form technical solutions, application scenarios, and terminal products that support later commercial implementation. That is an enabling objective, not a published service date. A future commercial claim would require a different record that identifies the service, operator, device, market, and availability terms.

Are IMT-2030 requirements already proof that 6G products are ready?

No. ITU-R records draft requirements and draft evaluation guidance moving through a stated approval process. The ITU’s material describes a framework for future evaluation, including proposed usage scenarios. It does not certify an unnamed device or prove real-world deployment performance. See the ITU technical-requirements update.

Do Chinese carrier names on an ITU-T work item prove that they are commercially ready?

No. The ITU-T entry shows that a network-considerations framework work item is under study and lists supporting members. Participation in a work item is a real form of involvement, but it is not an operator launch, a product certification, or a customer acceptance result. The relevant record is the ITU-T work programme.

Should a supplier mention China’s 6G programme in customer material?

It may be relevant as carefully attributed context, particularly in a research or roadmap conversation. The supplier should distinguish clearly between the public programme, any named collaboration, its current shipping products, any defined demonstration, and future work. It should not use the programme as evidence that its own product is commercially 6G-ready.

What should a factory ask for before joining a 6G-related pilot?

Ask for a written problem definition, named participants, the current and proposed system boundary, data and integration responsibilities, test method, operating conditions, success metrics, failure handling, ownership of results, cost, exit conditions, and the acceptance decision-maker. The public programme may explain why a pilot is being explored; it cannot substitute for these project records.

Why does this guide not rank China’s 6G patents or leading institutions?

Because neither a patent count nor a participant list is a reliable readiness verdict. This page’s purpose is narrower: explain what current public programme and standards records establish, and what evidence is still needed before a reader calls a product, operator, or industrial application commercially ready. A defensible comparison of patents, institutions, or vendors would need a different research design, clear definitions, comparable primary material, and limitations that match the claim.

Related entries

• China’s 5G Network: Four Files Behind the Huawei Debate
• China’s Semiconductor Industry: The Buyer’s Evidence File
• Smart Manufacturing in China: What the Factory Claim Must Prove