How Chinese Factories Use AI: Real Applications Beyond the Hype

Factory AI becomes real when it changes an identifiable production decision—and someone still owns the result when the system is wrong.

By China Made & Tech Team — an independent, desk-research field guide to Chinese manufacturing and technology.

“We use AI in the factory” has become a familiar phrase. It may describe something meaningful: a production rule adjusted from live process data, an inspection system that focuses an operator’s attention, a design route that prevents a configuration error, a planning system that exposes an upstream constraint, or a maintenance signal that sends a technician to the right asset before an interruption becomes larger. It may also describe a dashboard, a demonstration station, a generic chatbot, or a vision camera whose output never changes what the factory does.

The difference is not cosmetic. The phrase covers very different kinds of work: identifying a defect, choosing a process setting, translating a product configuration into instructions, reallocating a constrained resource, or finding a maintenance problem early. Each has different data, timing, authority, and consequences. The useful question is therefore not whether a site has “AI,” but which physical or commercial decision its system changes—and what remains accountable when data is incomplete, a model is uncertain, a system is unavailable, or people disagree with it.

There are real, published Chinese examples of AI being integrated into industrial operating systems. The World Economic Forum’s June 2026 Global Lighthouse Network release added 16 sites to bring the selected network to 238 and described AI as moving from isolated pilots toward a core operating capability in leading sites. That is useful evidence of what an application can look like. It is not a census of Chinese factories, nor is it a rating of the supplier sitting across from you. Read the WEF’s 2026 release.

This guide takes the useful middle path. It does not dismiss factory AI as hype, and it does not accept the label as proof. It first maps the operating decisions that AI can actually change, then uses published Chinese cases to show the application shapes behind the label. Only after that does it turn to the narrower question of what an overseas buyer should verify before allowing a supplier’s AI claim to influence a sourcing or release decision.

What makes a factory AI application real

An operational application has a visible chain. It starts with a product, process, asset, capacity, or service state; takes in data; produces a recommendation, alert, or control action; and ends with someone or something accountable for the consequence. Measurement, exception handling, and change control make the chain durable rather than demonstrative.

That can be expressed in seven questions that apply to any factory—not just a supplier conversation:

1. A clearly defined product, process, capacity, quality, service, or delivery decision.
2. Identified input data and a stated boundary around what the system can and cannot see.
3. An action path: recommendation, alert, automatic control, approval request, or human task.
4. A named owner who can accept, override, investigate, or stop the action.
5. A measure that has a baseline, a scope, a time period, and a reason it matters to the buyer.
6. An exception and fallback path when the system is unavailable, uncertain, stale, or contradicted by the physical process.
7. A change record when the product, component, process, data source, rule, or model changes.

The questions are deliberately harder than a technology checklist. They force the label back to an observable operating object. A capable application can be a genuine advantage; a vague one may still be a useful experiment, but it does not explain how the factory is controlled.

AI is a decision loop, not a layer of factory decoration

The label “AI factory” can make a production site sound like one thing. It is not. A modern factory may use many different digital and AI-supported tools at the same time, each with a different data source, cadence, user, error mode, and effect on the product.

One tool may classify images so that an operator investigates a possible surface defect. Another may propose a production schedule when a material arrival changes. Another may turn a product configuration into a design or work-instruction starting point. Another may look for patterns in equipment signals. Another may retrieve a maintenance procedure. Another may estimate energy use. Another may simply summarize a report for a manager without touching a manufacturing decision at all.

These are not interchangeable forms of “AI maturity.” They have different failure consequences. A tool that helps an engineer find an earlier drawing may be useful but low-risk to the buyer if an experienced person reviews the output. A system that changes a process setting, releases a product, commits a delivery date, or directs an exception needs a much stronger chain of ownership and verification.

The practical unit of analysis is the decision loop:

physical state or product definition → data capture → model, rule, or analysis → recommendation or control action → human or system owner → measured result → exception and change record.

Break any link and the impressive label loses much of its buyer meaning. A factory can have a sophisticated model but poor input data for your product. It can have excellent dashboards but no authority to alter a schedule. It can identify a quality anomaly but not connect the anomaly to containment, root-cause work, and shipment release. It can automate a design option while leaving product-change approval in an untracked email thread.

Editorial evaluation framework: an AI claim becomes operational only when its decision loop and recovery path are visible.

