Server and Method for Multimodal Generative Resource Routing Performing Eligibility Screening and Response-Contract-Based Remediation

Abstract

The present invention relates to a multimodal generater resource routing server and method for performing eligibility screening and response contract-based recovery. It evaluates multiple generater resource candidates based on policy, function, resource, and state criteria to remove ineligible candidates before determining rankings, verifies integrity hashes, freshness, minimum sample size, coverage, and quality thresholds on the performance evidence of the remaining candidates, determines the candidate order by applying a fixed standard normalization score or a deterministic policy order to candidates that pass verification, and fixes the determined order as an immutable execution plan by binding it to a request selector fingerprint, configuration revision, and evidence diagnosis. It rejects execution without replanning in the event of a discrepancy in execution timing, evaluates billing, licensing, consent, and retry policies at a single execution point prior to dispatch, and provides the effect of improving reliability and predictability by performing different recovery according to the type of response contract failure.

Description

Technology Field

[0001] The present invention relates to a multimodal generated resource routing server and method for performing eligibility screening and response contract-based recovery. Background Technology

[0002] Conventional generated resource routing technologies are limited to selecting candidates based on superficial indicators such as model name, cost, or latency, and include ineligible candidates that do not meet policy, function, resource, or status criteria in the ranking stage. Consequently, candidates that cannot be invoked or possess extreme values ​​distort the normalized distribution and trigger unnecessary computations, leading to the problem of ineligible candidates being ultimately selected. Furthermore, due to insufficient means of verifying the integrity of candidate performance evidence, speculative results based on small samples, as well as tampered or outdated evidence, are directly reflected in the ranking. Additionally, the addition or removal of candidates alters the absolute scores of existing candidates, compromising the reproducibility and determinism of routing results.

[0003] Recently, methods utilizing benchmark metrics to select candidates or perform retries in the event of errors have been introduced; however, relying solely on benchmark scores does not resolve issues regarding sample insufficiency and evidence freshness. Furthermore, if requests or settings change at the time of execution, impromptu replanning occurs, leading to discrepancies between pre-verified selection criteria and actual execution, and causing errors due to differences in state between the time of inspection and the time of use. Moreover, since billing, licensing, consent, and retry policies are distributed across provider-specific codes, policy violations through bypass routes are possible, and there are limitations in that policy consistency and the traceability of blocking reasons are reduced.

[0004] On the other hand, conventional methods rely solely on the free status indicated in the catalog, failing to filter out discrepancies between test credits or promotional indications and actual billing. Furthermore, the fragmentary evaluation of cost metadata leads to inaccurate determinations of free status. Additionally, performing uniform retries without distinguishing between types of response contract failures results in wasted resources and budget, as retries are repeated even in futile cases such as authentication errors or rejection responses. Therefore, technology is required to remove ineligible candidates before ranking, verify evidence integrity, perform plan consistency verification for immutable execution plans and policy evaluation at a single execution point, and implement different recovery methods based on the type of response contract failure. Prior art literature

[0005] Korean Registered Patent No. 10-2026700 The problem to be solved

[0006] The present invention aims to provide a multimodal generated resource routing server and method that performs eligibility screening and response contract-based recovery.

[0007] Conventional generated resource routing methods had problems in that ineligible candidates were included in the ranking stage, leading to the selection of candidates that did not meet policy, function, resource, and state criteria, or the execution of unnecessary computations. Furthermore, insufficient integrity verification of candidate performance evidence resulted in inaccurate rankings based on small samples, tampering, or outdated evidence; additionally, the addition or removal of candidates caused fluctuations in the scores of existing candidates, which limited the reproducibility and determinism of routing results.

[0008] In addition, conventionally, impromptu replanning was performed in response to requests or configuration changes at the time of execution, resulting in discrepancies between the pre-verified basis for selection and the actual execution. Furthermore, as billing, licensing, consent, and retry policies were executed across multiple points, there were issues that reduced policy consistency and the traceability of blocking reasons. Moreover, the free status was inaccurately determined due to fragmentary judgments of cost metadata, and resources and budget were wasted as useless retries were repeated for authentication errors or rejection responses due to uniform retries that did not distinguish between types of response contract failures.

[0009] The present invention aims to solve the above problems by removing ineligible candidates before ranking, verifying the evidentiary integrity of remaining candidates, performing deterministic ranking by fixed standard normalization and binding and plan consistency verification for invariant execution plans, evaluating policies at a single execution point, and performing different recovery depending on the type of response contract failure.

[0010] The technical problems of the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below. means of solving the problem

[0011] A multimodal creator resource routing server performing eligibility screening and response contract-based recovery according to an embodiment of the present invention comprises a communication unit that receives a content creation request, a processor, and memory. The processor comprises a candidate eligibility determination unit, an evidence integrity verification unit, a candidate ranking determination unit, an immutable execution plan generation unit, a plan match verification and execution control unit, a single-point policy gate unit, and a response contract-based recovery unit. The candidate eligibility determination unit is configured to determine eligibility for each of a plurality of creator resource candidates based on policy, function, resource, and state criteria, and to remove ineligible candidates before determining candidate rankings. The evidence integrity verification unit is configured to exclude small-sample, tampered, or outdated evidence by verifying integrity hashes, freshness, minimum sample size, coverage, and quality thresholds for the performance evidence of candidates remaining after removal. The candidate ranking determination unit is configured to determine candidate rankings by applying a fixed standard normalization score or a deterministic policy order to candidates that have passed the verification. The above immutable execution plan generation unit is configured to bind the determined candidate order to the request selector fingerprint, configuration revision, and evidence diagnosis to fix it as an immutable execution plan. The above plan match verification and execution control unit is configured to reject execution without performing replanning if the request or configuration at the time of execution is inconsistent with the above immutable execution plan. The above single-point policy gate unit is configured to evaluate billing, licensing, consent, and retry policies at a single execution point prior to the dispatch of the generation request, and to return the selection reason and the blocking reason in a machine-readable form upon blocking. The above response contract-based recovery unit is configured to perform different recovery among deterministic theorem, correction request, recovery model selection, and next candidate selection depending on the type of response contract failure.

[0012] The above candidate eligibility determination unit is configured to grant a verified free grade when multiple independent cost metadata, including cost values, free indication information, estimated costs, and billing modes of each creator resource candidate, match each other, and not to determine free based on a single cost value or a prefix of a candidate identifier, and the above single point policy gate unit may be configured to allow commercial use when eligibility of the usage context and explicit approval are both satisfied, and to set the default value of the retry budget for creation submission to zero by separating it from the retry budget for lookup.

[0013] Additionally, the processor may further include a capability-aware instance selection unit configured to verify whether a set of requirement models corresponding to the requirement task and style is included in the inventory of each instance, return an undistributed diagnosis if no capable instance exists, return an idle absence diagnosis without performing a submission if all capable instances are in use, and select an instance with the minimum queue load among the capable and idle instances.

[0014] The above candidate ranking unit is configured to apply fixed standard normalization such that the addition or removal of a candidate does not change the absolute score of an existing candidate, and to perform reordering by reflecting a runtime correction signal within a set range after passing through a minimum sample gate, and the above plan-matching verification and execution control unit may be configured to sequentially execute the candidate order fixed to the above immutable execution plan within a single absolute deadline and a shared call budget.

[0015] Additionally, the processor may further include a reference asset slot integrity verification unit configured to combine costume assets, location assets, and face anchor assets corresponding to scene numbers and appearing characters according to priority, remove duplicates, and construct a reference set up to the upper limit of the reference input, map the character of the prompt to the owner of the reference slot, determine a swap error if the owner and the character do not match, correct the prompt, and perform re-verification, and if the discrepancy is not resolved even after re-verification, block the submission of the creation request.

[0016] The above response contract-based recovery unit may be configured to perform preprocessing to identify failure types including format errors, language mismatches, transient transmission errors, authentication errors, rejection responses, and policy rejections in the verification of the response contract, select a different recovery from among a first recovery that performs re-verification after deterministic cleanup according to the identified failure types, a second recovery that re-requests a correction request with stricter constraints to the same candidate or recovery model, a third recovery that transfers to the next candidate after limited transmission retries within the allowable budget range, and a fourth recovery that preserves the diagnosis and excludes the corresponding candidate without repeated retries, determine whether to repeat the recovery according to an adjustable retry budget and reliability criteria, and perform a conditional branch to select the next candidate by bypassing general retries for authentication errors and rejection responses.

[0017] The evidence integrity verification unit described above is configured to maintain an automatic approval threshold bound to the hash value and formula version of the source file from which the threshold was derived, and to perform a conditional branch to disable automatic processing when a formula version mismatch, source file hash mismatch, or threshold drift is detected. The processor may further include a snapshot verification unit configured to maintain an expected candidate profile, an expected final order, and an exclusion list as reference fixed values, and to perform a fallback to restore to the previous source and policy by detecting drift when the candidate order at the time of operation is compared with the reference fixed values.

[0018] Other specific details of the present invention are included in the detailed description and drawings. Effects of the invention

[0019] According to the present invention, candidates that do not meet policy, function, resource, and status criteria are excluded in advance from the ranking determination stage through a candidate eligibility determination unit configured to remove ineligible candidates prior to candidate ranking determination. Accordingly, this solves the problem where ineligible candidates were previously included in the ranking determination stage for selection or where unnecessary computations were performed, thereby concentrating computational resources only on eligible candidates, which has the advantage of improving routing accuracy and computational efficiency.

[0020] According to the present invention, ranking is performed after excluding small-sample, tampered, or outdated evidence through an evidence integrity verification unit that verifies integrity hashes, freshness, minimum sample size, coverage, and quality thresholds, and a candidate order is determined by applying a fixed standard normalized score or a deterministic policy order. Accordingly, this solves the problem of inaccurate ranking caused by insufficient integrity verification of performance evidence in the past, and the problem of failure to ensure reproducibility and determinism due to fluctuations in the scores of existing candidates upon the addition or removal of candidates, thereby providing the advantage of reproducible and deterministic routing results based on reliable evidence.

[0021] According to the present invention, an immutable execution plan generation unit is provided for fixing an immutable execution plan by binding a determined candidate order to a request selector fingerprint, a setting revision, and an evidence diagnosis. Additionally, a plan consistency verification and execution control unit is provided for rejecting execution without performing replanning if the request or setting at the time of execution is inconsistent with the immutable execution plan. Accordingly, this resolves the problem where inconsistencies occurred between the pre-verified selection basis and the actual execution due to impromptu replanning in response to changes in the request or setting at the time of execution, thereby providing the advantage of ensuring consistency between the verified selection basis and the execution.

[0022] According to the present invention, a single-point policy gate unit is provided that evaluates billing, licensing, consent, and retry policies at a single execution point prior to the dispatch of a creation request, and returns the selection reason and the blocking reason in a machine-readable form upon blocking. Accordingly, this solves the problem in which policy consistency and the traceability of blocking reasons were degraded due to the conventional practice of billing, licensing, consent, and retry policies being executed in a distributed manner across multiple points, and also resolves the problem in which the free status was inaccurately determined due to fragmentary judgments of cost metadata, thereby providing the advantage of improving policy execution consistency and the traceability of blocking reasons.

[0023] According to the present invention, a response contract-based recovery unit is provided that performs different recovery among a deterministic theorem, a correction request, a recovery model selection, and a next candidate selection depending on the type of response contract failure. Accordingly, the problem of wasting resources and budget due to repeated useless retries for authentication errors or rejection responses caused by uniform retries that did not distinguish the type of response contract failure in the past is resolved, and there is an advantage of reducing the waste of resources and budget and increasing the recovery success rate by selecting a recovery path that corresponds to the type of failure.

[0024] The effects of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description below. Brief explanation of the drawing

[0025] Figure 1 is a block diagram showing the overall configuration of a multimodal generated resource routing system that performs eligibility screening and response contract-based recovery. Figure 2 is a block diagram showing the detailed configuration of a multimodal generated resource routing server. Figure 3 is a block diagram showing the detailed configuration of the candidate eligibility determination unit, evidence integrity verification unit, candidate ranking determination unit, immutable execution plan generation unit, and plan matching verification and execution control unit included in the processor. Figure 4 is a block diagram showing the detailed configuration of a single-point policy gate, a response contract-based recovery unit, a capability-aware instance selection unit, and a reference asset slot integrity verification unit included in the processor. Figure 5 is an example diagram showing the data structure of a multimodal generated resource routing server and method that performs eligibility screening and response contract-based recovery. Figure 6 is an example diagram showing a process scene of a multimodal generated resource routing server and method that performs eligibility screening and response contract-based recovery. Figure 7 is an example diagram illustrating a user scenario of a multimodal generated resource routing server and method that performs eligibility screening and response contract-based recovery. Specific details for implementing the invention

[0026] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

[0027] In describing the embodiments, technical details that are well known in the art to which the present invention belongs and are not directly related to the present invention are omitted. This is intended to convey the essence of the present invention more clearly without obscuring it by omitting unnecessary explanations.

[0028] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the size of each component does not entirely reflect its actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0029] The advantages and features of the present invention and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below but can be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0030] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0031] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For instance, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to their corresponding functions.

[0032] In this embodiment, the term "part" refers to a software or hardware component such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and '~parts' may be implemented to play one or more CPUs within the device or secure multimedia card.

[0033] In describing the embodiments of the present invention in detail, the primary focus will be on examples of specific systems, but the main point claimed in this specification is applicable to other communication systems and services having a similar technical background without significantly departing from the scope disclosed in this specification, and this will be possible at the judgment of a person with skilled technical knowledge in the relevant technical field.

[0034] FIG. 1 is a block diagram showing the overall configuration of a multimodal creator resource routing system that performs eligibility screening and response contract-based recovery. Referring to FIG. 1, the system is configured to include a multimodal creator resource routing server (100), a user terminal (200), a creator resource instance server (300), and an evidence / policy database (400).

[0035] A user terminal (200) is an input component that generates a content creation request and transmits it to a routing server (100). The content creation request consists of normalized request data including a work type, media type, quality requirements, cost conditions, usage context, and reference conditions. The user terminal (200) may be implemented as a personal computer, a mobile communication terminal, a tablet, or a production workstation, while in another embodiment, the user terminal (200) may be implemented as an application programming interface client to which an orchestration module of a higher-level production management system calls the routing server (100). Communication between the user terminal (200) and the routing server (100) is performed using a presentation state transmission method based on a hypertext transmission protocol with transport layer security, and the request data is serialized and transmitted in a normalized JavaScript object notation format.

[0036] The routing server (100) functions as the central hub of the system and performs eligibility screening, evidence integrity verification, candidate ranking, immutable execution plan fixing, plan matching verification, single point policy evaluation, and response contract-based recovery for content creation requests received from user terminals (200). The routing server (100) queries performance evidence and policy data from the evidence and policy database (400) and dispatches creation requests to the creation resource instance server (300) corresponding to the candidate that passed the verification.

[0037] The evidence and policy database (400) is a storage-side component that stores performance evidence and policy data for each of the multiple generation resource candidates. Performance evidence includes a model identifier, media type, task type, score by quality axis, sample pass rate and completion rate, latency and throughput indicators, integrity hash, benchmark basis file path and version, and sample size. Policy data includes billing information, license conditions, face and voice consent conditions, retry policy, policy version, and formula version. The routing server (100) and the evidence and policy database (400) exchange data bidirectionally, and the routing server (100) records diagnostic information, such as execution results and response contract failure types, in the evidence and policy database (400). Meanwhile, in another embodiment, the evidence and policy database (400) may be implemented as a relational database, a document-oriented database, or a key-value store, and may be implemented in a configuration that maintains performance evidence and policy data separately in different stores.

[0038] The generating resource instance server (300) is an output-side component that actually runs generating resources of different media among language models, image generating models, video generating models, audio generating models, and visual language models to produce a generating result. The generating resource instance server (300) includes multiple instances, and each instance holds an inventory of different request models. The routing server (100) selects an instance with the minimum queue load from among the capable and idle instances to submit a generating request, and the generating resource instance server (300) returns the generating result to the routing server (100) in a form that conforms to the response contract. Requests and responses between the routing server (100) and the generating resource instance server (300) are performed within a single absolute deadline and a shared call budget.

[0039] FIG. 2 is a block diagram showing the detailed configuration of a multimodal creation resource routing server. Referring to FIG. 2, the routing server (100) is configured to include a communication unit (110), a processor (120), and a memory (140). A content creation request received by the communication unit (110) is transmitted to the processor (120), and the processor (120) performs each operation while exchanging data with the memory (140).

[0040] The communication unit (110) is an input / output interface that receives a content creation request from a user terminal (200) and transmits the operation result of the processor (120) to the outside. The communication unit (110) is responsible for querying and recording the evidence / policy database (400), and for dispatching and receiving responses from the creation resource instance server (300). The communication unit (110) is implemented as a wired or wireless communication module, and in another embodiment, the communication unit (110) may be implemented with a configuration in which a remote procedure call interface for communication between internal services and a gateway interface for receiving external requests are physically separated.

[0041] The processor (120) is a central processing component that performs eligibility determination, evidence verification, ranking, execution control, and recovery operations on a content creation request transmitted by the communication unit (110), and functions as the hub of the system. The processor (120) includes a candidate eligibility determination unit (121), an evidence integrity verification unit (122), a candidate ranking determination unit (123), an immutable execution plan generation unit (124), a plan match verification and execution control unit (125), a single point policy gate unit (126), a response contract-based recovery unit (127), a capability-aware instance selection unit (128), a reference asset slot integrity verification unit (129), and a snapshot verification unit (130). Among these, the detailed configuration of the candidate eligibility determination unit (121) to the plan match verification and execution control unit (125) is described later in FIG. 3, and the detailed configuration of the single point policy gate unit (126) to the reference asset slot integrity verification unit (129) is described later in FIG. 4. The processor (120) performs the functions of these components in parallel or sequentially on one or more physical computation cores, while in another embodiment, the processor (120) may be implemented as a combination of one or more of a general-purpose central processing unit, a graphics processing unit, or a dedicated accelerator.

[0042] Memory (140) is a component that exchanges data with the processor (120) and stores data used for eligibility determination, evidence verification, ranking, execution control, and recovery operations. Memory (140) stores the normalization results of content creation requests, candidate eligibility determination results, evidence verification results, normalization scores, immutable execution plans, execution diagnoses, and policy digests. Instructions corresponding to each operation performed by the processor (120) are stored in memory (140), and the processor (120) reads the corresponding instructions to execute the functions of each component. Meanwhile, in another embodiment, memory (140) may be implemented in a configuration that includes both volatile memory and non-volatile storage devices, and maintains immutable execution plans and policy digests in the non-volatile storage device to ensure reproducibility.

[0043] FIG. 3 is a block diagram showing the detailed configuration of the candidate eligibility determination unit, evidence integrity verification unit, candidate ranking determination unit, immutable execution plan generation unit, and plan matching verification and execution control unit included in the processor. Referring to FIG. 3, the data flow proceeds in the order of the candidate eligibility determination unit (121), evidence integrity verification unit (122), candidate ranking determination unit (123), immutable execution plan generation unit (124), and plan matching verification and execution control unit (125).

[0044] The candidate eligibility determination unit (121) determines the eligibility of each of the multiple creator resource candidates based on policy, function, resource, and status criteria, and removes ineligible candidates before determining the candidate ranking. The policy criterion determines whether the required authority and license conditions are satisfied, the function criterion determines whether the creator resource candidate itself possesses the capability corresponding to the required task and style, the resource criterion determines whether the hardware requirements are satisfied, and the status criterion determines availability and circuit breaker status. Here, the function criterion determination by the candidate eligibility determination unit (121) determines whether the capability is possessed at the model level of the creator resource candidate, and is distinguished from the capability recognition instance selection unit (128), described later, which verifies at the inventory level whether the corresponding model is actually deployed to individual provider instances. By performing the elimination of eligibility before determining the ranking in this way, the problem of candidates that cannot be called or candidates with extreme values ​​distorting the normalized distribution is prevented.

[0045] The candidate eligibility determination unit (121) grants a verified free grade when multiple independent cost metadata, including the cost value, free indication information, estimated cost, and billing mode of each generated resource candidate, match each other. The verified free grade is granted when all conditions are satisfied, such that the cost value is zero, the free indication information is true, the estimated cost is zero, and the billing mode corresponds to user-verified free or billing-verified zero. The candidate eligibility determination unit (121) does not make a free determination based on a single cost value or a prefix of a candidate identifier.

[0046]

[0048] Here, F is a classification value indicating whether a verified free tier is assigned; if 1, a verified free tier is assigned, and if 0, it is not assigned. c is the candidate cost value, a real number greater than or equal to 0, in United States dollars. m is free indication information, a classification value having a value of 1 if true and 0 if false. e is the estimated cost, a real number greater than or equal to 0, in United States dollars. b is a classification value indicating the billing mode, and B_ok is an allowed set whose elements are User Verified Free and Billing Verified Zero. I(·) is an indicator function that returns 1 if the condition inside the parentheses is true and 0 if it is false.

[0049] For example, if c = 0, m = 1, e = 0 and b corresponds to the billing verification zero, then F = 1 1 1 1 1 1 = 1, and a verified free grade is assigned. However, if c = 1.20, unlike the catalog free notation, then I(c = 0) = 0, so F = 0 and a verified free grade is not assigned.

[0050] According to this configuration, even when there is a discrepancy between the free designation in the catalog and the actual billing, a technical effect can be achieved by preventing the problem of misclassifying candidates for actual charges as free through mutual matching verification of multiple fields. For example, some candidates marked as free in the catalog may actually be reclassified as candidates for per-transaction charges, and mutual matching verification of multiple cost metadata blocks such misclassification in advance. Meanwhile, in another embodiment, the number of cost metadata used for mutual matching determination can be expanded to three or more, and the configuration can be implemented by assigning a confidence level to each field and conservatively treating missing values ​​in some fields as unverified.

[0051] The evidence integrity verification unit (122) verifies the integrity hash, freshness, minimum sample size, coverage, and quality threshold of the performance evidence of the candidate remaining after the removal of the candidate eligibility determination unit (121) to exclude small sample, tampered, or old evidence. The integrity hash verification checks whether the hash value of the source file of the performance evidence matches the stored reference hash, and the freshness verification checks whether the time of production of the performance evidence is within a set validity period, and the freshness validity period can be set to thirty days, for example. The minimum sample size verification checks whether the number of completed samples is greater than or equal to the minimum sample size, and the minimum sample size is a lower limit value for including the candidate in the ranking determination, and can be set to twenty samples, for example. The coverage verification checks the degree of inclusion of evidence for the required category, and the quality threshold verification checks whether the quality score exceeds a set lower limit, and the lower limit of the quality score can be set to 0.6, for example. Raising the minimum sample size reduces the number of candidates participating in the ranking but increases statistical reliability, while lowering it increases the number of candidates but increases the risk of small sample luck being reflected.

[0052] The evidence integrity verification unit (122) maintains an automatic approval threshold by binding it to the hash value of the source file from which the threshold was derived and the formula version. The automatic approval threshold stores the hash value of the source file from which the threshold was calculated and the version identifier of the formula together. The evidence integrity verification unit (122) performs a conditional branch to disable automatic processing when, at the time of operation, the current formula version is inconsistent with the stored formula version, the hash value of the source file is inconsistent with the stored hash value, or drift of the threshold itself is detected. At this time, threshold drift is determined to be when the difference between the threshold currently maintained and the threshold re-derived from the source file exceeds a set allowable deviation, and the allowable deviation can be set to 0.02 based on a normalized threshold, for example.

[0053]

[0055] Here, A is a classification value indicating whether automatic processing is enabled; if 1, automatic processing is enabled, and if 0, it is disabled. v is the current formula version identifier at the time of operation, and v0 is the formula version identifier stored together with the automatic approval threshold. h is the hash value recalculated for the source file, and h0 is the reference hash value stored together with the automatic approval threshold. is a normalized threshold re-derived from the source file, which is a real number between 0 and 1, and 0 is the currently maintained normalized threshold value, which is a real number between 0 and 1. δ is the allowable deviation of the threshold drift, which is a real number between 0 and 1 and is set to, for example, 0.02 based on the normalized threshold value. I(·) is an indicator function that returns 1 if the condition inside the parentheses is true and 0 if it is false.

[0056] For example, the formula version and the hash match respectively, and = 0.71, If 0 = 0.70, δ = 0.02 since This enables automatic processing, In the case where = 0.74 Since A = 0, automatic processing is disabled.

[0057] According to this configuration, technical effects can be achieved to prevent the problem of replacement of the basis file, manual editing of the policy, or change of the formula passing through the automatic approval path asymptomatically, and to ensure the traceability of the threshold basis. In other words, the problem of unverified approvals occurring because automatic processing continues with the past threshold even though the basis and formula of the threshold have changed is blocked. Meanwhile, in another embodiment, the hash value of the basis file can be calculated using a 256-bit secure hash algorithm, and the configuration can be implemented to perform signature verification together by maintaining the binding relationship between the threshold and the basis in the form of a policy digest.

[0058] The candidate ranking unit (123) determines the order of candidates by applying a fixed standard normalization score or a deterministic policy order to candidates who have passed the verification of the evidence integrity verification unit (122). Fixed standard normalization is performed in such a way that the addition or removal of candidates does not change the absolute score of existing candidates, which is achieved by normalizing each candidate's score against a fixed standard value rather than the distribution of other candidates. For example, the throughput metric is normalized against hundreds of tokens per second, the latency metric is normalized against this second, and the quality score, sample pass rate, and normalized throughput and latency metric are combined with different proportions of contribution to form a base score.

[0059]

[0061] Here, S_base is the candidate's base score, a scalar normalized from 0 to 1. q is the quality score, a normalized value from 0 to 1, and p is the pass rate, a normalized value from 0 to 1. t is the candidate's throughput metric, a real number greater than or equal to 0 in tokens per second, and t_ref is the throughput normalization threshold, for example, 100 tokens per second. l is the candidate's latency metric, a real number greater than or equal to 0 in seconds, and l_ref is the latency normalization threshold, for example, 2 seconds. w_q, w_p, w_t, and w_l are the contribution weights of each term, each a real number greater than or equal to 1, and their sum is 1. min is a function that returns the smaller value among the values ​​inside the parentheses, and max is a function that returns the larger value among the values ​​inside the parentheses. The normalization criteria values ​​t_ref and l_ref are fixed constants independent of the distribution of other candidates, ensuring that the addition or removal of candidates does not change the S_base of existing candidates.

[0062] for example, And, since, It becomes.

[0064] The candidate ranking unit (123) performs reordering by reflecting a runtime correction signal within a set range after passing through the minimum sample gate, and the reflection weight of the runtime correction signal can be set to, for example, 0.15, and the minimum runtime sample can be set to twenty samples. At this time, the reflection weight of the runtime correction signal is adjusted within a range of zero or more and one or less. If this value is increased, recent operational performance is strongly reflected in the order, but the stability of reference evidence decreases, and if it is lowered, the stability of reference evidence increases, but the responsiveness to recent performance changes decreases. In addition, the runtime correction is reflected only after passing through the minimum sample gate, and the accumulated correction amount is limited so as not to exceed a set upper limit, thereby preventing excessive accumulation.

[0065]

[0067] Here, S is the final score of the candidate with runtime correction applied, a scalar normalized from 0 to 1. S_base is the base score of the candidate calculated based on a fixed standard according to Equation 3, a normalized value from 0 to 1. α is the reflection weight of the runtime correction signal, a real number from 0 to 1; as the value increases in the positive direction, the degree to which recent operational performance r is reflected in the final score S increases, for example, it is set to 0.15 and maintained within the range of 0.3 or less to prevent excessive reflection. r is the runtime correction signal representing recent operational performance, a normalized value from 0 to 1. n is the number of secured runtime samples, an integer greater than or equal to 0, and n_min is the minimum number of runtime samples required to reflect runtime correction, for example, 20. I(·) is an indicator function that returns 1 if the condition inside the parentheses is true and 0 if it is false, and invalidates the correction if the runtime samples fall short of the minimum number of samples.

[0068] for example, The order is determined solely by the weight of the basic score.

[0069] Meanwhile, in another embodiment, the candidate ranking unit (123) may apply a deterministic policy order based on a priority rule defined in policy instead of a normalized score, which may be implemented as a rule-based order such as prioritizing free resources or using paid resources after explicit approval.

[0070] The immutable execution plan generation unit (124) binds the candidate order determined by the candidate ranking unit (123) to the request selector fingerprint, configuration revision, and evidence diagnosis to fix it as an immutable execution plan. The request selector fingerprint is calculated as a canonical hash for the provider selector and routing metadata, the configuration revision is calculated as a canonical hash of the current configuration, and the evidence diagnosis includes the identifier and version of the evidence used for ranking determination. The immutable execution plan generation unit (124) recursively fixes the final candidate order, request selector fingerprint, configuration revision, and evidence diagnosis to maintain them in a state that is not changed in subsequent execution steps.

[0071] The plan-match verification and execution control unit (125) rejects execution without performing replanning if the request or setting at the time of execution is inconsistent with the immutable execution plan fixed by the immutable execution plan generation unit (124). The plan-match verification and execution control unit (125) compares whether the routing selector fingerprint of the current request matches the request selector fingerprint of the immutable execution plan, and whether the canonical hash of the current setting matches the setting revision of the immutable execution plan. If either of these is inconsistent, execution is rejected, and in this case, recalculation of candidate rankings or re-searching of provider status is not performed. The plan-match verification and execution control unit (125) sequentially executes the candidate order fixed in the immutable execution plan within a single absolute deadline and a shared call budget. According to this configuration, technical effects can be obtained to prevent setting drift, where the setting changes between the time of plan establishment and the time of execution, and errors caused by inconsistency between the time of inspection and the time of use.

[0072] FIG. 4 is a block diagram showing the detailed configuration of a single-point policy gate, a response contract-based recovery unit, a capability-aware instance selection unit, and a reference asset slot integrity verification unit included in the processor. Referring to FIG. 4, the single-point policy gate (126) functions as a hub, and the policy evaluation result of the single-point policy gate (126), the recovery result of the response contract-based recovery unit (127), and the reference set configured by the reference asset slot integrity verification unit (129) are each transmitted to the capability-aware instance selection unit (128). When the response contract-based recovery unit (127) determines that a transfer to the next candidate is made during the recovery process, it transmits the identification information of the candidate to the single-point policy gate (126), and the single-point policy gate (126) forms a closed loop by performing a policy evaluation prior to dispatch again on the transferred candidate.

[0073] The single-point policy gate (126) evaluates billing, licensing, consent, and retry policies at a single execution point prior to dispatching a creation request, and returns the selection reason and the blocking reason in a machine-readable form when blocked. The billing evaluation checks for the existence of explicit consent for paid, metered, and unverified costs; the licensing evaluation checks for the eligibility of the usage context and the explicit consent together; the consent evaluation checks for the existence of consent for the use of voice and facial identity; and the retry evaluation checks for the approval of submission retries that cause duplicate billing. The single-point policy gate (126) allows commercial use when the eligibility of the usage context and the explicit consent are both satisfied, and commercial use is not bypassed by a single approval parameter. The single-point policy gate (126) maintains the retry budget for creation submissions separately from the retry budget for lookup and sets the default value of the retry budget for creation submissions to zero. The selection reason and the blocking reason are simultaneously generated as a set of machine-readable reasons, for example, the selection reason includes items such as preference for free generated resources, and the blocking reason includes items such as a request for explicit approval from a paid provider or a request for benchmark evidence for quality optimization. By enforcing policy decisions in this way at a single execution point of the common generation path prior to dispatch, the problem of policy decisions being distributed across provider-specific codes and causing bypass paths is reduced. Meanwhile, in another embodiment, the single-point policy gate (126) may be implemented in a configuration that externalizes policy rules into a policy description language and delegates them to the policy engine.

[0074] The reference asset slot integrity verification unit (129) combines costume assets, location assets, and face anchor assets corresponding to scene numbers and appearing characters according to priority, removes duplicates, and forms a reference set up to the reference input upper limit. The priority of combination is applied in the order of costume assets, location assets, and face anchor assets. The reference asset slot integrity verification unit (129) forms a reference set by selecting assets up to the reference input upper limit of the generation model after removing unregistered asset identifiers and duplicate assets. After forming the reference set, the reference asset slot integrity verification unit (129) verifies whether the slot assignment of each reference asset does not exceed the reference input upper limit of the target generation model, and if it exceeds, excludes assets with lower priority to determine the size of the reference set. The reference asset slot integrity verification unit (129) calculates the asset identifier, asset type, and integrity hash of each asset assigned to the reference slot as a reference descriptor, and the reference descriptor is subsequently used for comparison with the response. The reference asset slot integrity verification unit (129) maps the character of the prompt to the owner of the reference slot and determines that if the owner and the character do not match, it is a swap error, corrects the prompt, and performs re-verification. If the mismatch is not resolved even after re-verification, it blocks the submission of the creation request. The number of reference slots is an integer value defined in the capability profile and has a value greater than or equal to zero, and the reference input upper limit is an integer value representing the maximum number of reference inputs accepted by the creation model. According to this configuration, the technical effect of blocking slot contamination where reference assets of different characters are mixed up before submission is achieved, and preventing errors caused by unregistered assets or assets exceeding the upper limit being included in the creation request.

[0075] The capability-aware instance selection unit (128) is a component that checks, at the inventory level, whether a model is actually deployed to an individual provider instance for a candidate whose capability is determined at the model level by the candidate eligibility determination unit (121). The capability-aware instance selection unit (128) queries the capability profile for each candidate provider instance and selects only instances that support the requested generation type, number of reference slots, and output format as execution targets. The capability profile is a data structure that includes a set of generation types supported by each provider instance, an acceptable number of reference slots, a set of supported output formats, and a set of supported resolutions. The capability-aware instance selection unit (128) excludes the instance from execution targets if the number of slots in the reference set configured by the reference asset slot integrity verification unit (129) exceeds the number of reference slots of the candidate instance, and also excludes the instance if the requested output format is not included in the set of supported output formats. At this time, since the size of the reference set is determined in advance by the reference asset slot integrity verification unit (129), the capability-aware instance selection unit (128) excludes only instances that cannot accommodate the determined reference set from the execution target without further excluding reference assets. The capability-aware instance selection unit (128) constructs a creation request for the selected execution target instances by combining the reference set and request parameters. The capability profile may be provided as a static setting or implemented as a data structure that is dynamically updated from the status inquiry response of the provider instance. The capability-aware instance selection unit (128) verifies whether a set of requirement models corresponding to the required task and style is included in the inventory of each instance, returns an undistributed diagnosis if there are no instances with the capability, returns an idle absence diagnosis without performing submission if all instances with the capability are in use, and selects the instance with the minimum queue load among the instances with the capability that are idle.This configuration secures throughput by preventing meaningless submissions to incapable instances and queue spikes in advance, and achieves the technical effect of reducing creation failures caused by capability mismatches and the resulting retries and wasted costs.

[0076] The response contract-based recovery unit (127) verifies whether the generated response satisfies a predefined response contract and performs a type-specific recovery procedure for responses that do not satisfy the response contract. The response contract is a specification that defines the essential fields that a response must possess, the correspondence relationship with reference assets, and integrity conditions. The response contract-based recovery unit (127) verifies whether the reference asset is reflected by comparing the reference descriptor included in the generated response with the reference descriptor calculated by the reference asset slot integrity verification unit (129), and if there is a mismatch, performs a re-request procedure through reference slot reassignment or reference set reconstruction. The response contract-based recovery unit (127) classifies the types of deficiencies in the response into partial deficiencies, format mismatches, and non-reflection of references, performs a request for supplementation limited to the deficient part for partial deficiencies, and performs a format conversion or format specification re-request for format mismatches. The response contract-based recovery unit (127) limits the number of times a type-specific recovery procedure is performed to within the scope of the previously defined shared call budget and absolute deadline, and returns failure with a machine-readable set of reasons if the recovery is not successful and the budget or deadline is exhausted.

[0077]

[0079] Here, R is a classification value indicating whether additional recovery procedures are allowed; if 1, the recovery procedure is performed, and if 0, failure is returned. k is the cumulative number of recovery procedures performed to date, which is an integer greater than or equal to 0, and K_max is the upper limit for the number of recovery procedures performed, which is an integer greater than or equal to 1, for example, 3. C_used is the cumulative call cost consumed to date, which is a real number greater than or equal to 0, c_k is the estimated call cost of the next recovery procedure, which is a real number greater than or equal to 0, and C_budget is the shared call budget, which is a real number greater than or equal to 0, with the unit being the call cost unit. T_now is the elapsed time from the start of the execution plan to the present, τ_k is the estimated time required for the next recovery procedure, and T_deadline is the allowed time until the absolute deadline set based on the above start time; T_now is the estimated time, and τ_k and T_deadline are all real numbers greater than or equal to 0 with the unit being seconds. I(·) is an indicator function that returns 1 if the condition inside the parentheses is true and 0 if it is false.

[0080] for example,

[0081] If, Therefore, R = 1, so an additional recovery procedure is performed, and the accumulated cost increases to C_used = 0.9, If this happens, Therefore, R = 0, and it returns failure with a machine-readable set of reasons.

[0083] The response contract-based recovery unit (127) identifies failure types including format errors, language mismatches, temporary transmission errors, authentication errors, rejection responses, and policy rejections in the verification of the response contract, and for format errors, selects a first recovery that performs re-verification after deterministic cleanup, for language mismatches selects a second recovery that requests a correction request with strengthened constraints, for temporary transmission errors selects a third recovery that transfers to the next candidate after a limited transmission retry within the allowed budget range, for policy rejections selects a fourth recovery that preserves the diagnosis and excludes the candidate without repeated retries, and for authentication errors and rejection responses selects the next candidate by bypassing general retries. At this time, when transfer to the next candidate is decided, the response contract-based recovery unit (127) transmits the identification information of the candidate to the single-point policy gate unit (126), and the single-point policy gate unit (126) ensures that execution is carried out only after re-performing the policy evaluation prior to dispatch for that candidate. In this way, by verifying whether the response satisfies the contract and performing a recovery procedure corresponding to the type of loss, the problem of the requested reference asset or required field not being reflected despite receiving a formal response is reduced, and a technical effect is obtained that prevents waste of costs and infinite retries caused by uniform retries regardless of the cause of failure. Meanwhile, in another embodiment, the response contract-based recovery unit (127) may be implemented with a configuration that manages the number of recovery attempts for each type of failure as an individual upper limit and escalates the diagnosis to a higher management system when the upper limit is exceeded.

[0084] The snapshot verification unit (130) maintains the expected candidate profile, expected final order, and exclusion list as reference fixed values, and compares the candidate order at the time of operation with the reference fixed values ​​to detect drift when it is detected, and performs a fallback to restore the previous basis and policy. The expected candidate profile is a request profile determined in advance for a representative request, the expected final order is the candidate order expected to be calculated by the candidate ranking unit (123) for the corresponding request, and the exclusion list is a list of candidates expected to be excluded due to ineligibility or insufficient evidence. The snapshot verification unit (130) compares the candidate order and exclusion list calculated at the time of operation with the reference fixed values, and determines that drift has occurred if either one is different. When drift is detected, the snapshot verification unit (130) stops the application of the changed evidence and policy and performs a fallback to restore the basis file and policy version verified immediately before, and records the detection details and restoration results as a diagnosis in the evidence and policy database (400). For example, if the expected final order is the order of the first candidate, the second candidate, and the third candidate, but the candidate order at the time of operation is calculated as the second candidate, the first candidate, and the third candidate, it is determined to be drift and restored to the previous policy. According to this configuration, even if a change in evidence or policy causes the routing result to change in an unintended direction, a technical effect is obtained in that it can be detected before being reflected in operation and restored to a verified state. Meanwhile, in another embodiment, the snapshot verification unit (130) may be configured to maintain a reference fixed value for a plurality of representative requests and to perform a fallback only when the ratio of representative requests in which drift is detected exceeds a set reference.

[0085] Each component described above may be implemented as a software module, a hardware circuit, or a combination thereof, and may be integrated within a single processor or distributed across multiple processors. The candidate eligibility determination unit (121), evidence integrity verification unit (122), candidate ranking determination unit (123), immutable execution plan generation unit (124), plan match verification and execution control unit (125), single point policy gate unit (126), response contract-based recovery unit (127), capability awareness instance selection unit (128), reference asset slot integrity verification unit (129), and snapshot verification unit (130) included in the processor (120) exchange data with each other and share the previously described request selector fingerprint, configuration revision, evidence diagnosis, shared call budget, absolute deadline, and reference descriptor as a common execution context. Through this integrated execution context, the fixation of routing decisions, single-point execution of policies, capability-based screening, verification of reference asset integrity, and verification of response contracts are performed in a single consistent execution path, thereby achieving the technical effect of comprehensively preventing complex errors caused by configuration drift, discrepancies between inspection and usage times, capability mismatches, and non-reflection of references.

[0086] Meanwhile, the arrangement and data flow of each component described above are exemplary, and in other embodiments, the processing order of the immutable execution plan generation unit (124) and the single point policy gate unit (126) may be adjusted, or the reference asset slot integrity verification unit (129) and the capability awareness instance selection unit (128) may be combined into a single integrated verification unit. Even in these modified configurations, the technical concept of ensuring consistency at the time of execution by sharing the request selector fingerprint, configuration revision, and reference descriptor as a common execution context applies equally.

[0087] Referring to FIG. 5, FIG. 5 is an example diagram showing a data structure maintained in memory (140) during the processing of a content creation request, and includes a candidate evaluation record (51) and an immutable execution plan record (54). The candidate evaluation record (51) is a table-shaped data structure having columns for each creation resource candidate, a candidate identifier, an eligibility determination result (52), an evidence hash and freshness (53), a sample size and coverage, a normalized score, and a confirmed order.

[0088] The eligibility determination result (52) is a field containing the indication of eligibility or ineligibility determined by the candidate eligibility determination unit (121) based on policy, function, resource, and status criteria, along with the reason thereof. For example, for a candidate that does not satisfy policy conditions, the reason for non-compliance with policy is recorded along with the indication of ineligibility, and the candidate is removed before the candidate ranking is determined. The evidence hash and freshness (53) is a field containing the integrity hash value of the performance evidence compared by the evidence integrity verification unit (122) and whether it is fresh at the time of calculation. Candidates whose freshness has expired or whose sample size falls short of the minimum sample size do not have a normalized score calculated and are marked as excluded. For example, a candidate with a fresh evidence hash, a sample size of 120, and a coverage of 0.91 is assigned the first rank with a normalized score of 0.87, while a candidate with an old evidence hash and a sample size of only 9 is marked as excluded and is not assigned a rank.

[0089] The immutable execution plan record (54) is a data structure generated by the immutable execution plan generation unit (124) and stored in memory (140), and has fields for a plan identifier, candidate order (55), request selector fingerprint, set revision, evidence diagnosis binding, absolute deadline, and shared call budget (56). The candidate order (55) is the execution order of candidates determined deterministically by the candidate ranking unit (123), and is fixed, for example, in the order from the first candidate through the second candidate to the fifth candidate. The shared call budget (56) is an upper limit on the number of calls shared by all candidates when the plan match verification and execution control unit (125) sequentially executes the candidate order, and is recorded together with the default value of the retry for generation submission set to zero. The request selector fingerprint and set revision serve as reference values ​​that the plan match verification and execution control unit (125) compares at the time of execution, and the evidence diagnosis binding enumerates the hash values ​​of the evidence used for ranking determination to preserve the correspondence relationship between the plan and the evidence. The processor (120) maintains the candidate evaluation record (51) and the immutable execution plan record (54) in memory (140) in a cross-referenced form.

[0090] Referring to FIG. 6, FIG. 6 is an example illustration showing a process scene in which a content creation request is processed, and includes each phase of a creation request (61), a single execution point (62), a block and reason return (63), an idle instance (64), and a response contract failure (65). The creation request (61) represents a creation request that is sequentially issued by the plan-matching verification and execution control unit (125) according to a candidate order fixed in an immutable execution plan, and corresponds to a state in which multiple candidates are waiting in a confirmed order.

[0091] The single execution point (62) represents a phase in which the single point policy gate (126) evaluates billing, licensing, consent, and retry policies at a single point prior to dispatch, and a creation request is dispatched only if the evaluation result is allowed, and a provider call is not performed if it is blocked. The blocking and reason return (63) represents a phase in which, if blocking is determined in the evaluation, the single point policy gate (126) returns the selection reason and the blocking reason as a machine-readable set of reasons.

[0092] Idle instance (64) represents a phase in which, for a creation request that has passed policy evaluation, the capability-aware instance selection unit (128) selects an instance with the minimum queue load from among the idle instances that have capability and dispatches it to the creation resource instance server (300) through the communication unit (110). Response contract failure (65) represents a phase in which, if the returned response does not satisfy the response contract, the response contract-based recovery unit (127) identifies the type of failure and branches to select a different recovery among deterministic cleanup, correction request, recovery model selection, and next candidate selection, and the processor (120) records the processing result and diagnosis of each phase in memory (140) and the evidence / policy database (400).

[0093] Referring to FIG. 7, FIG. 7 is an example diagram illustrating a user scenario in which a requesting user creates content through the system, and includes a content creation request (71), an immutable execution plan (72), a plan discrepancy and execution refusal (73), and a reason return and recovery guidance (74). The content creation request (71) represents a phase in which a requesting user requests to create a character image of a specific scene in a specific style through a user terminal (200), and the request is transmitted to a processor (120) via a communication unit (110) and becomes subject to selection of eligible candidates by a candidate eligibility determination unit (121) and an evidence integrity verification unit (122).

[0094] The immutable execution plan (72) indicates a state in which the immutable execution plan generation unit (124) binds the confirmed candidate order for the request to the request selector fingerprint and the setting revision, and as an example, the request selector fingerprint and the setting revision are each fixed to a specific value and maintained within the routing server (100). The plan mismatch and execution refusal (73) indicates a phase in which the plan match verification and execution control unit (125) refuses execution without performing recalculation of the candidate ranking or re-search of the provider status when the selector included in the request at the time of execution is different from the selector fixed in the immutable execution plan.

[0095] The return of reason and recovery guidance (74) represents a phase in which, regarding the above execution refusal, the routing server (100) returns the selection reason and blocking reason to the user terminal (200) in a machine-readable form, along with the refusal result citing a discrepancy with the execution plan, and the response contract-based recovery unit (127) performs a correction request and verification of the remapping of the owner and character, and if the discrepancy is not resolved even with such verification, it provides guidance to proceed with recovery to the next candidate selection. In this way, each phase from the content creation request (71) to the return of reason and recovery guidance (74) is implemented by the processor (120) reading the command stored in the memory (140) and sequentially operating each component.

[0096] The methods according to the present invention may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the computer-readable medium may be those specifically designed and configured for the present invention, or they may be those known and available to those skilled in the art of computer software.

[0097] Examples of computer-readable media may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions may include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The aforementioned hardware devices may be configured to operate as at least one software module to perform the operation of the present invention, and vice versa.

[0098] In addition, the above-described method or device may be implemented by combining all or part of its configuration or function, or by implementing it separately.

[0099] Although the present invention has been described above with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the invention without departing from the spirit and scope of the invention as described in the following claims.

Claims

Claim 1 In a multimodal creator resource routing server that performs eligibility screening and response contract-based recovery, a communication unit that receives a content creation request; a processor; and memory; wherein the processor determines eligibility for each of a plurality of generated resource candidates based on policy, function, resource, and state criteria and removes ineligible candidates prior to determining candidate rankings, wherein a verified free grade is assigned when a plurality of independent cost metadata, including a cost value, free indication information, estimated cost, and billing mode of each generated resource candidate, mutually match such that the cost value is zero, the free indication information is true, the estimated cost is zero, and the billing mode corresponds to user-verified free or billing verified zero, and the candidate eligibility determination unit is configured not to determine free based on a single cost value or a prefix of a candidate identifier; and excludes small-sample, tampered, or outdated evidence by verifying integrity hash, freshness, minimum sample size, coverage, and quality thresholds for the performance evidence of candidates remaining after removal, wherein an automatic acceptance threshold is maintained by binding it to the hash value and formula version of the source file from which the threshold was derived, and a set allowable deviation is set for formula version mismatch, source file hash mismatch, or the difference between the maintained automatic acceptance threshold and the threshold re-derived from the source file. An evidence integrity verification unit configured to disable automatic processing when a threshold drift exceeding the threshold is detected; a candidate ranking unit configured to determine the candidate order by applying a fixed standard normalization score or a deterministic policy order to candidates that have passed the verification; and an immutable execution plan generation unit configured to fix the determined candidate order as an immutable execution plan by binding it to an evidence diagnosis that includes a request selector fingerprint, which is a canonical hash for provider selectors and routing metadata; a configuration revision, which is a canonical hash of the configuration; and an identifier and version of the evidence used to determine the candidate order.A plan match verification and execution control unit configured to compare whether the routing selector fingerprint of the request at the time of execution matches the request selector fingerprint and whether the canonical hash of the setting at the time of execution matches the setting revision, and if either does not match, to reject execution without performing replanning, and if they match, to sequentially execute the candidate order fixed in the immutable execution plan within a single absolute deadline and a shared call budget; a single-point policy gate unit configured to evaluate billing, licensing, consent, and retry policies at a single execution point prior to the dispatch of a creation request, to allow commercial use if both the eligibility of the usage context and explicit consent are satisfied, to separate the retry budget for creation submission from the retry budget for lookup and set the default value to zero, and to return the selection reason and the reason for blocking in a machine-readable form upon blocking; and to combine costume assets, location assets, and face anchor assets corresponding to scene numbers and appearing characters according to priority, remove duplicates, construct a reference set up to the reference input upper limit, map the character of the prompt to the owner of the reference slot, and if the owner and the character do not match A multimodal generate resource routing server that performs eligibility screening and response contract-based recovery, characterized by comprising: a reference asset slot integrity verification unit configured to correct a prompt and perform re-verification upon determining a swap error, and to block the submission of a generate request if the discrepancy is not resolved even after re-verification; and a response contract-based recovery unit configured to perform different recovery among deterministic cleanup, correction request, recovery model selection, and next candidate selection within the scope of the shared call budget and the absolute deadline, depending on the type of response contract failure. Claim 2 delete Claim 3 A multimodal generate resource routing server for performing eligibility screening and response contract-based recovery, wherein, in claim 1, the processor further comprises a capability-aware instance selection unit configured to verify whether a set of request models corresponding to the request task and style is included in the inventory of each instance, return an undistributed diagnosis if no capable instance exists, return an idle absence diagnosis without performing a submission if all capable instances are in use, and select an instance with the minimum queue load among the capable idle instances. Claim 4 A multimodal generated resource routing server that performs eligibility screening and response contract-based recovery, wherein, in claim 1, the candidate ranking determination unit is configured to apply fixed standard normalization such that the addition or removal of a candidate does not change the absolute score of an existing candidate, and to perform reordering by reflecting a runtime correction signal within a set range after passing through a minimum sample gate. Claim 5 delete Claim 6 A multimodal generative resource routing server that performs eligibility screening and response contract-based recovery, characterized in that, in claim 1, the response contract-based recovery unit performs preprocessing to identify failure types including format errors, language mismatches, transient transmission errors, authentication errors, rejection responses, and policy rejections in the verification of the response contract, and selects a different recovery from among a first recovery that performs re-verification after deterministic cleanup according to the identified failure types, a second recovery that re-requests a correction request with stricter constraints to the same candidate or recovery model, a third recovery that transfers to the next candidate after limited transmission retries within the allowable budget range, and a fourth recovery that preserves the diagnosis and excludes the corresponding candidate without repeated retries, determines whether to repeat the recovery according to an adjustable retry budget and reliability criteria, and performs a conditional branch to select the next candidate by bypassing general retries for authentication errors and rejection responses. Claim 7 A multimodal generated resource routing server for performing eligibility screening and response contract-based recovery, wherein, in claim 1, the processor further comprises a snapshot verification unit configured to maintain an expected candidate profile, an expected final order, and an exclusion list as reference fixed values, and to detect drift when the candidate order at the time of operation is compared with the reference fixed values ​​and perform a fallback to restore to the previous basis and policy. Claim 8 A multimodal generated resource routing server that performs eligibility screening and response contract-based recovery, characterized in that, in claim 6, the response contract-based recovery unit corresponds to and performs the first recovery for the format error, the second recovery for the language mismatch, the third recovery for the temporary transmission error, and the fourth recovery for the policy rejection, respectively, and is configured to select the next candidate without performing the first to fourth recovery for the authentication error and the rejection response.

Images