Marketing method and system based on AIGC technology

Abstract

The application discloses a marketing method and system based on AIGC technology and relates to the technical field of reinforcement learning; and the technical points are as follows: a pre-sending project benchmark is constructed based on pre-sending project demand and technical state; AIGC marketing content and post-sending demand materials are analyzed, incremental claims and candidate demands are extracted, structure and time verification is performed, source candidate relationships are established, and candidate demands associated with enterprise marketing content are isolated; an implementation condition graph is constructed according to product versions, technical state increments are mapped to implementation paths, and demand verification permissions are generated; verification demands and marketing strategy states are formed according to the permissions, technical claim verification transfer records are generated, action value statistics are updated, statistical contributions are adjusted according to permission states, backflow content repetition reinforcement is blocked, and implemented demands are reserved.

Description

Technical Field

[0001] This invention relates to the field of reinforcement learning technology, specifically to a marketing method and system based on AIGC technology. Background Technology

[0002] With the application of generative artificial intelligence technology in enterprise marketing, marketing systems can combine the client's industry, existing communication records, and product capability information to generate technical solutions for specific projects. Based on subsequent client feedback, marketing content and strategies can be adjusted. In the long-term marketing process of industrial intelligent projects, after receiving the technical solution, clients typically need to complete internal technical verification, project initiation, and procurement document preparation. Some technical content in the marketing solution may be absorbed by the client during this process. For example, an industrial enterprise initially only proposed visual inspection of product defects on the production line. The marketing system's solution further proposed setting up edge inference nodes on the production line side to shorten the image data transmission path. After the client's technical department approved this deployment method, the relevant content was rewritten and included in the project initiation materials. The procurement department then formed bidding technical requirements based on this. When the marketing system collects this requirement again from client communication records or publicly available bidding documents after a period of time, it may identify it as a newly generated client need and thereby increase the selection weight of edge deployment-related marketing content in subsequent marketing strategies.

[0003] Existing marketing systems can evaluate marketing content based on customer feedback, requirement texts, and project results. They can also analyze the correlation between customer needs and historical marketing materials using text matching or content source information. However, technical content circulating internally within a client's organization may undergo wording adjustments, content compression, and contextual restructuring, altering the original text characteristics. Consequently, it's difficult to directly determine whether a specific technical claim originates from previously sent AIGC marketing content. Even if a requirement is confirmed to have a marketing content feedback source, it cannot be continuously excluded. This is because the client may have already allocated edge computing resources, opened image data interfaces, and adjusted on-site network configurations around the technical claim, transforming it from a marketing suggestion into the actual conditions required for project implementation. If the system directly treats the feedback content as the client's original requirement, historical marketing outputs may repeatedly enter the marketing strategy update process. If the system continuously excludes feedback content, it may overlook valid requirements that have already received support from the client's actual technical status. Therefore, it is necessary to address how to identify technical claims formed by AIGC marketing content feedback and determine the conditions for feedback requirements to enter the marketing strategy update process based on the client's project implementation status corresponding to the technical claim. Summary of the Invention

[0004] To achieve the above objectives, the present invention provides the following technical solution: A marketing method based on AIGC technology includes: Obtain the project requirements and technical status before sending AIGC marketing content, and construct a baseline diagram of the project before sending by project identifier, unified technical object identifier and product version; AIGC marketing content is parsed into a marketing proposition map, aligned with project requirements, and incremental propositions are extracted and generated. After receiving the requested materials, parse them into a requirement proposition diagram and align them with the project requirements to extract candidate requirements. Based on the generated incremental claims, a structural signature is formed. Structural matching is performed on the candidate requirements to form a structural source matching value. The source candidate relationship is established by combining the formation time verification result. The candidate requirements associated with the company's AIGC marketing content are written into the isolated requirement state. Implementation condition diagrams are generated by calling product deployment specifications according to product version; Obtain the project technical status change record after sending, extract the status increment relative to the project baseline diagram before sending, map the status increment and the project technical status in the project baseline diagram before sending to the implementation condition diagram to form the project execution status diagram, perform closure verification on the implementation path, and generate requirement verification permission. Based on the requirement verification permission, candidate requirements in the isolated requirement state are converted into verification requirements. Project requirements and verification requirements are encoded into marketing strategy states, and combinations of technical claims that meet product version and dependency constraints are selected as marketing actions. Generate a technology claim verification transfer record with a license identifier, write the independent contribution of the record into the action value statistic, and adjust the independent contribution according to the license status.

[0005] A marketing system based on AIGC technology includes: The project baseline processing module obtains the project requirements and technical status before sending AIGC marketing content, and constructs a project baseline diagram before sending according to the project identifier, unified technical object identifier and product version; it parses the AIGC marketing content into a marketing proposition diagram, aligns it with the project requirements, and extracts and generates incremental propositions. The source identification module acquires the required materials after they are sent, parses them into a requirement claim diagram and aligns them with the project requirements, and extracts candidate requirements. Based on the generated incremental claims, it forms a structural signature, performs structural matching on the candidate requirements, forms a structural source matching value, and establishes a source candidate relationship by combining the formation time verification result. Candidate requirements associated with the company's AIGC marketing content are written into the isolated requirement state. The project technical status verification module calls the product deployment specifications according to the product version to form an implementation condition diagram; it obtains the project technical status change records after sending, extracts the status increment relative to the project baseline diagram before sending, maps the status increment and the project technical status in the project baseline diagram before sending to the implementation condition diagram to form a project execution status diagram, performs closure verification on the implementation path, and generates a requirement verification license. The marketing strategy update module converts candidate requirements in isolated requirement states into verification requirements based on requirement verification permissions, encodes project requirements and verification requirements into marketing strategy states, and selects combinations of technical claims that meet product version and dependency constraints as marketing actions; it generates technical claim verification transfer records with permission identifiers, writes the independent contribution of the records into the action value statistics, and adjusts the independent contribution according to the requirement verification permission state.

[0006] This invention provides a marketing method and system based on AIGC technology, which has the following beneficial effects: 1. This invention uses the project requirement boundary before sending AIGC marketing content as a fixed benchmark, extracts structural signatures from the incremental claims generated by the marketing content relative to this benchmark, and uses technical objects, conditions for establishment, and dependencies to perform source matching on the requirement differences in the customer's subsequent materials; this process does not rely on the literal preservation of the original statement, so that the technical content after rewriting, compression, and context reorganization can still be identified at the technical claim structure level, and separates the requirement differences associated with the company's AIGC marketing content from the customer's independently added requirements.

[0007] 2. This invention does not directly determine the long-term usage status of the return request based on the source matching result. Instead, it constructs an implementation condition diagram based on the corresponding product version and maps the technical status increment formed on the customer's project side to the implementation condition node. Only when the implementation path consisting of resource configuration, interface relationship, operation deployment and data return is closed, a requirement verification license is generated and the isolated requirement is converted into a verification requirement, thereby distinguishing between marketing claims that are only disseminated in materials and technical requirements that have been transformed into actual project implementation conditions.

[0008] 3. This invention binds the impact of verification requirements on the value of marketing actions to the requirement verification license, and writes the technical claim verification transfer record into the action value statistics as an independently removable technical claim verification record; when the license loses project technical status support, the corresponding statistical contribution is removed, and the statistical contribution is restored when the license becomes valid again; thereby cutting off the self-reinforcing link formed by AIGC marketing content being treated as an independent requirement again after being returned by customer materials, while retaining the effective role of returned requirements that have obtained project implementation status support for subsequent marketing strategies. Attached Figure Description

[0009] Figure 1 This is a schematic diagram illustrating the closed-loop principle of the implementation conditions and project execution status of the present invention; Figure 2 This is a schematic diagram illustrating the matching of the return flow requirement structure in this invention; Figure 3 This is a schematic diagram illustrating the implementation path closure and requirement verification license generation of the present invention. Detailed Implementation

[0010] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0011] Please see Figure 1 , Figure 2 and Figure 3 This embodiment provides a marketing method based on AIGC technology, including the following specific steps: The following describes a specific implementation of the present invention using an industrial vision inspection platform marketing project as an example. This implementation takes customer project P-2026-017 as the processing object. The customer project identifier, product version, and unified technical object identifier jointly define the object boundary. The benchmark cutoff point τ1, the first verifiable occurrence time of relevant differences in the requirement materials, the evaluation cutoff point τ3, and the decision cutoff point τ4 jointly define the time boundary. The data objects transmitted from S1 to S4 all store the aforementioned identifiers and version numbers. When the project affiliation, unified technical object identifier, product version, or time boundary cannot be determined, the system outputs the status of benchmark to be completed, source to be confirmed, maintain isolation, or permission to be re-verified, respectively, and stops the corresponding automatic admission processing. The benchmark coverage threshold θ1 only controls the output of the project benchmark map and the generated incremental claim sub-map before sending. The structure source matching threshold θ2 only controls the establishment of source candidate relationships. The execution closure threshold θ3 is fixed at 1 and only controls the generation of requirement verification permission. If any pre-level gate is not satisfied, no compensation is made by other thresholds or subsequent results.

[0012] This implementation takes Company A, the target customer, as an example of building a visual inspection platform for its production line. Before sending marketing content, Company A proposed that industrial cameras collect product images and that the central server complete defect identification. However, it has not yet proposed deploying edge inference nodes on the production line side, nor has it established a project-specific authorization relationship between the image data interface and the edge inference nodes. The marketing system uses an Artificial Intelligence Generated Content (AIGC) model to generate marketing content and proposes to deploy the defect identification model to the edge inference nodes and complete defect identification before the image data is sent back to the central server. Company A subsequently wrote this deployment method into the project requirements and bidding technical requirements. This implementation sequentially generates incremental data through pre-send baseline extraction, forms return candidates through structural source matching, generates requirement verification permission through project technical status closure, and updates the marketing action value with revocable transfer records.

