Machine-readable self-description capability indexing method and device for artificial intelligence creation

Abstract

The application provides a machine-readable self-description capability index method and device for artificial intelligence creation. The machine-readable self-description capability index method for artificial intelligence creation is applied to a declarative engine, and the method comprises the following steps: a capability index projector traverses a primitive registry table, projects the registration information of each registered primitive into a machine-readable index entry, and generates a capability index; in response to a query word input by a machine reader, if the query word hits a registered primitive, the authoritative detail page of the hit registered primitive is rendered first, and the query word is removed from a subsequent matching list; only when the query word does not hit any registered primitive, a description-based matching is performed. The purpose of improving the data accuracy of the artificial intelligence reading engine is achieved.

Description

Technical Field

[0001] This invention belongs to the field of game engine technology, and in particular relates to a machine-readable self-describing indexing method and device for AI-driven creation. Background Technology

[0002] "How to describe the capabilities of an API to the caller" is a long-standing problem in software engineering, with various documentation and descriptor solutions. However, in the context of a native AI engine, the nature of the problem changes: the readers of the capabilities are not human engineers, but large language models; the readers are subject to hard constraints of lexical budgets and cannot access the source code.

[0003] The existing technology is as follows: I. API Reference Documentation Generators (Doxygen, Javadoc, and similar): Extracting API reference pages from source code comments: Advantages: The document structure corresponds one-to-one with the source code symbols, and function signature information is less prone to drift. Disadvantages: 1. It is designed for human browsing, and the output is a webpage organized by source code file / class, not a compact index designed for machine readers that is enumerable by primitive category and can be precisely retrieved by name. Readers still need to navigate through a large number of pages, which is not suitable for meta-calculus. 2. The comment text (semantic description, examples, default values, ambiguity annotations) is still handwritten prose, which can drift with the implementation. 3. There is no discovery guarantee—if the registration code of a primitive is not commented, it will quietly disappear from the reference without any alert. 4. There is no query semantics that prioritizes precise matching by name; there is no explicit disambiguation enforcement for ambiguous parameters.

[0004] II. OpenAPI / JSON-Schema Interface Descriptor: Declaring a set of interface endpoints, parameters, and types using structured descriptors (such as OpenAPI specifications or JSON-Schema): Advantages: Machine-readable, structured, tools can use it to generate clients and perform validations; Disadvantages: 1. The descriptor itself is an independently maintained source—it is separate from the actual service implementation; adding or deleting endpoints without modifying the descriptor will cause it to drift; unless additional code generation or reverse validation is added, there is no guarantee of same origin; 2. It is geared towards network interface calls and is not suitable for scenarios where a finite, closed set of engine primitives is used for machine readers to discover and learn how to write declarative configurations within a lexical budget; 3. There is no reader-side query semantics that prioritizes exact matching over fuzzy matching; 4. It does not perform explicit disambiguation for machine readers regarding ambiguous parameters with the same key but different meanings.

[0005] III. Description of the function-calling tool schema for large language models: Declaring callable tools in a structured schema (name, description, parameter schema) to a large language model for it to choose from: Advantages: machine-reader oriented, structured, allowing the model to discover which capabilities are available for invocation; Disadvantages: 1. The tool schema is a list manually declared by the application side, which is still a separate source from the actual implementation of the tools—registering one tool requires manually writing a schema, and deleting one requires manually deleting one, drifting and omissions (discoverability gaps) are entirely subjective, without guards; 2. It describes external callable tools, not the same set of primitives registered in the engine, fixed at compile time, and driving runtime, so it naturally cannot achieve the same source for index and runtime, generated from registration; 3. There is no query sorting that prioritizes exact matching when the author names a primitive (function selection is done by the model itself, and the problem of being overwhelmed by similar items with the same name when pulling authoritative details by name is not solved); 4. There are no mandatory guards that every primitive must be enumerable, and no explicit disambiguation contract for ambiguous parameters.

[0006] IV. Integrated Development Environment Auto-completion / Language Server: Integrated Development Environments (IDEs) provide symbol completion, hover suggestions, and jump definitions via language server protocols. Advantages: Symbol information comes directly from real-time analysis of the source code, sharing the same origin as the implementation and is less prone to drift; it focuses on discovering which symbols are available. Disadvantages: 1. It serves the immediate prompts of humans typing character by character in an editor, producing interactive pop-ups, not a compact self-describing index that can be retrieved, enumerated by category, and loaded into context by a machine reader; it is unavailable outside the editor process. 2. It completes symbols (classes, methods, variables) of the host programming language, not the semantic capabilities of engine domain primitives (parameter meaning, default values, ambiguous sides, calling methods). 3. Completion is sorted by prefix / relevance, not guaranteeing that the exact primitive will outweigh the approximate one, and it does not perform ambiguous parameter disambiguation for machine readers. 4. It relies on running a heavy language server process, which is not suitable for the machine reading mode of command-line question-and-answer and lexical-budget-based detail retrieval.

[0007] In summary, the inventors discovered the following problems with the prior art during the implementation of this invention: 1. The capability scope is not suitable for the vocabulary budget of machine readers: The capability scope of existing technologies is either a full webpage for human browsing or an interactive prompt that relies on heavy processes. Neither of them is a compact self-descriptive index that machine readers can pull at once, enumerate by category, and retrieve details precisely by name within a limited vocabulary.

[0008] 2. Dual-source drift and discoverability gap: The capability list and the actual registration are two true sources. Adding or deleting primitives relies on self-synchronization. If a primitive is missed in registration, it exists but cannot be discovered. If it is not deleted, it is listed but no longer exists. Both types of drift occur silently and are not intercepted by guards.

[0009] 3. Fuzzy matching overwhelms exact matches: Queries that score by description place a large number of similar items before the exact primitives mentioned. Machine readers cannot distinguish authoritative answers, are misled by noise, and waste words.

[0010] 4. Ambiguous parameters are not disambiguated: parameters with the same key but different meanings are not explicitly labeled, and examples use neutral values ​​to cover up the ambiguity. Based on this, the machine reader generates a configuration that seems correct but is silently wrong.

[0011] 5. Lack of a semantic layer: Existing solutions mostly stay at the symbol / endpoint / signature layer, without covering the semantic layer that machine readers really need, such as parameter meaning, default values, ambiguous sides, and how to write declarative configurations. Summary of the Invention

[0012] To address the problems existing in the prior art, this invention provides a machine-readable self-describing capability indexing method and device for AI-generated content.

[0013] In a first aspect, embodiments of this disclosure provide a machine-readable self-describing capability indexing method for AI-driven creation, applied to a declarative engine. The declarative engine does not execute new code at runtime and exposes a finite set of primitives fixed at compile time. Primitives are registered in corresponding primitive registry entries according to their categories, and the primitive registry entries allow declarative configuration to be scheduled by name. The method includes: The capability index projector traverses the primitive registry, projects the registration information of each registered primitive into a machine-readable index entry, and generates a capability index. The capability index is generated from the same set of primitive registration information during driver runtime, so that the index entries are of the same origin as the primitives scheduled at runtime and are added or deleted synchronously with the addition or deletion of primitive registry entries. In response to a query term entered by a machine reader, if the query term matches a registered primitive, the authoritative details page of the matched registered primitive is rendered first, and the query term is removed from the subsequent matching list. Description-based matching is performed only if the query term does not match any registered primitive. The authoritative details page is the unique and correct description page returned by the capability index projector when the query term matches a registered primitive, containing primitive parameter reduction, disambiguation annotations, and calling examples.

[0014] Optionally, the primitives include actions, conditions, components, value functions, selectors, syntactic primitives, and / or test steps.

[0015] Optionally, the registration information includes primitive name, category, parameter specification, default value, enumeration value, calling method, and brief description; The capability index includes a capability summary that can enumerate all primitives and primitive-specific details that can be retrieved by name; The capability summary lists all the engine's primitives by primitive category, with each primitive rendered as a single line containing the primitive name and a brief description. The primitive details are information pages rendered by the capability index projector from the same set of primitive registration information after any primitive is retrieved by its name. The information page includes at least parameter name, parameter type, default value, enumerated value, disambiguation annotation, and calling example.

[0016] Optionally, the capability index projector traverses the primitive registry, projects the registration information of each registered primitive into a machine-readable index entry, and generates a capability index, including: Enumerate the primitive registry entries and check each registered primitive to see if it appears in the rendering artifacts of the capability index. If any registered primitive does not appear in the capability summary or primitive details, the construction is deemed to have failed.

[0017] Optionally, the capability index projector traverses the primitive registry, projects the registration information of each registered primitive into a machine-readable index entry, and generates a capability index, further comprising: For parameters in the generative capability index that fall on the ambiguous semantic axis, the primitive details carry explicit disambiguation annotations. The ambiguous semantic axis includes at least: absolute value and relative increment, world coordinates and parent local coordinates, overlay and replacement, effective per frame and effective once, interval boundary included and excluded, and degree and radian. The explicit disambiguation annotation clearly indicates which side of the ambiguous semantic axis the parameter should take; The examples in the primitive details use non-neutral values, so that ambiguity is exposed rather than masked in the examples.

[0018] Optionally, the capability index is read by machine readers using a two-level retrieval method: first, the capability summary provides an overview of all primitives, and then the primitive details of individual primitives are retrieved by primitive name to adapt to the contextual lexical budget constraints of large language models.

[0019] Optionally, the carrier of the capability index includes: being pulled via product command in a command line manner, pre-generated as a structured data file and distributed with the package, or returning details of a primitive as requested via a service interface; The generation timing of the capability index includes: traversing various primitive registry entries at runtime and projecting them into an index; generating static index data from registration information during the build phase via compile-time reflection or code; or generating static index data during the build phase and verifying at runtime whether the static index data is consistent with the capability index generated based on the index entries.

[0020] Optionally, if the query term matches a registered primitive, the authoritative details page of the matched registered primitive is rendered first, including: When multiple primitive registry entries are hit, the authoritative detail pages of each primitive under the primitive registry name are rendered separately. The authoritative detail pages are distinguished by category tags, and the multiple identities of primitives with the same name are presented in a parallel manner.

[0021] Optionally, the method also includes: For a given game package or a single configuration file, the report results of the set of primitives used are obtained from the abstract syntax tree parsed by the engine. The report results are then grouped by primitive category, deduplicated, and output. During engine parsing, the same primitive registry is reused at runtime, so that primitives with the same name are not confused due to text matching, and primitives in deep nesting can be discovered by recursive traversal and are not silently missed as the syntax evolves. The report only reports the primitives used, without reporting the specific number of occurrences of the primitives' actual components, and constructs an inverse index from the primitives to the documents that use the primitives based on the report results for use by the knowledge base.

[0022] Secondly, embodiments of this disclosure also provide an electronic device, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to perform the machine-readable self-describing capability indexing method for AI-based creation as described in any of the first aspects.

