---
title: Stage 2
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---

← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Social Protocol]]  → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Lisp Machine]]

# Stage 2: Verification Subsystem

*Summary: A verified gate evaluates every action against formal policy.
Capability-based authorization. "Root" as an attack target no longer exists.*

## What is added

- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2-verified]] gate functions that evaluate every proposed action
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Capability-based authorization]]: every action requires a token, not an identity
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate]] checks every action — from user, agent, or external message — against:
  - Is the action authorized by policy?
  - Does the capability grant this operation?
  - Does the action violate any system invariant?
- Decision procedure formalized in ACL2, machine-checked
- Gate runs as a decision layer on the conventional host (Stage 0 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]])
- **Provenance store becomes operational infrastructure:** a structured data extension of the Knowledge subsystem storing empirical parameters, validity envelopes, and benchmark results with full provenance chains
- **Validity envelope predicates as gate vectors:** the gate checks not only security policy but also scientific validity — is this model valid in this context? Are the parameters within their validated range? Does the input fall within the model's training distribution?

## What is eliminated

- **Unauthorized actions** — even a fully compromised endpoint cannot perform an
  action the gate blocks. The gate is the final arbiter, not the OS or client.
- **Privilege escalation** — no amount of subversion below the gate can grant
  capabilities the policy doesn't allow. The gate checks capability tokens,
  not caller identity.
- **"Root" as a meaningful attack target** — there is no root in Passepartout. There
  are capabilities, and capabilities are checked.

## What does this cost?

- **Verification latency** — every action is checked against policy. Complex
  policies add delay
- **Policy formalization burden** — everything must be written explicitly. Gaps
  block legitimate actions (false positives) or allow undesirable ones (false
  negatives). There is no [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Common Sense]] fallback — the policy cannot rely on
  unformalized human intuition. Everything must be written down
- **Capability management complexity** — distributing, revoking, auditing
  capabilities is itself security-critical. A leaked capability is
  indistinguishable from an authorized action
- **Policy drift** — as the system evolves, the policy must evolve with it.
  Out-of-date policy blocks new legitimate uses
- **Proof maintenance** — the gate's decision procedure is verified, but the
  policy is not. Each policy change needs new proof
- **The gate runs on untrusted hardware** — if the OS or hardware is
  compromised, the gate's guarantees are meaningless. The attacker can skip
  the gate or modify its output. Full gate guarantees arrive at Stage 3

## What does this enable?

The system can now say "no" to unauthorized actions even when the endpoint is
fully compromised. Security is no longer dependent on client integrity. This is
the first layer where deductive guarantees enter the picture — but they are
contingent on Stage 3's trust substrate.

## When is this viable?

Today as a software layer on conventional hardware, but with limited guarantees
(the gate itself can be compromised by the host OS). Full power arrives at
Stage 3 when the gate runs on the verified Lisp machine.

## In practice

The gate is the final arbiter, not the OS or the client. But it runs on a
machine it doesn't trust. Users must weigh the benefit (unauthorized actions
blocked) against the operational cost (everything must be explicitly authorized
in policy). For high-stakes environments, the trade-off is worth it. For casual
use, the friction may lead users to bypass the gate.

*Full gate guarantees arrive when Passepartout runs on its own Lisp machine
(Stage 3). Before that, it's a correctness proof running on an untrusted substrate.*

### Symbolic Reasoner — CL-Native Higher-Order Logic Engine

The gate needs to evaluate not just *security policy* but *epistemic
validity*: is this action consistent with what the system knows about the
world? The provenance store (Stage 1) provides quality-scored assertions,
but there is no engine to **reason over them** — to combine assertions,
prove entailments, detect contradictions, or generate causal explanations.

**A CL-native symbolic reasoner** fills this gap. It operates over the
symbolic index of the Knowledge subsystem (predicates, relations,
constraints extracted from Org prose) and returns (entailed | contradicted
| undetermined) for any query.

### Architecture

| Layer | What it does | Implementation |
|-------|-------------|----------------|
| Assertion store | Quality-scored formal claims from Stage 1's truth layer | Provenance store hash table (Stage 2) |
| Constraint solver | SAT/SMT-style search over bounded problem spaces | Screamer (CL, existing) |
| Deduction engine | Forward/backward chaining over first-order subset of assertions | CL-native, starts as Screamer extension |
| Higher-order layer | Nested modalities — belief, intention, causation, temporal |
> Screamer cannot express these natively | CL macros + custom proof search |
| Gate interface | (action, context) → (permit \| deny \| needs-evidence) | ACL2 FFI across the Lisp boundary |

### Why not Lean directly

Lean 4 is C++ at its core — a separate trust domain that breaks the single
address space. The reasoner must be CL-native for the Stage 3 Lisp machine
model. Lean is the *reference* design: its tactics, elaboration, and type
theory inspire the CL implementation, but the engine itself is written in
Common Lisp and lives in the same memory graph as the evaluator and gate.

### Development path across stages

The reasoner is *born at Stage 1* and *hardens through Stage 2*:

| Stage | Reasoner state | How it gets there |
|-------|---------------|-------------------|
| 1 | CL prototype (Screamer-based, first-order) | Shared via social protocol's Reasoner Code Exchange. Users test against local symbolic indices, share patches |
| 1 | Higher-order extensions sketched | CL macros for modal logic, causal chains — tested on small assertion sets |
| 2 | Reasoner feeds gate decisions | Gate delegates knowledge-dependent checks: "is this action valid given what we know?" Works on quality-scored assertions from Stage 1's truth layer |
| 3 | Reasoner absorbed into address space | Same memory graph as evaluator, gate, LLM. No FFI, no IPC |
| 4 | Reasoner enters self-improvement loop | In-process LLM reads reasoner code, proposes improvements, gate checks policy |

### Cost

- **Screamer-level reasoning:** O(n) over the relevant subtree — the same
  sparse tree retrieval the Knowledge subsystem already uses. A 4K-assertion
  context resolves in milliseconds
- **Higher-order deduction:** O(exp) in the general case. Scoped by the
  LLM narrowing the reasoning window first — the user never waits for a
  global proof
- **Proof quality vs speed:** The reasoner can return (entailed with
  confidence 0.83) rather than a binary yes/no. The gate chooses the
  threshold per domain

### What this enables

The gate graduates from checking *who* is authorized to checking *what is
true*. A policy can say "deny actions based on false premises" — and the
detects which premises are false. This is the connection
between security verification and knowledge verification that the original
Cyc architecture required but could not enforce.

## ACL2 Integration Approaches

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.

## Risk Comparison: Stage 1 vs Stage 2

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

← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Social Protocol]]  → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Lisp Machine]]

:PROPERTIES:
:CREATED:  [2026-05-24 Sun]
:WEIGHT:  14
:ID:       4a1f23b0-abc3-4def-9876-543210abcdef
:END:
