Known Limitations — ACGP v1.0 Alpha

The repository now ships two important zero-to-one deployment building blocks for serious alpha use: a minimum enforceable trust/bootstrap profile and a PostgreSQL-backed reference runtime-state path. The remaining limitations are real, but they are now concentrated in advanced federation, external identity, higher-order scale-out, and non-Python local runtime parity.

For the conceptual map of these boundaries, see Protocol Boundaries.

v1.0 Publication Scope Boundaries

Identity & Key Lifecycle

ACGP v1.0 does not define a normative identity provider or key lifecycle management protocol (rotation, revocation, distribution).

  • Impact: Implementations MUST supply their own key management and identity verification mechanisms.
  • Mitigation: Use existing PKI, OIDC, or cloud KMS solutions.

Human-in-the-Loop (HITL) Completion Transport

ACGP v1.0 alpha standardizes HITL completion as a normative HITL_RESULT artifact/result surface linked to the final intervention. Human-review transport, reviewer UI, queueing, and callback mechanics remain deployment-defined.

  • Impact: Deployments can rely on a standard completion artifact consumed by the Steward, but they still need to supply their own human-review workflow transport and UI.
  • Mitigation: Use the shipped HITL_RESULT schema/vector surface for completion semantics and convert the reviewed outcome into the final standard INTERVENTION sent back to the SDK/runtime.

Compression

Compression is negotiated via capabilities but is not required for conformance in v1.0.

  • Impact: Implementations MAY ignore compression capabilities without violating conformance.
  • Mitigation: Use standard HTTP transport defaults and only apply Content-Encoding when both peers explicitly negotiate a common algorithm.

This document catalogs known gaps, deferred features, and areas requiring further work before ACGP reaches stable (v1.0.0) status. Each item is classified by priority.

Operator Checklist

The minimum trust profile is enough when:

  • you operate one steward authority per environment
  • you can distribute pinned trust material before production traffic begins
  • PostgreSQL satisfies your centralized runtime-state and audit requirements
  • local Tier-0 approval can be treated as an optimization and sampled remotely

You need more than the minimum profile when:

  • your deployment spans multiple organizations or external identity domains
  • you need automated federation or delegated trust-root lifecycle orchestration
  • you need multi-region or distributed-SQL operational guarantees beyond the shipped PostgreSQL path
  • you require non-Python local runtime parity instead of a service-bound evaluator path

P1 — Must Address Before Stable

L1: Key Lifecycle Management

Affected specs: ACGP-2 (§4.4, §9.5), ACGP-5 (§8)

No normative key rotation, revocation, distribution, or discovery mechanism is defined. Implementations MUST define their own key management. A future ACGP-KM extension is planned.

Risk: Without standardized key management, interoperability of signed messages across deployments is not guaranteed.

L2: Identity Binding

Affected specs: ACGP-1 (§3), ACGP-2 (§4)

ACGP now defines agent_id as the runtime- or operator-assigned identifier of the governed agent principal, but no normative cryptographic identity-provider, certificate-authority, or attestation integration is specified.

Risk: A deployment that accepts agent_id values without independent transport, signing, or operator/runtime validation can still allow principal impersonation. Deployments MUST implement their own identity verification.

L3: Fast-Path Bypass

Affected specs: ACGP-1 (§8), ACGP-3 (§3)

Tier-0 local-only evaluation runs entirely within the SDK. A compromised or malicious SDK can suppress traces, fabricate scores, or bypass tripwires without server-side detection.

Risk: No server-side verification of local evaluation results. Mitigations (remote spot-checks, trace sampling) are RECOMMENDED but not normative.

L4: ARS Self-Attestation

Affected specs: ACGP-1 (§3.2)

The Agent Risk Score (ARS) is self-reported by agents. No independent verification, attestation, or challenge mechanism is defined.

Risk: Agents can misrepresent their risk score to receive lower governance scrutiny.

L5: Advanced Automated Trust Federation

Affected specs: ACGP-1 (§2, §7.5)

The repository now ships a minimum serious-alpha trust profile with schema-defined trust roots, identity binding rules, and rotation/revocation workflow. Automated trust-root federation, external identity-provider integration, and fully automated lifecycle orchestration remain outside protocol core.

Risk: Cross-organization trust federation still depends on deployment-specific identity and key-management systems.

L6: Recourse Mechanism

Affected specs: ACGP-3 (§5)

The Python reference SDK and reference deployment now implement operator-mediated HITL recourse for steward escalations and product-level operator appeal for blocked or halted outcomes, including auditable completion paths. Affected-party dispute workflows and cross-deployment recourse portability remain out of scope.

Risk: Operator review now exists for escalated, blocked, and halted outcomes in the shipped product path, but recourse remains deployment-specific and is not yet a portable protocol-level mechanism.

L7: Reference SDK Parity

Affected specs: ACGP-6 (§3)

The Python reference SDK remains the canonical runtime. The TypeScript SDK now includes a supported evaluator-service client, but intentionally does not provide local runtime parity for CTQ, tripwires, or trust-debt execution.

Risk: Implementations that require non-Python local runtime parity or exhaustive scenario parity still need custom integration work.

L8: Advanced Batch Exchange Beyond TRACE

Affected specs: ACGP-2 (§6)

ACGP v1.0 alpha now defines ordering, partial failure handling, admission-atomic behavior, retry-safe replay, and audit requirements for TRACE batch submissions. Heterogeneous multi-message-type bundles and richer cross-message batching remain out of scope.

Risk: Implementations needing complex multi-message batching still require deployment-specific agreements.

P2 — Should Address Before Stable

L9: Scorer Model Inference

Affected specs: ACGP-3 (§4)

Tier-2 (cognitive-evaluator) and Tier-3 (hybrid) scorer model inference is implementation-defined. Conformance tests supply deterministic scorer outputs only.

L10: Extension Registry

Affected specs: ACGP-1 (§9)

The extension mechanism is defined but no registry or discovery mechanism exists for published extensions.

L11: Multi-Steward Coordination

Affected specs: ACGP-1 (§7)

Scenarios involving multiple Governance Stewards (federated governance) are not addressed.

P3 — Deferred to Future Versions

  • L12: Real-time streaming protocol binding (WebSocket, SSE)
  • L13: Hardware attestation integration (TPM, SGX)
  • L14: Formal verification of safety properties
  • L15: Internationalization of governance messages and rationale text

Alpha Publication Disclosures (v1.0.0-alpha.2)

L9: Affected-Party Recourse Not Yet Implemented

No normative appeals/dispute mechanism exists for affected parties in this alpha release. The shipped product path covers operator review of steward escalations plus operator appeal for blocked or halted outcomes only.

L10: ARS Verification Not Yet Implemented

Agent Risk Score remains self-attested. The Steward may override upward based on observed behavior, but no independent verification protocol is defined.

L13: Advanced Federation Is Deployment-Defined

The repository now defines and ships a minimum serious-alpha trust profile in docs/develop/guides/bootstrap-trust.md, including machine-readable trust-root artifacts and validation vectors. Full automated federation and external identity-provider orchestration remain advanced deployment responsibilities rather than unresolved bootstrap ambiguity.

L11: Runtime-State Scale-Out Beyond The Shipped PostgreSQL Path

The repository now ships PostgresStateStorage for centralized production runtime state and uses it in the reference deployment. Remaining work is in higher-order scale-out concerns such as multi-region topology, zero-downtime migration patterns, and distributed-SQL operational guidance.

L12: TypeScript SDK Uses A Service-Bound Runtime Path

The TypeScript SDK now provides protocol models plus a supported evaluator-service client. It still does not ship local runtime evaluation for CTQ, tripwires, or trust debt execution.