[0023] This invention provides a machine-readable, self-describing capability indexing method for AI-generated content, where primitives are automatically projected into a machine-readable, self-describing capability index. AI models can discover the primitives provided by the engine and how each primitive is invoked simply by querying this index, without needing to read any engine source code, thus improving the accuracy of AI in reading engine data. Attached Figure Description

[0024] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0025] Figure 1 A flowchart of a machine-readable self-describing capability indexing method for AI-based authoring provided in an embodiment of this disclosure; Figure 2 A schematic block diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0026] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0027] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] It should be noted that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice method. Furthermore, this device and / or practice method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0029] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0031] Terminology Explanation: Capability index: refers to the machine-readable self-descriptive index that the engine projects from all primitives, including capability summary and primitive-by-primitive details; Capability summary: refers to an overview of the capabilities of all primitives, with each primitive on a separate line, for machine readers to view at a glance; Discoverability refers to the property that every primitive exposed by the engine can be enumerated by a machine reader, and none of them are hidden outside the index; Usage derivation: refers to the first-order output of a parsed AST report showing which primitives are used in a configuration file; Exact match: This means that the query term exactly matches a registered primitive, taking precedence over fuzzy matching of descriptions and mentions. Disambiguation: refers to explicitly labeling which semantic side to take for ambiguous parameters with the same key but different meanings; Self-description: refers to the properties of a capability that do not require external documentation and are projected by the engine from its own registration. AST (Abstract Syntax Tree): refers to the typed structure that the engine parses into during configuration verification, and is a trusted source for deriving usage.

[0032] In AI-native game engines (such as physics engines), game logic is entirely described by declarative configuration data (world inventory, blueprints, behavior graphs, interfaces, data tables). The engine exposes a limited set of pre-compiled primitives (actions, conditions, components, value functions, selectors, syntax primitives, test steps, scaffolding, visual effects, etc.) with fixed compile-time. These primitives are not used by programmers who individually review the source code; instead, a Large Language Model (LLM) first discovers which primitives the engine provides and how each primitive is called, then generates configuration data accordingly. AI can only use the primitives it can discover; primitives it cannot discover are essentially non-existent to AI. This approach is detrimental to semantic retrieval indexing capabilities driven by digital threads.

[0033] Given this premise, how can an engine communicate its full capabilities to artificial intelligence in a machine-readable way? This question has evolved from an engineering convenience issue to a fundamental problem determining the upper limit and correctness of AI-generated content. The four technical issues exposed in this scenario are as follows: Question 1: If the capabilities are presented in source code, AI cannot read them all within the lexical budget. AI's understanding of engine capabilities is subject to a hard constraint—the context window (lexical budget). If the primitives provided by the engine, and the parameters and invocation methods of each primitive, only exist in the registration code scattered across hundreds or thousands of source files, AI has neither the right nor the ability to read the entire source code into the context; it can only invoke primitives based on guesswork or training memory, leading to numerous hallucination calls (invoking primitives that don't exist, giving non-existent parameters, and using the wrong parameter meanings). The capabilities available to AI are limited by the portion it can read within a finite number of lexical units.

[0034] Question 2: The manually maintained capability list inevitably drifts from the actual registered set. To provide AI with a readable capability list, engineers often write a separate capability manual. However, this manual and the engine's actual registered primitive set are two separate sources: if a primitive is added but forgotten to be registered in the manual, AI will never discover it (it exists but is invisible); if a primitive is deleted or renamed but the manual is not synchronized, AI will call a primitive that no longer exists according to the manual (it is listed but has been removed). This drift is silent—compilation succeeds, the manual is rendered as usual, but the capabilities it describes no longer match the engine.

[0035] Question 3: Fuzzy queries prioritize approximate matches over exact primitives. Artificial intelligence often already knows the name of a primitive and wants to retrieve its details. If the query uses fuzzy scoring based on mentions of the word in the description, a single query for a primitive name will return dozens of irrelevant entries that happen to mention the word, drowning out the exact match that truly refers to the primitive. The AI ​​cannot distinguish which entry is the authoritative answer and is misled by the sheer volume, wasting valuable vocabulary.

[0036] Question 4: Ambiguous parameters without explicit disambiguation can mislead artificial intelligence. The same parameter key may have different meanings in different contexts (e.g., is a target value an absolute value or a relative increment, world coordinates or parent local coordinates, or is it effective every frame or only once). If the capability index does not explicitly label this, and the examples happen to use two neutral values ​​that overlap in understanding, the artificial intelligence will generate configurations that silently do the wrong thing based on what seems to be the correct syntax.

[0037] The technical solution of this embodiment enables: the engine to project each class and each primitive it exposes into a machine-readable, self-describing capability index (capability summary + primitive-specific details). Artificial intelligence can discover what is available and how to invoke it simply by querying this index, without reading any source code. This index is generated from the same set of registration information used in the driver runtime. The existence of primitives, parameters, and invocation methods are consistent between the index and the runtime, making drift impossible. A discoverability guarantee ensures that every primitive exposed by the engine can be enumerated, and no primitive is hidden outside the index. Query parsing prioritizes exact matching over fuzzy matching, and the authoritative details of named primitives are always ranked first and not drowned out by noise. Ambiguous parameters carry explicit disambiguation labels and non-neutral examples in the index.

[0038] The differences between this embodiment and the prior art are as follows: The existing capability list is a genuine source independent of manual maintenance. Adding or deleting primitives relies on automatic synchronization, with no common source and no guards. The capability index in this embodiment is directly generated from the same set of primitive registrations during the driver runtime. The same registration is both scheduled by the runtime according to the table and projected as index entries, so the two cannot be mismatched. The existing combination does not guarantee that every capability will be listed (if a capability is not registered, it will remain silent and invisible); this embodiment sets up a discoverability guarantee guard - enumerate the registry of each type of primitive, and if any registered primitive does not appear in the capability index rendering, it will be highlighted in red, thus preventing the existence of a capability that cannot be discovered. Existing query / selection combinations do not distinguish between exact match and approximate mention; this embodiment establishes exact match priority—when a query term happens to name a registered primitive, its authoritative details are rendered first and the term is removed from subsequent fuzzy matching, so that the named primitive is never overwhelmed by similar terms with the same name; Existing combinations lack explicit disambiguation contracts for ambiguous parameters with the same key but different meanings; this embodiment requires that ambiguous parameters carry annotations and non-neutral examples in the index that clearly indicate which side of the semantics to take, to prevent seemingly correct but silently wrong actions.

[0039] The purpose of this embodiment is as follows: (a) Provide a mechanism that enables a declarative engine that does not execute new code at runtime to project each class and each primitive (action, condition, component, value function, selector, syntax primitive, test step, scaffolding, visual effect, etc.) it exposes into a machine-readable, self-describing capability index—consisting of a capability summary that enumerates all primitives and primitive-by-primitive details that can be pulled by name. Machine readers can discover what is available and how to call it simply by querying the index, without reading any source code; (b) The capability index is generated from the same set of primitive registration information that drives the runtime, and the index entries are of the same origin as the primitives scheduled by the runtime table, so that they cannot drift in terms of mechanism; (c) Provide a usage export that truthfully reports which primitives are used in each file from the parsed configuration abstract syntax tree (AST), outlining the mechanism. Original language The usage chain is presented to machine readers in a way that presents real usage rather than textual guessing; (d) Provide a discoverability guarantee guard, enumerate the registry of each type of primitive, and force every primitive exposed by the engine to appear in the capability index. Any primitive that exists but is not indexed will be built and turned red. (e) Provide query parsing that prioritizes exact match, so that when an author mentions a primitive, its authoritative details are rendered first and removed from subsequent fuzzy matches, and for multiple registry entries with the same name, each one renders its exact details; (f) Make ambiguous parameters carry explicit disambiguation labels and non-neutral examples in the index to prevent machine readers from generating configurations that silently make mistakes based on neutral examples.

[0040] Specifically, such as Figure 1As shown, this embodiment discloses a machine-readable self-descriptive capability indexing method for AI-driven creation, applied to a declarative engine. The declarative engine does not execute new code at runtime and exposes a finite set of primitives fixed at compile time. The primitives are registered in the corresponding primitive registry according to their categories. The primitive registry allows declarative configuration to be scheduled by name. A finite primitive set refers to a set of primitives whose total number is definite and countable, such as 300 actions, 80 conditions, 50 components, etc. This primitive set is configured at compile time and is not dynamically added during runtime, allowing the capability index to fully cover the entire capability surface, and enabling AI to read it within the lexical budget. A capability surface refers to the overall interface formed by all primitives exposed by the engine and their invocation semantics, which is understood by the AI ​​reader. Exposure means allowing declarative configuration invocation.

[0041] In a game scenario, before the game engine is developed, packaged, and released, the developers define all the usable functional modules and categorize them into different primitive registry entries. When the game runs, the engine reads a configuration file. If the engine reads `is_colliding`, it looks for a primitive named `is_colliding` in the conditional registry. If the engine reads `play_sound`, it looks for a primitive named `play_sound` in the action registry. The entire process involves looking up and calling primitives from the corresponding registry entries by name, without writing any new code.

[0042] The method includes: a capability index projector traversing the primitive registry, projecting the registration information of each registered primitive into a machine-readable index entry, generating a capability index, wherein the capability index is generated from the same set of primitive registration information during driver runtime, such that the index entries are of the same origin as the primitives scheduled during runtime and are added or deleted synchronously with the addition or deletion of the primitive registry. Each primitive is self-registered into the corresponding category's registry (action table, condition table, component table, value function table, selector table, syntax table, test procedure table, scaffolding table, visual effects list, etc.). These registry entries are the same data used for runtime name-to-function pointer scheduling. The capability index projector does not create a separate capability list; instead, it iterates through these registry entries, projecting the registration information of each primitive (primitive name, category, parameter specification, default value, enumeration value, calling method, summary) into index entries. The capability index includes: Capability Summary: Each category of primitives is listed in sections, with each primitive rendered as a single line (primitive name and a brief description), allowing machine readers to get a comprehensive overview of all the primitives the engine contains at once; Primitive details: Renders the complete page for a given primitive (parameter name, type, required, default value, enumerated values, disambiguation, and call examples), allowing machine readers to retrieve how to call the primitive by name.

[0043] Because the index and runtime are from the same source, the two types of drift present in existing technologies are eliminated in terms of mechanism: when a new primitive is added, it automatically appears in the capability summary and details (without needing to modify a separate manual); when a primitive is deleted or renamed, the index entry disappears or is renamed along with the registry, so machine readers will never read a listed primitive that no longer exists. The capability index is not a manual that needs to be updated manually, but rather a projection of primitive registration.

[0044] In response to a query term entered by a machine reader, if the query term matches a registered primitive, the authoritative details page of the matched registered primitive is rendered first, and the query term is removed from the subsequent matching list. Description-based matching is performed only if the query term does not match any registered primitive. The authoritative details page is the unique and correct description page returned by the capability index projector when the query term matches a registered primitive, containing primitive parameter reduction, disambiguation annotations, and calling examples.

