Skip to content

FR-003: Acknowledgment Checkpoints

Status: Proposed
Priority: Medium (compliance posture; NexTern pilot driver)
Author: Tim McCrimmon
Created: 2026-06-10
Target Version: v0.4
Regulatory hook: EU AI Act Art. 14(4) (named person with competence, authority, and support to exercise oversight)
Depends on: FR-002 (owner_id field and escalation routing)

Summary

For long-running or high-risk agents, periodic human acknowledgment that the agent is operating as expected. The named owner must confirm continued operation at a configurable interval; failure to acknowledge within the window triggers an escalation event. This creates a documented record of active oversight — not just nominal ownership.

Problem Statement

Assigning an owner to an agent at deploy time satisfies the "identified person" requirement of EU AI Act Art. 14(4), but not the "actively exercising oversight" expectation. A named owner who has not interacted with a running agent in 30 days does not constitute meaningful oversight for high-risk AI.

This is the difference between: - Nominal accountability — someone's name is on record (current state) - Active accountability — that person periodically confirms the agent is behaving as expected (this FR)

The NexTern process agreement ("someone accountable manages every deployed agent") implies the latter. This FR gives SCP a mechanism to enforce and document it.

Proposed Solution

1. Checkpoint policy on agent registration

Add an optional checkpoint_policy to agent configuration:

{
  "checkpoint_interval_hours": 24,
  "checkpoint_required_for": ["high_risk", "long_running"],
  "on_missed_checkpoint": "escalate"
}

Where on_missed_checkpoint supports: escalate (default), pause, or log_only.

2. Checkpoint state tracking

Add a agent_checkpoints table: - agent_id - due_at — when the next acknowledgment is required - acknowledged_at — when the owner confirmed - acknowledged_by — user who acknowledged - status — pending / acknowledged / missed / escalated

3. Background job

A scheduled job (runs at configurable interval, e.g. every 15 minutes) checks for: - Active agents with a checkpoint_policy - Checkpoints that are past due_at and not acknowledged - On miss: write a checkpoint record with status = missed, emit an escalation event via FR-002's routing mechanism, set due_at for next interval

4. Acknowledgment endpoint

POST /api/agents/{id}/checkpoint/acknowledge

Owner (authenticated) confirms the agent is operating as expected. Optionally accepts a note. Writes acknowledged_at, acknowledged_by. Resets due_at for the next interval.

5. Audit trail

Acknowledgments and misses are written to the audit log with the owner's identity and timestamp. This is the compliance evidence — a regulator or Notified Body can see the history of who acknowledged what, when.

Scope Boundaries

  • The checkpoint is a human-driven signal, not an automated health check. SCP already has agent heartbeats (last_heartbeat in active_subscriptions) for connection monitoring. This is separate — it records human oversight activity, not connection state.
  • The pause option for on_missed_checkpoint requires coordination with the context service to stop delivering context to the agent. Spec that interaction carefully before implementing.

Acceptance Criteria

  • Agent registration accepts an optional checkpoint_policy
  • Background job detects missed checkpoints and emits escalation events
  • POST /api/agents/{id}/checkpoint/acknowledge records acknowledgment with owner identity and timestamp
  • Acknowledgment history is queryable and appears in audit log
  • log_only and escalate modes for missed checkpoint implemented; pause mode specced but may be v0.4.1