Short definitional cards for the first-class concepts. Each card answers in one page: what is this concept, what's it composed of, what operates on it, what surfaces touch it, where to read more.
This is the central understanding layer — the source of truth for what a concept means.
╔═══════════════════════════════════════════════════════════════════════╗
║ ┌──────┐ own ┌──────────┐ contain ┌────────┐ ║
║ │TEAMS ├──────▶ PROJECTS ├─────────▶ AGENTS │ ║
║ └──────┘ └─────┬────┘ └────┬───┘ ║
║ Roles gate every │ defaults flow │ inherits Policy from ║
║ action. │ down (cascade) │ org → project → agent ║
║ ┌──────────────────────────────────┐ ║
║ │ authored by Operators (Teams) │ ║
║ │ • Pipeline steps (hot path) │ ║
║ │ • Sandbox config (static) │ ║
║ └──────┬─────────────────┬─────────┘ ║
║ POLICY ENGINE POLICY COMPILER ║
║ (runs every call) (produces signed ║
╚══════════════════════════════════════════│════════════════════════════╝
│ signed sync push to host
┌──────────────────────────┐
└────────┬─────────────────┘
┌────────────────────────────────┐
│ SANDBOX (host machine) │
│ ┌─────────────────────────┐ │
│ │ AGENT (running code) │ │
│ │ has many SESSIONS │ │
│ │ over its lifetime │ │
│ │ loop_guard, drift │ │
│ │ ─ emits AUDIT events │ │
│ └────────────┬────────────┘ │
└───────────────┼────────────────┘
┌────────────────────────────────┐
│ Hash-chained, Ed25519 signed │
│ Verifiable offline (JWKS) │
└────────────────────────────────┘
Read top-to-bottom: Teams own Projects. Projects contain Agents. Operators (members of Teams) author Policy at the appropriate cascade level. Policy has two dimensions and three engines act on it. The Policy compiler produces a signed Compiled Policy per Sandbox. Providers translate it to per-target configs. The Sandbox runs the Agent. Each Session emits hash-chained audit events into the Audit log.
Grouped by where they sit in the picture:
Card One-liner Organisation The root tenant. Owns Teams, billing, SSO, default Policy floor Team The people primitive — SSO-backed; gates every action by role Project Logical grouping of Agents; has its own Policy floor
Card One-liner Agent The running code (Claude Code, LangChain, custom Python). Distinct from Sandbox.
Card One-liner Policy What the operator authors. Two dimensions (pipeline + sandbox config), sub-elements — Policy engine Runs pipeline steps on every call. Hot-path arm. — Policy compiler Compiles Policy → signed Compiled Policy. Static-side arm. — Check pack Curated bundle of pipeline steps grouped by function (PII, secrets, …). — Compliance pack Regulation-mapped bundle of check packs (ISO 42001, NIST AI RMF, EU AI Act).
Card One-liner Compiled Policy Policy in deployed state. Signed JSON, one per Sandbox. Policy provider Translator per target — knows one tool's config format LLM provider HTTP client to one LLM API — distinct from Policy provider Runtime A recipe of which Provider per part of one deployment
Card One-liner Sandbox One running Agent on one machine, governed by one Compiled Policy Session One continuous run of an Agent. Unit for loop_guard, drift, audit chains. TapPass Chat First-party governed-chat runtime (LibreChat soft fork). The SMB wedge.
Card One-liner Tool Anything the agent calls — vendor SaaS, internal MCP, custom Python Tool discovery Audit-driven surface for catalogue completeness — review/approve unknown tools Audit log Hash-chained, signed record of every governed event Pipeline findings Per-session view of which checks fired and what they detected Tool footprint Per-session inventory of every tool + MCP call the agent made Metering Tokens / cost / call counts rolled up per session → agent → project → org
Card One-liner MCP server Headless TapPass control via MCP — configure from Claude Code SDK (admin) Programmatic admin client — distinct from runtime SDK Agentic CLI LLM-driven configuration loop — talk to TapPass
Not first-class on the dependency graph above, but referenced enough across strategic docs to deserve their own card. Each is a thin wrapper that makes one structural decision easy to look up.
Card One-liner Ring One of three in-process enforcement positions (harness, kernel, interpreter). Filled by Policy providers . Identity Three principal types (Operator, Host, Agent) with distinct auth, scope, and privilege. Cascade Three-tier Policy merge (org floor → project floor → agent override). Strictest-wins. Sandbox-spec Named template binding a Policy + Runtime; produces Sandboxes. Bootstrap Single-use, 15-min-TTL signed URL the operator hands to the host owner. Sync Unidirectional signed channel: push, pull, reconcile. Delivers Compiled Policy updates. Pipeline The 32-step engine that runs on every governed call. Already shipped. Probe An adversarial test case run by the pre-deployment evaluation harness.
If you're new and reading top-to-bottom:
Organisation — the root tenantTeam — who's in TapPassProject — how Agents are organizedAgent — what's being governedPolicy — and its sub-elements: engine , compiler , check packs , compliance packs Compiled Policy — what travels to the hostPolicy provider — the per-target translator (vs LLM provider which is the API client)Runtime — how Policy providers composeSandbox — where the Agent runsSession — one continuous runTool — what the Agent callsAudit log — what gets recorded
Each card has the same shape: opening blockquote (sharp definition), "At a glance" data-sheet, "What it is, concretely" with worked example, "Related concepts" graph.