[0013] Company A plans to upgrade one continuous assembly line. In this type of single-line visual inspection scenario, the preferred number of industrial cameras is 2 to 8, with 4 being the most preferred. The preferred image acquisition frame rate for a single camera is 10 to 30 frames per second, with 15 frames per second being the most preferred. The number of cameras is determined based on the number of workstations to be inspected, the field of view coverage, and the obstruction area. The acquisition frame rate is determined based on the conveyor speed, the duration of the minimum defect passing through the imaging area, and the available network bandwidth for the project. In this example, 4 industrial cameras are set up, with a total acquisition load of 60 frames per second, covering 4 inspection angles. The project monitoring system records the image upload completion time and the recognition result generation time, and uses the time difference between the two to represent the transmission and recognition time. This time increases under high load. This working condition is used to determine the resource requirements in the product deployment specifications. The source identification of S2 uses the demand claim structure, and the demand verification of S3 uses the project technical status increment.

[0014] This example unfolds sequentially along the same timeline: AIGC marketing content was sent on March 10, 2026; the initial version of the project requirements document was formed on March 28; the bidding technical requirements were formed on April 10; from April 18 to April 20, the allocation of computing resources for edge inference nodes, authorization of image data interfaces, model writing, and establishment of the production network were completed; and the requirements verification license was formed on April 22. On May 6, planned interface maintenance occurred, triggering a license re-verification. All of the above records are stored in the data field of project P-2026-017, and the subsequent step calls the data objects and versions frozen in the previous step.

[0015] This implementation method uses text segmentation, product master data query, version log reading, graph structure storage, and linear equation system solving to complete technical claim parsing, object normalization, version confirmation, relationship saving, and action value parameter solving. The differentiated processing focuses on continuous tracking of incremental claims, isolation of backflow requirements, closure of project technical status, and updating of revocable strategies.

[0016] The marketing system implementing this method is deployed on one or more servers and includes at least a data access component, a graph structure processing component, a project status verification component, a strategy update component, and a version storage component. The data access component reads requirement materials, project technical status records, product master data, and industry corpus. The graph structure processing component forms a pre-send project baseline graph B1, generates an incremental claim subgraph G1, and a return candidate subgraph R2. The project status verification component forms an implementation condition graph P3, a project execution status graph E3, and a requirement verification permission L3. The strategy update component maintains and verifies the requirement status V4, the effective transfer sample set Y4, the action value sufficient statistical matrix G4, and the action value cumulative vector h4. The version storage component stores customer project identifiers, product versions, time cutoff points, and previous data object versions. Each component can be implemented by a program module on the same server or deployed on multiple servers connected through a controlled interface.

[0017] Customer requirement materials, project technical status records, and feedback records are read only from the project data domain authorized by the target customer or the company. Industry corpora only use materials whose public sources and first publication dates can be verified. The system performs access control according to the customer's project permissions and does not collect personal identification information, biometric information, or private communication content that is unrelated to the project's technical status. Data that exceeds the authorized scope, whose source cannot be verified, or whose purpose is inconsistent with the project will not enter the automatic processing chain from S1 to S4.

[0018] The demand materials and marketing content are first converted into atomic technology claims and their dependencies. Project status records are converted into verifiable equipment, interface, network, and resource statuses. An incremental claim subgraph G1 is generated, representing the nodes, condition differences, and dependency edges that are added or changed in this marketing content relative to the demand before sending. The return candidate subgraph R2 represents the differences in subsequent customer materials that establish a valid source mapping with G1. The demand verification license L3 indicates that the complete implementation path corresponding to R2 has been closed by the incremental project technical status after sending. The technology claim verification transfer record represents the statistical contribution of L3 to the value formation of a specific marketing action, which can be independently added and removed. All of the above objects save the project identifier, product version, and previous version identifier. The date, number of records, and calculation results are the observation values ​​in this example. The preferred range, preferred values, and the basis for the configuration parameters are given separately.

[0019] S1, form the baseline map of the project before sending and extract the incremental claim sub-map; when the marketing system sends the AIGC marketing content, it reads the delivery record from the sending channel. In this example, the marketing content was successfully delivered to the project recipient of Company A for the first time at 9:30 on March 10, 2026. Therefore, this time is determined as the baseline cutoff point τ1 and converted into a millisecond-level timestamp in Coordinated Universal Time and written into the marketing content record. When the sending channel can only confirm the completion of sending but not the delivery, the time of completion of sending is used as the conservative cutoff point and a conservative mark is written in the cutoff point record.

[0020] Each authoritative data source completes clock calibration before accessing the project data domain. The allowable remaining offset between the source system clock and the unified time base is preferably 0 to 5 seconds, with 2 seconds being the preferred value. This range is less than one-tenth of the minute-level record resolution of this project and covers the correction error between delivery receipts and project status logs. In this example, the remaining offset does not exceed 2 seconds. The system reads the status effective time in the immutable audit record and performs the conversion by combining the time zone and the recorded offset. When the known offset exceeds 5 seconds, the status effective time interval is formed by the offset range. Records with only the last modification time, where the actual effective time cannot be determined, or whose time interval spans τ1 are marked as boundary uncertain records and included in the unparsed record statistics.

[0021] After the baseline cutoff point is determined, the system reads the synchronization levels of the requirement formation data source, the technical status confirmation data source, and the product version confirmation data source. The requirement formation data source is used to provide confirmed requirement materials and their project affiliation. The technical status confirmation data source is used to provide the effective status of interfaces, equipment, networks, and computing resources at the baseline cutoff point. The product version confirmation data source is used to provide component entities and applicable version ranges. In this example, the three roles are respectively undertaken by the customer requirement management system, the project technical status management system, and the product master data system. Each role is assigned only one authoritative data source. Other email archives or manual notes are only used as auxiliary information and do not independently increase the weight of the data source.

[0022] Before τ1, the customer requirement management system in this example returned 42 records awaiting benchmarking, the project technical status management system returned 67 status events, and the product master data system returned 28 object and version records. Of the 42 requirement records, one lacked a resolvable product version. The record completeness of the requirement data source was 41 divided by 42, which equals 0.976. Of the 67 status events, 3 could not form a complete status interval. The time interval consistency of the technical status data source was 64 divided by 67, which equals 0.955. All 28 product master data records could identify the object and version, corresponding to a completeness of 1. The above comparisons... For example, the system directly enters the synchronization validity calculation of the corresponding data source without setting a separate individual experience threshold. Before outputting the incremental claim subgraph, the system also performs a key object review on the unparsed records: comparing the object words, action words, and project areas already identified in the unparsed records with the unified technical object identifier and processing action to be output for generating incremental claims; if there is a possibility of association, the generated incremental claims involving that object will not be output. In this example, the record lacking the product version belongs to the equipment maintenance notice, and its object words and action words do not involve edge inference nodes, image data interfaces, or defect recognition models, so the generation of incremental output in this example is not blocked.

[0023] The system limits record affiliation based on the customer project identifier. In this example, the target customer project identifier is P-2026-017. If a record only has the name of Company A or the contact person's email address but lacks P-2026-017, it will not be directly merged into the target customer project. Only if the project relationship record can prove that a sub-project was derived from P-2026-017 and that the relevant technical objects and product versions are consistent, will the record be allowed to be included in the target customer project. This eliminates the interference of equipment with the same name or similar requirements in other production line projects of Company A on this benchmark.

[0024] The product master data system establishes a unified technical object identifier for each technical object. This identifier is composed of the product series, component entity, and applicable version range. In this example, the visual inspection platform version is V3.2. The central server inference component, edge inference node, image data interface, and defect recognition model each have independent component entity identifiers. Cross-version mapping is only allowed when the product master data confirms that the component identity is maintained, the interface semantics are continuous, and the processing functions have not been migrated between different versions. If the local inference component in the old version is split into the edge execution component and the central scheduling component in the new version, a new unified technical object identifier will be established for each, and they will not be merged again on the grounds of similar names.

[0025] The system acquires the required materials whose status takes effect no later than τ1, and forms atomic technology claims according to fixed parsing rules. Specifically, it first divides candidate statements by periods, semicolons, and explicit parallel, conditional, or temporal connectors such as "and," "when," "if," "before," and "after." Then, it determines the technology objects from the product object dictionary frozen with product version V3.2, and determines the processing actions from the controlled action dictionary frozen with this product version. It also breaks down comparison relations, negation relations, value ranges, and temporal constraints into atomic conditional predicates. When a candidate statement contains multiple processing actions, it is broken down into multiple nodes according to the processing actions. Pronouns have multiple possible pointers, and object words cannot be uniquely mapped or processed. When an action corresponds to multiple action categories, the statement is marked as an unparsed statement and will not be included in the automatic graph alignment. Dependency edges are established only based on textual relationships that can uniquely determine the direction, such as "before", "after", and "only if". Each atomic technology claim expresses only one technical object performing one processing action. The conditions for establishment and product version are used as node attributes. Taking Company A's pre-send requirements as an example, the system forms atomic technology claims such as "industrial camera acquires product images", "central server receives image data", and "central server performs defect identification". Directed dependency edges indicate that image acquisition precedes central server reception, and defect identification can only be performed after central server reception. The above nodes and dependency edges form the requirement layer D1.

[0026] The system further reconstructs a snapshot of the project's technical status at time τ1. For records that only provide state change events, the effective time of the current state change is used as the start of the interval, and the time when the state is replaced by the next state is used as the end of the interval. In this example, Company A already has a central server, industrial cameras, and image transmission relationships from cameras to the central server at time τ1, but the edge inference nodes have not yet been allocated project-available resources, and the image data interface has not granted project-specific access permissions to the edge inference nodes. The above states form the technical status layer T1. If the same unified technical object has mutually exclusive states at time τ1, the object is marked as a baseline conflict object, and the generation of incremental output involving the object is prohibited.

[0027] Specifically, regarding the on-site objects, the technical status layer T1 records that all four industrial cameras are bound to the central server, the central server has deployed the defect identification model V3.2, and the production network allows the cameras to upload images to the central server. At the same time, it records that although there are two shared computing nodes in the edge device resource pool, their project binding fields are empty, their available computing quota is 0, and the authorized object of the image data interface is only the central server. This can distinguish between "the enterprise already has edge devices" and "the target project has formed an edge deployment relationship", avoiding the subsequent assumption that the marketing content already has the same technical status before it is sent simply because there are devices in the shared resource pool.

[0028] The demand layer D1 and the technical status layer T1 establish a cross-layer association based on a unified technical object identifier, forming a pre-send project baseline diagram B1. The demand layer is used to represent the technical requirements that Company A has expressed before receiving this marketing content, and the technical status layer is used to represent the actual technical status of the project at that moment. The purpose of using both together is that S2 excludes existing customer requirements based on the demand layer, and S3 excludes equipment configurations and resource relationships that already exist before the marketing content is sent based on the technical status layer, thereby avoiding the use of different baselines for source identification and implementation verification.

[0029] Subsequently, the system uses the same product object dictionary, controlled action dictionary, conditional predicate splitting rules, and dependency direction identification rules as when forming the demand layer D1 to parse the AIGC marketing content, forming the marketing proposition graph M1. The marketing content "deploy the defect identification model to the edge inference node on the production line side and complete the defect identification before the image data is sent back to the central server" is split into atomic technical propositions and dependency edges: the edge inference node carries the defect identification model, the image data interface provides image data to the edge inference node, the edge inference node performs defect identification, and the identification result is sent back to the central server. Effect statements that only state "improving real-time performance" without giving technical objects, processing actions, and conditions for their validity are not formed into technical proposition nodes. When the internal reference cannot be uniquely recovered, the corresponding statement is marked as an unparsed statement. Conditions not explicitly stated in the marketing content in the product deployment specification are not added to the marketing proposition graph, but are called when the implementation condition graph is built in S3.

[0030] The marketing proposition graph M1 and the demand layer D1 are aligned with the one-to-one constraint graph. The system first generates candidate node mappings that satisfy the conditions of consistent object identification or continuous component identity, the same type of processing action, and product version compatibility. For each candidate mapping, the number of one-to-one node mappings, the number of dependency edges that maintain endpoint correspondence and consistent direction, the number of conditional predicates that maintain logical equivalence, and the number of dependency edges with reversed direction are compared in turn. The larger value is selected first in the above order, and the smaller value is selected last. This lexicographical comparison does not introduce empirical weights, and the content with the same processing action but a changed dependency direction is retained as the generated increment.

[0031] The incremental claim subgraph G1 is generated based on the optimal node mapping. Technical claim nodes that cannot be mapped are directly entered into G1. Condition additions, deletions, changes in negation relationships, or changes in value ranges between mapped nodes are entered into G1 as condition difference attributes. Dependency edges that do not exist between existing customer nodes but are added, deleted, or have changed direction in marketing content are also entered into G1. In this example, the industrial camera, central server, and defect identification action already exist in the demand layer, but the edge inference node carrying the defect identification model, the image data interface pointing to the edge inference node, and the dependency relationship that the edge inference node sends the identification result to the central server after completing the defect identification are all new content. Therefore, they together form the incremental claim subgraph G1.

[0032] In this example, the generated incremental claim subgraph G1 after freezing consists of 3 newly added technical claim nodes, 2 sets of conditional differences, and 2 newly added dependency edges. The 3 nodes represent the edge inference node carrying the defect identification model, the edge inference node performing defect identification, and the edge identification result being sent back to the central server. The 2 sets of conditional differences respectively limit the image data to enter the edge inference node before being sent back to the central server and the model version used to be compatible with the visual inspection platform V3.2. After atomization, the 2 sets of conditional expressions contain a total of 10 atomic conditional predicates, corresponding to data objects, interface subjects, target nodes, processing order, model components, version ranges, and interface compatibility relationships, respectively. The 2 dependency edges respectively indicate that the image data interface first provides image data to the edge inference node, and then sends the result to the central server after the edge identification is completed. This boundary is directly used in the structural signature of S2, the incremental coverage of S3, and the verification reward denominator of S4, and will not be expanded or reduced again in subsequent steps.

[0033] Before outputting G1, the system calculates the baseline coverage of the project baseline map before sending. For each authoritative data source, the synchronization completion value, record ownership completeness, and time interval consistency are determined first. The synchronization completion value is 1 when the data source synchronization level covers τ1, otherwise it is 0. The record ownership completeness is the proportion of records to be included that can be identified by customer project identifier, unified technical object identifier, and product version. The time interval consistency is the proportion of records to be included that do not have status interval conflicts and whose effective time can be determined. When the authoritative data source clearly returns 0 records and the synchronization level has covered τ1, both the record ownership completeness and the time interval consistency are 1, and the zero record source response identifier is retained. The synchronization validity of this data source is the lowest value among the three items, so that no gap can be compensated by other items.

[0034] In this example, the synchronization validity of the customer demand management system is 0.976, the synchronization validity of the project technical status management system is 0.955, and the synchronization validity of the product master data system is 1. Each of the three authoritative roles is undertaken by one data source, so the weight of each data source is one-third. All necessary data sources have been synchronized, and the synchronization threshold value of the necessary data sources is 1. The baseline coverage is calculated by the weighted product of the three synchronization validitys, that is, by taking one-third powers of each and then multiplying them together, resulting in 0.977.

[0035] The effective threshold θ1 for baseline coverage is defined according to historical project sending events. All nodes and dependent edges in the same customer project are considered as one sample. The candidate threshold formation set and independent validation set are divided according to customer projects. A false incremental project refers to a project whose original output incremental is completely covered by the pre-sending requirement or pre-sending technical status after a complete late record with an effective time no later than the corresponding baseline cutoff point is subsequently obtained. For each candidate threshold, a one-sided exact confidence upper bound of the proportion of false incremental projects in the independent validation set is calculated, and the lowest coverage not exceeding the allowed false incremental rate p1 is selected. In this example... With θ1 set to 0.95, p1 to 0.05, and confidence level at 95%, the calculated baseline coverage C1 is 0.977. Since the generated increments do not involve baseline conflict objects or records with uncertain boundaries, outputs B1 and G1 are used. When p1 is 0.05 and confidence level is 95%, this statistical result is adopted only if no false generated increments are found in the independent validation set and the number of independent validation projects is not less than 59. When the number of projects is insufficient, a hard-gating output rule is adopted, where all necessary data sources are synchronized, all records to be included can be identified with project affiliation and unified technical object identification, and there are no conflicts.

[0036] The effective threshold θ1 for baseline coverage is preferably 0.90 to 0.98, with a preferred value of 0.95; the allowable false increment rate p1 is preferably 0.02 to 0.08, with a preferred value of 0.05; the confidence level is preferably 90% to 99%, with a preferred value of 95%. The above ranges are determined based on the correspondence between baseline gaps and false generated increments in historical independent customer projects: the lower limit of θ1 is used to exclude baselines with obvious data gaps, and the upper limit is to reserve output space for a small number of traceable missing data that does not affect the generated increment objects; p1 is determined based on the number of acceptable erroneous candidate items in a single batch; the 95% confidence level is used to achieve a balance between the reliability of the upper bound of errors and the number of available historical samples. In this example, θ1, p1, confidence level, and sample version are written into the configuration together, and the above parameters are not changed during model operation based on the results of this project.

[0037] Before sending, the project baseline diagram B1 is output and then frozen as B1-V01. When a late record with an effective time no later than τ1 is received, the system generates a new baseline version and sets the generated incremental claim subgraph, source candidate relationship and requirement verification result that reference B1-V01 to invalid. Then it is reprocessed according to the new version.

[0038] Table 1, S1 core objects and degradation handling: S2 reads B1, D1, G1, τ1 and their version identifiers, and only processes requirement materials with project identifier P-2026-017 or with a clear sub-project relationship. The project requirement document was created by the customer requirement management system on March 28, 2026, and the first immutable content version was generated. There is no earlier version in the version chain, and the requirement layer D1 before sending does not contain the corresponding edge reasoning difference. Therefore, March 28 is determined as the first verifiable occurrence time of this set of requirement differences in the customer project system. This time is later than τ1, and the time priority value is 1. This value only indicates that the existing time evidence does not deny the dissemination after sending, and is not used to confirm the actual drafting time of the offline draft or the sole source of dissemination. The tender technical requirements formed on April 10, 2026 only have the original document signature and the first import record. This record is used to prove that the corresponding content already existed on that day and serves as subsequent corroboration. It is not used alone to establish the time priority value. For materials with only the import time, without a continuous version chain or a comparison version before sending, the system outputs a source pending confirmation status and prohibits the corresponding differences from entering the long-term marketing strategy update.

[0039] The system converts the requirement materials into a customer requirement claim diagram C2 according to the atomic technology claim granularity of S1. The "configure an edge inference node on the production line side, deploy the defect identification model to the node, and complete defect inference before uploading image data to the central server" in the project requirement book forms three technology claim nodes: edge inference node configuration, defect identification model deployment, and edge defect inference. The authorization relationship of the image data interface to the edge inference node and the order of performing edge defect inference first and then sending the identification results to the central server are saved as condition differences and dependency edges, respectively. Nodes whose unified technical object identifier cannot be determined are retained as path blocking nodes, and their preceding and following dependency edges are not merged across nodes.

[0040] Customer demand claim graph C2 and demand layer D1 use the same constraint graph alignment method as S1. Technical claim nodes, conditional differences, and dependency edges not covered by the demand layer are identified as demand difference elements. Demand difference elements that are interconnected and belong to the same clearly defined project area form candidate demand subgraph H2. Nodes directly adjacent to existing demands are retained as boundary anchors. In this example, industrial cameras and central servers are used as boundary anchors. Edge inference node configuration, defect identification model deployment, edge inference node execution of defect identification, and the conditions and dependencies of image data interface pointing to edge inference nodes and edge inference prior to result feedback form candidate demand subgraphs.

[0041] To determine whether the candidate demand subgraphs form a source candidate relationship with the AIGC marketing content, the system freezes the industry corpus A2 before sending. The scope of the corpus is determined based on the visual inspection platform product series and the corresponding superior function categories for edge inference, image data interfaces, and defect recognition. The superior function categories are taken from the product function classification table frozen together with product version V3.2. A2 only includes industry documents whose first publication time is earlier than τ1 and can be converted into a technical claim diagram according to the S1 rule. The first publication time is determined by the first version release record in the public database, the version log of the release platform, or a verifiable webpage archive snapshot. A digital signature can only prove that a document existed at the time of signing, and cannot prove that it has been publicly disclosed. Documents with only the current page update time but without confirming the first release time are not included in A2. Product information that the company has disclosed before τ1 is also included in the corpus to prevent the company's original public expression from being identified as the exclusive source of the current marketing content. Reprinted documents form a structural fingerprint according to the standardized technical claim diagram. The structural fingerprint is generated by the superior function category, processing action, condition variable, dependency edge endpoint, and dependency direction arranged in a fixed order. Reprints with the same structural fingerprint under the same initial public disclosure source are counted as only one copy.

[0042] After deduplication, this example yields 680 industry documents. The system compresses the strongly connected components in the generated incremental claim subgraph, retaining the cyclic call relationship as a composite structure node. Then, it extracts the shortest dependency path to the nearest boundary anchor point for each generated incremental element. Initial structural units with overlapping incremental elements are merged, ensuring that each incremental node, condition difference, and dependency edge enters only one structural signature. If a generated incremental connected component cannot be connected to any pre-send requirement boundary anchor point, the source candidate relationship is not automatically established based on the isolated structure; instead, the component is marked as a source pending confirmation. In this example, all incremental elements can be connected to the boundary anchor point of the industrial camera or the central server, thus forming two structural signatures. The first signature represents the directional combination between the image data interface, the edge inference node, and the defect identification action. The second signature represents the dependency relationship where the edge inference node sends the identification result to the central server after completing defect identification.

[0043] The version of the industry corpus before sending is determined through incremental stability verification. The number of deduplicated industry documents during the first verification is preferably 400 to 600, with 480 being the preferred option. Each new inspection batch is preferably 50 to 150 documents, with 100 being the preferred option. The allowable variation in the source indication strength of the structural signature per batch is preferably 0.005 to 0.02, with 0.01 being the preferred option. It is required that two consecutive inspection batches meet this variation. As a calculation example, when the number of documents increases from 480 to 580 and then to 680, the variation in the source indication strength of the two structural signatures does not exceed 0.01. Therefore, the corpus version containing 680 deduplicated documents is frozen. For other product areas, the corresponding scale and batches are re-determined based on the stability of the source indication strength as the number of deduplicated documents increases.

[0044] When calculating the frequency of occurrences in the industry, product-specific object identifiers are converted into higher-level functional categories to avoid the impact of different component naming conventions used by different manufacturers on the count of structural occurrences. Industry documents are only counted as containing the corresponding structural signature if a one-to-one node mapping can be established, the processing action categories are consistent, the product function categories correspond, the condition variables are comparable, and the dependency on edge endpoints and directions is maintained. If only the same keyword appears without maintaining the aforementioned structural relationship, it is not counted in the occurrence count. The first structural signature appears 4 times in 680 documents, and the second structural signature appears 18 times. The source indication strength of each structural signature is determined according to the following textual logic: first, the total number of documents plus 1 is divided by the number of documents containing the signature plus 1, then the natural logarithm of the resulting ratio is taken, and finally divided by the natural logarithm of the total number of documents plus 1. When the structural signature does not appear in the corpus, the source indication strength is 1; when the structural signature appears in the entire corpus, the source indication strength is 0.

[0045] According to the above calculations, the source indication strength of the first structural signature is 0.753, and the second structural signature is 0.549. These are used to indicate the distinguishability of the corresponding structure in the industry corpus before sending. When the industry corpus before sending is empty or the sum of the source indication strengths is 0, the candidate demand subgraph enters the source pending confirmation state.

[0046] A one-to-one structural mapping is established between the candidate demand subgraph and the generated incremental claim subgraph. For each structural signature, the system calculates the node retention ratio, the dependency edge retention ratio, and the condition retention ratio, and takes the lowest value among the three as the structural retention degree. Condition retention requires that the object of action and the condition variable are the same and can be determined as logical equivalence, condition narrowing, condition relaxation, or condition deletion. If the condition variables are different or logically mutually exclusive, they are not counted as retention. After adopting the lowest ratio, structures with the same name of a single technical object but inconsistent key conditions cannot obtain the complete structural retention degree.

[0047] The system also calculates the proportion of differential nodes, differential dependency edges, and conditional differences in the candidate demand subgraphs that are explained by the generated incremental claims, and takes the lowest value among the three as the candidate explanatory power X2. This minimum value is used to limit the high matching results when only a few fragments of the candidate demand subgraph are the same as the marketing content and the source of the remaining differential content is unknown.

[0048] The structural source matching value M2 is calculated in the following order: first, the source indication strength of each structural signature is multiplied by the corresponding structural retention degree; then, the products are added together and divided by the sum of the source indication strengths; finally, it is multiplied by the candidate interpretability. In this example, the nodes, dependencies, and conditional predicates of the first structural signature are all fully retained, so the structural retention degree is 1. The second structural signature contains 10 atomic conditional predicates, and 9 of them in the customer material can be identified as logically equivalent, conditionally narrowed, conditionally relaxed, or conditionally deleted. The condition retention ratio is 9 divided by 10, which is 0.9. Since the nodes and dependencies are also fully retained, the structural retention degree of the second structural signature is 0.9, and the candidate interpretability is 1. The calculated M2 is 0.958. This calculation increases the contribution of low-frequency structures in the industry that are fully retained in the customer material to the matching results, and the candidate interpretability limits the demand differences that are not explained by the generated incremental claims.

[0049] The structural source matching threshold θ2 is defined by positive samples with verifiable import records, explicit citation markers, or continuous version chains, and negative samples whose formation time is clearly earlier than the corresponding marketing content or have other verifiable source chains. Training and validation data are grouped simultaneously according to customer organization and marketing template version to ensure that the same customer organization and the same template version do not cross the candidate threshold formation set and independent validation set. For each candidate threshold, a one-sided exact confidence upper bound of the proportion of false passes for independent validation negative samples is calculated, and the lowest candidate value whose upper bound is not higher than the allowable error isolation item proportion p2 is selected. Simultaneously, it is confirmed that the independent validation positive samples have undergone reasonable compression or conditional compression. Narrow source samples were not completely excluded. In this example, θ2 is configured as 0.92, p2 as 0.05, and confidence level as 95%. The structural source matching value M2 of the candidate demand subgraph is 0.958, which reaches θ2. Moreover, the first verifiable occurrence of the relevant difference is later than τ1. Therefore, a source candidate relationship is established. If p2 is 0.05 and confidence level is 95%, the statistical result is adopted only if no false passes occur in the independently verified negative samples and the number of independently verified negative samples is not less than 59. When the number of samples is insufficient, a source candidate relationship is established only when the industry corpus is not empty, M2 equals 1, there is no conflict in the conditions, and the relevant difference has evidence of consecutive versions after sending.

[0050] The structure source matching threshold θ2 is preferably 0.88 to 0.96, with 0.92 being the most preferred; the allowable error isolation project ratio p2 is preferably 0.02 to 0.08, with 0.05 being the most preferred; the confidence level is preferably 90% to 99%, with 95% being the most preferred. The range of θ2 is determined by the distribution of structure source matching values ​​of positive and negative samples. The lower limit is used to exclude candidate requirements that only maintain local industry-wide common structures, while the upper limit prevents real backflow structures that have been reasonably compressed or narrowed from losing all subsequent verification opportunities due to incompatibility. p2 is determined based on the number of customer projects allowed for error isolation in a single batch. The confidence level is used to control the upper bound of the negative sample error passing ratio. In this example, θ2, p2, confidence level, and sample version are written into the configuration together, and θ2 is not changed in reverse by the subsequent results of this project during system operation.

[0051] The system extracts the largest connectivity difference part that participates in the effective structure mapping from the candidate demand subgraph and forms the backflow candidate subgraph R2. Customer independent demands that do not participate in the effective mapping do not enter R2. In this example, the backflow candidate subgraph includes the edge inference node configuration, defect identification model deployment, image data interface pointing to the edge inference node, and the dependency relationship of sending the identification result to the central server after the edge inference is completed. If the subgraph matches the company's current marketing content, the company's historical white paper, and external supplier information, then all source candidate relationships that reach the source threshold are written into the source candidate set Ω2, without forcibly identifying a unique source.

[0052] The same project requirements document also records the requirement to "add a mobile statistics dashboard". This requirement did not exist in the requirements layer before it was sent. However, it could not establish an effective structural mapping with the edge inference node, image data interface, defect identification action and dependency path in G1. Therefore, it was not included in R2 and was retained as an independent new requirement of Company A. This comparison shows that the isolation scope is determined by the difference in the effective structural mapping, and is not isolated as a whole according to the entire requirements document.

[0053] The source candidate set Ω2 contains the generated incremental claim subgraph formed by the company's AIGC marketing content. Therefore, R2 is written into the isolated demand state I2. I2 retains R2 and its source candidate relationship for S3 verification and suspends R2 as a customer native demand for long-term marketing strategy updates. When the industry corpus is empty, the first verifiable occurrence time is uncertain, the object mapping is ambiguous, or the structural source matching calculation cannot be completed, the corresponding demand difference enters the source pending confirmation state and adopts the same long-term strategy update blocking rule as I2. Only when the input evidence is complete and the company's historical marketing content has not reached θ2 will the corresponding difference be retained as a customer's independent new demand candidate.

[0054] Table 2, S2 Source Identification and Isolation Access: S3 uses the return candidate subgraph R2 in the isolated demand state as the only verification object, reads the generated incremental claim subgraph G1 associated with the source candidate set Ω2, and calls the S1 technical state layer T1. When multiple source candidates are mapped to the same demand difference element, only the mappings with consistent technical objects, processing actions, establishment conditions and dependencies are merged. Complementary fragments in different marketing content are not spliced ​​into new verification objects, thus forming the verification object graph V3.

[0055] The system retrieves the valid product deployment specifications at the baseline cutoff point τ1 according to the product version V3.2 in the verification object diagram, and selects the implementation template of the edge inference function in the production environment. Subsequent versions are only used as compatible templates when the product master data confirmation function is continuous, the interface semantics have not changed, and Company A's project has completed version migration. When the template version or deployment environment cannot be uniquely determined, R2 maintains the isolation requirement status and is marked as a template pending confirmation.

[0056] Each indivisible necessary state in the implementation template forms an implementation condition node. In this example, the edge inference function requires the target project to obtain the edge inference node computing resource quota, the image data interface to grant input image access permissions to the corresponding edge inference node, the defect identification model to be actually written into the edge inference node and associated with the running process, the edge inference node and the image acquisition device to form an available production network relationship, the edge inference node to send the identification results to the central server to establish a project-specific backhaul route, and the central server interface log confirms that at least one production identification result carrying the project identifier, source node identifier, model version, camera identifier and result message type has been received for each authorized camera. The six states form nodes respectively, and the common necessary conditions are connected by conjunction. When the deployment specification clearly states that integrated edge devices or general computing nodes are alternative implementation methods, they form alternative implementation paths within the same template respectively, and different versions or test environment conditions are not mixed into the production environment path.

[0057] Based on Company A's acquisition load of 4 cameras at 15 frames per second, Product Deployment Specification V3.2 stipulates that the available computing power for the edge inference path should be no less than 8 TOPS, where TOPS represents trillions of operations per second; the running memory should be no less than 16GB; the available storage space should be no less than 100GB; and an input image interface authorization and recognition result feedback route should be established for the 4 cameras within the project scope. Resource accounting uses the model compilation report and runtime tracking record corresponding to the model version, input resolution, and compilation configuration of this project. In this example, the upper bound of the single-frame preprocessing and defect inference computation is taken as 85 GOP, where GOP is the maximum computational cost. OP represents one billion operations, and 60 frames / second corresponds to approximately 5.1 TOPS. The optimal ratio of scheduling, concurrency, and peak margin is 30% to 70%, and in this example, it is 50%, which yields a minimum computing capacity of 7.65 TOPS, rounded up to 8 TOPS. The upper limit of model and runtime resident memory is approximately 10GB, the upper limit of 4-way image cache and preprocessing buffer is approximately 4GB, and after adding the operating system reserved space, a minimum memory of 16GB is formed. The upper limit of storage occupied by project deployment package, rollback package, log retention period, and storage calculated according to project sampling caching strategy is approximately 88GB, which is rounded up to form a minimum storage space of 100GB.

[0058] When determining the upper limit of computational load or memory through operational trials, it is preferable to conduct no fewer than three full-load tests, each lasting no less than 30 minutes, and record the maximum result. The upper limit of storage usage is determined by adding the deployment package, rollback package, log retention period, and sampling caching strategy item by item. The minimum configuration is used to determine whether the implementation path has an executable basis. After meeting the minimum configuration, the preferred configuration range for the project's computing power in a 4-way concurrent scenario is 12 TOPS to 24 TOPS, with 16 TOPS being the preferred option; the preferred configuration range for running memory is 24GB to 64GB, with 32GB being the preferred option; and the preferred configuration range for available project storage space is 150GB to 500GB, with 200GB being the preferred option. The preferred range is used to cover the margin required for model upgrades, short-term load increases, and rollback operations. This project actually allocated 16 TOPS of computing power, 32GB of running memory, and 200GB of project storage quota, all of which meet the implementation template requirements. The above resource status is only used to determine whether the implementation conditions are met and does not directly form marketing strategy rewards.

[0059] The necessary conditions in the implementation template are marked with observability and authoritative state sources. Resource quotas are confirmed by resource management records. Input image interface authorization, recognition result feedback routing, and recognition result receiving logs are confirmed by interface management records. Model writing and running process associations are confirmed by device or configuration management records. Production network relationships are confirmed by network status records. Authoritative source records must include at least the project identifier, device instance or interface subject, state variable, state value, effective range, and product version. Model writing records also include the model version and file checksum. Feedback routing and receiving logs also include the source node, target server, and result message type. Necessary conditions that cannot be confirmed by existing project technical status records are retained in the implementation condition diagram, and the corresponding paths are marked as pending manual review. Manual review conclusions cannot directly generate requirement verification licenses. Only after the review results are converted into authoritative technical status records with project, object, version, effective range, and immutable source identifiers will they re-enter automatic closed-loop calculation. The above implementation conditions and dependencies form the implementation condition diagram P3.

[0060] Comparing the implementation condition diagram with the S1 technical state layer T1, in this example, the central server, industrial cameras, and the original image upload relationship from the cameras to the central server already existed at τ1, which are baseline support conditions. The edge inference node computing resource quota, the authorization of the input image interface to the edge inference node, the association between model writing and running processes, the production network relationship from the cameras to the edge inference nodes, the route for the backhaul of recognition results from the edge inference nodes to the central server, and the log records of the central server receiving project-specific recognition results did not exist at τ1, which are incremental verification conditions. The baseline support conditions are used to confirm the original technical foundation of the project and are not used as evidence that the AIGC's new claims have been adopted by the project.

[0061] The system reads the synchronization level from the authoritative technical status data source required by the implementation condition diagram. The evaluation cutoff point τ3 is taken as the earliest time among the synchronization levels of all necessary data sources. In this example, the resource management, interface management, configuration management and network status data sources have all been synchronized to April 22, 2026. The earliest synchronization level is 17:52. Therefore, τ3 is taken at this time. Using the earliest synchronization level can prevent inconsistencies in the progress of different data sources from forming an incomplete project status snapshot.

[0062] The system acquires the project's technical status change records from τ1 to τ3, and reconstructs the project status at τ3 based on the effective period of the status. Company A allocates one edge inference node and corresponding computing resource quota for project P-2026-017 at 10:00 AM on April 18, 2026. At 9:20 AM on April 19, it grants the node access to the input image interface. At 2:30 PM on April 20, it writes the defect identification model V3.2 to the node and associates it with the running process. At 3:20 PM on April 20, it establishes a production network communication gateway between the industrial camera and the node. The system activated the identification result backhaul route from this node to the central server at 15:40 on April 20th. Before 16:10 on April 20th, the central server interface log recorded the first project-specific production identification result message from each of the four authorized cameras. Each record has a project identifier, unified technical object identifier, product version, status before and after the change, effective time interval, and immutable source record identifier. The latest formed and continuously maintained status is the identification result backhaul route. From its effective date to τ3, it has been continuously effective for 50 hours and 12 minutes, meeting the 24-hour retention requirement described later.

[0063] Shared resources only constitute a project technical state increment when both a project binding relationship and an executable scope are formed simultaneously. In this example, the edge inference node not only adds a project tag but also forms a project available computing quota; the image data interface authorization is limited to the camera data object corresponding to P-2026-017; the model writing and running process records point to the same edge inference node instance; the recognition result receiving log carries the same project identifier, source node identifier, model version, and camera identifier, and does not include a test environment tag. Therefore, the above states are all project technical state increments after sending. If the resource ledger only adds the project name without allocating an executable quota, or if the return route exists but the central server does not form a corresponding result receiving record, then it does not constitute the corresponding increment verification condition support.

[0064] The incremental technical status of the project and the continuously valid baseline support status are mapped to the implementation condition diagram according to the customer project identifier, unified technical object identifier, status variables, and product version, forming the project execution status diagram E3. The status support value of each implementation condition node is obtained by multiplying five binary gating values. The record authenticity gating requires that the record comes from the authoritative source specified by the implementation template, the source record has not been revoked, the status before and after the change is complete, and there is no conflict at τ3. The object version gating requires that the project identifier is consistent, the object is the same or belongs to the alternative components specified by the template and the version is compatible. The status predicate gating requires that the applied object, status variable, comparison relationship, and target value are all satisfied. The time retention gating requires that the status reaches the minimum retention time specified by the deployment specification, or is still valid at τ3 if the specification does not specify it. The status increment gating requires that the incremental verification condition is supported by the incremental project status formed after τ1, and the baseline support condition is continuously valid from τ1. If any gating is 0, the support value of that node is 0. The above five gatings are calculated for each of the six implementation condition nodes, and the high reliability record of one node is not used to compensate for the lack of another node.

[0065] The deployment specifications in this example require that resource quotas, input image interface authorization, production network relationships, and recognition result backhaul routes reach the specified continuous effective time. The model writing and running process association must still be effective at the evaluation cutoff point. The production recognition result reception logs of the four authorized cameras all occur after the model writing, input authorization, production network, and backhaul routes take effect. At the evaluation cutoff point τ3, all six states meet the corresponding requirements, and the source, project identifier, technical object, and product version are consistent. Therefore, the state support value of the corresponding implementation condition node is 1. This binary gating does not allow temporary states with insufficient holding time to participate in path closure proportionally.

[0066] The minimum retention time for resource quotas, input image interface authorization, production network relationships, and recognition result feedback routes is preferably 12 to 48 hours, with 24 hours being the preferred option. In this example, production operation records are based on a 12-hour production scheduling cycle. The lower limit is used to cover at least one complete production scheduling cycle and the synchronization process of necessary data sources. The upper limit is used to avoid prolonged blocking of requirement verification after the project status has stabilized. In this example, 24 hours is used to exclude short-term states formed only for demonstration or joint debugging. The synchronization cycle for resource management, interface management, configuration management, and network status data sources is preferably 2 to 6 hours. In this example, the maximum synchronization cycle among the necessary data sources is 4 hours. The 24-hour retention period covers 6 maximum synchronization cycles. Other product versions or deployment environments read the retention time in their corresponding deployment specifications and redetermine it based on the production cycle, the maximum synchronization cycle of necessary data sources, and the status revocation record. The values ​​in this example are not directly used. The model write record includes the device instance, model version, and file checksum, and a revocation event is generated when the model is unloaded. If the product deployment specification does not set an independent retention period for model write, the system requires that the model write record and the running process record point to the same device instance, and that the file checksum has not changed in the most recent maximum synchronization cycle before the evaluation cutoff point, in order to determine that the model write condition is valid.

[0067] The system forms a set of feasible implementation paths Π3 based on the conjunction and substitution relationships in the implementation condition graph. Each path contains only the conditions of the same template version and the same production environment. The implementation template explicitly marks the order of edge validation for time-dependent dependencies. In this example, resource quotas should be written before the model, interface authorization and network establishment can be completed in parallel, and the upper bound of the effective interval of the preceding state should not be later than the lower bound of the effective interval of the subsequent state, or the two have the same indivisible configuration transaction identifier. The time-dependent dependency is established when the configuration transaction identifier is generated by the configuration management system in the same atomic commit and is written to all state records involved in the commit at the same time. If the identifier is missing, the record time approximation is not used to replace transaction consistency. States not marked as time-dependent by the template only need to be valid together in τ3.

[0068] Each implementation path should also cover all requirement difference elements in the backflow candidate subgraph. Edge inference node configuration is supported by resource quotas and device instances. Defect identification model deployment is supported by model writing and running process association records. The image data interface pointing to the edge inference node is supported by the input image interface authorization and the production network relationship from the camera to the edge inference node. The dependency relationship of sending the identification result to the central server after the edge inference is completed is supported by the model execution location, the identification result backhaul route, and the central server's production result reception logs for the four authorized cameras. When all difference elements have obtained post-send status support, the incremental coverage threshold value is 1. If there is only input image interface authorization but no writing and running of the model, or no identification result reception logs, the incremental coverage threshold value is 0, and a license cannot be generated for the entire backflow candidate subgraph.

[0069] The implementation path closure is determined by the lowest value among template environment consistency gating, incremental coverage gating, path sequence gating, and all implementation condition node support values ​​within the path. Since these values ​​are all 0 or 1, the path closure will be 0 if any necessary condition is missing.

[0070] The execution closure of the reflow candidate subgraph is the maximum value of the closure of all legal alternative paths within the same frozen implementation template. It does not take the maximum value across template versions or deployment environments. In this example, all conditions of the edge inference path in the production environment are met, and the path closure is 1. Therefore, the execution closure C3 is 1. The automatic requirement verification threshold θ3 is fixed at 1 and no adjustable preference range is set. This fixed value is consistent with the role of all implementation conditions being necessary conditions, preventing the permission of paths lacking necessary states by lowering the threshold. Historical projects are only used to review implementation templates and maintain the integrity of requirements, and are not used to reduce the closure requirements of necessary conditions.

[0071] After the execution closure is equal to 1, the system generates a requirement verification license L3 for the reflow candidate subgraph. The license records the reflow candidate subgraph, the source candidate set, the verification object graph, the implementation condition graph version, the deployment environment, the project execution status graph version, the closure path, the evaluation cutoff point, the source record of the supporting nodes, and the project baseline graph version before sending. Only one license is generated for the same reflow candidate subgraph. Even if the source candidate set contains multiple historical marketing contents, the license will not be generated repeatedly.

[0072] This example completed the closed-loop computation at 17:52 on April 22, 2026. The edge inference node's computing resource quota, input image interface authorization, production network relationship, and recognition result feedback route have all been continuously effective for more than 24 hours. Model V3.2 remains effective on the edge inference node and is associated with the running process. The file verification value has not changed in the most recent maximum synchronization cycle. The central server has formed project-specific production recognition result receiving logs for the four authorized cameras. The authenticity gating, object version gating, state predicate gating, time retention gating, and state increment gating are all set to 1. The incremental coverage gating and path order gating of the edge inference path in the production environment are both set to 1. The requirement verification license version identifier is recorded as L3-V01.

[0073] When the L3 record of the requirement verification license backflow candidate subgraph is supported by the project technical status under the current baseline version, implementation template version and evaluation cutoff point, and the model is unloaded, the image data interface authorization is revoked, the project attribution is corrected or the baseline version becomes invalid, L3 is converted to a state pending re-verification, and S4 freezes the corresponding transfer record and removes its current statistical contribution.

[0074] Table 3, S3 Status Verification and Access Control: S4 receives the valid requirement verification permission L3 and its associated objects, and reads the requirement layer D1. This implementation adopts single-stage contextual reinforcement learning: the sending of a marketing action instance and its subsequent requirement verification constitute one round. The strategy state and technical proposition combination at the time of sending constitute the round input. L3 forms the termination reward. Each strategy model version freezes the product version, technical proposition feature index Λ4, regularization coefficient λ4, valid transition sample set and sufficient statistics respectively. The delayed L3 is written back according to the decision cutoff point τ4 recorded when the marketing action is sent and the strategy model version. It only applies to the marketing actions that have not yet been executed after that version. If the corresponding strategy model version has stopped being used for action selection when L3 arrives, the record is only saved in the historical sample of that version. It is not written to other activity model versions, nor is the stopped model version reactivated.

[0075] This marketing action instance was selected by strategy model version POL-V12 on March 10, 2026. The decision cutoff point τ4 is earlier than the time when the marketing content is delivered. POL-V12 selects from the central server expansion combination, the image compression and transmission combination, and the edge inference combination. Each combination has completed the product version and necessary dependency closure verification. The edge inference combination selected in this example generates the actual sent content through the AIGC expression template and passes the pre-send consistency verification. Subsequently, L3 only writes back the marketing action instance frozen in POL-V12.

[0076] The candidate subgraphs of the valid requirement verification license coverage are written into the verification requirement state V4. Each requirement difference element retains the object, action, condition difference, dependency edge, product version, license identifier, and generated incremental claim subgraph identifier. When the same requirement difference element has multiple valid license support, a valid license support set is established. When one license expires but there are other valid licenses, the requirement difference element continues to remain in the verification requirement state, and the part not covered by the license continues to remain in the isolated requirement state.

[0077] The technical claim feature index Λ4 is built according to the product version of the strategy model, and non-overlapping index intervals are set for technical claim nodes, establishment condition differences, and dependency edges. The index positions are partitioned according to the order of nodes, condition differences, and dependency edges. The node area is sorted by the unified technical object identifier and processing action identifier, the condition difference area is sorted by the corresponding node identifier, condition variable, and comparison relationship, and the dependency edge area is sorted by the starting node identifier and ending node identifier. Under the same product version and index version, the above sorting results remain unchanged. In this example, the index has a total of 36 positions, of which 14 positions are used for technical claim nodes, 10 positions are used for atomic condition predicate differences, and 12 positions are used for dependency edges. The existing requirements in the requirement layer are encoded as the existing requirement vector b4, and the verification requirement status is encoded as the verification requirement vector v4. The value is 1 when the corresponding feature exists, and 0 otherwise. The two are concatenated in a fixed order to form the strategy status vector s4. The nodes, condition differences, and dependency edges are partitioned and encoded to distinguish the existence of technical objects, changes in establishment conditions, and changes in dependency relationships.

[0078] Marketing actions consist of a technology claim combination (g4) and an expression template (e4). The technology claim combination must meet the requirements of product version compatibility, non-mutually exclusive conditions, and necessary dependency closure. When selecting edge inference actions, the indispensable edge inference nodes, model deployments, image data interfaces, and dependency conditions must also be selected. The expression template only changes the length, organization order, and presentation format, without changing the technology object, processing actions, conditions for establishment, and dependencies.

[0079] The deployed AIGC content generation model receives the technical claim combination g4, expression template e4, and scenario fields verified by project permissions through the content generation interface. It outputs marketing text to be sent. The scenario fields are only used to determine customer roles, marketing channels, and project product versions, without changing the technical objects, processing actions, conditions for success, and dependencies in g4. The system converts the output text into a marketing claim graph to be sent according to the atomic technical claim parsing rules of S1, and compares it item by item with g4. It is only sent if the technical objects, processing actions, conditions for success, and dependencies are consistent. If the condition "image data is processed before being sent back to the central server" is removed from the output text, or if additional functions that are not selected by actions are added, no marketing action instance is generated and the content generation interface is called again. This verification ensures that the structured input, text output, and subsequent verification objects of the AIGC model remain traceable and correspond.

[0080] At the decision cutoff point τ4, b4, v4, the technical claim action vector a4, and the strategy model version are frozen. The state-action interaction vector does not use the Kronecker product with quadratic dimension growth. Instead, the constant bias, the existing demand vector, the verification demand vector, the action vector, the positional product of the existing demand and the action, and the positional product of the verification demand and the action are concatenated in sequence. In this example, n4 is 36, so the dimension of the unnormalized interaction vector is 181. Then, the square root of the sum of the squares of the elements of this vector is used as the L2 norm. All elements are divided by the L2 norm to obtain the normalized interaction vector. The constant bias ensures that the denominator is not 0.

[0081] Once the requirement verification permission is obtained, the system reads the structural source matching value of each source candidate relationship in the source candidate set. For multiple candidate relationships pointing to the same marketing action instance, the highest structural source matching value is used as the merged matching value of that action instance, avoiding the accumulation of source weight for duplicate versions of the same marketing content. The merged matching value of each marketing action instance is divided by the sum of the merged matching values ​​of all source candidates to form the source allocation coefficient. Candidate relationships corresponding to external supplier information or the company's historical public information are also included in the denominator, but they are not included in the company's internal strategy update record. The source allocation coefficient is used to limit the total allocation of the same project status verification result among different candidate sources. The merged matching value continues to participate in the verification reward as the source evidence strength, avoiding the amplification of uncertain source relationships into complete rewards simply because there is only one candidate in the source candidate set.

[0082] In this example, only the source candidate relationship corresponding to this AIGC marketing action instance reaches the source threshold in the source candidate set, and its structural source matching value is 0.958. Although the company's historical public information and external information are included in the industry corpus before sending, they do not independently reach the source threshold, so they are not included in the source candidate set Ω2. The combined matching value of all valid source candidates belongs to this marketing action instance, so the source allocation coefficient is 1, but the source evidence strength is still 0.958.

[0083] For this marketing action example, the system uses the attributable incremental portion of the actual participating backflow candidate mapping in the generated incremental claim subgraph as the scope of the validation reward calculation. This example includes 3 technical claim nodes, 10 atomic condition predicate differences, and 2 dependency edges. L3 covers all of the above, and the coverage rate for all three types is 1. The technical claim validation reward is the lowest value among the three types of coverage, multiplied by the source allocation coefficient and the merged structure source matching value of this marketing action example, resulting in 0.958. This calculation means that project implementation closure only proves that the technical claim is supported by the project state, and the source candidate evidence still limits its contribution to the value of the marketing action. When the customer only uses edge inference nodes but does not maintain the key hold conditions, the condition coverage rate further limits the validation reward.

[0084] When the technical claim validation reward is greater than 0, the system generates a technical claim validation transfer record. The transfer record saves the strategy model version, marketing action instance, decision cutoff point, freeze status, action vector, interaction vector, validation reward, requirement validation permission, backflow candidate subgraph, generated incremental claim subgraph, and the project baseline map version before sending. The unique key is composed of the strategy model version, marketing action instance, backflow candidate subgraph, and validation coverage version. When the coverage changes, the contribution of the old record is removed first, and then the new record is written to avoid the old and new coverage being included at the same time.

[0085] Each transfer record has a contribution status of not written, written, frozen, or revoked. Records with valid license support and whose contributions have been written constitute the valid transfer sample set Y4. Each strategy model version maintains an action value full statistics matrix G4 and an action value cumulative vector h4. G4 is the sum of the outer product of the frozen regularization term and the interaction vector of each valid transfer record. h4 is the sum of the verification reward of each valid transfer record multiplied by the interaction vector.

[0086] The regularization coefficient λ4 is determined and frozen when the strategy model version is established. The maximum number of valid transition records N4max allowed by the strategy model version is preferably 300 to 800, and preferably 500. The upper limit of the matrix condition number allowed by the numerical solver is preferably 8001 to 20001, and preferably 10001. N4max is determined based on the update cycle of a single model version, available memory, and solution time of the linear equation system. The upper limit of the condition number is determined based on the effective accuracy of the solver and the allowable numerical fluctuation of the action value parameter. After the state-action interaction vector is normalized, the lower limit of λ4 is calculated by dividing N4max by the upper limit of the condition number minus 1. No other preferred range independent of N4max and the upper limit of the condition number is set. In this example, 500 divided by 10000 gives 0.05, so λ4 is 0.05. The above parameters are written into the model configuration during POL-V12 initialization and do not change due to the addition, freezing, or removal of a single sample during model operation.

[0087] The number of valid transfer records in POL-V12 does not exceed the maximum allowed number of 500 in this version. Since n4 is 36, the normalized state action interaction vector dimension d4 is 181, and G4 is an 181-order matrix, the system adds the matrix contribution and vector contribution of this record in the same transaction, solves the updated linear equation system, and forms a new version of action value parameters. The updated parameters are only used for marketing actions that have not yet been executed in POL-V12 and do not change the content that has already been sent.

[0088] The system obtains w4 by solving a system of linear equations where the product of G4 and the action value parameter w4 equals h4. The inverse matrix of G4 is not explicitly calculated. The action value of the candidate technology combination is the inner product of the corresponding state action interaction vector and w4. If the solution fails, G4 and h4 are reconstructed based on the current effective transition sample set, and the old parameters that have not been updated are not used.

[0089] The system selects the combination with higher action value from the legitimate candidate actions that meet the product version, condition compatibility, necessary dependency closure, and final content consistency verification. When the action values ​​are the same and there are not enough valid samples, the system selects legitimate candidate combinations in turn according to the loop position saved by the strategy model version, and does not always select the same combination with the smallest identifier, thus reserving the opportunity for legitimate combinations that have no verification samples to obtain project verification results.

[0090] Each transfer record stores its independent contribution to the sufficient statistics, where the matrix contribution is the product of the interaction vector and its transpose, and the vector contribution is the product of the validation reward and the interaction vector. The contribution is added when a record changes from unwritten to written; the contribution is removed immediately when entering a frozen state; the validity is restored only once when revalidated; when the record is finally revoked and there are no other valid permissions to support it, the current valid contribution is removed and marked as revoked. All insert and delete operations simultaneously verify the unique key, contribution status and model version, and update the statistics and action value parameter versions in the same transaction.

[0091] The expression template parameters and the value of the technical claim action are updated separately. The system establishes independent feedback counts according to customer roles, marketing channels, and expression templates, recording the number of valid positive format feedback and the number of valid negative format feedback respectively. Initially, both types of counts are set to 1 as equal initial pseudo-counts, so that templates without historical feedback have the same initial parameters and the denominator is not 0. Only positive or negative feedback that is clearly aimed at length, layout, interaction form, or language style, or template comparison feedback formed under the condition that the technical claim combination is completely consistent, will increase the corresponding count. The expression template selection parameter is the positive count divided by the sum of the positive and negative counts, and is only used for template sorting under the same technical claim combination. When a feedback record is confirmed to be misattributed or invalid, only the corresponding count previously added to the record is deducted, and it is not less than the initial pseudo-count of 1. Reading, forwarding, or consultation feedback that cannot exclude the influence of technical content is only saved as feedback records, not included in the count, not written into the valid transfer sample set, and does not change the verification reward, G4, or h4.

[0092] When S3 changes the requirement verification license to a pending re-verification state, S4 immediately freezes the transfer records supported only by that license and removes their statistical contributions. If the same requirement difference element is still supported by other valid licenses, the requirement verification state is retained. Otherwise, it is moved back to the isolated requirement state. After re-verification, only the frozen records consistent with the current verification scope are restored. After confirming that the technical implementation relationship is canceled and there is no equivalent implementation path, the license is finally revoked and the corresponding contribution is removed.

[0093] In subsequent operations, Company A conducted planned maintenance on the image data interface. The original authorization status was temporarily revoked. S3 changed L3-V01 to a pending re-verification status. Before POL-V12 selected the next marketing action, S4 froze the transfer record and removed the corresponding statistical contribution. After the image data interface was authorized and continuously valid for 24 hours, S3 reconfirmed the original closed path. S4 only restored the original contribution once when the contribution status was frozen. If the continuous valid time was less than 24 hours, the license remained in the pending re-verification status.

[0094] When the previous project baseline version becomes invalid, all transfer records referencing that version are immediately frozen and contributions are removed. After completing S1 to S3 processing under the new baseline version, the verification requirement status and transfer records are re-established based on the new license. The results of the old version are not copied. When the statistics change due to license freezing, revocation, or baseline invalidation, the contribution removal and action value parameters are re-solved before the model version is allowed to select subsequent marketing actions. Content that has already been sent is not retroactively revoked.

[0095] Table 4, S4 Strategy Update and Rollback Processing: Through the above processing, the edge inference claim in Company A's project requirements document is first formed by S2 into a backflow candidate subgraph and enters the isolated requirement state; after Company A completes the allocation of computing resources for edge inference nodes, authorization of image data interfaces, model writing and process association, establishment of production network, activation of recognition result backhaul routing and confirmation of central server result reception, S3 generates requirement verification permission. The text source candidate recognition and project implementation status verification use structural evidence and authoritative project status records respectively, and maintain the correspondence of objects through the same backflow candidate subgraph.

[0096] If the strategy is updated solely based on textual similarity relationships in the client's materials, the edge inference claim will enter the strategy state when the requirements document is formed on March 28, 2026. This implementation method will be admitted after the complete implementation path closure on April 22, a difference of 25 days. During this period, the backflow candidate subgraph R2 remains isolated and is not written into the verification requirement vector v4 and the effective transition sample set Y4, thus not changing the action value sufficient statistics matrix G4, the action value cumulative vector h4, and their corresponding action value parameters.

[0097] S4 allocates verification contributions based on the candidate relationships of the source and determines the reward based on the minimum coverage of nodes, condition differences, and dependent edges. Each transfer record saves an independent statistical contribution. When a project implementation relationship is canceled, only the corresponding contribution is removed. The existing requirements, other valid verification requirements, and expression template parameters before the customer sends the data remain unchanged. As a result, the system can restore sufficient statistics consistent with the current valid evidence when there are late records, license freezes, or project status revocations, avoiding the continued impact of low-reliability or expired return requests on the selection of subsequent marketing actions.

[0098] This invention also discloses a marketing system based on AIGC technology, comprising: The project baseline processing module obtains the project requirements and technical status before sending AIGC marketing content, and constructs a project baseline diagram before sending according to the project identifier, unified technical object identifier and product version; it parses the AIGC marketing content into a marketing proposition diagram, aligns it with the project requirements, and extracts and generates incremental propositions. The source identification module acquires the required materials after they are sent, parses them into a requirement claim diagram and aligns them with the project requirements, and extracts candidate requirements. Based on the generated incremental claims, it forms a structural signature, performs structural matching on the candidate requirements, forms a structural source matching value, and establishes a source candidate relationship by combining the formation time verification result. Candidate requirements associated with the company's AIGC marketing content are written into the isolated requirement state. The project technical status verification module calls the product deployment specifications according to the product version to form an implementation condition diagram; it obtains the project technical status change records after sending, extracts the status increment relative to the project baseline diagram before sending, maps the status increment and the project technical status in the project baseline diagram before sending to the implementation condition diagram to form a project execution status diagram, performs closure verification on the implementation path, and generates a requirement verification license. The marketing strategy update module converts candidate requirements in isolated requirement states into verification requirements based on requirement verification permissions, encodes project requirements and verification requirements into marketing strategy states, and selects combinations of technical claims that meet product version and dependency constraints as marketing actions; it generates technical claim verification transfer records with permission identifiers, writes the independent contribution of the records into the action value statistics, and adjusts the independent contribution according to the requirement verification permission state.

[0099] The above embodiments can be implemented in whole or in part by software, hardware, firmware or other arbitrary combinations. When implemented by software, the above embodiments can be implemented in whole or in part as a computer program product. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution.

[0100] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0101] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A marketing method based on AIGC technology, characterized in that, include: Obtain the project requirements and technical status before sending AIGC marketing content, and construct a baseline diagram of the project before sending by project identifier, unified technical object identifier and product version; AIGC marketing content is parsed into a marketing proposition map, aligned with project requirements, and incremental propositions are extracted and generated. After receiving the submitted requirements materials, parse them into a requirements proposition diagram and align them with the project requirements to extract candidate requirements; Based on the generated incremental claims, a structural signature is formed. Structural matching is performed on the candidate requirements to form a structural source matching value. The source candidate relationship is established by combining the formation time verification result. The candidate requirements associated with the company's AIGC marketing content are written into the isolated requirement state. Implementation condition diagrams are generated by calling product deployment specifications according to product version; Obtain the project technical status change record after sending, extract the status increment relative to the project baseline diagram before sending, map the status increment and the project technical status in the project baseline diagram before sending to the implementation condition diagram to form the project execution status diagram, perform closure verification on the implementation path, and generate requirement verification permission. Based on the requirement verification permission, candidate requirements in the isolated requirement state are converted into verification requirements. Project requirements and verification requirements are encoded into marketing strategy states, and combinations of technical claims that meet product version and dependency constraints are selected as marketing actions. Generate a technology claim verification transfer record with a license identifier, write the independent contribution of the record into the action value statistic, and adjust the independent contribution according to the license status.

2. The marketing method based on AIGC technology according to claim 1, characterized in that, The specific steps for creating a baseline diagram of the project before submission are as follows: Read the delivery records of AIGC marketing content and set the first successful delivery time as the baseline cutoff point; Obtain the project requirements formed before the baseline cutoff point and the valid project technical status at the baseline cutoff point. Determine the record ownership according to the project identifier, unified technical object identifier, and product version. Associate the project requirements with the project technical status to form a project baseline diagram before sending.

3. A marketing method based on AIGC technology according to claim 2, characterized in that, The specific steps for extracting and generating incremental claims are as follows: The same technical proposition parsing rules are used to process project requirements and AIGC marketing content, and node mapping is established according to unified technical object identification, processing actions and product versions; Perform graph alignment on the technology claim nodes, conditions for validity, and dependencies, and extract unmapped technology claims and graph alignment differences to generate incremental claims.

4. A marketing method based on AIGC technology according to claim 1, characterized in that, The specific operations for extracting candidate requirements and forming structured signatures are as follows: After sending the requirements materials, they are parsed into a requirements claim diagram, which is then aligned with the project requirements execution diagram in the project baseline diagram before sending. The interconnected requirements differences under the same project identifier are extracted as candidate requirements. A structural signature is generated based on the graph structure of the generated incremental claims, and the frequency of the structural signature in industry materials published before the AIGC marketing content is sent is counted.

5. A marketing method based on AIGC technology according to claim 4, characterized in that, The specific steps for establishing source candidate relationships are as follows: Perform a structure mapping between candidate requirements and structure signatures, and generate a structure source matching value based on the structure mapping result and the frequency of occurrence of the structure signature; When the structural source matching value reaches the source threshold, and the first verifiable occurrence of the candidate demand is later than the time when the AIGC marketing content is sent, a source candidate relationship is established. When the source object of the source candidate relationship is the company's AIGC marketing content, the differences in the candidate requirements involved in the structural mapping are written into the isolated requirement state.

6. A marketing method based on AIGC technology according to claim 1, characterized in that, The specific steps for creating the implementation condition diagram are as follows: According to the product version and deployment environment corresponding to the isolation requirement status, the product deployment specification is invoked to convert the necessary technical status into implementation condition nodes; The implementation condition nodes are connected according to common necessity and substitution relationships to form an implementation condition graph containing implementation paths, and the implementation condition nodes are associated with authoritative technical status data sources.

7. A marketing method based on AIGC technology according to claim 6, characterized in that, The specific steps for generating a requirements verification license are as follows: Read the authoritative technical status data source synchronization level associated with the implementation condition diagram, set the earliest synchronization level as the evaluation cutoff point, and reconstruct the project technical status at the evaluation cutoff point; Based on whether the implementation conditions are required to be formed after the AIGC marketing content is sent, the implementation condition nodes are divided into incremental verification conditions and baseline support conditions. Extract the state increment from the project technical status relative to the project baseline diagram before sending, map the state increment to the incremental verification condition, and map the project technical status from the project baseline diagram before sending to the baseline support condition to form the project execution status diagram; The implementation path execution status is supported for verification. When there is an implementation path where all implementation condition nodes have obtained status support, a requirement verification license is generated.

8. A marketing method based on AIGC technology according to claim 1, characterized in that, The specific steps for forming a marketing strategy and marketing actions are as follows: Establish a technical claim feature index based on product version, encode project requirements and validation requirements to form a marketing strategy status; select technical claim combinations that are compatible with product versions, have non-exclusive conditions for establishment and closed dependencies, and identify technical claim combinations as marketing actions; The combination of technical claims is used as structured input to call the AIGC content generation model. The model output is parsed into technical claims. When the parsing result matches the technical claims and dependencies in the combination of technical claims, the model output is sent.

9. A marketing method based on AIGC technology according to claim 8, characterized in that, The specific steps for updating the value of marketing actions are as follows: Freeze the marketing strategy status, marketing action, and strategy model version when a marketing action is sent; When the demand verification license is valid, a verification reward is generated based on the coverage of the incremental claims generated by the demand verification license and the structural source matching value. A technology claim verification transfer record with a license identifier is generated based on the frozen marketing strategy status, marketing actions and verification rewards. The independent contribution of the record is written into the action value statistics of the corresponding strategy model version. When a requirement verification permit is changed to a pending re-verification state, the record is marked as frozen and the independent contribution is removed from the action value statistics; when the requirement verification permit is restored to a valid state and the record is frozen, the independent contribution is written back to the action value statistics; when the requirement verification permit is revoked, the independent contribution is removed from the action value statistics and the record is marked as revoked.

10. A marketing system based on AIGC technology, employing a marketing method based on AIGC technology as described in any one of claims 1-9, characterized in that, include: The project baseline processing module obtains the project requirements and technical status before sending AIGC marketing content, and constructs a project baseline diagram before sending according to the project identifier, unified technical object identifier and product version; it parses the AIGC marketing content into a marketing proposition diagram, aligns it with the project requirements, and extracts and generates incremental propositions. The source identification module obtains the required materials after they are sent, parses them into a requirement claim diagram and aligns them with the project requirements, and extracts candidate requirements. Based on the generated incremental claims, a structural signature is formed. Structural matching is performed on the candidate requirements to form a structural source matching value. The source candidate relationship is established by combining the formation time verification result. The candidate requirements associated with the company's AIGC marketing content are written into the isolated requirement state. The project technical status verification module calls the product deployment specifications according to the product version to form an implementation condition diagram; it obtains the project technical status change records after sending, extracts the status increment relative to the project baseline diagram before sending, maps the status increment and the project technical status in the project baseline diagram before sending to the implementation condition diagram to form a project execution status diagram, performs closure verification on the implementation path, and generates a requirement verification license. The marketing strategy update module converts candidate requirements in isolated requirement states into verification requirements based on requirement verification permissions, encodes project requirements and verification requirements into marketing strategy states, and selects combinations of technical claims that meet product version and dependency constraints as marketing actions; it generates technical claim verification transfer records with permission identifiers, writes the independent contribution of the records into the action value statistics, and adjusts the independent contribution according to the requirement verification permission state.

Images