# Frequently asked questions — TrustFortress / Cubie Each answer is self-contained. For the evidence behind any claim, see the Grounded Claims Registry at . ## About the product ### What is TrustFortress / Cubie in one sentence? Cubie is a pre-inference admission gate that makes a formally-specified, constant-time *allow / degrade / deny* decision about an AI workload before a GPU cycle or tool call is spent; TrustFortress is the control plane around it (identity, audit, MCP, EU AI Act evidence). ### What problem does it solve? AI fleets waste capacity on work that should never have run — deadlocked GPUs, tool calls that shouldn't fire, requests whose cost exceeds their product. Cubie moves the trust/safety decision *before* the spend instead of after it. On real traces, a single NVLink cascade froze 66.85% of a fleet while the hypervisor saw "healthy"; ~99.5% of Azure-2024 requests produced less output than input. ### How is the decision made — is it a model? No learned model and no floating point. The request's facts (who/what/where/when/why/how) are compiled into a 192-byte geometric object over a 54-cell topology, and the verdict is a deterministic evaluation of it. Denials carry an explainable code (which face failed). ### Is it only for GPUs / NVIDIA? No. It's architecture-neutral: x86-64, aarch64, and RISC-V (no_std bare-metal) targets, plus a Cloudflare Workers (Wasm) edge build. It runs in a laptop-friendly mock mode with no special hardware, and can bind to Intel TDX / PUF / NVLink telemetry when present. ### Can an attacker spoof the gate? The gate can root its decision in hardware evidence when available (Intel TDX attestation, PUF device identity, eFuse, NVLink/PCIe telemetry), so a purely software forgery does not pass a hardware-rooted deployment. Without hardware, it falls back to software trust. ## About the claims (scope-honest) ### Is the TEP "100/100/100 at FAR=0" a real held-out detection result? It is an **in-sample calibration identity**, not a held-out product claim. The CUSUM threshold is set to 1.5× the peak observed on the fault-free baseline, so false alarms are zero *by construction* on that calibration set. FDR is measured in-sample on the Braatz/Rieth d00/d03/d09/d15 data; held-out transfer is **not yet** established. See . ### Do the formal proofs verify the shipping Rust code? Not directly, in general. The Coq/Lean/Verus corpus is a **mixed snapshot** of closed proofs and statement-form stubs, and the specs are checked **standalone** (0 of the Verus specs import the runtime crates). Proof-to-code binding is by CUB-ID cross-reference plus behavioral tests, with a growing set of in-crate `verus!` bindings over real functions. Treat "every predicate proven over the runtime" as overstated. See . ### Where does the 66.85% agentic-waste number come from? Re-measured from committed result JSONs (derived from the public Azure-2024 and Alibaba GPU traces): `full_tp4_blast_radius.capacity_pct = 66.8479`, i.e. 105,226 of 157,411 LLM GPU-intervals had zero SM duty during the event. The ~99.5% output. ### Is TrustFortress "EU AI Act compliant"? The `crates/cubie-eu-*` crates are a compiling **mapping + Annex IV generation scaffold** (per-article evidence structs, an AnnexIvBuilder, a `/api/v1/annex-iv` generator) — not a fully populated conformity pack; some fields are placeholders. Formal conformity for a high-risk system additionally requires a notified-body assessment (Annex VII route). See and the compliance docs. ### Why are only some numbers public / why so cautious? Because we publish claims with their boundaries. The evidence, pinned hashes, and reproduce commands are all public so anyone can check them, and the honest caveats travel with the numbers. See [learnings.md](learnings.md). ## For integrators / coding agents ### How do I connect a coding agent to this? Use the public MCP server: `https://lib.trustfortress.ai/mcp` (JSON-RPC 2.0, no auth, CORS `*`). Tools: `search_library`, `ask_library`, `ai_search`, `list_collections`, `list_claims`, `get_claim`, `read_object`. Client config + raw JSON-RPC examples: [../MCP.md](../MCP.md). ### What public API surface does the library expose? `GET /api/catalog` (D1-backed catalog), `GET /api/list?prefix=`, `GET /api/search?q=`, `GET /api/ai-search?q=` (semantic), `POST /api/ask`, `GET /api/claims`, `GET /objects/`, `GET /api/cubs/meta`, `GET /api/cubs/`, `GET /api/cubs?…`, `GET /browse/`, `GET /architecture`, `GET /claims`, `GET /llms.txt`, `POST /mcp`. ### Does the workload-admin surface run formal proofs or issue an admission certificate? No. It verifies embedded artifact integrity and recorded kernel receipts, recompiles the active signed sticker, and can evaluate seven explicitly supplied hypothetical inputs. Lean, Coq, and Verus do not execute during this read-back. The result is an `ADVISORY_SIMULATION` with no runtime effect, not an admission certificate, release certification, Canary authorization, or Enforce authorization. See [workload-admin-evidence.md](workload-admin-evidence.md). ### How do I verify the current CUB-3211 through CUB-3217 publication? First query `GET /api/cubs/meta`, then fetch each exact ID with `GET /api/cubs/` or MCP `get_cub`. Requery metadata after the seven reads when you need a consistent snapshot. Keep the Registry declaration, the running binary's embedded receipt, and a request-bound runtime observation separate. Exact-head equality requires full normalized 40-hex SHAs; an abbreviated source head is `INCONCLUSIVE`, never a prefix-based `PASS`. ### How is the monorepo structured? Four layers + proof kernels: **core** (`cubie-*` geometric runtime + admit pipeline), **EU** (`crates/cubie-eu-*` Annex IV mapping), **control plane** (`controlplane/`, `core-manifold/`, `ebpf-dataplane/`, `tests/` — TrustFortress), **proofs** (`coq/`, `lean/`, `verus/`, `proofs/`), and **apps** (`apps/`). See [agent-integrator-guide.md](agent-integrator-guide.md) for the crate-by-crate map. ### How do I build and run a demo? `cargo build --features std,mock` then the demos in `docs/DEMOS.md` (TDX cold path, fairness bench, agent harness, GPU-fleet dashboard, TEP detector). Everything runs in mock mode on a laptop; hardware paths are feature-gated. ## For onboarding admins ### What are the deployment modes? Local/On-Prem (`tf-server`, Axum), Data Center (`tf-server` with eBPF/AMX on Linux 5.15+), Kubernetes (PostgreSQL + SPIFFE + OpenFGA + Redis), and Cloud (`tf-edge` Wasm on Cloudflare Workers). See [admin-onboarding.md](admin-onboarding.md). ### How do identity and tenants work? Cloudflare Access (reads the authenticated-user email header) for cloud, or Keycloak/OpenBao over OIDC for on-prem; email is the natural key, tenant derives from the domain, and agent tokens are one-time-use and bound to intent + tenant. See [admin-onboarding.md](admin-onboarding.md). ### How do I turn on caching and semantic search? Create an AI Gateway and set `AI_GATEWAY_ID` (see [../AI_GATEWAY.md](../AI_GATEWAY.md)); provision AI Search with `wrangler ai-search create` and bind it (see [../AI_SEARCH.md](../AI_SEARCH.md)). Both are opt-in and safe to deploy before provisioning. ### Where do I report a vulnerability? Coordinated disclosure via the project's security policy (GitHub Security Advisories); critical issues target 24h acknowledgement / 7-day patch, aligned with EU CRA Article 11 and AI Act Article 73 incident-reporting timelines.