Clinical Indication Scope Governance

2. Summary

Clinical Indication Scope Governance requires that every AI agent deployed in a healthcare or life sciences context operates exclusively within the clinical indications, patient populations, and therapeutic purposes for which it has been validated and approved. The agent's operational scope must be formally declared, versioned, and enforced at the infrastructure layer — not by the agent's own reasoning or by clinician assumption. Actions, recommendations, or outputs that fall outside the validated indication scope must be blocked before they reach any clinical workflow, patient record, or decision-support interface, regardless of how clinically reasonable the out-of-scope action might appear. This dimension is the healthcare-specific instantiation of AG-001 (Operational Boundary Enforcement), adapted for the regulatory, safety, and ethical requirements unique to clinical environments where scope creep carries direct patient harm risk.

3. Example

Scenario A — Diagnostic Agent Applied Beyond Validated Population: A hospital deploys an AI agent validated for detecting diabetic retinopathy in adult patients aged 18 and above using fundus photography. The agent's clinical validation study enrolled 12,400 adults across 6 sites and achieved a sensitivity of 94.2% and specificity of 91.8% for referable diabetic retinopathy. Over time, the ophthalmology department begins routing paediatric fundus images through the same agent — initially for 16- and 17-year-olds with juvenile diabetes, then progressively for children as young as 8. The agent processes the images without objection because no infrastructure-layer check validates the patient's age against the approved population. For a 9-year-old patient, the agent returns a "no referable retinopathy detected" result. The paediatric ophthalmologist defers the follow-up examination based on this result. The child has early-stage retinal changes that the agent's algorithm — trained exclusively on adult retinal morphology — fails to detect. The condition progresses for 14 months before clinical symptoms trigger re-examination. By that time, the child has irreversible visual field loss in the left eye.

What went wrong: The agent's validated indication scope was adults aged 18+ with suspected diabetic retinopathy. No infrastructure-layer enforcement prevented the agent from processing paediatric images. The department's gradual expansion to younger patients was informal and unvalidated — no re-validation study assessed the agent's performance on paediatric retinal morphology. The agent itself had no mechanism to reject out-of-scope inputs. Consequence: Irreversible visual impairment in a paediatric patient, medical negligence claim valued at £1.2 million, regulatory investigation by the medical device competent authority, suspension of the AI diagnostic programme pending scope review, reputational damage to the hospital's AI adoption programme, and Medicines and Healthcare products Regulatory Agency (MHRA) enforcement action for operating a medical device outside its intended purpose.

Scenario B — Treatment Recommendation Agent Scope Creep to Unvalidated Indication: A pharmaceutical company deploys an AI agent to assist oncologists with treatment planning for non-small cell lung cancer (NSCLC). The agent is validated against clinical trial data covering NSCLC stages IIIA through IV with specific histological subtypes (adenocarcinoma and squamous cell carcinoma). An oncologist treating a patient with stage IIB large cell neuroendocrine carcinoma of the lung — a distinct histological subtype not included in the validation data — submits the case through the treatment planning interface. The agent generates a treatment recommendation based on its NSCLC model, suggesting a combination therapy regimen that was effective for adenocarcinoma in its training data but is contraindicated for large cell neuroendocrine carcinoma due to differential chemosensitivity. The oncologist, relying on the agent's recommendation as a starting point, prescribes the regimen. The patient experiences severe adverse effects from the contraindicated therapy, requiring ICU admission for 11 days. The total additional treatment cost is £87,000, and the patient's disease progresses during the period of ineffective therapy.

What went wrong: The agent's validated scope was limited to specific NSCLC subtypes. No enforcement mechanism checked the histological subtype of the submitted case against the agent's validated indications. The agent produced a confident-looking recommendation for a case outside its competence because it had no structural awareness of its own scope boundaries. The oncologist reasonably assumed the agent would flag cases outside its scope. Consequence: Patient harm from contraindicated therapy, £87,000 in avoidable treatment costs, clinical negligence proceedings, regulatory notification of adverse event involving an AI medical device, and potential suspension of the agent across all deployment sites.

Scenario C — Multi-Jurisdictional Scope Drift in Clinical Trial Support: A contract research organisation deploys an AI agent to screen patient eligibility for a Phase III clinical trial across 14 sites in 5 countries. The trial protocol specifies inclusion criteria including age 21-65, confirmed diagnosis via a specific biomarker panel, and no prior treatment with the investigational drug class. The agent is validated against the protocol version 3.2 inclusion/exclusion criteria. During the trial, a protocol amendment (version 3.3) narrows the age range to 25-60 and adds a new exclusion criterion related to hepatic function. The amendment is implemented at 11 of the 14 sites, but 3 sites — in jurisdictions where regulatory approval of the amendment is delayed — continue operating under version 3.2. The agent is updated to version 3.3 criteria globally, causing it to reject eligible patients at the 3 sites still operating under version 3.2. Alternatively, if the agent is not updated, it screens patients at the 11 updated sites against outdated criteria, potentially enrolling ineligible patients. Four patients aged 22-24 are enrolled at updated sites through manual override of the agent's rejection, but without proper documentation. Two patients with borderline hepatic function are enrolled at non-updated sites where the new exclusion criterion is not yet enforced.

What went wrong: The agent's indication scope was not versioned per jurisdiction. A single global configuration could not accommodate jurisdictional variation in approved protocol versions. No governance mechanism enforced which protocol version applied at which site. Manual overrides lacked structured documentation. Consequence: Six potentially ineligible patients enrolled, jeopardising trial data integrity, potential regulatory hold on the trial pending data review, estimated cost of £2.3 million in trial delays, and risk of complete trial invalidation if the data integrity issues cannot be resolved.

4. Requirement Statement

Scope: This dimension applies to any AI agent that generates, contributes to, or influences clinical decisions, diagnostic outputs, treatment recommendations, patient screening, clinical trial operations, drug safety assessments, or any other activity where the agent's output affects patient care, clinical research, or health outcomes. The scope extends to agents that operate indirectly — an agent that retrieves and ranks clinical literature to inform a physician's decision is within scope because its output influences clinical judgment; an agent that automates appointment scheduling based on clinical priority is within scope because its prioritisation affects when patients receive care. The test for inclusion is whether a governance failure in the agent's scope control could result in a clinical action being taken (or not taken) based on an output the agent was not validated to produce. Administrative agents that do not influence clinical decisions — such as billing code generation from confirmed diagnoses, or facility maintenance scheduling — are outside scope unless their outputs feed into clinical workflows. The scope includes all deployment contexts: hospital systems, general practice, pharmacy, clinical trials, drug safety surveillance, and direct-to-patient digital health platforms. Cross-border deployments must account for jurisdictional variation in approved indications, as the same agent may have different approved scopes in different regulatory jurisdictions.

4.1. A conforming system MUST maintain a formal, versioned clinical indication scope declaration for each deployed agent, specifying: approved clinical indications, validated patient populations (including demographic boundaries), approved clinical settings, approved input modalities and data sources, and the regulatory basis for each approved scope element.

4.2. A conforming system MUST enforce the clinical indication scope at the infrastructure layer, independent of the agent's reasoning, such that inputs outside the validated scope are rejected before the agent processes them and outputs outside the validated scope are blocked before they reach clinical workflows.

4.3. A conforming system MUST reject agent processing when mandatory clinical context fields required for scope validation — such as patient age, diagnosis code, clinical setting identifier, or indication code — are missing, rather than defaulting to permissive processing.

4.4. A conforming system MUST version the clinical indication scope declaration using immutable version control, with every change to the scope requiring documented clinical and regulatory justification, and historical scope versions retrievable for audit.

4.5. A conforming system MUST generate a structured, machine-readable rejection record when an input or output is blocked due to scope violation, including the specific scope boundary that was breached, the clinical context of the rejected request, and a timestamp.

4.6. A conforming system MUST support jurisdiction-specific scope configurations where the same agent is deployed across multiple regulatory jurisdictions with differing approved indications, ensuring each jurisdiction's scope constraints are independently enforced.

4.7. A conforming system SHOULD implement pre-deployment scope validation testing that verifies enforcement against boundary cases — inputs at the edge of the validated population, indications adjacent to but outside the approved scope, and data from modalities similar to but distinct from the validated input type.

4.8. A conforming system SHOULD monitor scope utilisation patterns to detect informal scope expansion — increasing frequency of near-boundary inputs, rising rejection rates suggesting clinical demand for out-of-scope use, or patterns of manual overrides that circumvent scope enforcement.

4.9. A conforming system SHOULD provide clinician-facing scope transparency — clear, non-technical declarations of what the agent is validated for and what it is not validated for, accessible at the point of clinical use.

4.10. A conforming system MAY implement provisional scope expansion mechanisms where, subject to institutional review board or ethics committee approval, the agent's scope may be temporarily expanded for research purposes under enhanced monitoring, with all outputs flagged as unvalidated.

5. Rationale

Clinical Indication Scope Governance addresses one of the most dangerous failure modes in healthcare AI deployment: the use of an AI agent beyond the clinical context for which it has been validated. Unlike most software failures, out-of-scope clinical AI use can directly cause patient harm — a missed diagnosis, an inappropriate treatment recommendation, an incorrect risk stratification — and the harm may be irreversible, delayed in detection, and difficult to attribute to the scope violation.

The risk is amplified by a phenomenon specific to AI systems: they do not know what they do not know. A traditional medical device — an ECG monitor, a blood glucose meter — has physical constraints that naturally limit its use to the intended context. An AI agent has no such physical constraints. It will process any input it receives, generate outputs regardless of whether those outputs are within its validated competence, and present those outputs with the same formatting and apparent confidence as outputs well within its validated scope. A diabetic retinopathy screening agent will process a paediatric fundus image and return a result. A lung cancer treatment planning agent will process a case with a histological subtype outside its training data and generate a recommendation. The agent cannot distinguish between competent and incompetent outputs because it has no structural awareness of its own scope boundaries. This structural absence must be compensated by infrastructure-layer enforcement.

The regulatory landscape reinforces this requirement. The EU Medical Device Regulation (MDR 2017/745) requires that medical devices — including AI-based software classified as medical devices under the Software as a Medical Device (SaMD) framework — operate within their intended purpose as defined in the conformity assessment. The intended purpose defines the clinical indications, target populations, and clinical settings for which the device is approved. Operation outside the intended purpose constitutes off-label use, which shifts liability to the deploying institution and may violate the conditions of the CE marking. The FDA's regulatory framework for AI/ML-based SaMD similarly ties authorisation to specific intended uses, and the predetermined change control plan framework requires that changes to the intended use trigger a new regulatory submission.

Beyond regulatory compliance, the clinical governance rationale is equally compelling. Clinical validation studies are conducted on specific patient populations, for specific indications, using specific input data types. The performance metrics reported in these studies — sensitivity, specificity, positive predictive value, negative predictive value — are valid only within the studied population and indication. Extrapolating performance to unstudied populations is clinically unjustifiable. A retinopathy screening agent validated on adults may have substantially different performance characteristics on paediatric retinas due to differences in retinal morphology, vessel calibration, and disease presentation. A treatment planning agent validated on adenocarcinoma may produce harmful recommendations for neuroendocrine tumours due to fundamentally different tumour biology. The governance framework must prevent these extrapolations structurally, not rely on individual clinicians to verify scope compliance for every interaction.

The temporal dimension adds further complexity. Clinical evidence evolves, regulatory approvals are amended, and trial protocols are versioned. An agent's validated scope at deployment may differ from its validated scope six months later due to new clinical evidence, regulatory actions, or changes in clinical practice guidelines. Version-controlled scope declarations ensure that the governance framework tracks these changes and that the enforced scope matches the current regulatory and clinical reality at every point in time.

6. Implementation Guidance

Clinical Indication Scope Governance requires a formal scope declaration artefact that defines the agent's approved clinical boundaries, an infrastructure-layer enforcement mechanism that validates every interaction against those boundaries, and a monitoring capability that detects scope creep before it results in patient harm. The scope declaration is the clinical equivalent of AG-001's operational mandate — it defines what the agent is permitted to do in clinical terms.

Recommended patterns:

• Scope declaration as structured metadata. Define the clinical indication scope as a structured, machine-readable artefact (not a free-text document) containing: ICD-10/ICD-11 codes for approved indications, demographic boundaries (age ranges, sex, ethnicity where clinically relevant), approved clinical settings (inpatient, outpatient, emergency, primary care), approved input modalities (imaging type, lab panel, clinical note format), and regulatory approval references (CE marking certificate number, FDA clearance number, national approval identifiers). Store this artefact in the same versioned configuration system used for AG-007 governance configuration. Every field in the scope declaration maps to an enforceable check.
• Pre-processing scope gate. Implement scope validation as a pre-processing gate that evaluates the clinical context of each request before the agent processes the input. The gate extracts mandatory context fields — patient demographics, indication code, clinical setting, input modality — and validates each against the scope declaration. If any field is outside the declared scope, or if any mandatory field is missing, the request is rejected with a structured scope violation record. The gate operates in a separate service from the agent runtime, ensuring the agent never receives out-of-scope inputs.
• Jurisdiction-aware scope resolution. For multi-jurisdictional deployments, implement a scope resolution layer that determines which jurisdiction's scope declaration applies to each request. The resolution may be based on the site identifier, the patient's location, or the ordering clinician's regulatory jurisdiction. Each jurisdiction maintains an independent scope declaration, and the enforcement gate applies the jurisdiction-specific scope to each request. This pattern is critical for clinical trial deployments where protocol amendments may be approved in some jurisdictions but not others.
• Scope boundary telemetry. Instrument the scope enforcement gate to emit telemetry on every scope check, including: pass/fail, which scope boundary was closest to the input's characteristics, the margin between the input and the nearest boundary, and the rejection reason for failed checks. Aggregate this telemetry to detect scope creep patterns — increasing frequency of near-boundary inputs suggests clinical demand is pushing toward the scope boundary, and the organisation should evaluate whether formal scope expansion (with re-validation) is warranted.

Anti-patterns to avoid:

• Relying on the agent's system prompt to define scope. A system prompt instruction such as "You are validated for adult diabetic retinopathy screening only" is not scope enforcement — it is a suggestion to the agent's reasoning process. The agent may ignore, misinterpret, or override this instruction, particularly under prompt injection or context dilution. Scope enforcement must be structural.
• Validating scope by diagnosis code alone. A diagnosis code identifies the condition but does not capture the full scope context. A patient may have the correct diagnosis code but fall outside the validated population due to age, comorbidities, prior treatments, or clinical setting. Scope validation must check all declared boundary dimensions, not only the indication code.
• Treating scope as static after deployment. Clinical evidence, regulatory approvals, and clinical practice evolve continuously. A scope declaration that is not updated to reflect new evidence, regulatory actions, or protocol amendments will diverge from the actual approved scope over time, creating either over-restrictive enforcement (blocking valid use) or under-restrictive enforcement (permitting unvalidated use).
• Permissive default on missing context. When mandatory clinical context fields are missing — no patient age recorded, no indication code specified, no clinical setting identified — the system must reject the request rather than process it under the assumption that it is in-scope. Missing context is a scope violation, not an edge case to handle gracefully.
• Conflating clinical utility with validated scope. An agent may be clinically useful for an indication outside its validated scope — clinicians may observe that it produces reasonable-looking results for adjacent indications. Clinical utility without validation evidence does not constitute validated scope. Informal scope expansion based on perceived utility is the primary mechanism through which scope creep occurs, as illustrated in Scenario A.

Industry Considerations

Hospital Systems. Hospital IT departments must integrate scope enforcement with clinical workflow systems (electronic health record systems, radiology information systems, laboratory information systems) to ensure that scope-relevant clinical context is available at the point of enforcement. Integration with order entry systems enables scope validation at the time of clinical request rather than at the time of agent processing, allowing clinicians to be informed of scope limitations before committing to the AI-assisted workflow.

Clinical Trials. Contract research organisations and trial sponsors must implement jurisdiction-aware scope configurations that account for protocol version differences across sites. Scope declarations must be linked to specific protocol versions, and protocol amendments must trigger scope declaration updates with appropriate jurisdictional sequencing. Audit trails must demonstrate which scope version was active at each site at every point during the trial.

Digital Health Platforms. Direct-to-patient platforms face unique scope challenges because the patient — not a clinician — initiates the interaction. The platform must collect sufficient clinical context from the patient to perform scope validation, and must communicate scope limitations in patient-accessible language. A symptom-checking agent validated for adult common conditions must reject or redirect paediatric cases and cases suggesting serious pathology outside its validated scope.

Pharmaceutical and Drug Safety. AI agents used for pharmacovigilance signal detection or drug-drug interaction screening must have scope declarations that specify which drug classes, populations, and adverse event categories are within scope. Out-of-scope signal processing could miss safety signals or generate false signals that divert pharmacovigilance resources.

Maturity Model

Basic Implementation — The organisation has defined a clinical indication scope declaration for each deployed agent, specifying approved indications, patient populations, and clinical settings. Scope enforcement is implemented as a software check in the clinical workflow integration layer that validates key context fields (indication code, patient age) against the scope declaration before forwarding requests to the agent. Scope declarations are documented and versioned. Scope violations generate rejection records. This level meets the minimum mandatory requirements but has limitations: scope validation may not cover all boundary dimensions (e.g., validating age but not comorbidities), enforcement is in the same application layer as the clinical integration, and jurisdiction-specific scope is not yet supported.

Intermediate Implementation — Scope enforcement operates as a dedicated service independent of the agent runtime and clinical integration layer. All declared scope boundary dimensions are validated, including indication, demographics, clinical setting, input modality, and jurisdiction. Scope declarations are stored in immutable version control with change audit trails. Scope boundary telemetry is collected and analysed for scope creep detection. Clinician-facing scope transparency provides clear indication of what the agent is and is not validated for. Jurisdiction-specific scope configurations are supported for multi-site deployments. Scope violation records include sufficient detail for regulatory audit.

Advanced Implementation — All intermediate capabilities plus: scope enforcement has been validated through adversarial testing including attempts to submit out-of-scope inputs disguised as in-scope through manipulated context fields. Scope boundary telemetry drives proactive scope management — patterns of near-boundary utilisation trigger formal re-validation evaluations before informal scope creep occurs. Provisional scope expansion mechanisms support institutional review board-approved research use under enhanced monitoring. Real-time dashboards show scope utilisation across all deployments, and automated alerts fire when scope creep indicators exceed defined thresholds. The organisation can demonstrate to regulators that no clinical interaction has occurred outside the validated scope, supported by complete enforcement logs and telemetry.

7. Evidence Requirements

Required artefacts:

• Clinical indication scope declaration. The formal, versioned, machine-readable scope artefact for each deployed agent, specifying all approved indications, populations, settings, input modalities, and regulatory bases. Format: structured data (JSON, XML, or equivalent) stored in version-controlled configuration management per AG-007.
• Scope enforcement configuration. Technical configuration of the enforcement gate, including the mapping between scope declaration fields and clinical context fields, validation logic, and rejection behaviour. Format: configuration export with version identifier.
• Scope violation records. Complete log of all scope enforcement actions (both passes and rejections), including clinical context, scope boundary evaluated, result, and timestamp. Format: structured log entries in append-only storage.
• Scope change justification records. For each change to a scope declaration, the clinical justification (new validation evidence, regulatory action, protocol amendment) and the regulatory basis for the change. Format: change request documentation linked to scope declaration version history.
• Scope boundary telemetry reports. Periodic reports on scope utilisation patterns, near-boundary frequency, rejection rates, and scope creep indicators. Format: analytical reports with supporting data.
• Clinical validation evidence. The clinical validation study reports, regulatory approval documents, and performance data that establish the evidentiary basis for each element of the scope declaration. Format: study reports and regulatory submissions.

Retention requirements:

• Scope declarations and scope violation records: minimum 15 years for medical device-classified agents (aligned with EU MDR post-market surveillance requirements); minimum 10 years for clinical trial support agents (aligned with ICH-GCP requirements); minimum 7 years for other healthcare agents in regulated environments; minimum 5 years otherwise.

Access requirements:

• Producible to medical device regulators, clinical auditors, or ethics committees within 72 hours of request. Scope violation records for specific patients must be retrievable by patient identifier for clinical incident investigation. Clinical validation evidence must be available for regulatory inspection without prior notice.

8. Test Specification

Testing AG-519 compliance requires verification that the scope enforcement gate correctly validates clinical context against the scope declaration, rejects out-of-scope inputs, handles missing context appropriately, and supports jurisdictional variation.

Test 8.1: In-Scope Input Acceptance

• Stimulus: Submit 50 clinical requests with context fields (indication code, patient demographics, clinical setting, input modality) that fall clearly within the declared scope. Vary inputs across the full range of approved indications and populations.
• Expected behaviour: All 50 requests pass scope validation and are forwarded to the agent for processing. Scope enforcement logs record a pass for each request with the validated context fields.
• Pass criteria: All in-scope requests are accepted. No false rejections occur. Scope enforcement logs are complete for all 50 requests.
• Fail criteria: Any in-scope request is incorrectly rejected, or scope enforcement logs are incomplete.

Test 8.2: Out-of-Scope Input Rejection

• Stimulus: Submit 30 clinical requests with context fields that violate one or more scope boundaries: patients outside the validated age range, indication codes outside the approved indications, clinical settings not included in the scope declaration, and input modalities not validated. Include boundary-adjacent cases (e.g., patient aged 17 when the validated range is 18+).
• Expected behaviour: All 30 requests are rejected before the agent processes them. Each rejection generates a structured scope violation record identifying the specific boundary breached.
• Pass criteria: All out-of-scope requests are rejected. No out-of-scope input reaches the agent. Every rejection record identifies the correct scope boundary violation.
• Fail criteria: Any out-of-scope request passes scope validation, or any rejection record is missing or incorrectly identifies the violated boundary.

Test 8.3: Missing Context Rejection

• Stimulus: Submit 20 clinical requests with one or more mandatory context fields missing: no patient age, no indication code, no clinical setting identifier, and combinations of missing fields. Include requests where all other fields are clearly in-scope.
• Expected behaviour: All 20 requests are rejected due to missing mandatory context. The system does not default to permissive processing. Each rejection record identifies the missing field(s).
• Pass criteria: All requests with missing mandatory context are rejected. No request is processed without complete mandatory context validation.
• Fail criteria: Any request with missing mandatory context is accepted, or the system defaults to permissive processing for any missing field.

Test 8.4: Scope Version Integrity

• Stimulus: Modify the scope declaration (e.g., narrow the approved age range from 18-85 to 25-75). Submit requests that were in-scope under the previous version but are out-of-scope under the new version (e.g., patient aged 20). Verify that the system enforces the current version. Then query the historical scope version and verify it is retrievable.
• Expected behaviour: The updated scope is enforced immediately upon activation. Requests in-scope under the old version but out-of-scope under the new version are rejected. The previous scope version is retrievable from version history with its full declaration and activation timestamp.
• Pass criteria: Enforcement reflects the current scope version. Historical versions are retrievable. The change audit trail records the modification with justification.
• Fail criteria: The system enforces an outdated scope version, historical versions are not retrievable, or the change audit trail is incomplete.

Test 8.5: Jurisdiction-Specific Scope Enforcement

• Stimulus: Configure two jurisdiction-specific scope declarations for the same agent: Jurisdiction A approves indications X, Y, and Z for ages 18-80; Jurisdiction B approves indications X and Y only for ages 21-65. Submit requests from each jurisdiction with indication Z (approved in A, not in B) and with a patient aged 19 (in-scope for A, out-of-scope for B).
• Expected behaviour: Requests from Jurisdiction A with indication Z and patient aged 19 are accepted. Requests from Jurisdiction B with indication Z or patient aged 19 are rejected.
• Pass criteria: Jurisdiction-specific scope enforcement is applied correctly for all test requests. No cross-jurisdiction scope leakage occurs.
• Fail criteria: Any request is evaluated against the wrong jurisdiction's scope, or jurisdiction-specific enforcement fails for any test case.

Test 8.6: Scope Enforcement Independence from Agent Runtime

• Stimulus: Simulate agent runtime failure (process crash, unresponsive state) and verify that the scope enforcement gate continues to operate. Submit scope validation requests during the simulated failure. Additionally, attempt to modify the scope enforcement configuration from the agent runtime context.
• Expected behaviour: The scope enforcement gate operates independently of the agent runtime. Scope validation continues during agent failure (requests are validated and either queued for the agent's recovery or rejected if the agent is unavailable). The agent runtime cannot modify scope enforcement configuration.
• Pass criteria: Scope enforcement operates during agent runtime failure. The agent cannot alter scope enforcement configuration or bypass scope validation.
• Fail criteria: Scope enforcement fails when the agent runtime fails, or the agent runtime can influence scope enforcement configuration.

Test 8.7: Scope Violation Record Completeness

• Stimulus: Trigger 15 scope violations across different boundary types (age, indication, setting, modality, jurisdiction). For each violation, verify that the scope violation record contains: timestamp, patient context (anonymised identifiers sufficient for audit), the specific scope boundary breached, the value that breached the boundary, the active scope declaration version, and the requesting clinical system identifier.
• Expected behaviour: Every scope violation generates a complete, structured record with all required fields. Records are stored in append-only storage that cannot be modified or deleted by clinical users or the agent.
• Pass criteria: All 15 violation records are complete with all required fields. Records are stored in append-only storage. No record can be modified after creation.
• Fail criteria: Any violation record is incomplete, any required field is missing, or records can be modified or deleted.

Conformance Scoring

• Score 0: No clinical indication scope governance exists — agents process clinical inputs without scope validation and produce outputs for any indication or population without enforcement.
• Score 1: A clinical indication scope declaration exists and scope enforcement is implemented as a software check in the clinical integration layer. Out-of-scope inputs are rejected for at least the primary scope dimensions (indication code, patient age). Scope violation records are generated. However, enforcement may not cover all scope dimensions, may not be independent of the agent runtime, and jurisdiction-specific scope is not supported.
• Score 2: Scope enforcement is implemented as an independent service covering all declared scope dimensions. Scope declarations are version-controlled with change audit trails. Missing context triggers rejection. Jurisdiction-specific scope is supported. Scope violation records are complete and stored in append-only storage. Clinician-facing scope transparency is provided.
• Score 3: All Score 2 capabilities plus adversarial testing of scope enforcement, scope boundary telemetry with scope creep detection, provisional scope expansion under ethics committee oversight, and demonstrated regulatory audit readiness with complete enforcement logs across all deployments.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management), Article 13 (Transparency), Annex III (High-Risk AI Systems)	Direct requirement
EU MDR	2017/745 Article 2(1) (Intended Purpose), Annex I Chapter I (General Requirements)	Direct requirement
HIPAA	45 CFR § 164.514 (Minimum Necessary Standard)	Supports compliance
FDA 21 CFR Part 11	Electronic Records; Electronic Signatures	Supports compliance
NIST AI RMF	MAP 1.5 (Deployment Context), GOVERN 1.1 (AI Risk Management)	Supports compliance
ISO 42001	Clause 6.1.2 (AI Risk Assessment), Clause 8.2 (AI Impact Assessment)	Supports compliance
DORA	Article 11 (ICT Risk Management Framework)	Indirect requirement

EU AI Act — Article 9, Article 13, Annex III

The EU AI Act classifies AI systems used in healthcare as high-risk under Annex III, Section 5(a), specifically AI systems intended to be used as medical devices. Article 9 requires providers of high-risk AI systems to establish and implement a risk management system that identifies and analyses known and reasonably foreseeable risks associated with the system. Operation outside the validated indication scope is a foreseeable risk that the risk management system must address. Article 13 requires that high-risk AI systems are designed to ensure transparency, including information about the characteristics, capabilities, and limitations of the system. The clinical indication scope declaration is a critical transparency artefact — it informs users of what the system is validated for and, equally importantly, what it is not validated for. AG-519 at Score 2 or above provides substantial evidence for conformity with Articles 9 and 13 in the healthcare domain.

EU MDR — 2017/745 (Intended Purpose)

The EU Medical Device Regulation defines "intended purpose" as the use for which a device is intended according to the data supplied by the manufacturer, including the medical condition to be diagnosed, treated, or monitored, the intended patient population, and the intended user. Article 2(1) makes intended purpose a foundational regulatory concept — the entire conformity assessment, clinical evaluation, and post-market surveillance framework is structured around intended purpose. AG-519's clinical indication scope declaration is the operational implementation of intended purpose. Scope enforcement ensures that the device operates within its intended purpose in production. Operation outside the intended purpose voids the CE marking and shifts liability to the deploying institution. AG-519 at Score 2 provides the operational controls that implement and enforce the MDR intended purpose requirement in deployed AI medical devices.

HIPAA — 45 CFR § 164.514 (Minimum Necessary Standard)

The HIPAA Minimum Necessary Standard requires that covered entities limit the use and disclosure of protected health information to the minimum necessary to accomplish the intended purpose. While AG-519 is primarily concerned with clinical scope rather than data scope, the principles are aligned: an agent operating outside its validated indication scope is, by definition, processing patient data for a purpose beyond the intended purpose for which the data was collected and for which the patient's consent was obtained. Scope enforcement supports HIPAA compliance by ensuring that patient data is processed only within the validated purpose context.

FDA 21 CFR Part 11 — Electronic Records; Electronic Signatures

FDA 21 CFR Part 11 establishes requirements for electronic records and electronic signatures, including requirements for audit trails, record integrity, and access controls. AG-519's requirements for versioned scope declarations, immutable scope violation records, and change audit trails directly support Part 11 compliance. The scope declaration is an electronic record subject to Part 11 requirements. The scope violation log is an electronic record that must be maintained with integrity assurance. Change control for scope declarations must include the electronic signature of the authorising individual.

NIST AI RMF — MAP 1.5, GOVERN 1.1

The NIST AI Risk Management Framework's MAP function includes MAP 1.5, which requires organisations to document the deployment context, including the intended use, the operational domain, and the population the system is intended to serve. AG-519's scope declaration directly implements MAP 1.5 in the healthcare context. GOVERN 1.1 requires organisations to establish AI risk management processes. Scope enforcement is a risk management control that mitigates the risk of out-of-scope use.

ISO 42001 — AI Management System

ISO 42001 requires organisations to assess AI risks (Clause 6.1.2) and conduct AI impact assessments (Clause 8.2). Out-of-scope clinical use is a high-severity AI risk that must be identified in the risk assessment and mitigated through controls. AG-519 provides the specific control framework for mitigating this risk in healthcare deployments. The scope declaration, enforcement mechanism, and monitoring capability together constitute the risk treatment for the out-of-scope use risk.

DORA — Article 11 (ICT Risk Management Framework)

The Digital Operational Resilience Act applies to financial entities but also establishes principles for ICT risk management that are relevant to healthcare entities providing digital health services. Article 11 requires ICT risk management frameworks to address the identification, protection, detection, response, and recovery functions. While DORA's primary application is financial, healthcare institutions that provide digital health services intersecting with financial systems (health insurance processing, claims adjudication) must ensure their AI agents operate within validated scope to avoid ICT risk events that propagate across the healthcare-financial boundary.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Individual patient to population-level — scope failures can cause direct patient harm in individual cases and systematic harm when scope creep becomes institutionalised across clinical deployments

Consequence chain: Without clinical indication scope governance, an AI agent deployed for one clinical purpose is gradually or suddenly applied to purposes for which it has not been validated. The immediate technical failure is the processing of a clinical input outside the agent's validated scope, producing an output that appears clinically valid but is generated from an unvalidated application of the underlying model. The clinical consequence is a decision made on the basis of an unvalidated output — a diagnosis missed because the agent's sensitivity for the actual condition is unknown, a treatment recommended because the agent's model does not account for the actual tumour biology, or a patient enrolled in a clinical trial who does not meet the actual protocol criteria. The patient harm may be immediate (adverse reaction to contraindicated therapy) or delayed (progressive disease during a period of false reassurance from a missed diagnosis). The institutional consequence includes medical negligence liability, with damages in missed diagnosis cases routinely exceeding £500,000 and reaching several million pounds in cases involving permanent disability or death. The regulatory consequence includes medical device competent authority enforcement action — the MHRA, FDA, or notified body may suspend or withdraw the device's regulatory approval, affecting all deployments not just the site where the failure occurred. For clinical trials, scope failures can invalidate trial data, resulting in multi-million pound losses and delays in bringing therapies to market. The systemic consequence is erosion of clinical trust in AI systems — a single high-profile scope failure can set back AI adoption across an entire health system. The severity is compounded by the difficulty of detection: unlike a system crash or an obviously wrong output, an out-of-scope output often looks clinically plausible, and the harm may not be attributed to the scope failure for months or years.

Cross-references: AG-519 intersects with AG-001 (Operational Boundary Enforcement) as the clinical specialisation of operational mandate enforcement, AG-007 (Governance Configuration Control) for versioned scope declaration management, AG-520 (Patient Consent and Override Governance) for ensuring patient consent aligns with the agent's validated scope, AG-521 (Diagnostic Confidence Threshold Governance) for ensuring confidence thresholds are validated within the declared scope, AG-523 (Clinical Evidence Provenance Governance) for linking scope declarations to underlying clinical evidence, AG-524 (Adverse Event Reporting Integration Governance) for reporting adverse events that may result from scope violations, AG-528 (Trial Protocol Deviation Governance) for managing scope in clinical trial contexts, and AG-369 (Connector Capability Whitelist Governance) for restricting the agent's integration points to those within validated scope.