Continuous Assurance Platform — v1.1

ARA certification is not a point-in-time assessment. The Continuous Assurance Platform (CAP) extends certification integrity into production by monitoring certified systems for behavioral drift, compliance degradation, and operational anomalies throughout the certification period.

In v1.1, monitoring requirements are differentiated by Assurance Class. Class A (Periodic) systems self-monitor with annual review. Class B (Monitored) and Class C (Continuous) systems require a Certified Assurance Platform Operator (CAPO) to provide ongoing monitoring infrastructure and incident response.

Class-Differentiated Monitoring

Monitoring depth, cadence, and infrastructure requirements scale with the Assurance Class. Higher classes demand greater automation, tighter SLAs, and dedicated CAPO involvement.

Class A — PeriodicClass B — MonitoredClass C — Continuous

Metric	A	B	C
CAPO Required	No	Yes	Yes
Reporting Cadence	Annual self-assessment	Monthly CAPO reports	24/7 real-time
Telemetry	Basic (optional)	Automated collection	Full pipeline required
Drift Detection	Self-monitored	CAPO-managed	Real-time with alerting
Incident Response	Self-managed	CAPO-assisted	CAPO-led, ≤4hr response
Review Cadence	Annual AVB review	Quarterly AVB review	Continuous AVB oversight

Certified Assurance Platform Operators (CAPOs)

CAPOs are organizations certified by ARAF to provide continuous monitoring infrastructure and assurance services for Class B and Class C certified systems. They serve as the operational backbone of post-certification assurance, bridging the gap between the certified organization and the certifying AVB.

What CAPOs Do

•Continuous monitoring of certified system telemetry against behavioral baselines
•Telemetry analysis including trend detection and statistical anomaly identification
•Drift detection with configurable thresholds per domain and assurance class
•Incident escalation to AVBs and certified organizations with documented response chains
•Compliance reporting on agreed cadences (monthly for Class B, real-time for Class C)
•Revalidation trigger management when monitoring signals breach thresholds

CAPO Technical Requirements

•Telemetry ingestion pipeline capable of processing structured ARA telemetry events
•Anomaly detection engine with statistical and rule-based analysis capabilities
•Real-time monitoring dashboard accessible to certified organizations and AVBs
•Alerting system with configurable severity levels and escalation paths
•Automated compliance reporting with audit trail and data retention
•Secure data handling with encryption in transit (TLS 1.3) and at rest (AES-256)

CAPO SLA Metrics by Assurance Class

BClass B SLAs

•99.5% platform uptime
•24-hour report turnaround
•Monthly compliance summary delivered to AVB
•Drift alerts within 4 hours of detection

CClass C SLAs

•99.9% platform uptime
•4-hour incident response time
•Real-time monitoring dashboard (≤30s latency)
•15-minute escalation to AVB for critical alerts

View CAPO directory →

Operational States

Every ARA-certified system exists in one of six operational states throughout its certification lifecycle. State transitions are triggered by monitoring events, time-based conditions, or governance actions. New in v1.1, the “Active — Assurance Lapsed” state provides a grace period before suspension.

Active

Certification valid and monitoring compliant. All reporting obligations current. System in good standing.

Active — Assurance Lapsed

Certification remains valid but monitoring obligations are overdue. The lapse window is active — the organization must remediate within the class-specific lapse period to avoid suspension.

Under Revalidation

Triggered by a material change notification, monitoring threshold breach, or incident report. The system remains operational but is undergoing targeted or full revalidation by the certifying AVB.

Suspended

Certification temporarily invalid. Typically triggered by an unremediated lapse, a critical monitoring breach, or a governance action. The system must not represent itself as ARA-certified while suspended.

Expired

The certification has passed its validity period without renewal. The organization must undergo reassessment to restore certification.

Revoked

Certification permanently invalidated by governance action. Revocation is reserved for material misrepresentation, fraud, or sustained non-compliance. A revoked certification cannot be reinstated — the organization must apply for a new certification.

Lapse Windows

When monitoring obligations fall overdue, the system enters the “Active — Assurance Lapsed” state. Each Assurance Class defines a lapse window — the maximum period during which the organization may remediate before automatic suspension.

A90 days

After lapse, the organization must re-establish periodic self-assessment and submit a remediation report to the certifying AVB.

Annual self-assessment cycle must resume before lapse window closes.

B60 days

Monthly CAPO reports must resume. A gap analysis covering the lapse period is required before the system returns to Active status.

CAPO must confirm monitoring restoration and deliver a lapse period review.

C30 days

Continuous monitoring must be fully restored. An incident review covering the lapse period is required, and the CAPO must confirm pipeline integrity.

Real-time telemetry must resume with ≤30s latency before lapse window closes.

Status Progression

Active→Assurance Lapsed→Suspended(if unremediated)

Telemetry Architecture

The ARA Telemetry SDK is the primary integration mechanism for connecting certified systems to the Continuous Assurance Platform. The SDK provides a lightweight, language-agnostic interface for reporting telemetry events, drift metrics, and operational status to the monitoring infrastructure (self-hosted for Class A, CAPO-managed for Class B and C).

Event Types

Operational Events

•System startup and shutdown events
•Decision execution events (with outcome metadata)
•Autonomy boundary enforcement events
•Escalation and override events
•Tool invocation events

Drift Metrics

•Decision distribution snapshots
•Error rate rolling averages
•Escalation frequency tracking
•Latency profile distributions
•Boundary adherence scores

Event Types (continued)

Incident Signals

•Error and exception events
•Boundary exceedance notifications
•Unauthorized autonomous action alerts
•Cascading failure indicators
•Version change without notification flags