[0045] When machine readers retrieve details, they often already know the name of the primitive and only want the authoritative page for that primitive. If the query is scored based on mention of the word in the description, a single query for a primitive name will return dozens of irrelevant entries that happen to mention the word in the description, overwhelming the exact match of the specified primitive. Therefore, this embodiment prioritizes exact matching over fuzzy matching in query parsing: When a query term happens to match a registered primitive (action, condition, component, syntax, test step, value function, selector, etc.), its authoritative details page is rendered first, and the term is removed from subsequent fuzzy matching. As a result, the authoritative answer of the specified primitive will always be ranked first and will no longer be dragged out by a bunch of noise by similar terms with the same name. Only when the query term does not precisely match any primitive, will fuzzy matching be used, and approximate results of the description mentioning class will be returned as a fallback (this fallback capability is reserved to handle situations where machine readers only remember the general concept and cannot remember the exact name). When multiple registry entries have the same name (a name that is also a primitive of multiple types, such as both an action and a test step, or both a value function and a syntax), each one renders its exact details page and is distinguished by category tags (such as action, test step). This is unambiguous and does not require machine readers to learn additional prefix syntax. The multiple identities of the same name are explicitly presented side by side, rather than choosing one or the other or causing confusion.

[0046] Thus, the machine reader's most frequent request—"I know the name, give me the details of this primitive"—receives a clean, authoritative, and noise-free response, without wasting lexical units on approximations. The specific settings are as follows: flowchart TD; classDef default fill:none,stroke:#000,color:#000; Q(["query term"]); HIT{"Whether to name precisely"} Is a certain registered primitive? MULTI{"Is the name...?" Hitting multiple registry types? ONE ["highlighting its authoritative details page"]; ALL["Each renders its precise details page"] Distinguish by category label; DROP ["Remove the word"] Subsequent fuzzy matching"]; FUZZY["Fuzzy matching fallback"] Return description mentions similar items of the same class"; OUT(["Delivery to machine reader") Authoritative details are preferred and noise-free. Q --> HIT; HIT -- "Yes" --> MULTI; MULTI -- "Single Category" --> ONE --> DROP --> OUT; MULTI -- "Multiple categories" --> ALL --> DROP; HIT -- "No" -->FUZZY -->OUT; linkStyle default stroke:#000,color:#000,fill:none.

[0047] In this engine, all capabilities available for AI to invoke (such as actions, conditions, components, value functions, etc.) are finite sets of primitives determined at compile time; no primitives are added or deleted at runtime. This means that the engine's capability surface is a well-defined closed set, and the primitives that AI can invoke are limited to members within this set.

[0048] In a specific scenario, this embodiment primarily redefines all the capabilities of the engine as a machine-readable, self-describing capability index projected from the same set of primitives registered during driver runtime. This projection relationship is then secured by three contracts: discoverability guarantee, exact match query, and ambiguity disambiguation. The machine reader retrieves the capability summary via the product command `angecapabilities` and the `ange query`. <topic>(Retrieve primitive details by name) Read the index. Details are as follows: flowchart TD; classDef default fill:none,stroke:#000,color:#000; REG["Primitive Registry"] Action / Condition / Component / Value Function Selector / Syntax / Test Steps Scaffolding / Visual Effects"]; RT["Runtime scheduling by table"] [Name to function pointer]; IDX ["Capability Index Projector"] Enumerate each type of registry Projected as index entries"; CAP["Capability Summary"] All primitives can be enumerated. Each primitive is on a separate line; QRY["Details of primitive language"] Parameters / Default Values ​​ / Invocation Method Disambiguation marker "]; USE["Usage Export"] Report from the parsed AST [Which primitives are used in each document]; DG["Discoverability Guarantee Guardian"] Each registered primitive It must appear in the capability index; EXACT["Exact match priority parsing"] First render the original text of the roll call. Remove subsequent fuzzy matches"; READER["machine reader"] Creator of large language models; REG -->RT; REG --> IDX; IDX -->CAP; IDX --> QRY; REG -.->DG; IDX -.->DG; QRY --> EXACT; CAP --> READER; EXACT --> READER; USE --> READER; linkStyle default stroke:#000,color:#000,fill:none.

[0049] The same primitive registration is both scheduled by the runtime by name → function pointer and enumerated and projected as an index entry by the capability index projector. Since the runtime and the index originate from the same source, it is impossible for a primitive to be able to run but not be found, or to be found but not run. The capability surface read by the machine reader is the product of this projection.

[0050] Besides knowing which primitives the engine uses, machine readers also need to know how each primitive is used in the actual game. This example demonstrates usage derivation: given a game package (or a single configuration file), it accurately reports which primitives are used in the file from the engine's parsed abstract syntax tree, grouped and deduplicated by category (action, component, selector, value function, etc.).

[0051] The key difference lies in the fact that usage export is derived from the Abstract Syntax Tree (AST) rather than text matching: When the engine loads the validation, it already parses each statement into a typed AST, precisely knowing which action each statement represents, which value functions a value reference calls, which selector a entity reference uses, and which components a blueprint declares. This information, already calculated, is discarded. Usage export outputs this as a first-class product. Therefore: Same name will not be confused. The set parameter key will not be mistakenly reported as a set action, and the property named count will not be mistakenly reported as a count value function (text matching cannot distinguish, but AST can). Deep nesting is reachable; selectors and value functions (such as nested integer counting expressions) embedded deep within conditional and value references can be discovered through recursive traversal. It doesn't decay with grammatical evolution; usage exports are bound to the real registry; new primitives won't be silently missed from the exports.

