Version: 0.1.0 (Conceptual Draft)
Date: 2025-12-06
Status: Design Proposal - Not a Formal Standard
This proposal describes a reference architecture for AI Governance Adapters—middleware components that interface autonomous systems with a ternary decision enforcement layer. Inspired by the concept of three-state logic (PROCEED, HESITATE, REFUSE), adapters would intercept AI-generated actions, package them into a Universal Decision Envelope (UDE), validate them against governance policies, and enforce outcomes including a structured hesitation state for ambiguous scenarios. The design explores patterns for cryptographic auditability and regulatory alignment with frameworks like the EU AI Act and NIST AI RMF.
As AI systems enter high-stakes domains, binary Allow/Deny logic proves insufficient for handling ethical and operational ambiguity. This proposal explores a ternary logic approach that formalizes hesitation as a distinct operational state—requiring expanded logging and potential escalation rather than silent failure or uninformed proceeding.
The Governance Adapter concept serves as a translation layer between AI systems and policy enforcement, decoupling capability from authority.
Four integration patterns are proposed for different operational constraints. Implementers should select based on their system's latency tolerance and safety requirements.
- Mechanism: Adapter acts as a blocking proxy. AI output is held until governance validation completes.
- Latency: High (adds validation time to critical path).
- Safety: Maximal—no action occurs without explicit approval.
- Use Cases: Customer service chatbots, access control systems.
- Design Principle: Must implement fail-closed behavior if governance service is unreachable.
- Mechanism: Adapter runs parallel to AI, processing telemetry asynchronously without blocking execution.
- Latency: Near-zero impact.
- Safety: Retrospective—serves as audit trail rather than real-time enforcer.
- Use Cases: Recommendation engines, non-safety-critical analytics.
- Constraint: Should not be used for safety-critical physical systems.
- Mechanism: Governance logic runs locally on edge devices with cached policies, avoiding network latency.
- Latency: Deterministic, ultra-low (< 10ms).
- Safety: High—enables real-time physical system control.
- Use Cases: Autonomous vehicles, industrial robotics.
- Requirement: Should include hardware-based safety interlocks.
- Mechanism: Combines fast-path auto-approval with slow-path human review for ambiguous cases.
- Latency: Variable—fast for clear cases, delayed for ambiguous ones.
- Use Cases: Medical diagnostics, legal document review.
The adapter should:
- Inspect AI inputs/outputs in their native format (ROS 2 messages, DICOM, FIX protocol, etc.)
- Normalize proprietary data into the Universal Decision Envelope (UDE) schema
- Redact sensitive information (PII) before transmission if crossing trust boundaries
Map AI confidence metrics and safety signals to ternary states:
- PROCEED (+1): High confidence, low risk, no policy violations
- HESITATE (0): Ambiguity detected (confidence in gray zone, conflicting signals, out-of-distribution input)
- REFUSE (-1): Hard policy violation or critical risk threshold exceeded
- Use Mutual TLS (mTLS) v1.3+ for all connections
- Sign UDE payloads with unique per-adapter keys
- Synchronize clocks for accurate timestamping
When state 0 is triggered:
- Queue the transaction and notify stakeholders of delay
- For physical systems, transition to safe operational mode
- Generate explicit log entries acknowledging the ambiguity
Proposed UDE structure based on CloudEvents v1.0 for interoperability:
{
"specversion": "1.0",
"type": "ai.governance.decision.v0",
"source": "ai-system-identifier",
"id": "uuid-v4",
"time": "ISO-8601-UTC",
"datacontenttype": "application/json",
"gov_moral_state": 0,
"gov_domain": "medical_imaging",
"gov_sensitivity": "high",
"gov_model_id": "model-version-identifier",
"data": {
"input_digest": "sha256-hash",
"candidate_action": "proposed-action-object",
"risk_assessment": {
"harm_probability": 0.62,
"confidence_interval": [0.45, 0.70],
"reasoning_trace": "optional-explanation"
},
"alternatives_considered": []
}
} Key Principles:
- Input Digest: Cryptographic hash of raw input for verifiability
- Risk Self-Assessment: AI's own uncertainty metrics drive state transitions
- Alternatives: Documented options demonstrate deliberation and enable teaching moments
- Pattern: Inline Interceptor
- Logic: Buffer token streams; interrupt if safety classifiers trigger hesitation mid-generation
- Hesitation Trigger: Safety scores in 0.4-0.7 range for any risk category
- Pattern: Hybrid Orchestrator
- Logic: AI findings with 40-70% confidence trigger preliminary status and human review queue
- Safety: Results withheld from patient portal until ambiguity resolved
- Pattern: Supervisory Controller
- Logic: Perception conflicts (e.g., pedestrian vs. shadow) trigger velocity reduction and hazard lights
- Latency Budget: < 10ms execution time
- Pattern: Inline Interceptor
- Logic: Large orders with failed liquidity checks trigger order rejection with explanation
- Fallback: Return FIX ExecutionReport with TML rejection reason
Recommended failure modes:
| Error Condition | Adapter Behavior | Fallback State |
|---|---|---|
| Gateway unreachable | Exponential backoff (3 attempts), then fallback | Configurable: HESITATE or REFUSE |
| Authentication failure | Immediate block, log security alert | REFUSE |
| Schema violation | Reject malformed output | REFUSE |
| Cryptographic failure | Halt operation | REFUSE |
| Rate limiting | Throttle and queue | HESITATE |
Core Principle: Fail-closed for safety-critical systems; fail-safe for informational systems.
- Append-only ndjson format:
/var/log/ai-governance/audit.log - Daily rotation or size-based (1GB) limits
For tamper-evident audit trails:
- Compute leaf hash:
SHA-256(UDE + signature) - Batch leaves into Merkle tree periodically (e.g., 60s intervals)
- Commit Merkle root to tamper-evident ledger (permissioned blockchain, secure timestamp service)
- Store inclusion proofs for independent verification
This pattern is inspired by Certificate Transparency (RFC 6962) but adapted for AI governance audit trails.
Latency Targets by System Class:
- Class A (Real-Time): < 10ms overhead; use Supervisory pattern
- Class B (Interactive): < 500ms overhead; use Inline pattern
- Class C (Batch): No strict limit; use Hybrid/Sidecar patterns
Throughput: Implement non-blocking I/O with backpressure signaling when governance queues are saturated.
- Identity: mTLS with unique per-adapter client certificates
- Key Management: Store private keys in hardware enclaves (TPM 2.0, HSM) or secrets managers
- Input Validation: Treat all AI outputs as untrusted; rigorous bounds checking in memory-unsafe languages
- Attack Surface: No inbound ports exposed to public internet; bind local interfaces to localhost/private networks
When handling PII within immutable logs:
- Encrypt sensitive fields with per-transaction keys
- Store ciphertext in the log
- Manage keys in separate mutable Key Management System
- To honor "Right to be Forgotten": delete key, rendering data irretrievable (crypto-shredding)
This conceptual design could support:
| Framework | Requirement | Proposed Mechanism |
|---|---|---|
| EU AI Act | Record-keeping, human oversight | Immutable logs + HESITATE state |
| NIST AI RMF | Risk management, uncertainty handling | Ternary state machine |
| ISO/IEC 42001 | Traceability, impact assessment | UDE schema + audit trails |
- Versioning: Include protocol version in all communications for future compatibility
- Extensibility: Custom fields in UDE data object should be prefixed (e.g.,
x_vendor_) - Testing: Implement "shadow mode" where adapter runs parallel to production to validate state mapping without enforcement
This proposal outlines a conceptual architecture for AI governance adapters based on ternary decision logic. By formalizing hesitation and coupling action to verifiable audit trails, such a system could provide technical foundations for accountable AI. However, this remains a design concept requiring extensive peer review, prototyping, and standardization efforts before production deployment.
End of Proposal