Field-Level Criticality Governance

2. Summary

Field-Level Criticality Governance requires that each data field consumed by an AI agent be individually classified by its criticality to decision outcomes, its legal sensitivity, and its operational impact if incorrect. Not all fields in a data record carry equal weight — a customer's date of birth in an age-verification context is decision-critical, while their preferred display name is not. Without field-level classification, governance controls are applied uniformly across all fields, leading either to excessive overhead on non-critical fields or inadequate protection of critical ones. This dimension ensures that governance intensity is proportional to field-level risk.

3. Example

Scenario A — Unclassified Field Causes Incorrect Drug Interaction Check: A healthcare AI agent assists pharmacists by checking drug interactions. The agent consumes a patient record with 47 fields. Two fields are critical for interaction checking: current_medications (a structured list) and allergy_flags (a coded set). The remaining 45 fields (name, address, insurance details, appointment history) are contextual but not decision-critical for interaction logic. The organisation applies uniform data quality monitoring across all 47 fields. When the data pipeline experiences a schema change that silently nullifies the allergy_flags field (replacing coded values with empty strings), the monitoring system does not prioritise this alert because it treats all field-level quality changes equally. The alert is buried among 200 other field-quality warnings generated that day. The agent processes 312 prescriptions over 8 hours without allergy data, missing 4 potential allergic interaction warnings. One patient experiences an adverse drug reaction requiring hospitalisation.

What went wrong: No field-level criticality classification existed. The monitoring system treated allergy_flags — a decision-critical field — with the same urgency as preferred_language or insurance_policy_number. The 4 missed interactions occurred because governance resources were not concentrated on the fields that mattered most.

Scenario B — Legally Sensitive Field Exposed Through Agent Output: An enterprise customer-service agent has access to a customer record containing 32 fields, including credit_score, annual_income, and ethnicity (collected for regulatory reporting under equality legislation). The agent is tasked with generating personalised service recommendations. No field-level sensitivity classification exists. The agent incorporates all available fields into its reasoning context, including ethnicity. A customer asks why they were offered a particular product tier. The agent's explanation references patterns in the customer's profile that correlate with ethnicity, creating a discrimination liability. Investigation reveals the agent had no mechanism to distinguish legally sensitive fields from general fields because no field-level classification was in place.

What went wrong: The agent consumed all available fields without distinguishing which were legally sensitive and should be excluded from certain reasoning contexts. Field-level criticality governance would have classified ethnicity as legally sensitive and restricted its availability to the agent for service recommendation contexts.

Scenario C — Non-Critical Field Error Triggers Unnecessary Escalation: A financial reconciliation agent processes 50,000 transactions daily. Each transaction record contains 28 fields. The organisation implements a blanket rule: any field-level data quality error triggers human escalation. The non-critical field display_currency_symbol (used only for UI rendering) has a 0.3% error rate — 150 transactions per day are escalated for a cosmetic field. The human review team spends 45 minutes daily reviewing these escalations and confirming they are non-material. Over a year, this consumes 273 hours (approximately £8,190 at £30/hour) of analyst time on a field with zero decision impact.

What went wrong: Without field-level criticality classification, the escalation rule could not distinguish between critical fields (transaction_amount, counterparty_id, settlement_date) and non-critical fields (display_currency_symbol). Governance overhead was misallocated.

4. Requirement Statement

Scope: This dimension applies to all AI agents that consume structured or semi-structured data containing multiple fields or attributes. Any agent that reads from a database table, API response, JSON/XML payload, CSV file, or any structured data source with identifiable fields is within scope. Agents consuming unstructured text (e.g., free-text documents) are within scope to the extent that extracted entities or parsed attributes function as fields. The scope includes fields generated by the agent itself (derived fields) if those fields are persisted or passed to downstream systems. Fields in vector store metadata (AG-132) are within scope.

4.1. A conforming system MUST classify every field in data consumed by agents into at least three criticality tiers: decision-critical (field directly influences agent decisions or actions), operationally relevant (field supports context but does not directly drive decisions), and non-critical (field has no material impact on agent outcomes).

4.2. A conforming system MUST classify fields by legal sensitivity, identifying fields subject to data protection regulation (personal data, special category data under GDPR), anti-discrimination law, or sector-specific restrictions (e.g., HIPAA protected health information, PCI cardholder data).

4.3. A conforming system MUST apply differentiated governance controls based on field criticality — decision-critical fields MUST receive higher quality monitoring thresholds, faster escalation on errors, and stricter access controls than non-critical fields.

4.4. A conforming system MUST restrict agent access to legally sensitive fields to only those reasoning contexts where the field is necessary and lawful to use, blocking access in other contexts.

4.5. A conforming system MUST maintain the field criticality classification as a versioned artefact with change history and attribution.

4.6. A conforming system SHOULD automate field criticality classification for new data sources using schema analysis, data profiling, and existing classification taxonomies, with human review for decision-critical and legally sensitive classifications.

4.7. A conforming system SHOULD integrate field criticality classifications with data quality monitoring (AG-311) to set per-field quality thresholds proportional to criticality.

4.8. A conforming system SHOULD propagate field criticality classifications through data transformations so that derived fields inherit the highest criticality of their contributing source fields.

4.9. A conforming system MAY implement dynamic criticality adjustment based on decision context — a field non-critical in one reasoning context may be decision-critical in another.

5. Rationale

AI agents consume data at field granularity — their reasoning processes operate on individual values within records, not on records as atomic units. A customer record is not consumed as a single entity; the agent reads the balance field for a credit decision, the address field for jurisdiction determination, and the communication_preference field for channel selection. Each field has a different relationship to the agent's decision and a different consequence if incorrect.

Governance controls that operate at the record or source level — "this database is classified as confidential" or "this API has a 99.9% SLA" — miss the field-level variation that drives actual risk. A database may be 99.99% accurate across all fields while having a 2% error rate on the one field that drives the agent's most consequential decisions. Without field-level classification, this risk is invisible.

The legal dimension compounds this. Data protection regulations operate at field granularity — ethnicity is special category data under GDPR while customer_name is not. Anti-discrimination law prohibits certain fields from influencing certain decisions. These legal boundaries cannot be enforced without knowing which fields carry which legal sensitivity. An agent that consumes all available fields into a single reasoning context creates legal exposure that uniform source-level classification cannot address.

Field-level criticality governance allocates governance resources proportionally to risk. Decision-critical fields receive intensive monitoring, rapid escalation, and strict access controls. Non-critical fields receive proportionate, lighter governance. This prevents both under-governance of critical fields and over-governance of non-critical fields, the latter being a significant source of alert fatigue and operational overhead in production systems.

6. Implementation Guidance

The field criticality classification is a structured metadata layer attached to every data source consumed by agents. For each field in each data source, the classification specifies: field name and identifier, criticality tier (decision-critical, operationally relevant, non-critical), legal sensitivity flags (personal data, special category, PCI, PHI, etc.), the decision contexts in which the field is used, the quality threshold applicable to this field, and the access restrictions by agent context.

Recommended patterns:

• Schema-annotated classification. Extend the data source schema (database schema, API specification, or JSON Schema) with custom annotations for criticality and sensitivity. For example, in a JSON Schema, add x-criticality: decision-critical and x-legal-sensitivity: ["gdpr-special-category"] to each field definition. The agent's data access layer reads these annotations and applies corresponding governance controls. This pattern keeps classification tightly coupled with the schema, ensuring they evolve together.
• Centralised field registry. Maintain a central registry (database table or configuration store) that maps source.table.field identifiers to criticality and sensitivity classifications. The data access gateway (per AG-309) consults this registry on each field access. This pattern supports cross-source consistency — the same logical field (e.g., date_of_birth) receives the same classification regardless of which source it appears in.
• Context-aware field masking. For legally sensitive fields, implement context-aware masking at the data access layer. When an agent requests data for a context where a legally sensitive field is restricted (e.g., ethnicity for product recommendation), the field is either omitted from the response or replaced with a masked value. The agent never receives the raw value in restricted contexts. This is structurally stronger than relying on the agent's instructions to ignore the field.

Anti-patterns to avoid:

• Binary classification only. Classifying fields as simply "sensitive" or "not sensitive" loses the distinction between criticality (impact on decisions) and legal sensitivity (regulatory restrictions). A field can be decision-critical but not legally sensitive (e.g., transaction_amount), or legally sensitive but not decision-critical (e.g., ethnicity stored for regulatory reporting but not used in the agent's decision logic). The classification must capture both dimensions independently.
• Classification without enforcement. Classifying fields in a spreadsheet or documentation but not integrating the classification into the data access layer. Without enforcement, agents consume all available fields regardless of classification, and the classification becomes a compliance artefact that does not reduce risk.
• Static classification without context. Assigning a single criticality level to a field regardless of how it is used. A customer's postcode may be non-critical for a general enquiry agent but decision-critical for a logistics routing agent. Where feasible, classification should account for decision context.
• Ignoring derived fields. Classifying source fields but not applying classification to derived or computed fields. An agent that computes "income_to_debt_ratio" from two decision-critical fields creates a new decision-critical field that must be classified accordingly.

Industry Considerations

Financial Services. Fields driving pricing, valuation, risk calculation, or regulatory reporting should be classified as decision-critical. PCI DSS requires specific handling of cardholder data fields (PAN, expiry date, CVV, cardholder name). MiFID II best execution requirements imply that fields driving execution decisions (price, volume, venue) are decision-critical with specific quality requirements.

Healthcare. HIPAA's 18 identifiers for Protected Health Information (PHI) define a baseline for legal sensitivity classification. Clinical decision fields (diagnosis codes, medication lists, allergy flags, vital signs) are decision-critical in clinical AI agent contexts. Field-level access controls must align with the minimum necessary standard.

Public Sector. Equality Act 2010 protected characteristics (age, disability, gender reassignment, marriage/civil partnership, pregnancy, race, religion, sex, sexual orientation) require legal sensitivity classification. Fields used in benefits determination or service allocation are decision-critical and subject to public law fairness requirements.

Maturity Model

Basic Implementation — The organisation has classified fields in its primary data sources into criticality tiers. The classification exists as a documented artefact (spreadsheet or configuration file) reviewed semi-annually. Decision-critical fields receive enhanced quality monitoring with lower error thresholds. Legally sensitive fields are identified and documented. Enforcement is manual — data pipelines are configured by engineers based on the classification, but no automated enforcement prevents misconfiguration.

Intermediate Implementation — Field classifications are stored in a machine-readable registry integrated with the data access layer. The data access gateway automatically applies differentiated governance: decision-critical fields have stricter quality gates, legally sensitive fields are context-masked based on the agent's declared reasoning context. New data sources are automatically profiled for provisional classification, with human review required for decision-critical and legally sensitive designations. Classification changes follow a versioned approval workflow.

Advanced Implementation — All intermediate capabilities plus: field criticality is dynamically adjusted based on decision context. The system tracks which fields actually influenced each agent decision (per AG-317), enabling empirical validation of criticality classifications. Adversarial testing has verified that context-masking cannot be bypassed through prompt injection or metadata manipulation. The organisation can demonstrate to regulators which fields informed any specific agent decision and that legally sensitive fields were appropriately restricted in that context.

7. Evidence Requirements

Required artefacts:

• Field criticality register. The current versioned classification of all fields in agent-consumed data sources, showing criticality tier, legal sensitivity flags, applicable decision contexts, and quality thresholds per field. Machine-readable format preferred.
• Enforcement configuration evidence. Configuration or code demonstrating that the data access layer applies differentiated controls based on field classification — quality thresholds, access restrictions, and context masking.
• Context-masking logs. Records demonstrating that legally sensitive fields were restricted in contexts where their use is not permitted, including the agent, the context, the restricted field, and the masking action taken. Minimum 12 months retention.
• Classification review records. Evidence of periodic review of field classifications, including changes made, justification, and approver.

Retention requirements:

• Field classification versions and enforcement logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.

8. Test Specification

Test 8.1: Differentiated Quality Threshold Enforcement

• Stimulus: Introduce a data quality error in a decision-critical field and separately in a non-critical field. Observe the system's response to each.
• Expected behaviour: The decision-critical field error triggers immediate escalation or action blocking (per AG-311). The non-critical field error is logged but does not trigger escalation.
• Pass criteria: Response to decision-critical field errors is demonstrably faster and more restrictive than response to non-critical field errors, consistent with the configured thresholds.
• Fail criteria: Both field errors receive the same response, or the decision-critical field error receives a lower-priority response.

Test 8.2: Legal Sensitivity Context Masking

• Stimulus: Request a legally sensitive field (e.g., ethnicity, health condition) in a decision context where it is classified as restricted (e.g., product recommendation) and in a context where it is permitted (e.g., regulatory reporting).
• Expected behaviour: In the restricted context, the field is omitted or masked. In the permitted context, the field is provided.
• Pass criteria: The legally sensitive field is never available in restricted contexts. The masking is applied at the data access layer, not by agent instructions.
• Fail criteria: The legally sensitive field is available in a restricted context, or masking depends on agent-side filtering.

Test 8.3: Classification Versioning Integrity

• Stimulus: Change a field's criticality classification (e.g., promote a field from operationally relevant to decision-critical). Verify the change is versioned and attributed.
• Expected behaviour: The previous classification is retained in version history. The new classification takes effect within the defined propagation window. The change is attributed to an approver.
• Pass criteria: Full version history is queryable. The agent's governance controls reflect the updated classification.
• Fail criteria: Previous classification versions are lost, or the updated classification is not enforced.

Test 8.4: Derived Field Classification Inheritance

• Stimulus: Create a derived field from two decision-critical source fields. Verify the derived field inherits decision-critical classification.
• Expected behaviour: The derived field is automatically classified at or above the highest criticality tier of its contributing fields.
• Pass criteria: The derived field receives decision-critical classification without manual intervention.
• Fail criteria: The derived field is unclassified or classified at a lower tier than its source fields.

Test 8.5: Context-Masking Bypass Resistance

• Stimulus: Attempt to access a legally sensitive, context-restricted field through indirect means: requesting the raw data record, querying the underlying data source directly, or crafting agent output that requests the field under a different context label.
• Expected behaviour: All bypass attempts are blocked. Context masking is enforced at the infrastructure layer regardless of the agent's request framing.
• Pass criteria: No bypass method retrieves the restricted field in a restricted context.
• Fail criteria: Any bypass method retrieves the restricted field.

Conformance Scoring

• Score 0: No field-level classification exists — all fields are treated uniformly regardless of criticality or legal sensitivity.
• Score 1: Field classifications exist as documentation but are not enforced at the data access layer — governance controls are applied uniformly.
• Score 2: Field classifications are enforced at the data access layer with differentiated quality thresholds, legally sensitive field context-masking, and versioned classification management.
• Score 3: Verified by independent adversarial testing — context-masking bypass, classification manipulation, and derived-field inheritance attacks have been attempted and failed. Dynamic context-aware classification is operational.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
GDPR	Article 5(1)(c) (Data Minimisation)	Direct requirement
GDPR	Article 9 (Special Categories of Personal Data)	Direct requirement
EU AI Act	Article 10 (Data and Data Governance)	Supports compliance
Equality Act 2010	Section 13 (Direct Discrimination)	Supports compliance
PCI DSS	Requirement 3 (Protect Stored Account Data)	Supports compliance
HIPAA	§164.502(b) (Minimum Necessary Standard)	Supports compliance
NIST AI RMF	MAP 2.1, MANAGE 2.4	Supports compliance

GDPR — Article 5(1)(c) (Data Minimisation)

Data minimisation requires that personal data be adequate, relevant, and limited to what is necessary. Field-level criticality governance implements data minimisation at operational granularity — by classifying which fields are necessary for each decision context, agents can be restricted to consuming only those fields, rather than ingesting entire records. This is the practical mechanism by which a controller demonstrates minimisation in an AI agent context.

GDPR — Article 9 (Special Categories of Personal Data)

Special category data (racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, sex life or sexual orientation data) requires explicit legal basis for processing. Field-level legal sensitivity classification identifies these fields and enables context-masking to prevent their use in reasoning contexts where no legal basis exists.

Equality Act 2010 — Section 13 (Direct Discrimination)

Direct discrimination occurs when a person is treated less favourably because of a protected characteristic. If an agent has access to protected characteristic fields and uses them in service or pricing decisions, the organisation is exposed to discrimination claims. Field-level criticality governance restricts access to protected characteristic fields in decision contexts where their use would constitute direct discrimination.

PCI DSS — Requirement 3 (Protect Stored Account Data)

PCI DSS requires specific protection for cardholder data fields. Field-level classification identifies PAN, expiry date, CVV, and cardholder name as requiring PCI-level controls, ensuring AI agents cannot access these fields outside PCI-compliant processing contexts.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Decision-specific — affects decisions relying on misclassified fields, potentially spanning multiple agents consuming the same data source

Consequence chain: Without field-level criticality classification, governance controls are misallocated. Decision-critical fields receive insufficient monitoring and agents make decisions on low-quality critical data without appropriate escalation. Legally sensitive fields are consumed in unrestricted contexts, creating discrimination and data protection liability. Non-critical field errors generate alert fatigue that masks genuine critical issues. The financial impact includes: remediation costs for decisions made on low-quality critical fields (Scenario A: hospitalisation from missed drug interaction), legal liability for discriminatory use of sensitive fields (Scenario B: discrimination claim), and operational waste from over-governance of non-critical fields (Scenario C: £8,190/year in unnecessary analyst time per agent). At enterprise scale with hundreds of data sources and thousands of fields, the misallocation is multiplicative.

Cross-references: AG-309 (Authoritative Source Register Governance) identifies the sources; AG-310 classifies the fields within those sources. AG-311 (Data Quality Threshold Enforcement Governance) uses field criticality to set proportional quality thresholds. AG-312 (Missing Data Escalation Governance) uses field criticality to determine whether missing data requires escalation or tolerance. AG-128 (Data Source Classification) provides source-level classification that AG-310 refines to field level. AG-057 (Dataset Suitability and Bias Control) uses legal sensitivity classifications to assess bias risk from sensitive fields. AG-133 (Source Record Lineage) traces field-level provenance.