| AI suitability assessment |
Determining whether AI is needed for a task, what form is simplest if needed, and whether conditions are met to build it now. |
| Ladder of solutions |
A framework arranged from lightweight to heavyweight solutions: from rules and lookups at the bottom rung, through search, classification and prediction models, generative model calls, and workflows, up to agents at the top rung. If an objective can be achieved with a lower rung, a higher rung is not chosen. |
| Rules and lookups |
A method of handling tasks with fixed inputs and rules that yield a single result through conditional branching or database queries. |
| Retrieval-augmented generation |
An architecture that retrieves source documents through search and generates answers grounded in that evidence. Used when an answer must be synthesized based on internal company documents or up-to-date information unknown to the model; if only source text verification is required, search alone is sufficient. |
| Workflow |
Systems where LLMs and tools are orchestrated through predetermined code paths (Anthropic's definition). |
| Agent |
A system where the LLM independently determines its process and tool use. Used for open-ended problems where the number of steps cannot be predicted. |
| Routing |
A workflow pattern that classifies inputs and routes them to specialized downstream processes. |
| Evaluator-optimizer |
An iterative structure where one call produces a result and another call provides evaluation and feedback. Used when evaluation criteria are clear. |
| Automation and assistance |
Replacing human work (automation) versus supporting human work (assistance). When risks are high, assistance, where humans retain control, is common. |
| High-impact AI |
Artificial intelligence systems used in areas designated by Article 2, Subparagraph 4 of the AI Basic Act (judgment and evaluation in recruitment and loan screening, determining eligibility for public services, student evaluation, etc.) that can significantly affect life, safety, or fundamental rights. |
| Generative AI |
An artificial intelligence system that generates text, audio, images, video, etc., by imitating the structure and characteristics of input data (Article 2, Subparagraph 5 of the AI Basic Act). |
| AI business operator |
Entities that develop and provide artificial intelligence (developers) and entities that use it to provide products or services (deployers). State agencies and public institutions are also included. |
| Prior notification |
The obligation to inform users in advance that a product or service using high-impact or generative AI operates based on that artificial intelligence (Article 31, Paragraph 1 of the AI Basic Act). |
| Output labeling |
The obligation to indicate that an output of generative AI was generated by generative AI (Article 31, Paragraph 2). |
| High-impact confirmation |
A procedure allowing a business operator to review in advance whether a system qualifies as high-impact AI and, if necessary, request confirmation from the Minister of Science and ICT (Article 33). |
| Automated decision |
A decision made by processing personal information through a fully automated system (including AI) (Article 37-2 of the Personal Information Protection Act (PIPA)). Automated administrative dispositions by administrative agencies under Article 20 of the Framework Act on Administration are excluded. If it significantly affects rights or obligations, the right to refuse arises. |
| Success criteria |
Criteria used to judge whether a feature is successful. Must include metrics, data, target values, a baseline, and measurement methods. |
| Launch-blocking criteria |
Criteria that, if not met, prevent launch even if other metrics are good. Established for items that lead to legal or contractual violations or user harm. |
| Improvement targets |
Levels to track and elevate post-launch. Established for quality items that do not disrupt usage. |
| Baseline |
The current level serving as the starting point for comparison. The performance of humans or existing systems. |
| Precision |
The proportion of actual positives among those predicted as positive. Protected in features where false alarms cause substantial harm. |
| Recall |
The proportion of actual positives successfully identified as positive. Protected in features where misses cause substantial harm. |
| False positive and false negative |
The error of judging a negative as positive, and the error of missing a positive. The metric to protect is determined by weighing the costs of both errors. |
| F1 score |
A harmonic mean metric that combines precision and recall into one. |
| Input contract |
The scope of inputs accepted by a feature (language, format, length, required information) and rules for handling out-of-scope inputs. |
| Output contract |
Rules for the format of results returned by a feature, handling empty values, and handling validation failures. |
| Structured outputs |
A capability that constrains responses to follow a specified JSON schema. It may deviate during refusals or when reaching max_tokens. |
| Schema |
A specification defining field names, formats/types, and required statuses of results. |
| TTFT |
Time to first token; the duration from sending a request until the first token emerges. Determines perceived latency for features where users wait at a screen. |
| Streaming |
A method of transmitting responses before the complete output is finished. Enhances perceived responsiveness even if total time remains the same. |
| Batch processing |
A method of aggregating high-volume requests that do not require an immediate response and processing them asynchronously to improve cost and throughput. For example, Anthropic's Message Batches API reduces costs by 50%, typically finishes within 1 hour, and expires if not completed within 24 hours (verified 2026-10-22). |
| max_tokens |
The upper limit on output tokens. Because generation halts mid-sentence or mid-structured data when reached, use it as a ceiling for cost and latency rather than for length control, and inspect the finish reason. |
| Evaluation |
A structured test measuring the performance of a model or feature. Consists of an evaluation set, scoring method, and success criteria. |
| Evaluation set |
A collection of inputs and expected outputs used for evaluation. Must represent the distribution of actual usage. |
| Edge cases |
Failure-prone cases, such as irrelevant inputs, excessively long inputs, harmful inputs, and ambiguous cases where even human judgments differ. |
| Holdout set |
A portion of the evaluation set withheld during revisions and used solely for final determination. Catches overfitting. |
| Overfitting |
A phenomenon where scores become higher than actual performance as a result of tuning to the same evaluation set. |
| Code-based scoring |
Scoring judged by code, such as exact match, substring inclusion, and schema validation. The fastest and most reliable. |
| LLM-based scoring |
Scoring where an LLM provided with a rubric judges results. Well suited for complex judgments, but reliability must first be validated against human scoring. |
| Human scoring |
Scoring evaluated by humans. The baseline for quality, but slow and expensive; used for ground-truth data and calibration. |
| Rubric |
A scoring guide specifying judgment criteria and scoring scales for each evaluation dimension to enhance grading consistency. |
| Position bias |
The tendency of LLM evaluators to vary judgments depending on the presentation order of responses. Mitigated through pairwise comparisons with swapped orders. |
| Blind comparison |
An evaluation where an evaluator compares two results side by side without knowing which version produced each. |
| Capability evaluation |
An evaluation composed of tasks not yet performed well, starting from a low pass rate. |
| Regression evaluation |
An evaluation verifying that tasks already performed well continue to be done well. The pass rate must be nearly 100%. |
| Evaluation saturation |
A state where all evaluation tasks are passed, showing no further room for improvement. |
| pass@k |
The probability of succeeding at least once out of k attempts. |
| pass^k |
The probability that all k attempts succeed. Suited for features requiring consistent quality every time. |
| Offline evaluation |
An evaluation measuring results with a prepared evaluation set without exposing them to users. |
| Online metrics |
Metrics measured in actual production (regenerations, escalation to human agent, drop-offs, reports, purchase conversions). |
| A/B testing |
An experiment randomly dividing users to compare metrics between two variants. Used when risk is low and traffic is sufficient. |
| Fabricated answers |
A failure where ungrounded content is generated as if it were fact (hallucination). Can be reduced, but cannot be eliminated. |
| Over-refusal |
A failure where even answerable questions are refused. Because it is not captured in the error rate of answers, the refusal rate on answerable questions is measured separately. |
| Format error |
A failure where not adhering to the agreed output format breaks the UI or integration. |
| Exponential backoff |
A retry strategy that increases the wait interval after each attempt. |
| Graceful degradation |
A design ensuring that core operations continue along a simpler path even if AI functionality halts. |
| Pre-approval |
An intervention method where a human verifies every result before releasing it. |
| Conditional escalation |
An intervention method where only cases with low confidence or triggered risk conditions are routed to a human. |
| Post-hoc sample inspection |
An intervention method where a sample is periodically inspected after automatic application. |
| Appeal handling |
An intervention method where a human reprocesses a case upon request from the recipient of the result. |
| Rubber-stamping |
A state where reviewers approve almost all results as-is without grounds or authority, causing oversight to fail. |
| Automation bias |
The human tendency to accept AI recommendations uncritically. Serves as a cause of rubber-stamping. |
| Strict tool input |
A setting that forces tool names and input values to adhere to defined schemas (strict tool use). |
| Trust calibration |
Calibrating the user's trust level so that they trust AI in appropriate situations and verify again when necessary. |
| Implicit and explicit feedback |
User behavior recorded in logs (implicit) and feedback intentionally left by users (explicit). |
| Background errors |
A failure where the system malfunctions, but neither the user nor the system recognizes it as an error (Google PAIR's background errors). Also called silent failures. |
| Shadow testing |
A test where a copy of live requests is sent to a new version, while returning only the existing version's results to the user. |
| Canary deployment |
A method of first deploying changes to a small percentage of live traffic with a time limit, evaluating them against a control group, and progressively expanding exposure if no issues arise. |
| Control group |
A comparison group that uses the existing version during the same period. |
| Abort criteria |
Metrics and threshold values set before launch that, when exceeded, stop expansion and trigger a rollback. Defined together with a minimum sample size for evaluation. |
| Feature flags |
A mechanism to turn features on or off or change the exposure scope without deploying code. |
| Guardrail metrics |
Metrics that must not degrade beyond an acceptable threshold during an experiment or rollout, even if target metrics improve (e.g., report rate, refund rate). |
| Model lifecycle |
Model support and deprecation status and its changes. For example, Anthropic divides models into Active, Legacy, Deprecated, and Retired, and requests sent to retired models fail. Check statuses and schedules for each vendor and serving platform. |
| Postmortem |
A record and discussion covering the sequence of events, impact, actions taken, root causes, and measures to prevent recurrence of an incident. |
| Blameless postmortem |
A postmortem focused on identifying contributing factors without blaming individuals or teams. |