GAIA Orchestra

One request, eleven gates

Orchestra is the control layer. It decides what context is allowed, what policy applies, which route should execute, what proof is required, and whether the final answer is safe to return.

In business terms

What happens when a user sends a request

A chatbot takes text and returns text. Orchestra takes a request and runs it through a governed execution path. Each stage is a contract — a typed envelope that can be inspected, audited and blocked. If any gate refuses, the request returns a structured blocked output with proof, never a silent failure or an improvised answer.

Policy runs twice — before and after prompt enhancement — so prompt expansion can never escalate scope.

The request journey

Every stage is a typed contract

These are the actual envelope names used inside Orchestra. Each one is inspectable, and each gate can return a blocked output instead of letting an unsafe request continue.

  1. InputEnvelope The raw request: source channel, actor, tenant, message, metadata. Nothing runs without one.
  2. NormalizedIntent Deterministic cleanup and classification — what is actually being asked, in a machine-checkable form.
  3. TenantScope Resolves which tenant this request belongs to. Memory and tools are only reachable inside that scope.
  4. PolicyDecision (early) First policy check on the raw intent: forbidden categories, secret-fishing, scope violations.
  5. ContextPack Tenant-scoped memory retrieval. Every recalled item is trust-labeled; untrusted content is filtered or flagged.
  6. EnhancedPrompt Memory-aware auto-prompting: system context, task instruction, proof requirements — assembled, not improvised.
  7. PolicyDecision (final) Policy runs again on the enhanced prompt, so enrichment can never widen what the request is allowed to do.
  8. RouteDecision Policy-aware routing across approved model tiers and tools — the right capability for the task, not the biggest model by default.
  9. ExecutionPlan → ExecutionResult Durable, idempotent execution with a task ID. Sensitive actions stop at approval gates for a human decision.
  10. ProofBundle The evidence record: proof ID, verdict, trace references. Generated for every output — including refusals.
  11. OutputEnvelope + OutputCritic A final hard gate reviews the answer before release. What passes becomes a MemoryWriteCandidate — only safe, useful results are remembered.

Proof status taxonomy

No proof means no production claim

Every output is labeled with exactly one status. Mock, fallback or dry-run results are never marked verified — the taxonomy is enforced in code, not in marketing copy.

verified

Verified

The output is backed by a real artifact — a test run, a file, a trace — attached to its ProofBundle. This is the only status that supports a production claim.

reported-pending-proof

Reported, pending proof

The work was performed and reported, but the verifying artifact is not yet attached. Honest middle state — never silently upgraded.

blocked

Blocked

A policy, tenant or approval gate refused the request. Blocked outputs are expected safety behavior, returned as structured envelopes with their own proof ID — never as exceptions.

error

Error

Something failed mechanically. The failure is recorded with a proof ID so it can be audited and retried idempotently.

See the pipeline run on your own workflow

Bring one workflow. We will map it, connect it, and return proof-backed outputs within a bounded pilot.