AG-732 governs how AI agents acquire, represent, convert, validate, and apply locale-dependent context — including time-zones, date and time formats, calendar systems, numeric separators, currency symbols and denominations, measurement units, language registers, and culturally specific norms such as business day conventions, public holiday calendars, and legally prescribed date-ordering requirements. This dimension matters because locale-dependent logic is pervasive in virtually every agent task that involves scheduling, financial calculation, document generation, regulatory compliance, or end-user communication, yet it is systematically underspecified in agent deployment configurations, causing agents to silently apply incorrect defaults that propagate into decisions, contracts, audit records, and safety systems. Failure manifests as: a cross-border payment executed on a date offset by 24 hours due to an unresolved UTC assumption; a medical dosing agent scheduling medication at the wrong clock time across a daylight-saving-time boundary; a public-sector agent rendering a deadline one month late because it misinterpreted a DD/MM/YYYY input as MM/DD/YYYY; or a customer-facing agent quoting a price in the wrong currency denomination without disclosure.
A Financial-Value Agent is configured to process international wire transfers for a treasury operations team. The agent receives an instruction at 23:45 on Monday 30 October 2023 in the operator's local time, which is Central European Time (UTC+1 in winter, but on this specific date — the last Sunday of October — the EU had just completed its autumn DST transition at 03:00, meaning the server clock had already rolled back). The agent's internal scheduling module stores timestamps in what it labels "local time" without persisting the UTC offset. When the instruction is dispatched to the correspondent bank's API — which operates in UTC — the agent transmits a value-date of Monday 30 October rather than Tuesday 31 October, because its 23:45 local time resolved to 22:45 UTC on the same calendar day. The correspondent bank processes the transfer on 30 October. The originating bank's end-of-day cut-off had already passed on 30 October, creating a same-day settlement failure. The resulting float discrepancy of USD 4.2 million sits unclaimed overnight, triggers a margin call on the receiving entity's overnight collateral position, and generates a regulatory reporting obligation under EMIR Article 9. The root cause: the agent stored wall-clock time without an IANA time-zone identifier and failed to detect the DST transition boundary.
A Safety-Critical / CPS Agent manages medication reminder and dispensing schedules for a home-care monitoring platform deployed across multiple US states. On 12 March 2023 — the date of the United States spring DST transition — the agent's scheduling engine, configured to use a server-local time of US/Eastern, calculates the next dose interval for a patient on warfarin (a narrow therapeutic index anticoagulant) as 08:00 the following morning. Because the agent stores the next-trigger epoch as an integer Unix timestamp computed from "08:00 local time" without accounting for the spring-forward gap (02:00 → 03:00), the calculated epoch is one hour earlier than intended. The patient receives their morning dose at 07:00 actual clock time instead of 08:00, compressing the inter-dose interval from the prescribed 24 hours to 23 hours. Over three consecutive days — because the agent's recalculation anchors each subsequent dose to the prior trigger rather than re-resolving from the patient's prescribed absolute clock time — the cumulative drift reaches 3 hours. An INR (international normalised ratio) test on day 4 returns a value of 4.1 against a therapeutic range of 2.0–3.0, indicating over-anticoagulation. The patient is admitted for observation. The agent's audit logs record all events with correct-looking local timestamps because the DST error affected scheduling arithmetic, not display formatting, making the failure invisible to routine log review.
A Public Sector / Rights-Sensitive Agent is deployed to assist citizens in preparing and submitting benefit entitlement applications to a national social security agency. The agency's internal system was built to the ISO 8601 standard (YYYY-MM-DD), but a legacy data import pathway exposes dates in a field labelled submission_deadline in the format 05/06/2024. The agent's date-parsing module, trained predominantly on North American English corpora, interprets this as May 6, 2024 (MM/DD/YYYY). The correct interpretation under the agency's domestic locale convention is June 5, 2024 (DD/MM/YYYY). The agent communicates to a cohort of 3,400 users that their filing deadline is "5 May 2024." The actual deadline is 5 June 2024. Of the notified users, 847 submit their applications between 6 May and 5 June — after what the agent described as the deadline but before the actual deadline — believing they are filing late and therefore self-selecting into a lower-priority processing queue with a reduced benefit rate. An additional 214 users do not submit at all, having been told by the agent that their deadline had passed when it had not. The financial harm to affected users is calculated at approximately £1.9 million in aggregate reduced or forfeited benefit payments. The agent's deployment configuration contained no locale assertion and no date-format disambiguation rule.
This dimension applies to all AI agents that produce, consume, store, transform, or act upon any data element whose value or interpretation is locale-dependent, including but not limited to: clock times, calendar dates, date-time ranges, recurring schedules, deadlines, expiry timestamps, currency amounts and symbols, numeric values using decimal or thousands separators, measurement quantities with culturally variable units, natural language output directed at end users, references to public holidays or business day conventions, and any derived calculation whose result depends on the resolution of any of the foregoing. Scope includes agents operating in a single-locale deployment where locale assumptions are implicitly fixed and therefore subject to failure upon undetected configuration drift, as well as agents explicitly designed for multi-locale or cross-border operation. Scope excludes purely internal computational intermediaries that never surface locale-sensitive values to downstream consumers or external systems, provided that exclusion is explicitly documented and verified.
4.1.1 The agent deployment configuration MUST explicitly assert the operative locale context for every locale-sensitive dimension, including at minimum: (a) the canonical IANA time-zone identifier (e.g., America/New_York, Europe/London), not a UTC offset alone; (b) the date format ordering convention (ISO 8601 preferred, or explicit DD/MM/YYYY or MM/DD/YYYY with justification); (c) the locale code in BCP 47 format for any natural language output; (d) the ISO 4217 currency code for any monetary values; and (e) the preferred numeric format (decimal separator, thousands separator).
4.1.2 When the agent operates in a multi-locale environment or processes inputs from users in different locales, the agent MUST maintain a per-session or per-user locale context record that is resolved at session initiation and persisted for the duration of the interaction, not inferred dynamically from individual message content.
4.1.3 The agent MUST NOT inherit locale configuration from the host operating system's ambient locale settings without explicit operator acknowledgement, because OS locale settings are subject to unannounced change through system updates, administrator action, or containerisation inconsistencies.
4.2.1 The agent MUST store all internally computed timestamps in UTC and MUST attach the resolved IANA time-zone identifier as a separate, co-persisted metadata field whenever the timestamp has locale significance for display, scheduling, or downstream processing.
4.2.2 The agent MUST implement DST-aware time arithmetic using a maintained time-zone rule database (such as the IANA Time Zone Database / tzdata) and MUST NOT compute future timestamps by adding fixed integer-hour offsets to wall-clock times where DST transitions may intervene.
4.2.3 When scheduling recurring events (daily, weekly, or other periodic triggers), the agent MUST re-resolve the IANA time-zone offset at each scheduled occurrence, not carry forward the offset computed at schedule creation time.
4.2.4 The agent MUST detect and surface to the operator any configuration or input state in which a time-zone is expressed as a raw UTC offset (e.g., UTC+5:30, GMT-7) without a corresponding IANA identifier, and MUST prompt for or apply a deterministic IANA identifier resolution before proceeding.
4.2.5 For Safety-Critical / CPS Agent profiles, the agent MUST apply a DST transition guard: any scheduled action within a ±2-hour window of a known DST transition boundary for the operative time-zone MUST be flagged for human review or validated against the post-transition clock state before execution.
4.3.1 When the agent receives a date string in a format that is ambiguous between DD/MM/YYYY and MM/DD/YYYY interpretations (i.e., both the day-first and month-first readings would yield a valid calendar date), the agent MUST NOT silently resolve the ambiguity using model-default assumptions. The agent MUST either: (a) apply the explicitly configured locale's date format convention; or (b) surface the ambiguity to the user with both interpretations for confirmation.
4.3.2 The agent MUST validate all parsed date values for calendar correctness, including: correct month ranges (1–12), correct day-of-month ranges given the specific month and year (including leap year handling for February), and rejection of any date value that resolves to a logically impossible calendar date after format disambiguation.
4.3.3 When generating date output in natural language for end users, the agent MUST render dates in the user's confirmed locale format and MUST also include an unambiguous machine-readable representation (ISO 8601 or explicit month name) in any context where the output will be used for scheduling, filing, or legal reference.
4.3.4 The agent MUST support calendar systems beyond the Gregorian calendar when the operative user or jurisdiction context requires it, including at minimum the Islamic (Hijri) calendar for relevant jurisdictions and the Hebrew calendar where legally mandated, and MUST perform accurate inter-calendar conversions using authoritative rule sets.
4.4.1 The agent MUST NOT display or transmit monetary amounts without an explicit ISO 4217 currency code attached to the value. The agent MUST NOT infer currency from geographic context alone when the user's locale, the transaction counterparty's locale, and the platform operator's locale may differ.
4.4.2 The agent MUST apply the correct decimal and thousands separator for the operative locale when parsing numeric input. The agent MUST detect and reject or flag inputs where the separator usage is internally inconsistent (e.g., a value like 1.234.567,89 parsed under a locale expecting 1,234,567.89 conventions without explicit locale qualification).
4.4.3 For Financial-Value Agent and Crypto/Web3 Agent profiles, the agent MUST store monetary and token quantities in a canonical integer or fixed-precision representation internally and MUST NOT perform arithmetic on locale-formatted string representations of numbers.
4.4.4 The agent MUST correctly handle currencies with non-standard subdivision (e.g., the Kuwaiti Dinar with 3 decimal places, the Japanese Yen with 0 decimal places, the Bahraini Dinar with 3 decimal places) and MUST NOT apply a default 2-decimal-place assumption to all currencies.
4.4.5 When presenting exchange rates or converted amounts, the agent MUST disclose the exchange rate source, the rate timestamp, and the rate's operative time-zone, and MUST flag any conversion where the rate data is older than a configurable staleness threshold.
4.5.1 For Customer-Facing Agent and Public Sector / Rights-Sensitive Agent profiles, the agent MUST generate user-facing output in the user's stated preferred language, and where a confirmed language preference is not on record, MUST request language preference before proceeding with substantive content delivery in multi-locale deployments.
4.5.2 The agent SHOULD adapt communication register (formal vs. informal address forms, honorifics, gendered language agreement) to locale-appropriate norms when the operative locale has grammatically significant register distinctions, and SHOULD NOT apply English-default informal register to outputs in languages where formality norms carry legal or social weight (e.g., administrative correspondence in German, French, or Japanese).
4.5.3 The agent MUST NOT make assumptions about the cultural acceptability of content, imagery references, or idiomatic expressions based solely on the inferred geographic location of a user, and SHOULD apply explicit cultural appropriateness validation rules configured by the operator when producing content for Cross-Border / Multi-Jurisdiction Agent deployments.
4.5.4 The agent MUST correctly represent culturally variable elements in date-adjacent communication, including: (a) the first day of the work week (Monday vs. Sunday vs. Saturday depending on jurisdiction); (b) weekend composition; (c) public holiday and non-business-day calendars for scheduling assertions; and (d) fiscal year boundaries where these differ from the calendar year.
4.6.1 When computing business day counts, payment settlement dates, regulatory filing deadlines, or contract performance dates, the agent MUST use a jurisdiction-specific holiday calendar sourced from an authoritative and versioned data set, not a hardcoded or model-inferred approximation.
4.6.2 The agent MUST apply an explicit business day convention (e.g., Following, Modified Following, Preceding, End of Month) when computing date offsets that may land on a non-business day, and MUST surface the applied convention to the user or downstream system.
4.6.3 The agent MUST flag any scheduling computation that crosses a public holiday boundary in the operative jurisdiction(s) and MUST surface the flag to the operator's review queue when the computation affects a legal, financial, or safety-critical deadline.
4.6.4 Holiday calendar data MUST be subject to version control and refresh governance under the agent's operational maintenance schedule, with a maximum permissible staleness of 90 days for general use and 30 days for Financial-Value and Safety-Critical profiles.
4.7.1 The agent MUST implement a locale consistency checker that validates, on every locale-sensitive operation, that the input locale context, the operative processing locale, and the output locale context are mutually consistent or that any intentional conversion between them is explicitly logged.
4.7.2 The agent MUST detect and alert on the following sentinel conditions: (a) a date or time value that, after locale resolution, falls more than 48 hours outside the plausible range for the stated intent (e.g., a "next business day" settlement that resolves to a date 15 days out without holiday justification); (b) a currency amount that, after conversion, differs from the pre-conversion amount by more than a configurable tolerance without an explicit exchange rate event; (c) a scheduled recurring event whose next occurrence, after DST re-resolution, differs from the prior interval by more than ±90 minutes.
4.7.3 The agent MUST NOT proceed with locale-sensitive operations when the locale context assertion is absent, incomplete, or contradicted by input data, unless a fallback locale policy is explicitly defined in the deployment configuration and the fallback is logged.
4.7.4 For Research / Discovery Agent profiles, the agent MUST annotate any data point or finding that was retrieved, processed, or synthesised under a specific locale context with that context as persistent metadata, so that downstream consumers can identify locale-dependency in conclusions.
4.8.1 The agent MUST record in its audit log, for every locale-sensitive operation: the input locale context asserted, the output locale context applied, the IANA time-zone identifier used, the date format convention applied, the currency code(s) operative, and the version of any holiday calendar or time-zone rule database consulted.
4.8.2 Audit log entries for locale-sensitive operations MUST store timestamps in UTC with the IANA time-zone identifier as a separate field; the agent MUST NOT store only wall-clock local time in audit records.
4.8.3 The agent MUST preserve locale context metadata alongside any artefact (document, record, message, transaction) it produces that contains locale-sensitive values, so that the artefact can be correctly re-interpreted if the consuming system's locale differs from the producing system's locale.
4.9.1 The operator MUST maintain a documented Locale Governance Policy that specifies: the agent's default locale assumptions; the process for updating locale configuration when the agent is deployed in a new geography or jurisdiction; the refresh schedule for time-zone rule databases and holiday calendars; and the escalation path for locale-related errors detected in production.
4.9.2 Any change to the agent's operative locale configuration MUST be treated as a configuration change event subject to the same change management controls as software version changes, including impact assessment, test execution, and approval record.
4.9.3 The agent MUST support locale configuration injection at deployment time through a controlled, versioned configuration artefact rather than relying solely on model fine-tuning or prompt-level locale instructions, which are subject to override, injection, or omission.
Locale-dependent logic is structurally different from most other agent failure modes because it is invisible by default. An agent that performs arithmetic with incorrect unit assumptions produces a numerically wrong answer that can often be detected by domain-expert review. An agent that schedules an event one hour early due to a DST error produces a structurally correct-looking timestamp that passes all syntactic and range validation checks, appears correctly formatted in logs, and only reveals its error at execution time — frequently after the window for correction has closed. This invisibility is compounded by the fact that locale errors are often within the plausible range of values: a date one month off, a time one hour off, a currency amount one percent different due to a decimal separator error. These values survive automated anomaly detection because they are not outliers; they are plausible values that are simply wrong for the specific context.
The structural solution is therefore not primarily alerting after the fact, but configuration assertion before the fact. By requiring explicit locale context assertion at deployment time (4.1.1), UTC-internal storage (4.2.1), and locale consistency checking on every operation (4.7.1), the framework converts locale assumptions from implicit and invisible to explicit and auditable. This is the same principle applied to unit governance in AG-731: the answer to invisible assumption error is not better error detection downstream, it is mandatory assumption declaration upstream.
Large language models trained on multilingual corpora develop strong implicit locale priors. A model trained predominantly on English-language data will default to MM/DD/YYYY date ordering, USD currency assumptions, and Monday–Friday business week conventions even when operating in a deployment context where none of these are correct. These priors are not configurable through simple prompting because they are encoded in the model's weights and are subject to contextual override by any sufficiently strong in-context signal — including adversarial signals injected by malicious inputs (see AG-011 for input validation controls). Behavioural enforcement through system-level configuration (4.9.3) that is independent of model-level instruction is therefore essential: the model's locale behaviour must be governed by the deployment architecture, not delegated to the model's own inference about what locale it should use.
Furthermore, locale failures are jurisdictionally consequential. The interpretation of a filing deadline as May vs. June is not a matter of preference; under administrative law in most jurisdictions, the legal effect of a submission turns on the calendar date, not on the filer's intent. An agent that communicates the wrong date to a citizen is not merely unhelpful; it may constitute a failure of the administrative duty to provide accurate information, with consequences ranging from administrative appeal costs to judicial review exposure. The Enhanced Tier designation of this dimension reflects that locale correctness is frequently a legal compliance matter, not merely an accuracy matter.
Unlike many governance dimensions that apply intensively to one or two agent profiles, locale governance is genuinely universal. Every profile listed in the primary profiles section has a distinct and serious locale failure mode: financial agents face settlement date errors; safety-critical agents face dosing schedule errors; public sector agents face deadline communication errors; customer-facing agents face trust erosion through culturally inappropriate communication; research agents face data provenance ambiguity; cross-border agents face compound multi-jurisdiction locale conflict; embodied agents face timing failures in physical actuation. The breadth of the requirement set in Section 4 reflects this universality.
Pattern 1 — UTC-Canonical Internal Representation with IANA Tag Co-Persistence All timestamps generated or stored internally by the agent should be in UTC epoch format (Unix timestamp or ISO 8601 with Z suffix), with the IANA time-zone identifier stored as a mandatory parallel field. Example record structure: { "event_time_utc": "2024-03-10T13:00:00Z", "tz_iana": "America/New_York", "tz_display": "08:00 EST" }. Display conversion to local time is performed only at rendering time, never at storage time. This pattern eliminates an entire class of DST errors because the canonical value never changes; only the display projection changes.
Pattern 2 — Locale Context Manifest in Agent Configuration The agent's deployment configuration should include a machine-readable Locale Manifest as a first-class configuration artefact (not embedded in a prompt). The manifest specifies: default IANA time-zone, date format convention, BCP 47 locale code, ISO 4217 currency code, numeric format (e.g., en-GB decimal/thousands), first day of week, holiday calendar source URI and version hash, and the fallback policy for unresolvable locale inputs. The manifest should be version-controlled alongside the agent's model version and system prompt version.
Pattern 3 — Multi-Locale Session Context Record For agents serving multiple user locales, each session or user record should carry a resolved Locale Context Object (LCO) populated at session initiation. The LCO should be derived from: (1) explicit user preference if stated; (2) user profile record if available; (3) Accept-Language header or equivalent signal; (4) operator-configured default as final fallback. The LCO should not be re-inferred from message content mid-session unless the user explicitly requests a locale change, which should itself be logged.
Pattern 4 — DST Transition Guard for Scheduled Operations Implement a pre-execution check for any scheduled operation that queries: does the scheduled UTC epoch, when converted to the operative IANA time-zone, fall within a 2-hour window of a known DST transition in that time-zone for the next 12 months? If yes, flag for human review or apply the post-transition wall-clock time as the authoritative target. This check should be re-applied at each recurrence for recurring schedules.
Pattern 5 — Ambiguous Date Disambiguation Protocol When a date string is received that is ambiguous between DD/MM and MM/DD interpretations, implement a three-stage resolution: (1) apply the configured locale's date format convention; (2) if no locale is configured, query the user explicitly with both interpretations rendered as full text (e.g., "Did you mean 5 June 2024 or 6 May 2024?"); (3) log the resolution path and the user's confirmation. Never silently resolve ambiguity using model priors.
Pattern 6 — Versioned Holiday Calendar with Staleness Check Maintain holiday calendar data as a versioned data asset with a source attribution and a last-verified date. Before any business day computation, check the calendar's last-verified date against the staleness threshold configured for the agent's profile. If stale, block the computation and trigger an alert to the operations team rather than proceeding with potentially incorrect calendar data. Holiday calendar updates should be part of the agent's regular operational maintenance cycle, not an ad-hoc activity.
Pattern 7 — Currency Denomination Assertion Every monetary value produced or consumed by the agent should be represented in the form { "amount": 12500, "currency": "JPY", "precision": 0 } or an equivalent structured form, never as a plain numeric string. The precision field should be validated against the ISO 4217 specified minor unit for the currency. Arithmetic should be performed on the integer representation in minor units (e.g., cents for USD, not dollars) and converted to display form only at output rendering.
Anti-Pattern 1 — OS Locale Inheritance Do not configure agent locale by reading LANG, LC_ALL, TZ, or equivalent environment variables from the host OS without explicit operator acknowledgement and configuration lock. OS locale settings are not stable deployment artefacts; they are administrative settings subject to change.
Anti-Pattern 2 — UTC Offset Without IANA Identifier Do not store or pass time-zone information as a numeric UTC offset (e.g., +05:30) without the corresponding IANA identifier. UTC offsets are not stable across DST transitions and do not uniquely identify a time-zone (multiple IANA zones share the same UTC offset). This is the root cause of the failure described in Example A.
Anti-Pattern 3 — Prompt-Level Locale Instruction as the Sole Control Do not rely on a system prompt instruction such as "always use DD/MM/YYYY date format" as the sole locale control mechanism. System prompt instructions are subject to context window compression, adversarial override, and model interpretation variability. Locale control must be implemented at the configuration and code level.
Anti-Pattern 4 — Hardcoded Holiday Lists Do not embed holiday dates as hardcoded constants in agent logic or prompts. Holiday calendars change through legislative action, royal proclamation, or administrative decision. A hardcoded list becomes stale silently and without any error signal.
Anti-Pattern 5 — Locale Inference from User Name or IP Address Do not infer a user's date format, currency, or language preference from their name, inferred geographic location, or IP-derived country code. These signals are unreliable and ethically problematic. Always use explicit preference declaration or profile record.
Anti-Pattern 6 — Treating "English" as a Locale English is a language, not a locale. en is not a sufficient BCP 47 locale for locale-sensitive operations. en-US, en-GB, en-AU, and en-IN have materially different date conventions, currency defaults, spelling norms, and legal contexts. The agent's locale configuration must specify the full BCP 47 subtag.
| Maturity Level | Characteristics |
|---|---|
| Level 1 — Ad Hoc | Locale is not explicitly configured; agent uses model defaults; no locale logging; errors discovered reactively |
| Level 2 — Defined | Locale Manifest exists and is documented; UTC storage applied; date format convention stated; no automated validation |
| Level 3 — Managed | Automated locale consistency checking on operations; DST guard implemented; holiday calendar versioned; locale logged in audit trail |
| Level 4 — Optimised | Per-session LCO with user confirmation; multi-calendar support; staleness alerting; locale change management integrated with CI/CD; regular locale accuracy testing in regression suite |
7.1 Locale Governance Policy Document A documented Locale Governance Policy (per 4.9.1) describing default locale assumptions, locale configuration process, time-zone and holiday calendar refresh schedule, and escalation path. Retention: minimum 3 years or for the operational lifetime of the agent, whichever is longer.
7.2 Locale Manifest Artefact The machine-readable Locale Manifest (per 4.1.1, 4.9.3) for each deployed agent version, version-controlled and linked to the specific agent model version and system prompt version it applies to. Retention: minimum 5 years for Financial-Value and Public Sector profiles; 3 years for all other profiles.
7.3 Time-Zone Rule Database Version Record A record of the version of the IANA Time Zone Database (tzdata) in use at each deployment, with the date of the last update and the date of the next scheduled update. Retention: 3 years.
7.4 Holiday Calendar Version Record A record of each jurisdiction-specific holiday calendar data set in use, its source, its version or publication date, and the date it was last verified against the authoritative source. Retention: 3 years, or 7 years for Financial-Value Agent profiles where business day calculations affect settlement records.
7.5 Locale Audit Log Samples Sampled audit log records demonstrating compliance with 4.8.1 and 4.8.2, showing UTC timestamps with IANA tags, locale context fields, and currency codes as required. Samples should cover at minimum one DST transition period per year for each operative time-zone. Retention: aligned with the agent's general audit log retention policy per AG-412, minimum 2 years.
7.6 DST Transition Test Records Records of DST transition boundary tests (per test 8.3) executed at least annually for each operative IANA time-zone, including test inputs, expected outputs, actual outputs, and pass/fail determination. Retention: 3 years.
7.7 Locale Ambiguity Detection Test Records Records of date format ambiguity detection tests (per test 8.2) demonstrating that the agent correctly surfaces ambiguity rather than silently resolving it. Retention: 3 years.
7.8 Locale Configuration Change Records Change management records for every modification to the agent's Locale Manifest, including the change rationale, impact assessment, approver, and test results confirming the change did not introduce regressions. Retention: 5 years.
7.9 Incident and Near-Miss Log A log of any locale-related error, near-miss, or alert triggered in production, including the nature of the locale error, affected operations or users, remediation action taken, and whether the error resulted in downstream harm. Retention: 5 years or for the duration of any related regulatory inquiry.
Conformance scoring for each test:
Each test maps to the MUST requirements identified in Section 4. Tests should be executed in a controlled test environment using the production agent configuration.
Maps to: 4.1.1, 4.1.3, 4.9.3
Test objective: Verify that the agent's locale context is derived from the Locale Manifest artefact and not from OS ambient settings or model defaults.
Procedure:
en-US, Locale Manifest set to en-GB with DD/MM/YYYY).03/04/2024.Pass criteria (Score 3): Agent applies Locale Manifest convention in step 3; Locale Manifest version is logged in step 4; agent halts and logs an error in step 5. **Pass criteria (Score
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Time-Zone, Locale and Cultural Context Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-732 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. Time-Zone, Locale and Cultural Context Governance directly supports the robustness and cybersecurity requirements by implementing structural controls that resist adversarial manipulation and ensure system integrity under attack conditions.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-732 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Time-Zone, Locale and Cultural Context Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Business-unit level — affects the deploying team and downstream consumers of agent outputs |
| Escalation Path | Senior management notification within 24 hours; regulatory disclosure assessment within 72 hours |
Consequence chain: Failure of time-zone, locale and cultural context governance creates significant operational risk within the agent deployment. The absence of this control allows agent behaviour to deviate from governance intent in ways that may not be immediately visible but accumulate material exposure over time. The impact extends beyond the immediate deployment to affect downstream consumers of agent outputs, stakeholder trust, and regulatory standing. Detection of the failure may be delayed, increasing the remediation scope and cost. Regulatory consequences may include supervisory findings, required corrective actions, and increased scrutiny of the organisation's AI governance programme.