Health Checks

•Periodic heartbeat signals
•Telemetry pipeline health status
•Model or version change events
•Resource consumption baselines

Integration Patterns by Assurance Class

BClass B Integration

•Telemetry SDK reports to CAPO-managed ingestion endpoint
•Automated daily batch collection with optional real-time streaming
•CAPO processes drift analysis on configurable schedules
•Monthly compliance reports generated and delivered to AVB
•Webhook-based alerting for threshold breaches

CClass C Integration

•Full telemetry pipeline with real-time streaming (≤30s latency)
•Continuous drift analysis with real-time anomaly detection
•Live monitoring dashboard accessible to organization, CAPO, and AVB
•Automated escalation within 15 minutes for critical alerts
•mTLS required for all API interactions

View Telemetry SDK documentation →

Drift Detection

Behavioral drift occurs when a certified system's operational characteristics diverge from the behavioral baseline established during evaluation. Drift may result from model updates, data distribution shifts, environmental changes, or emergent behavior patterns. Drift detection responsibility varies by class: self-monitored for Class A, CAPO-managed for Class B, and real-time with automated alerting for Class C.

Drift Dimension	What Is Measured	Threshold Behavior
Decision distribution	Statistical distribution of decision outcomes compared to the baseline. Detects shifts in decision frequency, outcome ratios, or action type distribution.	Warning at 15% deviation; critical at 30% deviation from baseline distribution.
Error rate	Rate of errors, exceptions, and failed operations relative to total operations. Tracked as a rolling average with configurable window.	Warning at 2x baseline error rate; critical at 5x baseline error rate.
Escalation frequency	Rate of escalation events compared to baseline. Both increases and decreases may indicate drift — a system that stops escalating may be bypassing controls.	Warning at 50% increase or 30% decrease from baseline frequency.
Boundary adherence	Frequency and severity of operations approaching or exceeding declared autonomy boundaries.	Any boundary exceedance triggers an immediate critical alert.
Latency profile	Response time distribution for decision execution. Significant latency changes may indicate underlying system changes.	Warning at p99 latency exceeding 3x baseline.

Revalidation Triggers

Beyond scheduled reassessment cycles, monitoring data may trigger unscheduled revalidation when it indicates potential compliance degradation. Revalidation triggers are automatic — they cannot be suppressed by the certified organization, the CAPO, or the AVB.

Sustained drift threshold breach

A drift dimension exceeds the critical threshold for more than 48 consecutive hours without remediation.

Action: Targeted revalidation of affected domains. AVB must initiate within 10 business days.

Blocking ACR indicator

Runtime telemetry suggests that a blocking ACR may no longer be satisfied (e.g., escalation path unavailability, boundary enforcement failure).

Action: Immediate AVB notification. Certification suspension pending investigation if not resolved within 24 hours.

Telemetry gap

The system fails to report required telemetry for a period exceeding the maximum allowable gap. Class A: 30 days. Class B: 72 hours. Class C: 1 hour.

Action: Warning issued to organization. Escalation to AVB if gap persists beyond the class-specific lapse window threshold.

Version change without notification

Monitoring detects behavioral signatures consistent with a material system change that was not reported through the version tracking interface.

Action: Critical alert. Organization must provide a version change report within 48 hours or face suspension review.

Incident report

A material safety incident, unauthorized autonomous action, or operational failure is reported by the organization, a user, or a third party.

Action: AVB-led incident review. For Class B/C, CAPO provides monitoring data for investigation. Revalidation scope determined by findings.

External intelligence

ARAF receives credible information (e.g., vulnerability disclosure, regulatory action) that may affect the certified system’s compliance status.

Action: Targeted revalidation or full reassessment as determined by ARAF.

Certification Inheritance Monitoring

When a deployment inherits from a platform certification, monitoring must cover both the platform layer and the deployment layer. This dual-layer monitoring ensures that inherited compliance guarantees remain valid throughout the certification period.

Platform Vendor Responsibilities

•Maintains platform-layer monitoring per its own Assurance Class
•Reports platform-layer telemetry to its designated CAPO (if Class B/C)
•Notifies deployment operators of platform-level changes that may affect inherited domains
•Provides platform health data accessible to deployment CAPOs

Deployment Operator Responsibilities

•Maintains deployment-layer monitoring per its own Assurance Class
•Reports deployment-specific telemetry covering non-inherited domains
•Monitors the integration boundary between platform and deployment layers
•Tracks platform vendor notifications for changes affecting inherited compliance

Combined Stack Monitoring

When a CAPO is involved (Class B or C deployments), the CAPO monitors the combined stack — both the platform-layer signals and the deployment-layer signals. The CAPO correlates cross-layer telemetry to detect drift or incidents that span the inheritance boundary, ensuring that neither the platform vendor nor the deployment operator has a blind spot in their compliance posture.

Version Tracking

ARA certification is scoped to a specific system version. Any material change to the certified system must be reported via the version tracking interface. Version changes are categorized and may trigger different levels of revalidation.

Change Category	Examples	Impact
Minor configuration	Threshold adjustments, feature flag toggles, UI changes with no decision logic impact.	Logged only. No revalidation required.
Model update	Foundation model version change, fine-tuning update, embedding model swap.	AVB notification required. Targeted revalidation of affected domains.
Logic change	Decision tree modifications, new tool integrations, autonomy boundary adjustments.	Full recertification may be required. AVB determination within 10 business days.
Scope expansion	New deployment environment, new user population, expanded geographic or operational scope.	Full recertification required for the expanded scope.