CAPTCHA
Enable an AI agent to recognise a CAPTCHA gate, assess its current state and requirements, and determine whether to wait, request human completion, use an authorised alternative or report a failure.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex
Purpose and description
Enable an AI agent to recognise a CAPTCHA gate, assess its current state and requirements, and determine whether to wait, request human completion, use an authorised alternative or report a failure.
It can be Identify the CAPTCHA gate and the action it protects.; Observe challenge requirements and distinguish rejection, expiration and technical failure.; Pause the protected workflow and request human completion through the intended interface.; Select an offered accessible mode or follow a documented alternative when authorised.; Refresh or retry through supported controls when permitted, preserving the relationship between attempts.; Resume the protected workflow after confirmed acceptance or report an unresolved gate..
Distinguishing features
Its declared purpose includes distinguishing human participation from automated interaction; a password or one-time code primarily establishes access to a credential.
Its result conditions a protected interaction on a human-versus-automation assessment; a consent checkbox records agreement without making that assessment.
An interactive task is evaluated as evidence of human participation; an ordinary quiz evaluates knowledge or learning outcomes.
A non-interactive assessment belongs here only when its integration or documentation identifies it as CAPTCHA verification; a generic risk score alone is insufficient.
Passing the gate does not by itself establish a person's identity or authorisation to perform the protected action.
Scope
+ The protected action and the CAPTCHA requirement attached to it
+ Interactive challenges and explicitly identified non-interactive CAPTCHA assessments
+ Challenge presentation, response submission and verification state
+ Verification-result validity and binding to an action or session
+ Accessibility, human handoff and authorised alternative routes
+ Observed errors, rejection patterns and evidence supporting effectiveness claims
- Account authentication, identity proofing and account recovery
- General bot detection, traffic scoring and rate-limiting systems beyond their CAPTCHA interface
- The business transaction or content submission protected by the CAPTCHA
- General browser, device and network configuration
- Provider contracts and organisation-wide privacy or security governance
Characteristics
- Protected action
- Reference to the submission, request or operation gated by verification Determines what completion permits and prevents treating verification as unrestricted permission.
- Interaction mode
- Interactive challenge | non-interactive assessment | adaptive combination | unknown Determines whether a visible task, background assessment or escalation must be represented.
- Challenge modality
- Text | image selection | audio | pointer interaction | mixed | no visible task | other | unknown Identifies the interaction demands and relevant accessibility routes.
- Verification state
- Not requested | loading | awaiting interaction | evaluating | accepted | rejected | expired | unavailable | unknown Separates incomplete interaction, negative decisions and technical failures.
- Assessment output
- Pass/fail | score with documented scale | other documented result | unavailable Prevents interpreting a provider score as acceptance without the relying service's decision rule.
- Verification binding
- Documented or observed association with an action, session, origin or request; unknown where unverified Determines where a result applies and whether another attempt needs separate verification.
- Remaining validity
- Seconds, when exposed or documented; otherwise unknown Determines whether an accepted result may expire before the protected action completes.
- Attempt completion time
- Seconds from presentation to terminal outcome, with waiting time and observation boundaries recorded Makes completion burden and stalled attempts assessable.
- Alternative completion route
- Reference to an offered accessible challenge, human handoff, support route or documented exemption; none observed | unknown Identifies legitimate next steps when the presented route cannot be completed.
- Execution authority
- Human completion required | authorised automated test context | documented alternative permitted | unclear Constrains agent action independently of technical capability.
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 5 bundles · 10 layers · 10 findings · 20 questions.
Gate purpose and boundary Establishes why this interaction is a CAPTCHA and what operation its decision controls.
An agent must distinguish human-participation verification from authentication, consent and ordinary form validation.
CAPTCHA identification
Records evidence that the encountered mechanism performs CAPTCHA verification.
Human-participation claim
Records the stated verification purpose and evidence supporting classification, including non-interactive implementations.
- What interface text or integration documentation identifies this mechanism as a human-versus-automation check? definition
- What distinguishes this gate from authentication, consent, a knowledge question or a general traffic-risk assessment? boundary
Protected operation
Connects the verification requirement to the operation awaiting permission to continue.
Gate attachment
Records when CAPTCHA verification is required and the precise operation affected by its outcome.
- Which request, submission or workflow step is blocked pending verification? boundary
- Is verification always required here or triggered conditionally, and what evidence establishes that behaviour? provenance
Challenge and evidence Describes what the CAPTCHA asks the participant to do and what assessment evidence is disclosed.
Visible tasks and background assessments impose different requirements and provide different levels of observability.
Presented task
Records the actual challenge instructions and interaction demands.
Response requirements
Identifies the current modality, instructions and response controls without presuming a challenge is solvable by the agent.
- What must the participant perceive and do to respond to this challenge? definition
- Does the interface disclose multiple rounds, changing instructions or conditions for requesting another challenge? action
Assessment observability
Separates disclosed assessment inputs and outputs from hidden provider behaviour.
Disclosed assessment contract
Records documented signal categories and result semantics while preserving unknowns about internal classification.
- Which interaction, browser or device signal categories are explicitly disclosed as inputs, and by which source? provenance
- What output is exposed, and what documented meaning and scale apply to it? definition
Attempt and decision lifecycle Tracks challenge attempts through verification and application of the resulting decision.
A completed interaction, a provider result and permission to continue are distinct events that may fail independently.
Attempt progression
Records observable progress and terminal outcomes for each attempt.
Attempt state and recovery
Distinguishes waiting, evaluation, rejection, expiration and unavailability, retaining links between retries.
- What is the current attempt state, and which visible message or integration event supports it? measurement
- Which supported next action applies: wait, submit, refresh, retry, hand off or stop? action
Result acceptance
Connects the verification result to the relying service's acceptance and its validity limits.
Acceptance binding and expiry
Records whether the protected service accepted verification and the documented scope and lifetime of that acceptance.
- What confirms that the protected service accepted verification, beyond the challenge interface appearing complete? measurement
- To which action or session does the result apply, and what expiry or reuse restrictions are documented? boundary
Accessible and authorised completion Represents the participant's ability to complete the gate and the routes an agent may legitimately support.
A CAPTCHA can block a legitimate participant, and technical ability alone does not determine the agent's permitted role.
Accessibility routes
Records sensory, motor, language and timing demands alongside offered alternatives.
Completion barriers and alternatives
Connects observed completion barriers to specific accessible modes or support routes.
- Which perception, input, language or timing requirement prevents this participant from completing the current challenge? measurement
- Which offered alternative addresses that barrier, and is it currently usable? action
Agent role and handoff
Establishes the permitted agent role and how human completion returns control to the workflow.
Permitted completion path
Records whether human completion, an authorised test mechanism or another documented route applies.
- What instruction or documented integration policy establishes who may complete this gate and by which route? provenance
- How can the agent request human completion, preserve the pending operation and detect when continuation is permitted? action
Effectiveness and operational burden Records evidence about classification quality, legitimate-user burden and failures affecting the gate.
The presence of a CAPTCHA does not establish its effectiveness or show whether failures arise from classification or infrastructure.
Classification evidence
Captures measured outcomes with their populations, conditions and uncertainty.
Acceptance and rejection quality
Records supported estimates of legitimate-participant rejection and automated-interaction acceptance without treating provider claims as local measurements.
- What evidence measures rejection of legitimate participants or acceptance of automated interactions, and how was ground truth established? measurement
- Which deployment, challenge version, population and observation period does that evidence cover? boundary
Completion cost and failure
Records time, retries, abandonment and service problems that affect completion.
Burden and failure attribution
Separates challenge difficulty and negative assessment from loading, connectivity and integration failures.
- What completion times, challenge-round counts, retry counts or abandonment observations are available, and for which participants? measurement
- What evidence distinguishes a rejected response from a provider outage, blocked resource or relying-service verification error? provenance
What the second pass must settle
- Does the registry intend CAPTCHA to include all provider-labelled non-interactive assessments, or only mechanisms that present or can escalate to a human challenge?
- Should reusable CAPTCHA configurations and individual verification attempts be separate related models or two levels within this model?
- Which provider-specific states, score meanings, expiry rules and result bindings can be mapped consistently without losing distinctions needed for action?
- Which accessibility alternatives are demonstrably usable across different sensory, motor, cognitive and language requirements?
- What independent deployment-specific evidence is available for effectiveness, legitimate-participant rejection and completion burden?