A Judicial Verification Method for System-Level Trade Secrets in the Age of AI

By Scott Shields – Contributing Writer – Capitol Times Media – From Conversations and Material of Zhu Weisha. Learn more about Zhu Weisha here at Capitol Times Media’s July Magazine Issue. “From Double-Entry Accounting To Verifiable Finance”

A Transparent Bank as an Example

I. A New Problem That a Senior Judge Considered “Intractable”

We recently discussed a practical problem. As AI’s programming capabilities continue to improve, developing a complex software system no longer necessarily requires dozens of programmers working in specialized teams over a long period. Instead, an engineer who understands the business, system architecture, and AI-assisted development may be able to lead a group of AI agents and complete it within a relatively short time.

In the future, a single AI architect may simultaneously master the architecture of a chainless platform, the business logic of a transparent bank, database design, state machines, verification structures, chains of responsibility, AI development workflows, prompt systems, and key code.

If that person leaves the company without taking source code, copying documents, or leaving any obvious download records, but then relies on a remembered understanding of the system and AI to develop a highly similar new system, how can the company protect its trade secrets?

We consulted a senior judge with extensive experience adjudicating such cases. The judge’s preliminary view was that, under the evidentiary approaches commonly used in traditional cases, this type of problem would be almost impossible to address. Trade-secret cases have traditionally looked for traces such as copying or downloading, the removal of files, or identical code. In an AI-enabled reconstruction, all such direct traces may disappear even though the system can still be rebuilt.

This does not necessarily mean that the trade-secret regime has failed. It means that the facts of the case, the carriers of knowledge, and the methods of proving misappropriation have all changed.

II. What Has Really Changed: The Development Method and the Carrier of Knowledge

On the surface, this is an intellectual-property problem created by AI. At a deeper level, however, the organization of software development has changed. In the past, knowledge of

a complex system was generally dispersed among separate product, business, architecture, database, front-end, back-end, and operations teams. Few individuals understood the system as a whole. AI has greatly increased an individual’s ability to integrate knowledge and reconstruct a system, potentially concentrating system knowledge in a very small number of people.

This gives rise to a new factual role: the Core Knowledge Holder.

As used in this article, a Core Knowledge Holder is a person who has a comprehensive understanding of a system’s core architecture, key design decisions, and overall business logic, and who can independently reconstruct the system’s core functions with the assistance of AI within a reasonable period. The person need not know every line of code or every technical detail, but must possess system-level knowledge that cannot be derived directly from public information, industry common knowledge, or general professional skills.

What may actually leave with a departing employee is therefore no longer merely a particular piece of code or a file, but the enterprise’s method of transforming theory, business requirements, rules, and technology into a complete system. AI makes code easier to regenerate, while making the knowledge of why the system was designed in a particular way, why alternatives were rejected, and why modules were combined in a particular configuration even more scarce and important.

III. What Is a System-Level Trade Secret?

A system-level trade secret does not replace the existing legal concept of a trade secret, nor does it create a new statutory right. China’s current Anti-Unfair Competition Law already protects technical, operational, and other commercial information that is not known to the public, has commercial value, and is subject to corresponding confidentiality measures. Current regulations and judicial interpretations also make clear that structures, methods, data, algorithms, computer programs, code, and related documentation may constitute technical information.

The term “system-level trade secret” is therefore used here to identify the systematic, combinational, and process-based form that technical information in complex software systems may take in the age of AI. Whether it is legally protected must still be assessed under three basic conditions: the claimed information can be specifically identified; it is not generally known or readily accessible to relevant persons in the field; and it has actual or potential commercial value and is subject to confidentiality measures commensurate with that value.

A classification must first be made; otherwise, public theories, industry knowledge, and enterprise secrets will be conflated.

Category One: Public theories. Publicly disclosed propositions such as “key facts must be verifiable” and “a transparent bank is not a bank moved onto a blockchain” do not become an enterprise’s trade secrets merely because that enterprise adopts them.

Category Two: Industry knowledge and general capabilities. Examples include the fact that a bank needs accounts, a general ledger, and identity authentication, as well as the general knowledge, skills, and industry experience accumulated by developers in their work. In principle, an enterprise may not monopolize such material through trade-secret law.

Category Three: System-level trade secrets. A system-level trade secret is not a single, isolated secret point. It consists of structural combinations, decision paths, and implementation methods developed by an enterprise around a specific problem and not readily derivable from public information.

Using a transparent bank as an example, system-level trade secrets may include:

• how public theories are mapped into specific system rules;

• how a chainless platform is adapted to the business and verification layers of a transparent bank;

• how state transitions, exception rollbacks, and three-tier confirmation are connected;

• how the general ledger is connected to the credit root;

• permission structures, chains of responsibility, security models, and regulatory-adaptation solutions;

• key AI development workflows, particular prompt systems, and methods of allocating work between humans and machines; and

• paths rejected after testing and the reasons for their failure.

The true value often lies not in any single element, but in the distinctive relationships formed after these elements have been selected, weighed, and verified. New information produced by organizing, improving, and processing public information may also be non-public. Failed experimental data and technical solutions may also have commercial value if they shorten development time, reduce costs, or create a competitive advantage.

However, overall similarity between two systems does not automatically establish misappropriation. Only distinctive structural correspondences that can be specifically described, have been subject to confidentiality measures, and cannot be explained by industry practice, functional necessity, or public sources may serve as important evidence in determining the source of knowledge.

IV. Why Courts Have Difficulty Reaching a Judgment: The Object of Comparison Has Changed

A court is not a system-development organization. It cannot decide whether two systems “feel the same” by intuition, but must rule on the basis of specifically asserted secret information and lawfully obtained evidence. Direct evidence such as source code, design documents, download records, email transmissions, and storage media has traditionally been important. In an AI-enabled reconstruction, however, the new system may regenerate all of its code, making line-by-line comparison incapable of revealing the true source of knowledge.

Existing law already provides a basic basis for protecting structures, methods, algorithms, programs, and the use of trade secrets after modification or improvement. The principal weakness today is not whether the law recognizes such information, but whether the right holder can clearly define the secret it claims, prove how it was formed, its confidential status and scope of access, and whether technical appraisers and courts can establish comparison methods suited to complex systems.

The inquiry must therefore expand from “Is the code identical?” to “Where did the key knowledge embodied in the accused system come from?”

This comparison cannot stop at broad problem definitions or general functions, because the same market demand may cause different enterprises to adopt similar functions. More probative objects of comparison include:

• key architectural layers and their nonstandard sequence of connections;

• distinctive state-machine transitions, exception handling, and rollback logic;

• the distinctive placement and configuration of verification nodes, chains of responsibility, and regulatory adaptation;

• correspondence between solutions selected and rejected in major design decisions;

• failed paths that are not standard industry practice but appear in both systems; and

• particular terminology, prompt structures, or naming conventions that may reveal an internal source of knowledge.

An unusually short development cycle, similar terminology, or comparable functionality can serve only as supporting clues. None can independently establish misappropriation

without evidence of an opportunity for access, non-public status, and distinctive structural correspondence. The court’s ultimate question is not whether “the two products look alike,” but whether the accused party breached a duty of confidentiality or otherwise improperly acquired or used a trade secret that the right holder can specifically identify.

V. Building a Judicial Verification Structure with Two Categories of Facts

The key is not to decide the case for the court in advance, but to ensure that the enterprise leaves, during the formation of the system, facts capable of supporting a legal judgment. Under verifiable thinking, these facts can be divided into two categories.

The first category is determinate facts: what the system has already become.

These include layered architecture diagrams, state machines, database structures, interface definitions, chains of responsibility, verification structures, release records, snapshots of key modules, permission records, access logs, and design documents. Such materials show when particular system knowledge existed, what it specifically contained, who controlled it, and who could access it.

Depending on importance, an enterprise may preserve evidence through version control, signed confirmations, timestamps, hashes, trusted evidence-preservation services, or notarization. One limitation must be made clear: a hash and timestamp primarily prove that a particular file existed at a particular time and whether it was later altered. Standing alone, they do not prove that the file’s content is true, that ownership is clear, that the information is secret, or that the opposing party used it. They must be combined with evidence of authorship, version provenance, chain of custody, access controls, and specific content.

The second category is process facts: how the system was formed.

An enterprise need not preserve every routine discussion or permanently archive every AI conversation. What genuinely needs to be recorded are major design decisions: the problem to be solved; the available alternatives; why the chosen solution was selected; why other solutions were rejected; who participated and decided; when the decision was made; and whether it was later materially revised. For key modules, the enterprise may also preserve the final prompts adopted, errors in AI outputs, and records of human corrections, thereby showing how human knowledge and internal enterprise judgment entered the system.

A signed meeting memorandum, architecture-review record, or decision form of only a few hundred words is often more valuable than a massive, unfocused development log. In particular, failed paths and reasons for rejection—when documented contemporaneously, maintained continuously, and linked to specific versions—can help prove that the enterprise not only possesses the final result but also went through a distinctive process of problem identification and selection.

Saying that “only two categories of facts are needed” does not mean that an enterprise need preserve only two kinds of documents, or that a trade-secret case has only two legal elements. It means that the various forms of evidence an enterprise should retain can, by their factual nature, be classified as either “what was formed” or “how it was formed.” On that basis, the court can make a reviewable determination as to whether a trade secret exists, whether access and use occurred, and whether the knowledge came from the same source.

VI. How a Court Can Form a Complete Chain of Judgment

A system-level trade-secret case cannot be decided on the basis of a single anomaly or one piece of code. A more reliable judgment structure has four levels.

Level One: Foundation of the right. The claimant must clearly identify the specific information for which protection is sought and prove that it is not known to the public, has commercial value, and has been subject to appropriate confidentiality measures. It is insufficient to assert broadly that “the entire system,” “all knowledge,” or “the business model” is secret.

Level Two: Access and duty. The court should examine the defendant’s former position, responsibilities, permissions, project participation, reading and download records, attendance at key meetings, and any contractual or statutory duty of confidentiality. A company’s internal designation of a person as a Core Knowledge Holder may serve as management evidence, but it cannot replace proof of the person’s actual scope of access.

Level Three: Substantive correspondence and use. The accused system should be compared with the claimant’s asserted secret information to determine whether there are substantive differences, with particular attention to distinctive structural correspondences that cannot readily be explained by public information, industry practice, or functional requirements. Literal copying is not the only form of “use.” Modifying or improving a trade secret, or using it to adjust and optimize production or business operations, may also constitute use.

Level Four: Lawful source and alternative explanations. The accused party may prove that the information resulted from independent development, public sources, lawful reverse engineering, or the former employee’s general knowledge, skills, and industry experience. Complete and continuous independent-development records are important defense materials for explaining the source of knowledge.

Under the current Anti-Unfair Competition Law, the right holder must first provide preliminary evidence that confidentiality measures were taken and that reasonably indicates misappropriation. If the right holder further proves that the suspected infringer had an opportunity for access and that the information used is substantively identical to the trade secret, the suspected infringer must prove the absence of infringement. Access history, distinctive structural correspondence, and an independently documented formation process therefore constitute the core materials through which both sides prove the source of knowledge.

The final judgment should rest on the combination of all relevant facts: whether the foundation of the right has been established; whether the opportunity for access was real; whether the structural correspondence is distinctive; whether the development cycle and failed paths provide corroboration; and whether the accused party can offer a continuous, reasonable, and verifiable explanation of a lawful source.

VII. Protection and Boundaries for Core Knowledge Holders

A Core Knowledge Holder is not a new statutory status and is not legally “equivalent to the company.” The concept helps an enterprise identify a confidential role carrying materially greater risk than that of an ordinary employee and establish protective measures proportionate to the person’s scope of access.

An enterprise can establish three basic tools for such personnel: first, an inventory identifying the specific content and versions of system-level trade secrets; second, process-fact records for major technical decisions; and third, a complete management chain composed of confidentiality agreements, tiered permissions, training and notice, access logs, exit handover, and continuing confidentiality obligations. Different modules and personnel should be governed by the minimum-necessary principle, rather than having all information indiscriminately marked “top secret.”

A special confidentiality agreement may expressly prohibit an employee from breaching confidentiality duties by using particular system-level trade secrets to help the employee or a third party reconstruct the system. It may not, however, treat everything in the employee’s memory as company property or prohibit the use of general knowledge, skills, industry experience, and public information. Any non-compete restriction must also comply with labor-law requirements concerning eligible personnel, duration, territory, scope, and compensation; a trade-secret agreement cannot serve as an unlimited substitute.

Likewise, an enterprise cannot stipulate that “three similarities create a presumption of infringement,” or unilaterally determine the court’s allocation of the burden of proof. The agreement’s function is to clarify the scope of the secret, the state of knowledge,

confidentiality duties, and responsibility for preserving evidence. Whether infringement occurred remains for the court to determine under the applicable legal elements and the totality of the evidence.

VIII. What Truly Changes Is the Method of Judicial Verification

The age of AI changes not only the carrier and manifestation of trade secrets, but also the way evidence is formed and judicial verification is conducted in trade-secret cases.

In the past, cases often depended on direct traces such as copied files, download records, and identical code. Courts will increasingly also need to examine system structures, decision processes, access histories, and knowledge sources. Evidence once centered on information carriers that could be copied, downloaded, or physically removed; courts must now also identify system knowledge that can be memorized, re-expressed by AI, and regenerated. Enterprises once searched for evidence after a dispute arose; they must now build a verifiable structure while the system itself is being formed.

This is primarily a change in methods of fact-finding, evidence formation, and technical appraisal, and may not require the creation of a new trade-secret right. As such cases increase, however, judicial interpretations, appraisal standards, case rules, and corporate compliance standards may require further clarification—particularly concerning how system structures are defined, how distinctive correspondence is assessed, how public knowledge is distinguished from secret combinations, and how employee rights are balanced.

Conclusion: From Verifiable Finance to Verifiable Justice

At first glance, transparent banks, trade secrets, and AI development are three entirely different subjects. In fact, they apply the same method: verify key facts instead of first trusting a person or institution; replay the system’s formation process instead of reasoning backward solely from an existing result; and make the basis of judgment reviewable instead of allowing judgment to stop at an authoritative conclusion.

A transparent bank addresses how financial facts generate credit. Verifiable regulation addresses how regulatory judgments obtain a factual basis. Protection of system-level trade secrets in the age of AI addresses how the source of system knowledge enters judicial decision-making.

This article proposes the concepts of “system-level trade secret” and “Core Knowledge Holder” not to expand enterprise control over employee knowledge or create a new right outside existing law, but to identify factual categories emerging in the age of AI and build corresponding verification structures for them.

What the senior judge described as “intractable” does not truly lack a new rule that predetermines who wins or loses. It lacks an evidentiary method that enables a court to see how knowledge was formed, how it was accessed, and how it was reused.

If enterprises can transform key facts, key processes, and the bases of judgment into verifiable structures, courts can reduce the risk of making an intuitive choice between “there is no identical code” and “the systems clearly come from the same source.” On a complete evidentiary record, they can make reviewable determinations concerning the source of knowledge, lawful boundaries, and allocation of responsibility. This is the significance of extending verifiable thinking from finance into the judicial domain.