---
title: Stage 2 Architecture — ACL2 Integration and Risk Profile
type: reference
tags: :passepartout:architecture:gate:acl2:
created: 2026-05-28
---

← Stage 2 — Verification Subsystem

# Stage 2: ACL2 Integration and Risk Profile

## ACL2 is not a CL library

ACL2 is a separate system — a theorem prover and programming language with a Lisp-like syntax, not a Common Lisp library you import. It has its own image, its own evaluator, and its own type system (a subset of CL). There are three integration approaches:

**1. Embed exported compiled code (recommended)**
Write the gate's core decision procedures in ACL2, prove them correct, then compile to CL code that runs natively in the PDS process. ACL2's :program mode and defattach mechanism allow verified functions to be called from unverified CL code. The proof artifact is the source; the runtime is the compiled function.

**2. Subprocess with serialized inputs**
The PDS sends the action + context + policy as JSON to an ACL2 subprocess, which evaluates the decision procedure and returns permit/deny. Simpler to implement but adds latency and a trust boundary between the PDS and the ACL2 process.

**3. Hybrid**
Common path decisions (cached/simple) are compiled CL code from approach 1. Complex or novel decisions are escalated to the subprocess. This is the most practical approach for a Phase Zero gate.

## Stage 2 risk: design uncertainty, not spec complexity

Stage 1's risk is implementing published standards correctly. Stage 2's risk is different: the gate's policy language, capability model, and ACL2 proof architecture are Passepartout inventions.

| Stage | Nature of risk | Failure mode | Mitigation |
|-------|---------------|--------------|------------|
| 1 | Spec complexity — implement DAG, DID, JOSE, Double Ratchet correctly per published standards | Wrong output, test vectors catch it | Sidecar strategy reduces to near-zero for initial release |
| 2 | Design uncertainty — what does the policy language look like? How do capabilities compose? How does ACL2 model the system? | Wrong abstraction, must rewrite | Gate kernel is small (authorize? deny?) — the proof surface is narrow even if the policy surface is large |

## What makes Stage 2 tractable

The gate kernel is tiny: a function that takes (action, context, policy) and returns permit or deny. The policy can grow arbitrarily complex (capability tokens, validity envelopes, compliance rules) but the decision procedure is a simple predicate.

The ACL2 verification covers the kernel — "does this decision follow from the policy?" — not the policy itself. Policy changes don't require reproving the kernel; they require writing new policy rules.

## Constraint on the PDS

The gate runs in the same address space as the PDS (Stage 2 runs on conventional hardware; Stage 3 moves it to the verified Lisp machine). This means:

- The PDS must expose an action interception point that the gate can hook into
- Every action path — user command, LLM proposal, network message, file write — routes through the same decision procedure
- The gate cannot be bypassed; there is no privileged path

→ Stage 3 — Lisp Machine

:PROPERTIES:
:CREATED:  [2026-05-11 Mon]
:ID:       460e06f4-6bfc-4969-89d8-685c0c4434cf
:END: