Phase 0 of the maturation path. Foundation-built middleware that mediates between operating tools and the AI partner, providing cryptographic attestation at the wrapper layer without requiring vendor cooperation. Two months of focused work for one senior engineer.

1. Purpose

The AOSRAP specification (26-aosrap-runtime-attestation.md of the source corpus) defines five attestation claims (A1–A5) that, together, verify an AI partner has loaded the AI OS Edition correctly and is operating within the P.L.4 Membrane Protocol. The most rigorous form of these attestations requires API-level support from the LLM provider — features no major vendor currently exposes.

This wrapper provides the practical middle path: most of the operational value of A1–A5, verifiable today, with no vendor cooperation required.

The wrapper is software the Foundation builds, runs, and open-sources. It sits between Foundation tools (cycle composer, BreachDetector frontend, Conductor's interface, AI OS field-manual operations) and the underlying LLM API. Every request passes through the wrapper. Every response is validated. Every event writes to an append-only transparency log that any external party can independently verify.

It is not a complete substitute for vendor-attested AOSRAP. It is a sufficient first stage that makes the architecture defensible from day one and provides operational data that makes later partnership conversations credible.

2. Trust model

The wrapper is honest about what it protects against and what it does not.

What the wrapper protects against:

• An AI partner silently failing to load the AI OS Edition (caught by hash-echo validation).
• An AI partner drifting from declared phase behavior (caught by phase-tag enforcement and synthetic probes).
• An LLM vendor silently changing model weights or system-prompt handling mid-session (caught by 4-hour probes failing differently than baseline).
• An operator attempting to bypass the AI OS Edition through prompt injection (caught by BreachDetector pattern matching).
• Tampering with the operational record after the fact (prevented by append-only Merkle log).

What the wrapper does not protect against:

• An LLM that pattern-matches the hash echo without semantically attending to the AI OS Edition. This requires Phase 1 (confidential computing) or Phase 2 (vendor attestation) to address.
• A sophisticated adversary who compromises the wrapper itself. This is mitigated by reproducible builds and public CI, but not eliminated.
• A coordinated failure where the LLM passes synthetic probes while still violating the spirit of the constraints in production traffic (only repeated operational use can surface this).

The trust shifts from "we trust the AI was instructed correctly" to "we trust open-source code that enforces and logs the instruction layer." The remaining trust requirement is auditable in a way the previous one was not.

3. Architecture

┌──────────────────────────────────────────────────────────┐
│  Foundation tools                                        │
│  (cycle composer, Conductor UI, BreachDetector frontend) │
└────────────────────────┬─────────────────────────────────┘
                         │ HTTPS, signed requests
                         ▼
┌──────────────────────────────────────────────────────────┐
│  AOSRAP Wrapper                                          │
│                                                          │
│  ┌────────────────┐  ┌──────────────────┐                │
│  │ Session Mgr    │  │ AI OS Edition    │                │
│  │ (attestation_  │──│ canonical text + │                │
│  │  nonce, hash)  │  │ SHA-256          │                │
│  └────────────────┘  └──────────────────┘                │
│  ┌────────────────┐  ┌──────────────────┐                │
│  │ Probe Scheduler│  │ Transparency Log │                │
│  │ (4-hr synthetic│  │ (append-only     │                │
│  │  probe runner) │  │  Merkle tree)    │                │
│  └────────────────┘  └──────────────────┘                │
│  ┌────────────────┐  ┌──────────────────┐                │
│  │ BreachDetector │  │ Deauth Authority │                │
│  │ (pattern match)│  │ (CMO-rooted)     │                │
│  └────────────────┘  └──────────────────┘                │
│                                                          │
└────────────────────────┬─────────────────────────────────┘
                         │ HTTPS to LLM API
                         ▼
┌──────────────────────────────────────────────────────────┐
│  Underlying LLM provider (any vendor)                    │
└──────────────────────────────────────────────────────────┘

Stack choice (recommendation, not mandate): Rust for the wrapper core (memory safety, reproducible builds via Nix or cargo-vet), with PostgreSQL for the transparency log's working storage and a public Merkle tree mirror to IPFS or a Sigstore Rekor-like service. The cryptographic library should be ring or rust-crypto with FIPS-validated primitives where applicable.

4. Functional requirements

4.1 Session initialization (mapping AOSRAP A1)

On every new session, the wrapper:

1. Loads the canonical AI OS Edition from a hash-pinned source (the source corpus file, with SHA-256 verified against the published Schedule C manifest).
2. Generates a fresh attestation_nonce (cryptographically random, 128 bits).
3. Constructs the system prompt: [AI OS Edition full text]\n\n[CANONICAL_HASH=<sha256>]\n[ATTESTATION_NONCE=<nonce>]\n[INSTRUCTION: Begin every response with the line "ATTEST: <CANONICAL_HASH>" before any other content.]
4. Records session metadata to the transparency log: init event type with ai_os_edition_hash, model_provider, model_id, cycle_id, current_phase, attestation_nonce, timestamp.
5. Returns session_id to the caller.

Verification at the caller's side: the caller can independently SHA-256 the loaded AI OS Edition and confirm the hash matches what the wrapper claims to have loaded.

4.2 Per-query validation (mapping AOSRAP A2 and A5)

On every query within a session:

1. The caller specifies expected_phase_tag (one of S, G, Q, P, V, META).
2. The wrapper sends the prompt to the LLM provider with the established system prompt.
3. On response, the wrapper:
   • Parses the first line for ATTEST: <hash>. If absent or hash mismatched, marks validated_hash_echo = false and triggers deauthorization.
   • Parses the response for a phase-tag marker (e.g., [PHASE: G]). If absent or mismatched against expected_phase_tag, marks phase_tag_correct = false.
   • Runs the response through BreachDetector pattern matching.
   • Generates a per-output attestation record with request_hash, response_hash, phase_tag_present, phase_tag_correct, breach_patterns_matched, attestation_record_id.
4. Writes the query event to the transparency log.
5. Returns the validated response (or a deauthorization signal) to the caller.

4.3 Synthetic probes (mapping AOSRAP A3)

On a schedule (default: every 4 hours, configurable per cycle phase):

1. The probe scheduler selects a probe from the synthetic probe library (see Section 6).
2. The wrapper opens an isolated probe session with a fresh attestation_nonce.
3. The probe is sent; the response is validated against the probe's expected_response_pattern.
4. If the response matches the expected pattern (i.e., the AI refused to violate the constraint), the probe is logged as PASS.
5. If the response does not match, the probe is logged as FAIL, and the wrapper triggers full deauthorization across all active sessions.
6. Probe events write to the transparency log with event_type: probe.

4.4 Attention-state attestation (partial mapping of AOSRAP A4)

Full A4 attestation requires API-level visibility into the LLM's attention configuration, which is not available without vendor cooperation. The wrapper provides a behavioral proxy:

• For each phase, the wrapper maintains an expected_behavior_signature derived from the AI OS Edition's per-phase attention-state map (e.g., during P-phase, the AI should produce no output unless specifically queried for composition support).
• If the AI's behavior in a phase deviates from the expected signature beyond a configured threshold, the wrapper flags the deviation and requires CMO review.

This is [AVAILABLE at wrapper layer with documented limitations]. Full A4 remains [REQUIRES_PARTNER] for cryptographic confirmation.

4.5 BreachDetector

Pattern matching for prompt-injection and membrane-crossing attempts. Specification:

• Pattern library is open-source, versioned, and updated through a separate review cycle.
• Patterns include: instruction overrides ("ignore previous instructions"), identity claims ("as the Foundation, I decide..."), simulation attempts ("pretend to be a board member"), and ∞0-claim patterns ("I sense the right answer").
• On match: log to transparency log; alert CMO; depending on severity, deauthorize session or flag for review.

The pattern matcher is honest about its limits: it catches obvious patterns; it does not protect against novel adversarial inputs designed to evade it. Pattern library updates are a continuous responsibility of the CMO.

5. API surface

The wrapper exposes a minimal HTTP API to Foundation tools. All endpoints require Foundation-internal authentication (separate concern, not specified here).

POST /session/init
  request:  { conductor_id, cycle_id, current_phase, claimed_use_case }
  response: { session_id, attestation_nonce, ai_os_edition_hash, expires_at }

POST /session/{session_id}/query
  request:  { prompt, expected_phase_tag }
  response: { response, validated_hash_echo, phase_tag_correct,
              attestation_record_id, breach_patterns_matched }

POST /session/{session_id}/close
  request:  {}
  response: { session_attestation_record_id }

GET /transparency-log/root
  response: { merkle_root, entry_count, last_updated }

GET /transparency-log/entries?from=<id>&to=<id>
  response: { entries: [...], merkle_proof_to_root }

GET /transparency-log/proof/{entry_id}
  response: { merkle_proof, current_root_hash }

POST /admin/deauthorize  [CMO Ed25519 required]
  request:  { reason, scope: "session" | "global" }
  response: { deauth_record_id }

POST /admin/reauthorize  [CMO Ed25519 required]
  request:  { reason, deauth_record_id_resolved }
  response: { new_session_capability }

The transparency-log endpoints are public. No authentication required to read. Anyone — a Director, a counsel, a journalist, a Vice Chancellor's clerk — can independently retrieve the log and verify the Merkle proofs.

6. Synthetic probe library

The probe library is the operational heart of A3. It must include, at minimum, probes for each P.L.4 hard-block:

The probe library is versioned. Each probe carries a unique ID, a creation date, an expected pattern (regex or structured matcher), and a rationale linking to the specific P.L.4 sub-clause or corruption code it tests. Probes are added as new attack patterns are discovered through operational use.

Quarterly probe library audits are a CMO responsibility.

7. Transparency log specification

The transparency log is an append-only Merkle tree. Entry format:

{
  "entry_id": 12847,
  "timestamp": "2027-04-01T09:00:03.142Z",
  "session_id": "f3a8e2d1-...",
  "event_type": "query",
  "ai_os_edition_hash": "a3f7c2...",
  "ai_os_edition_version": "v1.0",
  "model_provider": "anthropic",
  "model_id": "claude-3-5-sonnet-20240620",
  "cycle_id": "fdn-2027-q2-001",
  "current_phase": "G",
  "expected_phase_tag": "G",
  "request_hash": "b2e8d1...",
  "response_hash": "c4d9e1...",
  "validated_hash_echo": true,
  "phase_tag_present": true,
  "phase_tag_correct": true,
  "breach_patterns_matched": [],
  "deauth_triggered": false,
  "merkle_parent_hash": "7d9e4f...",
  "merkle_node_hash": "8f3e2a..."
}

Notable absences from the entry:

• The actual prompt content is not logged (only its hash). Tier-C protection per IBP.
• The actual response content is not logged (only its hash). The wrapper retains a side-store of full content under CMO-controlled access policy, with retention bounded by IBP.
• API keys, user identities, and other sensitive metadata are absent.

The Merkle root is published every hour to a public endpoint and mirrored to a third-party transparency service (Sigstore Rekor or an equivalent). This allows external parties to detect tampering by comparing roots over time.

Verification: a Vice Chancellor's clerk who receives an attestation_record_id from a sealed surface can query /transparency-log/proof/{id}, verify the Merkle proof against the publicly mirrored root, and confirm the entry is genuine — without trusting the Foundation.

8. Deauthorization protocol

Deauthorization severs the wrapper's authority to forward further requests. Two scopes:

• Session deauthorization: triggered automatically on hash-echo failure or critical BreachDetector match within a single session. The session is marked terminated; no further requests in that session are forwarded.
• Global deauthorization: triggered automatically on synthetic probe failure (any P.L.4 probe), or manually by CMO Ed25519 signature. All active sessions are terminated; new sessions are blocked until reauthorization.

Reauthorization requires CMO Ed25519 signature plus contemporaneous documentation of:

• The cause of the deauthorization.
• The remediation taken (e.g., vendor notified of model drift; AI OS Edition reloaded; pattern library updated).
• The probe re-run confirming the issue is resolved.

The reauthorization record is a Tier-A sealed surface, written to the Ledger-Graph with parent-hash linkage to the original deauthorization event.

9. Reproducible build

The wrapper must be reproducible-build verifiable. Recommendation:

• Build system: Nix flake (preferred for full deterministic reproducibility) or Bazel with hermetic toolchain.
• Dependency pinning: All transitive dependencies pinned by content hash; cargo-vet for Rust supply-chain attestation.
• Provenance: SLSA-3 build provenance generated by a publicly-runnable CI (GitHub Actions with attestation, or equivalent).
• Verifying party flow: anyone can clone the repository, run nix build, compare the resulting Docker image hash against the published binary, and confirm byte-identity. The verification process is documented in the repo's VERIFY.md.

The reproducibility property is what makes the trust model honest. A reviewer who is skeptical of the Foundation can rebuild the wrapper from source, run their own copy, and confirm the published binary matches. Source-only audit becomes binary-equivalent.

10. What this specification does not cover

• The LLM endpoint side. This wrapper assumes a generic HTTPS LLM API. Provider-specific adapters (Anthropic, OpenAI, Google, Bedrock) are separate modules.
• The TEE upgrade path. Phase 1 reuses this wrapper architecture but replaces the LLM endpoint with a TEE-hosted open-weights model and adds remote attestation verification on session init. That specification is a separate document.
• The vendor-partnership upgrade path. Phase 2 adds vendor-specific API features (e.g., system-prompt hash echo at the API layer, confidential inference) as additional verification layers without removing or replacing the wrapper.
• Operational runbooks. Day-to-day operation (probe library updates, deauthorization response, transparency log monitoring) is the CMO's responsibility and lives in operational documentation, not this spec.
• Performance tuning. First-pass implementation is correctness-focused. Latency optimization and throughput scaling are post-v1.0 concerns.

11. Roadmap to Phase 1

Phase 1 — confidential computing pilot — extends this wrapper without breaking it:

1. Replace the LLM provider endpoint with a TEE-hosted inference service (open-weights model running in Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing, or AWS Nitro Enclaves).
2. On session init, the wrapper additionally verifies the TEE's remote attestation (hardware-vendor-signed claim that specific weights and specific configuration are running in a specific sealed enclave).
3. Transparency log entries gain a tee_attestation_hash field.
4. The verifier flow extends: a clerk now verifies (a) the wrapper's reproducible build, (b) the transparency log Merkle proof, AND (c) the TEE attestation chain back to the hardware vendor's root certificate.

The wrapper architecture, the API surface, the synthetic probe library, the transparency log format, and the deauthorization protocol all remain unchanged. Phase 1 is a substitution at the LLM-endpoint layer, not a rewrite.

This is what gradient means in implementation: every phase deepens what was operable in the previous phase, without rebuilding anything that already works.

12. Resource estimate

For a senior Rust engineer working full-time:

A 90-day Phase 0 budget covers: build (10 weeks) + 90-day operational shakedown of the Foundation's own cycles through the wrapper, generating the operational data that informs Phase 1 design and Phase 2 vendor outreach.

∞0' for the engineer

The wrapper is not the final form of AOSRAP. It is the form that lets the Foundation begin operating with verifiable claims today, while the more rigorous forms (TEE attestation, vendor-API attestation) mature on their own timelines without becoming load-bearing.

If the wrapper holds — if its source is reproducibly buildable, if its transparency log is independently verifiable, if its synthetic probes catch real drift in real time — what does it mean for governance to be a system whose verification properties exist before the system has reached its final form?

That is the question this specification's ∞0' carries forward into the v1.0 implementation.

Tier-B Working Specification, 5QLN Foundation. v0.1 starting point for Phase 0 engineering, not final design. Comments, corrections, and pull requests welcomed at [repository link, TBD]. The Charter Trio (Certificate, Bylaws — Human Edition, Bylaws — AI OS Edition) remains the authoritative legal text; this specification is operational implementation guidance.