Latency SLA & Performance Specifications

Effective: v10.1.5+ · Last updated: 2026-02-26

This document defines the formal service-level objectives (SLOs), consistency model, and failure behavior of the ABS Core governance engine. It is intended for risk committees, enterprise architects, and compliance officers evaluating ABS Core for regulated-environment deployment.

Formal SLO Commitments

Operational Load (up to 1,000 req/s)

Overload Protection (above 1,000 req/s)

Latency Budget by Component

LLM context: A standard LLM response (OpenAI GPT-4o, Anthropic Claude) takes 500ms–2,000ms. The 153ms P50 governance overhead represents <10% of total agent response time at P50, and is below the perceptual threshold for end users.

Consistency Model

This section addresses the consistency and transactional guarantees required for regulated financial environments.

Decision Consistency: Strong

Every POST /v1/decide or POST /v1/authorize call is:

• Synchronous — the caller receives a verdict before any downstream action executes
• Deterministic — same input + same policy version → same verdict, always
• Versioned — the active policy version is recorded in every decision envelope

There is no eventual consistency in the decision path. A decision is either ALLOW or DENY — never "pending" or "probably allow."

Audit Log Consistency: Write-once, append-only

Idempotency

All write operations in ABS Core are idempotent by event_id:

// Submitting the same event_id twice → same result, no duplicate record
const result = await abs.process({
  event_id: "evt_TXN-4421-refund",   // client-generated stable ID
  tenant_id: "my-tenant",
  event_type: "agent.action",
  payload:  { action: "WRITE", target: "accounts/acc_123/refund", amount: 250.00 },
}, { sync: true });

const decision = result.envelope;

If the same event_id is submitted twice (e.g., due to network retry), the second call returns the original decision without creating a duplicate audit record. This guarantee is critical for payment systems where retry-on-failure is standard practice.

MTTR and Recovery Commitments

RTO / RPO

Circuit Breaker Behavior

The CHI semantic analysis engine has a 200ms hard timeout. If exceeded:

1. The request proceeds with Fail-Safe ALLOW — the agent's action is not blocked
2. The event is flagged as chi_timeout: true in the audit record
3. A Sentry alert is fired for the workspace
4. The CHI engine is bypassed for subsequent requests until it recovers (exponential backoff, max 30s)

This design ensures the governance layer never becomes a single point of failure that halts production systems — a hard requirement for financial infrastructure.

Shadow Mode (Non-Blocking Governance)

For high-frequency, low-stakes operations where even 153ms P50 overhead is unacceptable:

# policy.yaml
mode: shadow          # analyze but do not block
enforcement: strict   # when promoted, full blocking applies
alert_on_violation: true

In shadow mode:

• All requests pass through regardless of verdict
• Violations are recorded in the audit log with shadow: true flag
• Dashboards show violation rate for that operation class
• Teams can promote to enforcement mode when confident in policy correctness

Shadow mode is the recommended entry point for new agent integrations and high-frequency read operations.

Benchmark Reference

All numbers in this document are derived from the Benchmark Report, which documents three test classes (endurance at 200 req/s for 2h, load at 1,000 req/s for 60 min, stress at 5,000 req/s for 15 min) with results anchored on the Bitcoin blockchain.