Core Concepts & Terminology

Status: Standard-only Alpha (v1.0.0-alpha.2)
Last Updated: 2026-03-12
Spec ID: ACGP-1
Normative Keywords: MUST, SHOULD, MAY (per RFC 2119 and RFC 8174)

Abstract

This specification defines the foundational concepts, terminology, runtime topologies, profile model, resilience defaults, and two-stage evaluation architecture for ACGP v1.0.

ACGP-1 is the read-first document for all implementers. Every subsequent specification (ACGP-2 through ACGP-6) builds on the concepts and definitions established here.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1. Scope

ACGP-1 defines architecture-level concepts and normative runtime behavior expectations.

ACGP-1 does not define:

  • Wire schema details (→ ACGP-2)
  • Full policy schema details (→ ACGP-3)
  • Tripwire DSL grammar (→ ACGP-4)
  • Audit and privacy controls (→ ACGP-5)
  • Conformance runner protocol (→ ACGP-6)

2. Introduction and Design Principles

2.1 What is ACGP?

The Agentic Cognitive Governance Protocol (ACGP) provides runtime governance for AI agents, ensuring they operate safely and in alignment with organizational policies through continuous cognitive quality monitoring.

Core Principle: Separate governance logic from agent logic, enabling real-time oversight without modifying your agent's code.

2.2 How It Works

  • Assess deployment risk and assign a Governance Tier.
  • Apply Blueprint-defined governance at runtime.
  • Emit interventions and audit-visible artifacts for each governed action.
  • Rely on later specifications for operational ordering, wire behavior, and fail-closed details.

The authoritative operational evaluation ordering is defined in ACGP-3, with tripwire fail-closed semantics defined in ACGP-4.

2.3 Primary Design Principles

  • Separation of Concerns: Governance logic is separate from agent logic. An agent does work; a steward ensures it is safe.
  • Defense in Depth: Multiple layers of validation and intervention — tripwires, CTQ scoring, trust debt accumulation, and human-in-the-loop escalation.
  • Minimal Intrusion: One-line integration for existing agents. Governance wraps agent behavior without requiring changes to core agent code.
  • Deterministic Defaults: Safety-critical pathways use deterministic, fail-closed behavior. No probabilistic shortcuts for critical safety checks.
  • Auditability: Every governance-relevant decision is logged to a tamper-evident audit store with cryptographic integrity guarantees.
  • Scalability: Horizontal scaling of governance components. Stewards, policy engines, and query services scale independently.
  • Resilience: Graceful degradation under failure conditions with profile-mandated fallback defaults.

2.4 Requirements Language

Requirements language for this specification is defined in the top-level Requirements Language section.

Alpha Trust Boundary

v1.0.0-alpha.2 defines interoperable governance semantics and now ships a minimum steward trust/bootstrap profile, but it does not yet define full automated trust federation.

Implementations MUST validate the configured steward trust root, identity binding, key lifecycle state, and local fast-path assurances using the shipped bootstrap artifacts and deployment controls. External identity-provider integration and federation still remain deployment responsibilities.

For the conceptual deployment-responsibility map, see docs/learn/concepts/protocol-boundaries.md.

3. Terminology and Naming Rules [NORMATIVE]

3.1 Tier Namespace Conventions

ACGP introduces multiple concepts that use the term "tier" or "level". To prevent ambiguity, all tier/level references MUST be qualified in documentation, APIs, and implementations.

Canonical Tier Namespaces:

Concept Short Form Long Form Set At Example
Governance Tier GT-2 Governance Tier 2 Design/deployment "This agent is in Governance Tier 2"
Evaluation Depth Eval-1 Eval Tier 1 Runtime (per-request) "Run Eval-1 checks"
Conformance Profile Standard Standard Profile Deployment "Standard conformant implementation"

Usage in code [NORMATIVE]:

# GOOD: Unambiguous
from acgp import EvalTier
agent = Agent(governance_tier="GT-2")
request = EvalRequest(eval_tier=EvalTier.FAST_SYNC)  # Eval-1

# BAD: Ambiguous
agent = Agent(tier=2)  # Which tier?!

Usage in message formats [NORMATIVE]:

{
  "governance_tier": "GT-2",
  "requested_eval_tier": "eval-1",
  "steward_conformance": "standard"
}

Usage in documentation [NORMATIVE]:

ALWAYS use qualified terms in prose.

  • GOOD: "An agent in Governance Tier GT-2 requests Eval-1 checks within a 300ms budget."
  • BAD: "A Tier 2 agent requests Tier 1 checks within a 300ms budget."

Serialized Governance Tier values remain GT-0 through GT-5 on the wire and in policy data.

3.2 Normative Terminology Table

Term Definition
Governance Steward Runtime governance agent that observes Cognitive Traces, calculates CTQ scores, and issues interventions.
Operating Agent The autonomous or semi-autonomous AI agent being monitored and governed.
Agent Principal The stable governed identity of an Operating Agent within a deployment-defined trust domain, represented by agent_id. Assigned by the host runtime, operator, or deployment control plane. The primary key for per-agent governance state.
Agent Label Optional human-readable display name for an Operating Agent. Non-authoritative and MUST NOT be used as a trust anchor, policy key, or audit correlation key.
Steward Network Coordinated network of multiple Governance Stewards for distributed governance.
Cognitive Trace Structured record of an agent's inputs, reasoning, tool calls, decisions, and outputs for a single execution step. The fundamental unit of governance observation.
Reflection Blueprint YAML/JSON configuration file defining quality metrics, thresholds, checks, and evidence requirements. Primary policy artifact.
Clarity Baseline Mandatory minimum governance policy evaluating reasoning clarity, logical consistency, and absence of cognitive biases. The "cognitive seatbelt."
ARS (Agent Risk Score) Composite deployment-time risk metric (0–15) quantifying agent risk: Autonomy + Adaptability + Continuity, each 0–5.
Governance Tier Discrete default enforcement tier initially derived from ARS. Steward implementations MAY maintain a stricter effective Governance Tier or stricter runtime posture based on trust debt, intervention history, or operational signals, but v1.0 alpha does not standardize downward relaxation below the ARS-derived baseline. Governance Tier values remain serialized as GT-0 through GT-5 in v1.0 alpha for wire stability.
CTQ (Cognitive Trace Quality) Normalized runtime quality score (0–1). Weighted average of five standard metrics.
Risk Score Inverse of CTQ: 1.0 - CTQ. Used for threshold comparisons.
Intervention Runtime decision: one of ok, nudge, escalate, block, halt (five primary levels), plus orthogonal flag.
Intervention Execution Mode Session-scoped control-plane state that determines whether a final intervention is advisory (passive, default) or execution-authoritative (active). It does not change intervention computation semantics.
Tripwire Critical condition triggering immediate intervention regardless of CTQ score.
Trust Debt Runtime governance state reflecting accumulated intervention pressure. Debt MAY increase scrutiny, logging, review requirements, or restricted handling and MAY trigger Governance Tier review or queued ARS reassessment. Trust Debt MUST NEVER relax intervention severity. Implementations MAY use public or private providers while preserving the observable semantics defined in ACGP-3 §9.
Authoritative Enforcer Runtime responsible for enforcing a scoped extension requirement. For local, the authoritative enforcer is the SDK or local runtime applying the bundle. For remote, the authoritative enforcer is the Governance Steward or other remote authoritative runtime. For both, both local and remote runtimes are authoritative enforcers.
Governance Store The durable persistence layer used to record governance decisions, evidence, state transitions, and audit artifacts for replay, review, and cross-agent verification. Where a deployment requires immutable notarization or append-only audit semantics, the Governance Store may expose or integrate a narrower Governance Ledger surface.
Policy Engine Runtime component that evaluates CTQ scores against thresholds and issues intervention decisions.
Trusted Monitor (TM) Independent observer that validates agent behavior and detects anomalies.
Human-In-The-Loop (HITL) Escalation pathway routing critical decisions to human operators.
MPA (Multi-Party Authorization) Security mechanism requiring multiple approvers for sensitive configuration changes.
Mission Envelope Defined boundaries of allowed tools, resources, data domains, and budgets for a specific agent.

For normative identity semantics, including agent_id, agent_label, and sender_id distinctions, see ACGP-7.

3.3 Wire Representation for Intervention Decisions [NORMATIVE]

Intervention decision values on the wire MUST use the canonical lowercase representation and MUST be compared case-sensitively.

Canonical values are: ok, nudge, escalate, block, halt.

3.4 Intervention Types

Five primary intervention levels:

Intervention Action Semantics
ok Allow and log In passive mode, advisory allow. In active mode, affirmative permit to proceed.
nudge Suggest modification Agent MUST acknowledge. Active-mode execution semantics are controlled by the frozen nudge_behavior contract in §3.5.
escalate Pause for human review In passive mode, advisory escalation. In active mode, execution is suspended pending HITL finalization or timeout fallback.
block Prevent this action In passive mode, advisory deny. In active mode, execution is denied.
halt Kill-switch In passive mode, advisory terminal signal. In active mode, execution is terminated. See ACGP-4 for the tripwire-only halt invariant.

Orthogonal Modifier

Modifier Action Semantics
flag Audit tag + trust debt Action marked for review; accumulates trust debt in addition to the primary decision's accumulation weight. Orthogonal — combines with any primary intervention via flags.flagged: true. NOT a decision-level value on the wire.

Decision Formation Summary

Thresholds yield primary decisions: ok | nudge | escalate | block. These are the four outcomes of the risk-score → threshold mapping (ACGP-3 §7).

flag is orthogonal — it can combine with any primary decision via flags.flagged: true. It is NOT a threshold level.

See ACGP-4 for the tripwire-only halt invariant.

decision: "flag" is not a valid standalone wire value. Implementations MUST represent flagging as decision: "ok" plus flags.flagged: true. See §3.3 for canonical wire values.

3.5 Nudge Behavioral Contract [NORMATIVE]

The v1.0 nudge_behavior surface is frozen to exactly two values:

  • acknowledge_and_proceed
  • acknowledge_and_retry

For nudge interventions, implementations MUST enforce the following minimum behavior:

  1. Operating Agent MUST acknowledge receipt of a nudge intervention (via EVAL response, TRACE follow-up metadata, or equivalent wire-visible acknowledgment).
  2. In passive mode, Operating Agent MAY retry the action with modifications informed by the nudge message.
  3. In passive mode, Operating Agent MAY proceed with the original action after acknowledgment, but the nudge and acknowledgment MUST be logged.
  4. Consecutive nudge interventions for the same action pattern SHOULD increase trust debt accumulation pressure per ACGP-3 trust debt settings.

In active mode, nudge_behavior applies only after the final intervention decision is known:

  1. acknowledge_and_proceed permits continuation only after acknowledgment when no modifications are present.
  2. When nudge includes modifications, allow_local_auto_apply means whether the runtime may apply Steward-provided nudge modifications locally without caller resubmission.
  3. allow_local_auto_apply affects only the active nudge plus modifications path. It does not change ok, escalate, block, or halt semantics.
  4. If active-mode nudge modifications cannot be applied safely or deterministically under the synchronized policy, the runtime MUST NOT continue the current execution unchanged.
  5. flag remains orthogonal in both passive and active mode. flag alone MUST NOT deny, suspend, or terminate execution.

The normative v1.0 nudge execution table is:

Execution Mode Modifications Present allow_local_auto_apply nudge_behavior Required Runtime Behavior
passive No false or true acknowledge_and_proceed Agent MUST acknowledge. Agent MAY proceed unchanged or retry.
passive No false or true acknowledge_and_retry Agent MUST acknowledge. Agent MAY retry. Agent MAY also proceed unchanged because passive mode remains advisory, but the acknowledgment and advisory nudge MUST be logged.
passive Yes false acknowledge_and_proceed Agent MUST acknowledge. Agent MAY retry with modifications or proceed unchanged.
passive Yes true acknowledge_and_proceed Agent MUST acknowledge. Agent MAY retry with modifications or proceed unchanged.
passive Yes false acknowledge_and_retry Agent MUST acknowledge. Agent MAY retry with modifications or proceed unchanged, but the intervention remains advisory in passive mode.
passive Yes true acknowledge_and_retry Agent MUST acknowledge. Agent MAY retry with modifications or proceed unchanged, but the intervention remains advisory in passive mode.
active No false or true acknowledge_and_proceed Runtime MUST require acknowledgment before allowing the current execution to continue.
active No false or true acknowledge_and_retry Runtime MUST require acknowledgment and caller resubmission. The current execution MUST NOT continue unchanged.
active Yes false acknowledge_and_proceed Runtime MUST fail closed because the current execution cannot continue with unapplied modifications and caller resubmission is not authorized by this behavior.
active Yes true acknowledge_and_proceed Runtime MAY apply the Steward-provided modifications locally if safe and deterministic, then MUST require acknowledgment before continuing. If safe local application is not possible, the runtime MUST fail closed.
active Yes false acknowledge_and_retry Runtime MUST require acknowledgment and caller resubmission with the modifications. The current execution MUST NOT continue unchanged.
active Yes true acknowledge_and_retry Runtime MAY apply the Steward-provided modifications locally if safe and deterministic, then MUST require acknowledgment before continuing. If local application is not performed safely, the runtime MUST require caller resubmission and MUST NOT continue the current execution unchanged.

3.6 Intervention Execution Mode [NORMATIVE]

intervention_execution.mode is synchronized control-plane state carried by SESSION_INIT and optionally updated by BUNDLE_UPDATE.

  1. If intervention_execution is absent, the default is passive.
  2. Execution mode changes execution semantics only. Tripwires, CTQ, thresholds, flags, trust debt, and posture-floor logic remain unchanged.
  3. In active mode, a terminal local decision derived from a valid signed evaluation bundle has the same execution-authoritative force as a Steward-issued final intervention for allowing, denying, suspending, or terminating execution.
  4. In active mode, fallback behavior used during Steward/session-path unavailability inherits the active execution profile or session state. It is not downgraded to advisory-only behavior.
  5. Active-mode escalation requires durable pending state that survives process restart. If the runtime cannot safely persist that state, it MUST fail closed.
  6. Active to passive transitions MUST be audit-visible and MUST preserve a transition reason.
  7. Any protocol or capability surface that advertises execution support MUST use the canonical enumerated field intervention_execution_modes with allowed values drawn from passive and active.

For v1.0 conformance, the removed levels taxonomy (Minimal/Standard/Complete) is superseded by profile-based conformance and MUST NOT be used in certification claims.

4. Three-Layer Architecture [NORMATIVE]

ACGP operates through three integrated layers that connect static risk assessment to dynamic runtime control.

┌─────────────────────────────────────────────────────────────┐
│  Layer 1: ASSESSMENT (Static/Periodic)                      │
│                                                             │
│  ARS Assessment → Governance Tier Assignment                │
│  (Before deployment / when capabilities change)             │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  Layer 2: CONFIGURATION                                     │
│                                                             │
│  Reflection Blueprints + Source Catalog                     │
│  → Policy Engine Configuration                              │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  Layer 3: RUNTIME EVALUATION (Continuous)                   │
│                                                             │
│  Agent Action → Cognitive Trace → CTQ Evaluation            │
│  → Intervention Decision → Audit Log                        │
└─────────────────────────────────────────────────────────────┘

4.1 Layer 1: ARS Assessment [NORMATIVE]

Purpose: Determine agent's inherent risk level.

The Agent Risk Score (ARS) is a composite metric quantifying risk across three dimensions, each scored 0–5:

Dimension What It Measures 0 (Minimal) 5 (Maximum)
Autonomy Independence of decision-making Fully manual Unrestricted execution
Adaptability Ability to learn and modify behavior Static/fixed Self-modifying
Continuity Duration and persistence of operation Ephemeral Indefinite/evolutionary

ARS Calculation: ARS = Autonomy + Adaptability + Continuity (range 0–15)

The ARS result is the deployment-time baseline assignment mechanism. After deployment, the Steward MAY maintain a stricter effective Governance Tier or stricter runtime handling when trust debt, repeated interventions, or operational signals justify tighter governance. v1.0 alpha does not standardize runtime relaxation below the ARS-derived baseline.

ARS to Governance Tier Mapping:

ARS Governance Tier Risk Level Required Controls
0–2 GT-0 Minimal Basic logging, rate limits
3–4 GT-1 Low Standard policy rules, human override
5–7 GT-2 Medium Warnings, spend caps, approval for sensitive scopes
8–10 GT-3 High Approval gates, step-through, immutable audit
11–13 GT-4 Very High Crypto signing, isolation, multi-agent RBAC
14–15 GT-5 Critical Dual control, kill-switch, pre-commit review

When to assess [NORMATIVE]:

  • Before initial deployment (REQUIRED)
  • When agent capabilities change (REQUIRED)
  • When trust debt triggers Governance Tier review or queued ARS reassessment (REQUIRED)
  • Periodic re-assessment (RECOMMENDED: quarterly)

4.2 Layer 2: Configuration [NORMATIVE]

Purpose: Define governance policies.

  • Reflection Blueprints: YAML/JSON files defining quality metrics, thresholds, and rules (→ ACGP-3)
  • Clarity Baseline: Mandatory minimum governance policy, always active
  • Source Catalog: Authoritative data sources for knowledge grounding (→ Source Catalog extension)

4.3 Layer 3: Runtime Evaluation [NORMATIVE]

Purpose: Continuously monitor and govern agent behavior.

Standard runtime evaluation follows the ordering defined in ACGP-3 §10. This section is an orientation summary only.

This section is a summary only. The authoritative normative definition is in ACGP-3 §10.

4.4 Quick Reference: Key Numbers

Concept Range Meaning
ARS 0–15 Agent risk level (higher = more risk)
Governance Tier 0–5 Default enforcement strictness (higher = stricter)
CTQ Score 0–1 Quality score (higher = better)
Risk Score 0–1 Inverse of CTQ (higher = worse)

4.5 Decision Thresholds by Governance Tier [NORMATIVE]

Default Governance Tier threshold mapping is defined in ACGP-3. This document summarizes profile behavior only and does not redefine threshold ownership.

This section is a summary only. The authoritative normative definition is in ACGP-3 §7.

See ACGP-4 for the tripwire-only halt invariant.

5. Core Runtime Flow [NORMATIVE]

Standard runtime evaluation follows the ordering defined in ACGP-3 §10. This section is an orientation summary only.

This section is a summary only. The authoritative normative definition is in ACGP-3 §10.

ACGP-4 owns tripwire precedence and fail-closed behavior. ACGP-5 owns audit durability and privacy controls. ACGP-6 owns claim semantics.

5.1 Minimal Trace Lineage Rule [NORMATIVE]

When an implementation emits a Cognitive Trace or TRACE payload derived from a prior governed trace or delegated action chain, it MUST preserve the immediate parent trace lineage when known.

The canonical field for this linkage is parent_trace_id.

Full cross-system delegation, propagation, and adapter semantics remain extension-defined behavior.

For normative runtime details, use the owner specs directly:

  1. ACGP-4 for tripwire precedence and runtime failure semantics
  2. ACGP-3 for deterministic checks, CTQ computation, threshold mapping, orthogonal flagging, trust-policy state changes, and Governance Tier review triggers
  3. ACGP-5 for audit artifact requirements
  4. ACGP-6 for claim obligations and profile language

5.2 Open vs. Proprietary Components

Open (protocol-standardized): Message formats, ARS/Governance Tier/CTQ framework structure, decision threshold tables, tripwire categories, state transition rules, weighted average formula, metric names and weight ranges, trust debt observable semantics and guardrails, extension identifiers and negotiation rules, API specifications.

Proprietary (implementation freedom): Individual metric scoring algorithms, anomaly detection models, threshold auto-tuning, feature extraction, model architectures, training data, advanced pattern recognition, specialized tripwire detectors, private source catalogs, private extension payload semantics, trust debt provider internals.

6. Profile Model and Runtime Topologies [NORMATIVE]

For v1.0.0-alpha.2, ACGP exposes one active claimable profile (Standard) and one non-conformant runtime mode (Dev Mode). ACGP-6 is the single authoritative source for claim obligations and badge semantics.

Alpha.2 scope note: The following Safety-Critical material is retained for architectural continuity and future-track planning. It is not part of the active external claim surface for v1.0.0-alpha.2.

6.1 Profile Overview

Profile Meaning Runtime Topology
Standard Default profile for v1.0 alpha claims. Single steward. Five primary intervention levels plus orthogonal flag. Full CTQ evaluation. Strict tripwire validation. Single steward on hot path
Safety-Critical Additional high-assurance control material that may appear for model completeness, but is not part of the claimable alpha conformance surface. Consensus-based governance with fail-safe semantics. Multi-steward quorum. Any HALT is HALT. HSM required. Mutual TLS. Distributed steward quorum
Dev Mode Non-conformant local mode (dev_mode: true). Observe-only or allow-and-log. No conformance claim permitted. No enforcement

6.2 Profile Conformance Claims

  • Standard Conformant: active alpha claim surface; passes Standard suite (100% required)
  • Safety-Critical Conformant: not available for v1.0.0-alpha.2 publication claims
  • Badge suites are additive (e.g., Standard Conformant + Regulated Controls Badge)
  • Partial suite pass rates are not conformant

6.3 Deployment Topologies

Single Agent Governance (Simple)

  • 1 Operating Agent + 1 Governance Steward (sidecar)
  • Embedded Policy Engine, local Governance Store (SQLite)
  • Use case: Development, Governance Tier GT-0 / GT-1 deployments, edge deployments

Multi-Agent with Shared Governance (Standard)

  • N Operating Agents + N Stewards (1:1), shared Policy Engine service
  • Distributed Governance Store (shipped reference path: PostgreSQL), git-backed Blueprint Store
  • Use case: Enterprise deployments, Governance Tier GT-2 / GT-3 agents

The shipped v1.0.0-alpha.2 reference deployment uses PostgreSQL-compatible runtime state for shared and production-oriented deployments. Other backends are implementation-defined and are not implied by this topology summary unless they are separately documented with code, tests, and deployment guidance.

Distributed Steward Network (Safety-Critical)

  • N Operating Agents, M pooled Stewards with regional Policy Engines
  • Distributed Governance Store, replicated Blueprint Stores, cross-region coordination
  • Use case: Global deployments, Governance Tier GT-4 / GT-5 environments, regulatory compliance

