Cryptographic governance evidence for learned multi-model orchestration. From routing decision to regulatory evidence in zero lines of new code.
Who this is for: AI engineers, MLOps teams, and compliance officers deploying Sakana Fugu in regulated environments. Addresses the EU/EEA access gate, GPAI obligations, and the multi-model accountability gap. Works with the existing OpenAI-compatible API and NVIDIA Dynamo infrastructure.
Fugu is currently unavailable in EU/EEA countries pending GDPR compliance adjustments to its routing system. EU AI Act GPAI and transparency obligations enforce . This guide shows how SWT3 provides the compliance evidence layer that multi-model orchestration systems need for regulated market entry.
When a user sends a request to Fugu, the learned conductor model decides how to handle it: answer directly, delegate to a specialist model in the pool, decompose into sub-problems and assign different models to each, or recursively call itself. The final response is a synthesis of outputs from multiple models, each contributing a different piece.
The compliance question: when a regulator asks "which model produced this output?", the answer for orchestrated systems is not a single model identifier. It is a routing decision, a set of model contributions, and a synthesis step. No existing compliance framework handles this. Traditional AI governance assumes one model, one inference, one provenance chain.
SWT3 solves this by witnessing the orchestration itself. Every routing decision, every model contribution, every handoff between Thinker, Worker, and Verifier becomes a cryptographic witness anchor. The orchestration is no longer a black box -- it is an auditable, verifiable evidence chain.
Fugu is not a foundation model. It is a trained conductor that orchestrates a swappable pool of frontier LLMs. The architecture has four stages:
| Stage | What Happens | Compliance Implication |
|---|---|---|
| 1. Routing | Fugu receives the request and decides whether to handle directly or delegate. This is a learned decision, trained via reinforcement learning. | The routing decision determines which models touch user data. This is a GDPR-relevant data processing decision. |
| 2. Role Assignment | Conductor assigns roles: Thinker (reasoning), Worker (execution), Verifier (validation). Each role may go to a different model. | Authority delegation. The conductor grants each model a scoped mandate. Auditors need to know what each model was authorized to do. |
| 3. Parallel Execution | Multiple models process their assigned sub-tasks independently. Fugu can recursively call itself for nested sub-problems. | Multi-model provenance. Token consumption and cost are distributed across providers. Each provider may be in a different jurisdiction. |
| 4. Synthesis | Aggregator synthesizes outputs into a single coherent response returned via the API. | The final output is a composite. Provenance must trace back through each contributing model. |
Key architectural property: the model pool is swappable. Models can be added, removed, or updated without rebuilding the orchestration logic. This is powerful for vendor flexibility but creates a moving target for compliance: the audit trail from last week may reference models that are no longer in the pool.
Fugu deployments on NVIDIA infrastructure benefit from two complementary witnessing layers. Neither requires changes to Fugu's application code.
The SWT3 Dynamo adapter wraps async generator endpoints at the GPU serving layer. When Fugu's conductor routes a sub-task to a model served by Dynamo, the adapter transparently witnesses:
Chunks pass through untouched. Witnessing happens after stream completion. Zero latency impact on the inference pipeline.
The SWT3 SDK wraps the Fugu API call at the application layer. Because Fugu exposes an OpenAI-compatible API (api.sakana.ai/v1), the existing OpenAI adapter works without modification:
Together, the two layers create a complete evidence chain: Layer 2 proves what the conductor decided; Layer 1 proves what each model actually did.
Eight SWT3 procedures map to Fugu's orchestration architecture:
| Procedure | What It Witnesses | Fugu Component |
|---|---|---|
| AI-INF.1 | Inference provenance per model contribution | Each sub-inference in the routing pipeline |
| AI-CHAIN.1 | Multi-agent chain witnessing | Thinker to Worker to Verifier handoff sequence |
| AI-CHAIN.2 | Trust degradation across handoffs | Confidence scoring as outputs pass between models |
| AI-DEL.1 | Delegation tree witnessing | Conductor delegating authority to pool models with scoped roles |
| AI-COST.1 | Resource consumption witnessing | Token and cost attribution across all providers in one Fugu call |
| AI-MDL.2 | Model version tracking | Each model in the swappable pool, recorded at inference time |
| AI-DRIFT.2 | Consequence-mapped drift | Routing pattern changes that degrade output quality over time |
| AI-GRD.2 | Content safety filtering | Safety verification across synthesized multi-model outputs |
Fugu orchestrates frontier models that individually qualify as general-purpose AI (GPAI). Under the EU AI Act, GPAI providers have obligations that enforce August 2, 2026. Multi-model orchestration systems face compounded obligations because they aggregate multiple GPAI models.
| Article | Requirement | SWT3 Evidence |
|---|---|---|
| Art. 12 | Automatic logging of AI system operation | AI-INF.1 + AI-CHAIN.1 anchors provide cryptographic, immutable logging of every routing decision and model contribution |
| Art. 13(3)(b) | Information on computational resources needed | AI-COST.1 anchors attribute token consumption and cost across all models per inference. Aggregate reporting over time. |
| Art. 14 | Human oversight measures | AI-DEL.1 anchors trace authority from the conductor's routing decision back to the human who configured the model pool and routing policy |
| Art. 53 | GPAI provider obligations (technical documentation, transparency, copyright compliance) | Combined evidence chain: AI-MDL.2 (which models), AI-CHAIN.1 (how they interact), AI-COST.1 (resource consumption), AI-INF.1 (per-model provenance) |
The evidence chain does not require Fugu to modify its routing logic or API. The SDK wraps the existing OpenAI-compatible endpoint and witnesses the orchestration transparently.
Fugu's EU/EEA access gate exists because routing decisions involve sending user data to different model providers, potentially in different jurisdictions. GDPR requires transparency about who processes personal data and where.
SWT3 clearing levels address this directly:
| Clearing Level | What Is Recorded | Use Case |
|---|---|---|
| CL0 (Analytics) | Full routing details: model names, providers, regions, token counts, latency per model | Internal engineering teams. Full observability. |
| CL1 (Standard) | Full routing details with model identifiers. Provider regions included. | Compliance teams. GDPR documentation. Audit evidence. |
| CL2 (Sensitive) | Model category (e.g., "reasoning-model") without provider name. Region tier (e.g., "eu") without specific region. | Cross-border sharing. Proves routing governance without revealing vendor relationships. |
| CL3 (Classified) | Routing decision hash only. No model names, no providers, no regions. | Classified environments. Proves orchestration governance occurred without revealing any detail. |
For GDPR compliance, CL1 provides the evidence that data processing decisions (which model, which jurisdiction) were logged. CL2 enables sharing this evidence with regulators without exposing commercial relationships with model providers. The clearing level is set at SDK initialization and applies uniformly to all anchors.
Fugu was launched in response to US export controls that restrict access to advanced American AI models in certain contexts. Its value proposition is routing around these restrictions by using a swappable model pool.
SWT3 strengthens this value proposition by providing audit continuity when the model pool changes:
The result: Fugu can swap models freely in response to regulatory changes, and the compliance evidence chain adapts automatically. No manual re-documentation required.
What Fugu does: Routes tasks through a Thinker (reasoning), Worker (execution), and Verifier (validation) pipeline, with each role potentially assigned to a different frontier model.
What SWT3 witnesses: Each handoff in the chain is a linked witness anchor. The chain ID connects all anchors in a single Fugu inference. Auditors can reconstruct the complete routing path from a single identifier.
Query the chain endpoint with the lifecycle_chain_id to see all models that contributed to a single Fugu response. Verify that the Verifier role actually validated the Worker's output (check anchor sequence).
What Fugu does: The conductor delegates authority to pool models with scoped roles. Each delegation has a specific mandate (reasoning, code generation, fact verification) and a bounded scope.
What SWT3 witnesses: The delegation tree captures the conductor's authority structure: who delegated what to whom, with what scope constraints. The scope hash binds the specific permissions to the attestation anchor.
For Article 14 (human oversight), trace the delegation tree back to the root. The human who configured the model pool and routing policy is the root authority. AI-DEL.1 proves the chain of authority from human configuration to model execution.
What Fugu does: Consumes tokens across multiple model providers in a single request. A complex Fugu Ultra task might involve 3-5 different models, each with different per-token pricing.
What SWT3 witnesses: Aggregate token counts (input + output), API call count, and estimated cost in cents. At CL0-1, per-provider breakdown is recorded. Enables fiduciary cost attribution and budget enforcement.
For Article 13(3)(b) (resource information), AI-COST.1 anchors provide the computational resource evidence. Aggregate over time to show total resource consumption for the AI system. Compare against budget thresholds.
What Fugu does: Routing patterns may change as the conductor learns from new data or as models in the pool are updated. A model swap (due to export controls, provider changes, or performance optimization) can alter output characteristics.
What SWT3 witnesses: Drift magnitude mapped to consequence categories (safety, financial, operational, reputational) with graduated response actions. If drift from a model swap exceeds the safety threshold, the system can trigger an emergency override (AI-EMRG.1).
After any model pool change, check for AI-DRIFT.2 anchors in the 48 hours following. The absence of drift anchors after a pool change is itself meaningful -- it means the consequence thresholds were not breached.
| Examiner Question | Where to Look |
|---|---|
| Which models produced this output? | AI-CHAIN.1 chain, each anchor identifies the contributing model |
| Who authorized the routing decision? | AI-DEL.1 delegation tree, trace to root (human configuration) |
| How much did this inference cost? | AI-COST.1 factor_a (tokens), factor_c (cost cents) |
| What happens when a model is removed from the pool? | AI-MDL.2 anchors before/after show pool composition change |
| Is the orchestration quality degrading? | AI-DRIFT.2 anchors with consequence severity and response action |
| Where was user data processed? | CL1 routing evidence shows model providers and regions per sub-inference |
| Does this system meet GPAI obligations? | Combined AI-INF.1 + AI-CHAIN.1 + AI-COST.1 + AI-MDL.2 evidence chain |
| Can I verify the evidence independently? | Every anchor has a SHA-256 fingerprint verifiable at /verify |
Fugu exposes an OpenAI-compatible API. The existing SWT3 OpenAI adapter works without modification:
For Fugu deployments on NVIDIA GPU infrastructure, the Dynamo adapter witnesses at the serving layer:
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup