Temporal Policy Trigger Governance

2. Summary

Temporal Policy Trigger Governance requires that policy changes based on time windows, scheduled cutovers, and expiry events are executed with precision, atomicity, and auditability. Many policy rules are inherently time-dependent: regulatory obligations activate on specific dates, promotional windows open and close at defined times, safety parameters change with shift schedules, and emergency overrides expire after defined durations. This dimension mandates that temporal triggers are defined declaratively, evaluated against an authoritative time source, and enforced atomically so that no decision falls into a gap between the old and new policy, and no expired policy continues to govern decisions after its expiry time.

3. Example

Scenario A — Regulatory Cutover Misses Midnight Deadline: A new regulatory requirement mandates enhanced due diligence for cryptocurrency transactions above £1,000, effective 1 January 2027 at 00:00 UTC. The organisation schedules the policy change as a cron job that runs at 00:05 UTC on 1 January. Between 00:00 and 00:05, the agent processes 47 cryptocurrency transactions under the old policy — 12 of which are above £1,000 and should have been subject to enhanced due diligence. A regulatory audit identifies the 5-minute gap.

What went wrong: The temporal trigger was implemented as a deployment job rather than a time-evaluated policy condition. The 5-minute delay between the regulatory effective time and the actual policy activation created a compliance gap. Consequence: 12 non-compliant transactions, regulatory finding for failure to implement controls by the effective date, potential fine of £250,000.

Scenario B — Expired Emergency Override Persists Indefinitely: A safety-critical agent controlling a water treatment plant operates under a policy that limits chlorine dosing to 4.0 mg/L. During a contamination event, operators apply an emergency override raising the limit to 6.0 mg/L for a 24-hour period. The override is implemented as a configuration change with a comment noting "expires in 24 hours." There is no automated expiry mechanism. The override persists for 17 days before a routine review discovers it. During those 17 days, the agent doses chlorine at up to 5.8 mg/L under conditions that no longer warrant elevated dosing.

What went wrong: The emergency override had no automated expiry trigger. The expiry was recorded as a human instruction, not a system-enforced time boundary. Consequence: 17 days of elevated chlorine dosing outside the standard operating envelope, potential health risk to consumers, regulatory investigation by the water quality regulator, incident report required.

Scenario C — Daylight Saving Transition Creates Double-Apply Window: A customer-facing agent offers a promotional interest rate of 4.5% between 01:00 and 02:00 local time during a marketing campaign. On the night of the daylight saving "fall back" transition, the clock moves from 02:00 back to 01:00. The promotional window fires twice — once during the real 01:00-02:00 and again during the repeated 01:00-02:00. Customers who apply during the second window receive the promotional rate unintentionally, as the campaign budget assumed a single 1-hour window per night.

What went wrong: The temporal trigger used local time without accounting for daylight saving transitions. The ambiguous hour during the fall-back transition caused the trigger to fire twice. Consequence: Unbudgeted promotional exposure of £34,000, campaign cost overrun, need to honour the rate for customers who received it.

4. Requirement Statement

Scope: This dimension applies to all AI agents governed by policy rules that include time-dependent conditions: activation dates, expiry dates, time-of-day windows, duration-limited overrides, regulatory effective dates, scheduled cutovers, and any rule whose applicability changes based on time. Systems with entirely time-invariant policy are excluded, but organisations should verify this formally — many policies have implicit time dependencies (e.g., "this version is effective until superseded") that bring them into scope. The scope extends to interactions between temporal triggers and other trigger types (e.g., a rule that is both time-limited and jurisdiction-specific, involving AG-274).

4.1. A conforming system MUST evaluate temporal policy triggers against an authoritative, tamper-resistant time source (e.g., NTP synchronised to a stratum-1 or stratum-2 server) rather than the local system clock of the agent runtime.

4.2. A conforming system MUST activate time-triggered policy changes at the exact specified time, with a maximum tolerance of 1 second, not as scheduled deployment jobs with potential delay.

4.3. A conforming system MUST automatically expire duration-limited policy overrides at the specified expiry time without requiring manual intervention, reverting to the prior policy version.

4.4. A conforming system MUST use UTC for all temporal trigger definitions and evaluations, converting to local time only for display purposes, to eliminate daylight saving ambiguities.

4.5. A conforming system MUST handle time-boundary decisions atomically — a decision that begins evaluation before the trigger time and completes after the trigger time must be evaluated entirely under one policy version, not a mix of old and new.

4.6. A conforming system MUST log every temporal trigger activation and deactivation, recording: the trigger definition, the authoritative time of activation/deactivation, the policy version before and after, and the time source used.

4.7. A conforming system SHOULD implement pre-cutover validation that simulates the policy change against recent decision data to predict the impact before the cutover takes effect.

4.8. A conforming system SHOULD implement grace period alerting that warns operators a defined time before a policy expiry or cutover (e.g., 24 hours, 1 hour, 15 minutes).

4.9. A conforming system MAY implement temporal trigger orchestration across multiple dependent policy changes, ensuring that related changes activate in the correct sequence.

5. Rationale

Time is a deceptively complex input to policy evaluation. It appears straightforward — "activate this rule on 1 January 2027" — but the implementation is fraught with edge cases: clock skew between distributed systems, daylight saving transitions creating ambiguous hours, deployment delays causing missed deadlines, and expired overrides persisting because expiry was a human process rather than an automated mechanism.

The requirement for an authoritative time source (4.1) exists because distributed systems commonly have clock skew of seconds to minutes. If different nodes evaluate temporal triggers against their own clocks, two nodes can disagree about whether a time-triggered policy change has occurred. This produces the same non-deterministic behaviour that AG-272 prohibits for rule precedence — the outcome depends on which node processes the request.

The UTC requirement (4.4) eliminates an entire class of bugs related to daylight saving time. When clocks "fall back," the same local time occurs twice — creating ambiguous hours where a time trigger can fire twice (Scenario C) or where the system cannot determine whether the trigger time has passed. When clocks "spring forward," a local time window may be skipped entirely. UTC has no daylight saving transitions, making temporal trigger behaviour deterministic. Local time can be used for display but must never be used for trigger evaluation.

The atomicity requirement (4.5) addresses race conditions at the policy boundary. Consider a decision that begins evaluation at 23:59:59.998 and completes at 00:00:00.003, spanning a policy cutover at midnight. If the evaluation begins under the old policy and the enforcement check occurs under the new policy, the decision is evaluated under a mixed state that represents neither the old nor the new policy. Atomicity requires that the entire evaluation occurs under one consistent policy version.

Emergency override expiry (4.3) addresses a particularly common operational failure. Emergency overrides are created under time pressure with the understanding that they are temporary. But "temporary" is only enforced if the system enforces it. Every override that depends on human memory for expiry will eventually be forgotten, especially as the emergency that prompted it recedes in attention.

6. Implementation Guidance

Recommended patterns:

• Declarative temporal triggers in policy metadata. Define temporal conditions as metadata on the policy rule itself rather than as external deployment schedules. For example, a rule includes effective_from: "2027-01-01T00:00:00Z" and effective_until: "2027-06-30T23:59:59Z" as part of its definition. The rule engine evaluates these conditions at decision time against the authoritative clock. This approach makes temporal behaviour visible, testable, and versioned alongside the rule.
• Authoritative time service. Deploy a dedicated time service synchronised to stratum-1 or stratum-2 NTP servers. All policy evaluation components query this service rather than the local system clock. The time service logs its synchronisation status and raises alerts if clock drift exceeds a defined threshold (recommended: 100 milliseconds). In cloud deployments, use the cloud provider's time synchronisation service (e.g., Amazon Time Sync, Google Cloud NTP).
• Snapshot-at-evaluation-start for atomicity. When a decision evaluation begins, the system snapshots the current time and the active policy version. All evaluations within that decision use the snapshotted values. This prevents mixed-state evaluation when a policy cutover occurs mid-evaluation. The snapshot includes the policy version identifier per AG-269.
• Override expiry as a first-class mechanism. Implement duration-limited overrides with an explicit expiry time stored in the same data layer as the policy. The rule engine checks the expiry time on every evaluation. When the expiry time is reached, the override is automatically deactivated and the prior policy is restored. The deactivation is logged. No human action is required for expiry — human action is required only for extension.
• Pre-cutover impact simulation. Before a scheduled cutover, replay the last 24 hours of decision inputs against the new policy and compare outcomes. Differences indicate the impact of the change. Large unexpected differences trigger a review before the cutover proceeds. This provides concrete numbers: "This cutover will change the outcome of approximately 340 of the last 12,000 decisions."

Anti-patterns to avoid:

• Using cron jobs or deployment pipelines for policy cutovers. Deployment-based cutovers have inherent latency (build, deploy, restart), creating gaps between the intended activation time and the actual activation time. For regulatory deadlines, even a 5-minute gap can constitute non-compliance.
• Local time for trigger definitions. Local time introduces daylight saving ambiguity, timezone confusion across distributed teams, and inconsistent behaviour across regions. UTC eliminates these issues entirely.
• Manual expiry for time-limited overrides. Any override that requires a human to remember to remove it will eventually be forgotten. Automated expiry is the only reliable mechanism.
• Evaluating temporal conditions after action execution. If the system checks whether a policy has expired only after the action is submitted for execution, a race condition exists at the expiry boundary. Temporal conditions must be evaluated before action execution as part of the pre-execution policy check.
• Assuming clock synchronisation without verification. Distributed systems experience clock drift. Without monitoring and alerting on clock synchronisation status, the authoritative time source may drift without detection, causing temporal triggers to fire early or late.

Industry Considerations

Financial Services. Regulatory effective dates are legally binding. MiFID II tick-size regime changes, PSD2 strong customer authentication deadlines, and sanctions list updates must be enforced at the exact effective time. The FCA expects firms to demonstrate that regulatory changes were implemented by the deadline — not "within a few minutes of the deadline."

Healthcare. Drug formulary changes and clinical guideline updates often have effective dates that determine which patients receive which treatment. A delay in activating an updated contraindication list can result in patients receiving contraindicated medications.

Critical Infrastructure. Shift-based safety parameters (e.g., different operating limits during day and night shifts due to staffing levels) must transition at the exact shift change time. A gap between shifts where neither the day nor the night policy is active could create unsafe operating conditions.

Maturity Model

Basic Implementation — Temporal triggers are defined for policy rules with effective dates and expiry dates. Triggers are evaluated against the system clock. Duration-limited overrides have defined expiry times, though expiry may require a scheduled job. UTC is used for trigger definitions. Activation and deactivation events are logged.

Intermediate Implementation — An authoritative NTP-synchronised time service is used for all trigger evaluations. Policy cutovers are atomic, with no mixed-state evaluation. Override expiry is automated and requires no human action. Pre-cutover impact simulation is performed for major policy changes. Grace period alerting warns operators before upcoming cutovers and expiries. Clock synchronisation is monitored with alerting on drift.

Advanced Implementation — All intermediate capabilities plus: formal verification of temporal trigger behaviour including daylight saving edge cases, leap-second handling, and concurrent cutover scenarios. Temporal trigger orchestration sequences dependent policy changes. Sub-second cutover precision verified by independent testing. The time service is hardened against manipulation (e.g., NTP authentication, GPS-disciplined clocks for critical infrastructure).

7. Evidence Requirements

Required artefacts:

• Temporal trigger inventory. A list of all active temporal triggers, showing: trigger type (activation, expiry, window), the associated rule, the trigger time (UTC), the policy version before and after, and the current status (pending, active, expired). Format: structured data.
• Trigger activation/deactivation logs. Timestamped records of all temporal trigger events, showing: trigger definition, authoritative time, policy version transition, and time source. Format: structured log export.
• Time synchronisation evidence. Evidence that the authoritative time source is synchronised to a stratum-1 or stratum-2 NTP server, including synchronisation logs, drift measurements, and alert history. Format: NTP status logs.
• Override expiry evidence. Evidence that at least one duration-limited override has been automatically expired by the system, showing: override creation time, override expiry time, automatic deactivation timestamp, and the policy restored after expiry. Format: structured log.

Retention requirements:

• Trigger activation/deactivation logs: aligned with decision log retention per AG-269. Time synchronisation logs: minimum 12 months.

Access requirements:

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

8. Test Specification

Test 8.1: Cutover Precision

• Stimulus: Schedule a policy cutover for a specific time T. Submit decision requests at T-2s, T-1s, T, T+1s, and T+2s.
• Expected behaviour: Decisions at T-2s and T-1s are evaluated under the old policy. Decisions at T, T+1s, and T+2s are evaluated under the new policy. The transition occurs within 1 second of the specified time T.
• Pass criteria: Policy cutover occurs within 1 second of the specified time, with no decisions evaluated under a mixed state.
• Fail criteria: Cutover is delayed by more than 1 second, or any decision is evaluated under mixed old/new policy.

Test 8.2: Override Automatic Expiry

• Stimulus: Create a duration-limited override with a 5-minute expiry. Submit decisions during the override and after expiry.
• Expected behaviour: Decisions during the override period are governed by the override policy. Decisions after expiry are governed by the restored prior policy. No human action is required for the transition.
• Pass criteria: The override expires automatically within 1 second of the expiry time and the prior policy is restored.
• Fail criteria: The override persists beyond the expiry time, or manual intervention is required for expiry.

Test 8.3: Daylight Saving Immunity

• Stimulus: Define a temporal trigger using UTC and evaluate it during a daylight saving transition in the local timezone (both spring-forward and fall-back). Verify that the trigger fires exactly once.
• Expected behaviour: The trigger fires exactly once regardless of local timezone transitions. No double-firing during fall-back. No skipped firing during spring-forward.
• Pass criteria: Trigger fires exactly once at the correct UTC time.
• Fail criteria: Trigger fires twice during fall-back, is skipped during spring-forward, or fires at the wrong time.

Test 8.4: Clock Skew Resilience

• Stimulus: Introduce artificial clock skew of 5 seconds on one node in a multi-node deployment. Submit decisions to both the skewed and non-skewed nodes near a policy cutover time.
• Expected behaviour: Both nodes evaluate temporal triggers against the authoritative time service, not the local clock. Both nodes cut over at the same time regardless of local clock skew.
• Pass criteria: All nodes apply the policy cutover at the same time (within 1 second) regardless of local clock skew.
• Fail criteria: Nodes with clock skew apply the cutover at a different time than nodes without skew.

Test 8.5: Atomic Evaluation Across Cutover Boundary

• Stimulus: Submit a decision request that begins evaluation immediately before a policy cutover and completes evaluation after the cutover (simulate by introducing a processing delay).
• Expected behaviour: The decision is evaluated entirely under one policy version — either the old or the new, not a mix.
• Pass criteria: The decision log shows a single policy version for the decision, consistent with the snapshot-at-evaluation-start mechanism.
• Fail criteria: The decision is evaluated under mixed policy versions, or the policy version in the log does not match the version that was actually evaluated.

Test 8.6: Temporal Trigger Logging Completeness

• Stimulus: Trigger 10 temporal events (activations and expirations). Query the trigger log.
• Expected behaviour: All 10 events are logged with: trigger definition, authoritative time, policy version transition, and time source.
• Pass criteria: 100% of temporal trigger events are logged with complete metadata.
• Fail criteria: Any temporal trigger event is missing from the log or has incomplete metadata.

Test 8.7: Expired Policy Rejection

• Stimulus: Attempt to submit a decision request referencing an expired policy version (one whose expiry time has passed).
• Expected behaviour: The system rejects the decision request with a structured error indicating the policy has expired.
• Pass criteria: No decision is executed under an expired policy.
• Fail criteria: A decision executes under a policy whose expiry time has passed.

Conformance Scoring

• Score 0: No temporal trigger management — policy changes are applied via manual deployment with no time precision or automatic expiry.
• Score 1: Temporal triggers are defined and logged, but evaluation uses the local system clock; override expiry requires manual action; cutover precision is measured in minutes rather than seconds.
• Score 2: Authoritative time source for all trigger evaluations, atomic cutover within 1 second, automated override expiry, UTC for all trigger definitions, and daylight saving immunity verified.
• Score 3: All Score 2 capabilities plus formal verification of temporal trigger behaviour, sub-second cutover precision, pre-cutover impact simulation, temporal trigger orchestration for dependent changes, and hardened time source with authentication.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
MiFID II	RTS 25 (Clock Synchronisation)	Direct requirement
PSD2	Article 97 (Strong Customer Authentication)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.4, MANAGE 2.2	Supports compliance
ISO 42001	Clause 8.2 (AI Risk Assessment)	Supports compliance
IEC 61511	Clause 16 (SIS Modification)	Supports compliance

MiFID II — RTS 25 (Clock Synchronisation)

RTS 25 requires investment firms to synchronise their business clocks to UTC with defined precision tolerances (100 microseconds for high-frequency trading, 1 second for other activities). Temporal policy triggers that govern financial decisions must meet the same clock synchronisation standards. This maps directly to Requirement 4.1 (authoritative time source) and the precision requirements of Requirement 4.2.

PSD2 — Article 97 (Strong Customer Authentication)

PSD2 strong customer authentication requirements were phased in with specific effective dates. Financial agents that process payments must enforce SCA requirements from the exact regulatory effective date. A temporal trigger that activates the SCA policy even 5 minutes late creates a compliance gap where transactions are processed without required authentication.

FCA SYSC — 6.1.1R

The FCA expects firms to implement regulatory changes by the effective date. For automated systems, this means the system must enforce the new policy from the exact effective time. "The deployment usually runs at midnight and finishes by 12:05" is not adequate — the firm must demonstrate that the policy was active at the regulatory effective time.

IEC 61511 — Clause 16

Clause 16 addresses modifications to safety instrumented systems. Time-triggered safety parameter changes (e.g., shift-based operating limits) are safety modifications that must be implemented atomically and without gaps. A transition period where neither the old nor the new safety parameters are active is a safety integrity loss.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	All decisions made during the temporal gap or under expired policy — concentrated but potentially high-value

Consequence chain: Temporal trigger failures create concentrated compliance gaps around transition times. The immediate technical failure is a policy cutover that occurs late, a policy expiry that is not enforced, or a policy that applies twice during a daylight saving transition. The operational impact is that decisions made during the gap are governed by the wrong policy — the old policy when the new one should be active, or the expired override when the base policy should have resumed. For regulatory effective dates, the gap constitutes non-compliance from the effective time until the actual activation, exposing every decision in that window to challenge. For expired emergency overrides, the impact accumulates over time — the override in Scenario B persisted for 17 days. The regulatory consequence depends on the domain: in financial services, MiFID II RTS 25 non-compliance for clock synchronisation can result in fines; missed regulatory effective dates create compliance gaps that regulators view as control failures; in critical infrastructure, temporal gaps in safety parameters can create unsafe conditions during shift transitions. The business consequence includes regulatory enforcement, remediation of all decisions made during the gap, and potential customer harm.

Cross-references: AG-269 (Policy Version Pinning Governance) ensures that temporal trigger events are linked to specific policy versions. AG-272 (Exception Precedence Governance) defines how time-limited exemptions interact with permanent rules. AG-274 (Geographic Policy Trigger Governance) addresses jurisdiction-based triggers that often combine with temporal triggers (e.g., a regulation effective in jurisdiction X from date Y). AG-270 (Policy Compilation Verification Governance) verifies that compiled temporal conditions match the approved specification. AG-277 (Policy Change Provenance Governance) tracks who scheduled each temporal trigger and under what authority. AG-007 (Governance Configuration Control) governs changes to trigger definitions. AG-134 (Machine-Checkable Policy Semantics) provides the formal framework for expressing temporal conditions. AG-136 (Independent Control-Plane Separation) supports the requirement for an authoritative time source independent of the agent runtime.