6.4 Safety-Critical Consensus

Safety-critical actions require multiple steward agreement:

  • Minimum 3 stewards, quorum of ⅔
  • Any halt from any steward → final decision is halt
  • No consensus within timeout → fail-safe halt
  • Implementations SHOULD provide Byzantine fault tolerance. Safety-Critical conformance requires that the consensus mechanism documents its fault model, including: the maximum number of faulty stewards tolerated (e.g., f < n/3), the assumed network model (synchronous, partially synchronous, or asynchronous), and the safety/liveness guarantees provided. The specific BFT algorithm is implementation-defined.

7. Resilience, Profile Failure Fallback, and Timeout Policy [NORMATIVE]

Profile-failure fallback applies when the Steward or session path is unavailable. Runtime Governance Contracts timeout behavior applies only when the Steward/session path remains available but an evaluation exceeds its negotiated budget. These mechanisms are distinct and MUST NOT be conflated.

7.1 Fallback Ownership Matrix [NORMATIVE]

Scenario Owning Spec Trigger Allowed Outcomes Default Rule
Steward / session-path unavailable ACGP-1 core fallback Steward unreachable, session unavailable, disconnect before decision profile-defined fallback Standard default block; stricter local policy MAY apply
Evaluation exceeds negotiated latency budget while session remains available Runtime Governance Contracts preview Per-evaluation timeout deny, allow_and_log, cached_decision, escalate Preview-only; no effect if extension unsupported
Required extension unsupported / unavailable ACGP-1 + relevant extension required capability missing fail activation or fail evaluation per extension rules MUST fail as defined by extension metadata
Optional extension unsupported / unavailable ACGP-1 + relevant extension optional capability missing continue without extension behavior MUST NOT silently claim extension semantics

7.2 Profile Failure Fallback Defaults

Profile Default Fallback Override Rule
Standard block MAY tighten to halt or relax to escalate only when explicitly policy-declared and audit logged
Safety-Critical halt MUST NOT be relaxed
Dev Mode allow_and_log or observe_only Non-conformant mode

7.3 Directional Override Rules

  1. Safety-Critical defaults are non-relaxable.
  2. Standard overrides MUST be explicit, versioned, and audit logged.
  3. Degraded-mode fallback decisions MUST be replayed to the Governance Store when connectivity returns.
  4. Per-evaluation timeout handling MUST use the negotiated timeout policy when one exists; profile failure fallback remains the rule for Steward/session-path failure.

7.4 Graceful Degradation Levels [INFORMATIVE]

These levels are implementation guidance for operational posture and do not independently define new wire-visible protocol outcomes.

Level Condition Behavior
Normal All systems operational Full evaluation
Degraded Non-critical failure Increased cache usage, relaxed consistency, async interventions
Essential Multiple failures Only critical interventions, batch processing, cached policies
Emergency Critical failures Block all high-risk, force human review, read-only mode
Shutdown Safety threshold exceeded System halted, manual restart required

7.5 Failure Recovery

Component Failure Mode Recovery Strategy
Governance Steward Process crash Auto-restart, session failover, failover to backup
Policy Engine Unavailable Cached policies, default thresholds
Governance Store Write failure Write-ahead log (WAL), local buffer (max 1000 events), retry queue
Blueprint Store Unavailable Local blueprint cache, no policy updates
Trusted Monitor Timeout Async processing, skip anomaly check

7.6 Multi-Party Authorization for Governance Changes [NORMATIVE]

Policy-weakening deltas requiring MPA:

  1. Threshold relaxation > 0.02
  2. Tripwire removal or relaxation
  3. Retention shortening
  4. Profile downgrade (Safety-Critical → Standard)
  5. Resume from halt for GT-⅘
Profile Governance Tier Requirement Timelock
Standard GT-0 to GT-2 SHOULD 2-of-3; MAY single-operator with audit Implementation-defined
Standard GT-3 to GT-5 MUST 2-of-3 ≥ 1 hour
Safety-Critical All Governance Tier values MUST 3-of-5 ≥ 24 hours

All MPA actions MUST produce audit records containing: requesting and approving identities, before/after values, and timestamps.

8. Two-Stage Local/Remote Evaluation [NORMATIVE]

Deterministic/stateless checks MUST run locally in the SDK before remote evaluation.

8.0 Canonical Two-Stage Sequence

sequenceDiagram
  participant PA as Operating Agent
  participant SDK as SDK / Agent Wrapper
  participant GS as Governance Steward
  participant Store as Governance Store

  Note over PA,GS: Session Bootstrap
  SDK->>GS: VERSION_NEGOTIATION
  GS-->>SDK: VERSION_SELECTED
  GS->>SDK: SESSION_INIT (local evaluation bundle)

  PA->>SDK: Execute Action
  SDK->>SDK: Generate Cognitive Trace
  SDK->>SDK: Stage 1 local evaluation

  alt Local BLOCK/HALT
    SDK->>PA: INTERVENTION (Block/Halt)
    SDK-->>GS: Async audit
    GS->>Store: Log event
  else Local OK + Tier-0 only
    SDK->>PA: INTERVENTION (OK)
    SDK-->>GS: Async audit
    GS->>Store: Log event
  else Inconclusive
    SDK->>GS: TRACE + local_eval_results
    GS->>GS: Stage 2 remote evaluation
    GS->>SDK: INTERVENTION
    SDK->>PA: Enforce intervention
    GS->>Store: Log TRACE + EVAL + INTERVENTION
  end

8.1 Stage 1 (Local Tier-0)

SDK executes, in order:

  1. Tier-0 tripwires (deterministic, in-memory, <100ms)
  2. Rule-based scorers
  3. Pattern-match scorers
  4. Local threshold comparison

Latency budgets in ACGP (per-tripwire, per-tier, and per-profile p95 ceilings) apply to governance evaluation time only, measured from receipt of the Cognitive Trace by the evaluation engine to emission of the intervention decision. Network round-trip time between Operating Agent and Governance Steward is excluded from these budgets.

Per-evaluation timeout policy is distinct from profile failure fallback. Exceeding a negotiated latency budget does not, by itself, redefine Steward-unavailable behavior.

Implementations SHOULD measure and report end-to-end governance latency (including network) separately from evaluation latency. For distributed topologies, implementations SHOULD document expected network latency contributions.

If active execution mode is in force and the local signed bundle yields a terminal decision (ok, block, halt, or escalate), the SDK MAY enforce that execution outcome immediately without waiting for contradictory remote treatment. Passive mode does not grant that authority.

8.2 Stage 2 (Remote Tier 1+)

If Stage 1 is not conclusive and remote scorers exist, SDK submits trace for Steward evaluation including:

  • Tier-1 tripwires (may use local state/cache)
  • Source-match/LLM/hybrid scorers
  • Authoritative trust debt updates
  • Governance Store logging

8.3 Local Evaluation Bundle and Sync

Steward provides a local evaluation bundle at session start and on updates. Bundle contains:

Field Description
Tier-0 tripwires Compiled conditions, severities, fail actions
Rule-based scorer configs Rule IDs, modes
Pattern-match scorer configs Patterns, aggregation modes
Threshold mappings ok/nudge/escalate/block boundaries
Governance Tier overrides Tier-specific adjustments keyed by serialized GT-* values
Fallback behavior Profile failure fallback default
Blueprint version hash SHA-256 hash for staleness detection

Sync lifecycle:

  • Session bootstrap via SESSION_INIT message
  • Runtime updates via BUNDLE_UPDATE message
  • Staleness detection via version hash comparison
  • Disconnect mode: SDK uses cached bundle + profile failure fallback defaults, buffers decisions, replays on reconnect, and preserves the currently active intervention execution mode for fallback enforcement semantics

8.4 Tier-0 Fast Path

If a blueprint uses only Tier-0 checks, SDK MAY evaluate end-to-end locally and send audit data asynchronously for durability and reconciliation.

8.5 Session Lifecycle

stateDiagram-v2
  [*] --> Negotiating
  Negotiating --> Active: VERSION_SELECTED
  Active --> Bundled: SESSION_INIT loaded
  Bundled --> Bundled: BUNDLE_UPDATE applied
  Bundled --> Disconnected: Steward unavailable
  Disconnected --> Bundled: Reconnect + replay buffered decisions
  Bundled --> [*]: Session end

8.6 Disconnect and Profile Failure Fallback

sequenceDiagram
  participant PA as Operating Agent
  participant SDK as SDK / Agent Wrapper
  participant GS as Governance Steward (Down)

  PA->>SDK: Execute Action
  SDK->>SDK: Stage 1 local evaluation
  SDK->>GS: TRACE (if remote required)
  GS--xSDK: Unreachable / session path unavailable

  alt Safety-Critical
    SDK->>PA: INTERVENTION (Halt/Block fail-closed)
  else Standard + profile failure fallback deny
    SDK->>PA: INTERVENTION (Block)
  else Standard + profile failure fallback allow_and_log
    SDK->>PA: INTERVENTION (OK + heavy logging)
  else Standard + profile failure fallback cached_decision
    SDK->>SDK: Evaluate cached policy
    SDK->>PA: Cached decision or Block on miss
  end

  SDK->>SDK: Buffer decision
  Note over SDK,GS: On reconnect: replay buffered decisions to Steward

9. Extension Hooks (v1.0 Core Reserved)

v1.0 core defines non-breaking extension hooks for future capabilities:

Hook Extension Description
Registry hook Source Catalog SourceCatalog interface for source catalog lookups
Contracts hook Runtime Governance Contracts Reserved governance_contract message field for per-action risk/latency contracts
Interoperability hook Interoperability Adapters Cognitive Trace interchange basis for cross-protocol governance
Trust debt hook Advanced Trust Debt TrustDebtProvider interface for advanced decay, recovery, and compounding

9.1 Extension Visibility Classes [NORMATIVE]

ACGP defines three extension visibility classes:

Visibility Meaning Publicly Standardized Portable On Wire
public Fully documented extension with public payload semantics Yes Yes
private Publicly negotiable capability whose internal payload semantics remain deployment-defined Descriptor only Yes
local Deployment-local extension not intended for cross-implementation interoperability No No, except opaque local metadata

The protocol standardizes extension identifiers, version negotiation, visibility semantics, attestation shape, and required/optional handling. The protocol does not standardize private source contents, document locators, source lineage, proprietary formulas, or private evaluator logic.

9.2 Required and Optional Extensions [NORMATIVE]

Portable artifacts MAY declare extension requirements through extensions.required[] and extensions.optional[] metadata.

  • required means the sender expects the extension to be enforced for correct activation or evaluation semantics.
  • optional means unsupported runtimes MAY preserve the descriptor and continue without applying extension semantics.

The consolidated local / remote / both truth table is defined in ACGP-3 §2.2.1 and applies across negotiation, activation, and runtime enforcement.

local extensions MUST NOT be listed as a portable interoperability requirement unless wrapped by a public or private capability descriptor that defines the cross-party contract.

9.3 Failure Semantics [NORMATIVE]

Each required extension descriptor MUST declare a fail behavior:

  • reject_activation: blueprint or bundle activation MUST fail before use.
  • deny: evaluation MUST fail closed when the required extension cannot be enforced at decision time.
  • ignore: permitted only for unsupported optional extensions.

Implementations MUST NOT silently ignore unsupported required extensions, including required private extensions. The earlier v1.0 blanket "safe ignore" rule applies only to unsupported optional extensions.

9.4 Attestation Boundary [NORMATIVE]

Private extensions MAY expose opaque attestation metadata such as digests, issuer identifiers, policy pack identifiers, or opaque handles. Public artifacts MUST NOT be required to disclose private payload structure, source document identifiers, clause locators, derivation provenance, or proprietary formulas in order to negotiate or conform.

10. Conformance Requirements

A conformant ACGP-1 implementation MUST:

  1. Use qualified tier namespace conventions in all APIs and message fields
  2. Implement ARS assessment with three dimensions and standard Governance Tier mapping (serialized as GT-0 through GT-5)
  3. Support five primary intervention levels with orthogonal flag semantics
  4. Implement the canonical evaluation sequence (tripwires -> deterministic checks -> CTQ -> thresholds -> flag -> trust debt -> governance-tier review -> audit)
  5. Apply profile failure fallback defaults under Steward/session-path failure conditions and keep per-evaluation timeout handling separate
  6. Support two-stage local/remote evaluation with SESSION_INIT and BUNDLE_UPDATE sync lifecycle
  7. Preserve and enforce extension descriptors with required/optional, visibility, fail-mode, and authoritative-enforcer semantics
  8. Safely ignore unsupported optional extension data, preserve unsupported required remote descriptors for remote authoritative enforcement, and fail closed when a required local or both authoritative enforcer is unavailable

Normative References

  • RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
  • RFC 3339 — Date and Time on the Internet: Timestamps
  • RFC 8785 — JSON Canonicalization Scheme (JCS)
  • ACGP-1 — Core Concepts & Terminology, v1.0, 2026
  • ACGP-2 — Messages & Wire Protocol, v1.0, 2026
  • ACGP-3 — Blueprints, Traces & Evaluation, v1.0, 2026
  • ACGP-4 — Tripwires & Safety Semantics, v1.0, 2026
  • ACGP-5 — Audit & Privacy Controls, v1.0, 2026
  • ACGP-6 — Conformance, v1.0, 2026