[0052] Usage exported as "mechanism" Original language The downstream knowledge base / retrieval layer of "usage" provides a reliable base map: linking a gameplay mechanic of an example game to the exact primitive it actually uses, thereby guiding the machine reader precisely to the primitive to be queried, rather than letting it guess from the text.

[0053] If a primitive is allowed to exist at runtime but fails to appear in the index for some reason, it cannot be discovered, so the machine reader has zero awareness of that primitive, which is equivalent to it being unusable. An entire class of capabilities may be completely invisible to the machine reader. Therefore, this embodiment designs a discoverability guarantee guard.

[0054] The guard enumerates the registry for each type of primitive, checking each entry to see if it appears in the rendered output of the capability index. If any registered primitive does not appear in the capability summary or details, the guard marks it as red and the construction fails. This establishes a hard invariant: every primitive exposed by the engine can be enumerated by the machine reader, and no type or any primitive is hidden outside the index.

[0055] The engine once had a whole class of primitives (such as test steps) that were clearly registered in the registry and each had its own usage description, but were completely invisible to machine readers because the index projector did not traverse this type of registry. Machine readers were required to use the index as the sole source of truth, but they could not find the existence of this type of primitive at all, and therefore could not write the correct corresponding configuration. The discoverability guarantee guard changes this kind of complete cloaking from relying on accidental discovery by humans to turning it red upon construction: if a new type of primitive is added or a new primitive is added but not connected to the index, the guard immediately fails, eliminating silent discoverability gaps.

[0056] If a capability index only provides the parameter name and type without specifying which semantic side to use for parameters with the same key but different meanings, the machine reader will generate a silently incorrect configuration based on what appears to be a correct syntax. This invention requires that: for any parameter falling on an ambiguous semantic axis—whether it's an absolute value or a relative increment, world coordinates or parent local coordinates, overlay or replacement, effective per frame or one-time, included or excluded from interval boundaries, or in degrees or radians—its capability index details must include explicit disambiguation annotations clearly indicating which side to use; and its examples must use non-neutral values ​​(not a baseline value where the two interpretations coincide), so that the ambiguity is exposed in the examples rather than masked.

[0057] In a specific scenario, the target parameter of a tween action might be an absolute target value, not a relative multiplier. If the details are not annotated and the example happens to use the baseline value (where absolute targets and relative multipliers give the same result), the machine reader will not learn this semantic aspect. It will write an entity that should be shrunk to a small size as being magnified several times, seemingly correct in writing but silently incorrect in result. By adding explicit disambiguation annotations (clearly stating the target as an absolute value) and non-neutral examples (using a value deviating from the baseline to fork the two interpretations), the machine reader can read the correct semantic aspect from the index. Disambiguation of ambiguous parameters is therefore a necessary component of the self-descriptive completeness of capability indexes: an index that only describes the existence of a parameter but not which semantic aspect it takes is incomplete for the machine reader.

[0058] The capability index is read by machine readers in a two-level fetching manner: first, a capability summary provides an overview (what types of engines exist, and what primitives are in each type), and then detailed primitives delve into specific primitives (how this primitive is invoked). This two-level design, summarizing first and then detailing by name, serves lexical budgeting. Machine readers do not need to load all the complete details of all primitives into the context at once. Instead, they first spend a small amount of lexicals reading a capability summary to locate the target primitive, and then spend a small amount of lexicals precisely fetching the details of that primitive (and, with exact matching priority, the fetched information is a noise-free, authoritative page). The capability summary, primitive details, and usage derivation form three orthogonal axes: the capability summary answers what is available, the primitive details answer how something is used, and the usage derivation answers which files are used. All three share the same index base generated from the registry, so they never contradict each other.

[0059] In a specific application scenario, a creator of a large language model needs to write the behavior of an entity facing the nearest enemy every frame in a game, but the creator doesn't know if the engine has a corresponding primitive, what that primitive is called, or how to invoke it. Constrained by the lexical budget, the creator cannot read the hundreds or thousands of source files of the engine.

[0060] The method disclosed in this implementation, using capability indexing for discovery and retrieval, is as follows: 1. The creator first retrieves the capability summary (ange capabilities), and with a small number of terms, finds a "direction" primitive and a brief description in the "actions" section: its existence is discovered; 2. The creator retrieves the primitive details by name (ange query plus the primitive name). Due to the priority of exact matching, the returned result is the authoritative details page of the primitive (parameters, default values, and call examples), rather than dozens of approximate items that "mention is mentioned in the description"; 3. The target parameter of the primitive in the details page falls on the ambiguity axis of "effective per frame or one-time use," so it carries explicit disambiguation annotations and non-neutral examples. Based on this, the creator correctly writes the configuration of "continuous orientation per frame," instead of mistakenly writing it as one-time use; 4. If the creator wants to refer to the actual usage of the primitive in a sample game, the usage can be exported to obtain "which primitives are used in the sample file," accurately locating the actual usage point of the primitive from the AST, rather than guessing from the text.

[0061] Throughout the entire process, the creator did not read a single line of source code; all their understanding came from the ability index generated through registration, which is non-drifting, enumerable, precisely matched, and explicitly disambiguated.

[0062] All three scenarios employ the method described in this embodiment: creators are either forced to guess a primitive name and provide parameters (illusionary invocation), misled by a manual of manual skills (which may omit the primitive or list a primitive that has been deleted), or unable to distinguish which of the dozens of noisy segments returned by a fuzzy query is authoritative. All three scenarios will generate incorrect games.

[0063] Relationship with discoverability guards: The reason why the aforementioned "orientation" primitives can always be found in the capability summary is because the discoverability guarantee guards force every registered primitive to appear in the capability index; in the history of the engine, there was an entire class of primitives (test steps) that were completely invisible to creators because the index projector failed to traverse its registry. It was this guard that transformed the gap from being discovered by chance to being highlighted upon construction.

[0064] This embodiment has the following effects: 1. Full Capability Awareness with Zero Source Code Access: This embodiment automatically projects each category and each primitive exposed by the engine into a machine-readable, self-describing capability index, which consists of a capability summary and primitive-specific details. The AI ​​model can discover which primitives the engine provides and how each primitive is invoked simply by querying this index, without needing to read any engine source code, significantly lowering the integration barrier between AI and the engine.

[0065] 2. The index and runtime are from the same source, fundamentally eliminating information drift: In this embodiment, the capability index is generated directly from the same set of primitive registration information in the driver runtime. Key information such as the existence of primitives, parameter lists, and calling methods remain consistent between the index and the runtime, thus fundamentally preventing information drift caused by the separation of documentation and implementation.

[0066] 3. Comprehensive Discoverability Guarantee: This embodiment ensures that every primitive exposed by the engine can be enumerated in the capability index through a built-in discoverability guarantee guard. Any registered primitive that is not covered by the index will be judged as a construction failure, thereby completely eliminating the risk of primitives being hidden outside the index.

[0067] 4. Prioritizing Exact Matching to Eliminate Query Noise: This embodiment employs a query strategy that prioritizes exact matching over fuzzy matching. When a query term precisely points to a registered primitive, the authoritative details page for that primitive is returned first, ensuring that the user-specified primitive is always ranked at the top and is not overwhelmed by noise from a large number of approximate results, significantly improving the accuracy and efficiency of the query.

[0068] This embodiment is compared with the prior art as follows: The comparison results of capability surface properties and drift suppression are shown in Table 1. Table 1. Comparison of Capability Surface Properties and Drift Suppression Results: .

[0069] The comparison between discoverability and drift is shown in Table 2: Table 2. Comparison of Detectability and Drift Results: .

[0070] The query experience comparison is shown in Table 3: Table 3. Comparison of Query Experience Results: .

[0071] The following technical solutions can also be used in this embodiment: For the capability index carrier, this embodiment can deliver it via a command-line question-and-answer method (capability summary and primitive details are retrieved via product command); it can also be pre-generated as a structured data file (such as a machine-readable manifest file) and distributed with the package, which can be directly read by machine readers; or it can return the details of a primitive as requested by a service interface, which is essentially another delivery surface of "projection from the same registration".

[0072] For the registration-generated method, this embodiment can adopt runtime traversal of various primitive registry entries and projection into an index; it can also adopt the method of generating static index data from registration information during the build phase (compile-time reflection / code generation), with zero traversal at runtime; or it can combine the two—generating during the build phase and verifying consistency at runtime (with a separate consistency guard to prevent drift).

[0073] For the discovery guarantee determination, this embodiment can use enumeration of the registry to check whether each primitive appears in the index rendering, and if one is missing, it will be marked as red; it can also use separate guards for each type of primitive, and check that the number of entries in the registry and the index section of the same type are equal; or it can use runtime self-checking instead of build-time guards (enumerate and assert at startup, and refuse to start if it fails).

[0074] For the exact match priority strategy, this embodiment can render the exact match first and remove it from the subsequent fuzzy match; it can also display the exact match and fuzzy results in separate partitions (the exact area is placed on top and the fuzzy area is placed next), without removing them but distinguishing them by partitions; or it can suppress the fuzzy results only when an exact match exists, and only display the fuzzy results when there is no exact match (a more aggressive suppression).

[0075] For the disambiguation delivery method, this embodiment can adopt an explicit disambiguation annotation embedded in the details + non-neutral example; or it can declare the semantic axis and the structured field of which side to take in its specification for each ambiguous parameter, which is then rendered uniformly by the index renderer; or it can assert which side of the semantics to take using a behavior probe that follows the primitive.

[0076] For usage-derived granularity, this embodiment can report the set of primitives used by a document (existence, excluding the number of actual participants); it can also report the occurrence count or source location (fineer granularity, at the cost of a larger output); and it can also use a reverse index (primitive → set of documents that use it) as a post-reversal of this derivation for downstream knowledge base retrieval.

[0077] The method of this embodiment can be extended to any domain language system (not limited to game engines) where the capability surface is read by a machine reader and a structured configuration is generated, and the capability is a fixed finite closed set at compile time. As long as the capability index is generated from the same set of registrations during driver runtime, discoverability guarantees and exact matching are applied, and ambiguous parameters are explicitly disambiguated, it is within the protection scope of this embodiment.

[0078] The electronic device disclosed in this embodiment includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0079] The processor may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the electronic device to perform all or part of the steps of the machine-readable self-describing capability indexing method for artificial intelligence creation described in the foregoing embodiments of this disclosure.

[0080] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0081] like Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the electronic device in the embodiment of the present disclosure. Figure 2 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0082] like Figure 2 As shown, an electronic device may include a processing unit (such as a central processing unit, graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from a storage device into random access memory (RAM). The RAM also stores various programs and data required for the operation of the electronic device. The processing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0083] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow electronic devices to exchange data wirelessly or via wired communication with other devices, such as edge computing devices. Although Figure 2 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0084] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, all or part of the steps of the machine-readable self-describing capability indexing method for artificial intelligence creation according to embodiments of this disclosure are performed.