Start with the physical consequence

Before asking about models, platforms, agents, cameras, cloud services, or digital twins, ask what the system changes in the physical world. Does it change a product configuration? A component choice? A design parameter? A machine setting? An inspection queue? A material allocation? A production order? A maintenance action? A shipment promise? A customer service response?

This sounds elementary, but it prevents two common errors. The first is accepting a technically impressive demonstration that has no path to your order. The second is rejecting a modest-looking system that actually improves a fragile handoff—perhaps a component-revision check, an assembly instruction, a quality escalation, or a service-parts identification process—that matters more than a highly visible robot.

The physical consequence also tells you who should be in the conversation. A buyer looking at a configuration system needs the product-development owner and the change-control owner. A buyer looking at AI-assisted inspection needs the quality leader, line owner, and shipment-release authority. A buyer looking at AI planning needs the planner, production owner, material buyer, and person who makes customer delivery commitments. A buyer looking at maintenance analytics needs the equipment owner and the person responsible for production recovery. One sales contact cannot answer all of those questions alone, even if they can arrange a persuasive tour.

The application shapes that show up in factories

Published cases are useful because they show that industrial AI is usually a connected set of operational choices, not one magic model. The following patterns make the operating work visible. They identify what to investigate; they do not establish that another factory has the same capability or will deliver the same outcome.

1. Configuration and design: preventing a bad product decision upstream

For high-mix products, the first place AI can matter is before the line starts. Product variants, customer options, technical constraints, part availability, packaging differences, and service implications can create a configuration problem that is easy to hide in a catalogue and expensive to discover after release.

The World Economic Forum’s 2026 release describes NIO’s Hefei site as linking in-vehicle AI, battery-swap networks, and a digital-twin platform that can manage more than 3.6 million vehicle configurations. The release attributes a 44% speed-to-market improvement and 90% automation of R&D workflows to the transformation. Those figures belong to the named site and its stated system, not to vehicle factories generally. The useful lesson for a buyer is the shape of the loop: configuration data, product-development work, operating data, and a shared digital representation were connected rather than treated as separate departments. See the NIO entry in WEF’s 2026 Lighthouse release.

Midea General Refrigeration’s Chongqing operation provides another, smaller-scale way to read the pattern. WEF reported in January 2025 that the site deployed 79 digital use cases powered by machine learning, augmented reality, and simulation in response to a sharp increase in customized orders, combining configuration, intelligent design, agile production, and adaptive quality assurance. WEF attributes site-specific reductions in configuration and design lead time, as well as a lower after-sales failure rate, to that transformation. Read WEF’s 2025 Midea entry.

Midea’s own site description makes the operating links more visible: it describes physical models, product-lifecycle-management-linked design data, AI-assisted heat-exchanger and piping design, quality-error prevention, traceability, and IoT-informed maintenance at the named chiller factory. A company account is not independent proof of a buyer outcome, but it is useful for asking a better question: Where does the product configuration become an approved production version, and what stops a later option, drawing, component, or instruction from drifting? Read Midea Building Technologies’ site description.

For a buyer, a credible configuration-and-design application should lead to tangible evidence:

• the product or order attributes the system receives;
• the attributes that are fixed, optional, or manually reviewed;
• the version or revision that is released to production;
• the relationship between the design output, bill of materials, packaging, instructions, and service parts;
• the owner who approves a deviation or substitution; and
• the record that shows what changed between a sample, an order, and production.

Notice that none of those items requires you to judge an algorithm’s mathematical architecture. You are evaluating whether the application protects the product definition you care about. If the factory cannot show how a configuration becomes a controlled release, a claim about AI-assisted design may be interesting but should not change the buyer’s confidence.

2. Quality and process control: turning a signal into a contained decision

Visual inspection is probably the most recognizable factory AI application. Cameras, computer vision, anomaly detection, and defect classification can be useful. They can also become the most misleading kind of factory theatre because a buyer can see a screen without seeing what happens after it lights up.

The relevant question is not whether a camera finds something. It is whether the factory has built a reliable path from signal to action. Which product and process step are covered? How is the output reviewed? What is the escalation threshold? What is held, reworked, investigated, or released? How does the result connect to the product version, lot, process parameter, component source, and shipment decision? What happens when the image quality changes, the product finish changes, a new defect pattern appears, or the system is unavailable?