[0085] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0086] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When the non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the machine-readable self-describing capability indexing method for artificial intelligence creation according to the foregoing embodiments of the present disclosure are performed.

[0087] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0088] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0089] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0090] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0091] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0092] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0093] Various changes, substitutions, and modifications can be made to the techniques described herein without departing from the teachings defined in this embodiment. Furthermore, the scope of this embodiment is not limited to the specific aspects of the processes, machines, manufacturing processes, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufacturing processes, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, this embodiment includes such processes, machines, manufacturing processes, events, means, methods, or actions within its scope.

[0094] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0095] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.< / topic>

Claims

1. A machine-readable self-descriptive indexing method for AI-generated content, characterized in that, Applied to declarative engines, which do not execute new code at runtime and expose a finite set of primitives fixed at compile time, the primitives are registered in corresponding primitive registry entries according to their categories, and the primitive registry entries allow declarative configuration to be scheduled by name; the method includes: The capability index projector traverses the primitive registry, projects the registration information of each registered primitive into a machine-readable index entry, and generates a capability index. The capability index is generated from the same set of primitive registration information during driver runtime, so that the index entries are of the same origin as the primitives scheduled at runtime and are added or deleted synchronously with the addition or deletion of primitive registry entries. In response to a query term entered by a machine reader, if the query term matches a registered primitive, the authoritative details page of the matched registered primitive is rendered first, and the query term is removed from the subsequent matching list. Description-based matching is performed only if the query term does not match any registered primitive. The authoritative details page is the unique and correct description page returned by the capability index projector when the query term matches a registered primitive, containing primitive parameter reduction, disambiguation annotations, and calling examples.

2. The machine-readable self-describing indexing method for AI-generated content according to claim 1, characterized in that, The primitives include actions, conditions, components, value functions, selectors, syntactic primitives, and / or test steps.

3. The machine-readable self-describing indexing method for AI-generated content according to claim 1, characterized in that, The registration information includes primitive name, category, parameter specification, default value, enumeration value, calling method, and brief description; The capability index includes a capability summary that can enumerate all primitives and primitive-specific details that can be retrieved by name; The capability summary lists all the engine's primitives by primitive category, with each primitive rendered as a single line containing the primitive name and a brief description. The primitive details are information pages rendered by the capability index projector from the same set of primitive registration information after any primitive is retrieved by its name. The information page includes at least parameter name, parameter type, default value, enumerated value, disambiguation annotation, and calling example.

4. The machine-readable self-describing indexing method for AI-generated content according to claim 3, characterized in that, The capability index projector traverses the primitive registry, projecting the registration information of each registered primitive into a machine-readable index entry to generate a capability index, including: Enumerate the primitive registry entries and check each registered primitive to see if it appears in the rendering artifacts of the capability index. If any registered primitive does not appear in the capability summary or primitive details, the construction is deemed to have failed.

5. The machine-readable self-describing indexing method for AI-generated content according to claim 3, characterized in that, The capability index projector traverses the primitive registry, projects the registration information of each registered primitive into a machine-readable index entry, and generates a capability index, further including: For parameters in the generative capability index that fall on the ambiguous semantic axis, the primitive details carry explicit disambiguation annotations. The ambiguous semantic axis includes at least: absolute value and relative increment, world coordinates and parent local coordinates, overlay and replacement, effective per frame and effective once, interval boundary included and excluded, and degree and radian. The explicit disambiguation annotation clearly indicates which side of the ambiguous semantic axis the parameter should take; The examples in the primitive details use non-neutral values, so that ambiguity is exposed rather than masked in the examples.

6. The machine-readable self-describing indexing method for AI-generated content according to claim 3, characterized in that, The capability index employs a two-level retrieval method for machine readers: first, the capability summary provides an overview of all primitives, and then the primitive details of individual primitives are retrieved by primitive name to adapt to the contextual lexical budget constraints of large language models.

7. The machine-readable self-describing indexing method for AI-generated content according to claim 6, characterized in that, The carriers of the capability index include: retrieved via product command through command line, pre-generated as a structured data file and distributed with the package, or returned as requested by a service interface for details of a primitive; The generation timing of the capability index includes: traversing various primitive registry entries at runtime and projecting them into an index; generating static index data from registration information during the build phase via compile-time reflection or code; or generating static index data during the build phase and verifying at runtime whether the static index data is consistent with the capability index generated based on the index entries.

8. The machine-readable self-describing indexing method for AI-generated content according to claim 1, characterized in that, If the query term matches a registered primitive, the authoritative details page of the matched registered primitive is rendered first, including: When multiple primitive registry entries are hit, the authoritative details page for each primitive under the primitive registry name is rendered separately. Each authoritative details page is distinguished by a category label, and the multiple identities of the primitive with the same name are presented in a parallel manner.

9. The machine-readable self-describing indexing method for AI-generated content according to claim 1, characterized in that, Also includes: For a given game package or a single configuration file, the report results of the set of primitives used are obtained from the abstract syntax tree parsed by the engine. The report results are then grouped by primitive category, deduplicated, and output. During engine parsing, the same primitive registry is reused at runtime, so that primitives with the same name are not confused due to text matching, and primitives in deep nesting can be discovered by recursive traversal and are not silently missed as the syntax evolves. The report only reports the primitives used, without reporting the specific number of times each primitive's actual quantifier appears. Based on the report results, an inverse index is constructed from the primitives to the documents that use the primitives for use by the knowledge base.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the machine-readable self-descriptive indexing method for AI-based authoring as described in any one of claims 1-9.

Images