Beijing Shougang Cold Rolling is a useful published case because it links AI to a named quality and process problem rather than to a generic smart-factory story. WEF’s 2025 Global Lighthouse report says the site deployed 67 Fourth Industrial Revolution use cases, 61% of which used AI, in the context of high-end automotive quality demands and growing SKU complexity. The report attributes reductions in product defects and customer complaints, along with an improvement in line efficiency, to the site transformation. It also names applications such as a knowledge-graph-enabled AI expert system for customer stamping quality, machine-learning-assisted process settings optimization, and AI-neural-network-enabled real-time galvanizing control. Those are the site’s stated cases and measures, not a promise for another steel mill or supplier. See the Beijing Shougang case in WEF’s 2025 report.

The buyer lesson is more durable than the technology names. Quality AI has to connect three things:

1. Detection: what signal, defect family, parameter, or deviation is being surfaced?
2. Disposition: who determines whether the unit, lot, process, or product release is affected?
3. Learning: how does the plant decide whether a repeat pattern requires a material, design, process, supplier, instruction, or control-plan change?

If a supplier says that AI improves quality, request a single current use case relevant to your product family. Ask to see the boundary in plain language: included products and lines, alert type, human review, containment action, measure, exception route, and change record. You do not need a complete factory data map. You need enough detail to know whether a quality signal can still disappear between screen and shipment.

3. Planning, assembly, logistics, and allocation: connecting the promise date to the factory state

Buyers often encounter AI claims when a supplier is describing planning or delivery. “Our system optimizes production,” “we use AI scheduling,” and “we have intelligent logistics” may all be relevant, particularly for high-mix orders, volatile material availability, project deliveries, or multiple factories. They are not, by themselves, evidence that a delivery date is dependable.

WEF’s 2026 release describes China Merchants Heavy Industry’s Haimen shipyard as deploying more than 25 digital solutions, including AI-driven planning, digital-twin assembly, and just-in-time logistics, to connect planning and execution. The release also describes CIMC Reefer Containers in Jiaozhou as using more than 50 digital applications and AI-enabled solutions for resource allocation and production-process optimization. In both cases, the Forum reports outcomes for named sites and transformation programs. Read the China Merchants Heavy Industry and CIMC entries in WEF’s 2026 release.

The specifics differ between a shipyard, a container plant, and the kind of factory an importer may be considering. The planning logic is familiar. A system is useful when it sees constraints early enough to influence the next action: material shortage, labour availability, tooling status, machine availability, inspection hold, process bottleneck, warehouse position, transport constraint, or customer-priority change. It is not enough to optimize a schedule on a clean screen if the inputs are stale or if no one owns the action after the schedule changes.

For a buyer, ask to trace one real but anonymized planning scenario from a change to a revised commitment. The scenario might be a late component, a capacity conflict, an urgent order, a line interruption, a quality hold, or an engineering revision. Ask:

• What data was used to identify the conflict?
• What options did the system or team consider?
• Who accepted the revised plan?
• Which purchase order, work order, product version, or lot was affected?
• Who informed the customer, and when?
• What prevented an attractive schedule from overriding a quality or product-release constraint?
• How is the final outcome compared with the original commitment?

The answer reveals more than a factory tour. It reveals whether the claimed system is connected to the commercial promise you are expected to rely on.

4. Maintenance and service: keeping an asset signal connected to customer experience

AI-assisted maintenance can mean prediction, diagnostic support, prioritization, an operator alert, or better retrieval of a known procedure. It may help a factory protect uptime. It may also matter after shipment when the product itself generates operational data and the supplier supports a customer installation.

Midea’s Chongqing account describes an intelligent diagnostic platform using IoT data to provide early warnings for equipment faults and performance degradation, alongside service and maintenance tools for its named chiller context. That is a useful example of a broader pattern: a factory’s AI capability may connect production, installed-product data, maintenance, and service. It should not be read as proof that a different supplier can diagnose your product, meet your warranty commitments, or safely access your customer data. Midea’s description is specific to the named site and systems.

For a buyer, maintenance and service claims matter only after three roles are separated. Who owns the factory asset data? Who owns the customer product data, if any? Who owns the service decision and cost? A factory may operate sophisticated predictive maintenance on its own equipment while having no route to support an exported product in the buyer’s market. Conversely, a modest factory may have a mature spare-parts and warranty process that matters much more to the buyer’s actual customer promise.

Do not let a general claim of “AI-enabled service” blur these responsibilities. Ask what product or asset is covered, who can view the data, what decision is made from it, what human review exists, what customer or buyer approval is required, and what happens when the system does not produce a clear answer.

Editorial application map: the same AI label can touch different decisions, evidence, owners, and failure modes.

A published case is a clue, not a verdict on another factory

The most important discipline in reading AI examples is to preserve their scope.

The WEF Lighthouse material is valuable precisely because it names sites, problems, applications, and stated outcomes. The June 2026 release says the newest cohort includes different industries and operating environments, and it emphasizes that the greatest impact comes when technology is combined with operational fundamentals, workforce engagement, and clear strategic objectives. That is a reminder that an AI model is rarely the whole explanation for a measured result. The release explains this selected-site context.

The danger lies in transferring a result across boundaries that matter:

• from a selected leading site to an unrelated factory;
• from one product architecture to another;
• from a long-running transformation to a new pilot;
• from a factory-wide metric to one line, SKU, order, or lot;
• from a reported operational result to a contractual delivery commitment;
• from an internal factory system to a buyer-facing product or service system; or
• from a good normal-case demonstration to an untested exception.

This does not make case studies useless. It makes them more useful. They give readers a catalogue of questions. NIO’s example asks whether configuration, product development, and live operations share a controlled object. Midea’s example asks whether customized design, production, quality, traceability, and maintenance are connected. Shougang’s example asks whether a quality signal has a route into process control and customer-relevant disposition. China Merchants and CIMC ask whether planning and execution are connected when constraints change.

An application does not need to replicate the scale or software of a Lighthouse to be meaningful. It needs a credible, current, proportionate route from the decision to its operating result. That is the standard for understanding a factory application; it becomes a supplier question only when the result is being offered as relevant to a particular program.

What a working factory application has to connect

China’s Ministry of Industry and Information Technology published a Manufacturing Enterprise AI Application Guide in January 2026. The guide says it applies to companies using AI in research and design, production manufacturing, operations management, and extended services. It calls for capability assessment, scenario and technology priority, rational objectives, industrial foundations, and data resources as part of application planning. That is public planning guidance, not a certificate for a factory or a verdict on a particular AI deployment. Read the MIIT guide.

The useful implication is not “the factory follows a guide, therefore the system works.” A credible application should have a reason for existing: a defined scenario, an objective, data and operational foundations, a path into the business, and a way to evaluate whether it is doing the job.

Use the following eight connections to understand a claimed application.

1. Decision: name the decision before the tool

Ask for one sentence: “This application helps us decide ___ for ___ product, process, or order.” The blank should be concrete. It might be release a configuration, route a work order, prioritize an inspection, recommend a process setting, investigate a deviation, schedule maintenance, allocate a component, or identify a service issue.

If the sentence cannot be completed without words such as “insight,” “intelligence,” “optimization,” or “empowerment,” the claim is not yet operationally clear. It may still be an interesting experiment, but it does not explain what the factory is controlling.

2. Object: identify the product or process boundary

Every useful application has a boundary. Which family, configuration, line, machine, component, supplier input, work order, lot, or service asset is included? What is explicitly out of scope? A system may work well for stable products and poorly for new variants. It may cover one process step but not the downstream release. It may provide a recommendation for factory equipment but not for an exported product.

The object boundary establishes relevance. An application trained on a stable product family may say little about a new custom variant. A line-level dashboard may say little about control of a critical component. The boundary is what stops a broad technology label from quietly becoming a broader operational claim.

3. Data: ask what enters the loop and how it stays usable

You do not need source code to ask practical data questions. What records, signals, images, documents, or inputs feed the decision? Who creates and corrects them? How are products, versions, lots, tools, and process steps identified across systems? How does the factory notice missing, stale, contradictory, or implausible inputs? Who can change a master record or mapping?

Data quality is not an abstract technology concern. If the wrong product revision, component code, inspection standard, inventory quantity, or work order enters the loop, a sophisticated recommendation can become a fast way to spread the wrong answer. The operational question is whether the identifiers that matter remain identifiable in the process.

4. Action: distinguish recommendation from automatic control

An AI system can observe, recommend, prioritize, draft, approve, trigger, or control. Those are different actions. A recommendation that an engineer reviews is different from a process setting applied automatically. An alert that opens a quality investigation is different from an alert that releases a shipment. A generated work instruction that is reviewed is different from an instruction that reaches the line without a release owner.

The action should be labelled honestly. This is not a test of sophistication: a human-reviewed application can be entirely appropriate. What matters is knowing when a person must decide and when an automated mechanism can change a physical or commercial state.

5. Owner: name the person or role who can disagree

Every application needs an operating owner. A data scientist, IT team, equipment engineer, quality manager, planner, production supervisor, product engineer, or service leader may play different parts. The relevant owner is the person or role with authority over the decision itself.

Ask who can override the output, who investigates an exception, who approves a change, and who has the power to stop a release. If the answer is a vague “the system team,” the application may be managed technically but not governed operationally. Someone must own the consequence when an AI-supported decision collides with a product specification or customer promise.

6. Measure: preserve the baseline and the denominator

“AI improved efficiency by 30%” is not a usable buyer statement without a baseline, measure, period, scope, and relation to the buyer’s product. Was it a selected line, a product family, a labour task, a defect category, a planning response, a maintenance event, a total plant measure, or an after-sales metric? Was the product mix stable? What changed alongside the system? What trade-offs were accepted?

The measure needs a baseline, period, scope, and definition. If a system is said to improve delivery, the record should define delivery performance and exceptions. If it is said to improve quality, it should define defect category, containment, rework, and release outcomes. If it is said to improve configuration, it should show how it reduces a wrong or late release.

7. Exception and fallback: find out what happens on a bad day

This is the most important connection and the one most often skipped in a technology tour. What happens when the data feed is late? When an image cannot be classified? When a product version is new? When a component substitute appears? When a model’s confidence is low? When the network is unavailable? When an operator disagrees? When an alert is ignored? When the system recommends an action that conflicts with a customer requirement?

A factory does not need to claim that failure never happens. In fact, a credible answer usually acknowledges it and identifies an ordinary operating path: manual review, an alternate inspection, a held lot, a revised schedule, a human approval, a maintenance response, or an escalation. A fallback does not weaken an AI claim. It makes the claim operationally credible.

8. Change: keep the use case connected when the factory changes

Factories and products change continuously. A new material, supplier, camera, sensor, line, software release, model version, packaging arrangement, configuration rule, process parameter, or product revision can change an application’s meaning. A use case that was reliable on yesterday’s object may need re-evaluation on today’s object.

Ask what changes trigger review, whether the change record connects the product or process change with the AI application that depends on it, and who signs off if an application is temporarily bypassed. These questions keep an AI claim from becoming detached from the product or process it is supposed to improve.

Where AI may not be the deciding factor

It is possible for a supplier to have a credible AI application and still be the wrong supplier for your program. AI does not settle a product’s material choice, tooling fitness, component ownership, quality release, testing scope, destination requirements, price structure, capacity commitment, packaging, warranty, service, or contract. Those decisions still need the evidence appropriate to the exact order.

It is also possible for a supplier to have little visible AI and still be a strong partner. A stable process, a controlled product file, disciplined change management, clear quality ownership, honest capacity communication, and reliable service can matter more than an advanced system that the supplier cannot connect to your product. The buyer’s goal is not to reward technology branding. It is to reduce avoidable uncertainty in the delivered product and relationship.

This is why the wider context matters. China’s smart-manufacturing guide explains the broader industrial operating system. China’s industrial robotics guide distinguishes physical automation from a generic technology narrative. How China manufactures adds the production and supplier context that no software layer can replace.

What this means when a supplier cites factory AI

Only after the application itself is clear does the buyer question begin. A supplier may have a genuine, well-run AI application and still be unable to show that it touches the product, order, quality release, delivery promise, or service obligation under discussion. A short evidence file keeps that distinction visible. It is not a request for every factory document or a demand to expose proprietary models. It is a shared operating record for the one claimed use case that might influence a sourcing or release decision.

The evidence file should be proportional. A complex factory-wide scheduling system can require several conversations and a defined review. A simple inspection-assistance application may require only a use-case map, owner, sample decision, escalation route, and a statement of scope. The point is not paperwork. The point is to retain the distinction between understanding a technology and relying on a supplier decision. Editorial buyer file: assess one operating claim through its connections to the product, people, evidence, and recovery path.

A short acceptance sequence

Use staged acceptance rather than a single declaration that the supplier is “AI capable.”

Stage 1: relevance. Identify the one use case that could plausibly affect your product or delivery decision. If none is relevant, treat the claim as background context and focus on normal supplier qualification.

Stage 2: mapping. Map the decision, boundary, data, action, owner, metric, exception, fallback, and change path. If the mapping is incomplete, ask what is unknown; do not fill gaps with assumptions.

Stage 3: product connection. Confirm whether the use case covers the intended product family, configuration, component route, line, order pattern, or service model. If it does not, record the limitation.

Stage 4: evidence review. Review the evidence appropriate to the claim: an example of the controlled record, a current operating explanation, an approved process or release path, and a measure with scope. Seek appropriate specialist review where a technical, safety, security, regulatory, or contractual question exceeds the buyer’s role.

Stage 5: commercial clarity. Decide what, if anything, the claim changes in the supplier relationship. AI should not silently become a quality guarantee, a delivery commitment, or a warranty representation. Keep the product, process, and commercial responsibilities explicit.

The stop rule

Pause when the supplier cannot show which decision the application changes, whether it covers your product or process, who owns the output, how it is measured, or what happens when it fails. Pause when the factory’s AI claim is being used to avoid a normal discussion about specification, component control, quality disposition, capacity, delivery, service, or contractual responsibility.

The stop rule is not anti-technology. It protects a genuine use case from being oversold. A factory with a modest but well-owned application can be more valuable than a factory with an elaborate display and no traceable exception path.

Frequently asked questions

Do Chinese factories commonly use AI?

There are published examples of selected Chinese industrial sites using AI-supported applications in design, configuration, quality, planning, assembly, logistics, maintenance, and service. The existence of those examples does not show how common, mature, or relevant a use case is at a particular factory. Ask the supplier to map one current application that affects your product or delivery decision.

Is computer vision enough to say a factory has AI quality control?

No. A vision system is a potential detection tool. Quality control depends on what is inspected, how the result is reviewed, what happens to a flagged unit or lot, how the issue is investigated, and who can release or stop shipment. The buyer should assess the full detection-to-disposition path.

Should I ask a supplier to reveal its model or source code?

Usually not as a first step. The buyer’s immediate need is operational evidence: what decision is made, what data boundary applies, what action follows, who owns it, how it is measured, and what happens in an exception. Technical access may be appropriate in a specific joint program, but it is not a substitute for an owned operating process.

Can an AI claim become part of a supplier’s delivery commitment?

Only if the parties expressly define what is being committed. A statement that AI supports planning or quality does not automatically define a product standard, delivery date, quality acceptance level, warranty, or remedy. Keep the underlying product and commercial obligations explicit, and seek appropriate professional support for contract-specific questions.

What is the fastest way to test a claim during a factory visit?

Ask the team to walk through one recent, relevant exception rather than a normal-case demonstration. A delayed component, a revised product version, a quality alert, a schedule conflict, an equipment event, or a customer change can reveal the real decision loop: input, system output, human owner, action, record, and outcome. If the factory cannot share a real case, ask for an anonymized or simulated one and keep the claim provisional.

Does a Lighthouse recognition mean the factory is the right supplier?

No. It can be useful context about a named site’s published transformation. Supplier selection still depends on the exact product, manufacturing route, components, quality system, capacity, delivery terms, service model, and commercial accountability for your program.

Method and limitations

This is an independent desk-research guide, not a factory visit, system audit, AI model test, software review, cyber assessment, product test, supplier assessment, or recommendation. It uses 2025–2026 World Economic Forum, MIIT, and company-published material to identify bounded application patterns. Lighthouse and company records describe named sites and stated measures; they do not establish an unrelated Chinese factory’s AI maturity, quality, delivery, security, capacity, product fitness, or commercial performance. Before relying on an AI claim, recheck the exact use case, current data and process boundary, owners, measure, exceptions, fallback, change history, and commercial responsibility for the supplier and product at hand.

Related entries

• Smart manufacturing in China — the broader operating context.
• China industrial robotics — where physical automation fits beside AI applications.
• How China manufactures — the sourcing system that surrounds technology claims.