Deployment architecture

Fibric is a managed cloud service. You do not install servers, run databases, or operate queues; you connect systems and configure operators, and the platform runs the governed loop for you. This page describes where Fibric runs, how the request path is put together, the swap-seam architecture that lets the platform scale without rewrites, and the short answer to what customers host: nothing, except the credentials they grant to connectors.

#The managed cloud

Fibric runs on AWS in the us-east-1 region. All platform components, the API, the event store, the executor, the secret store, and the receipt ledger, run inside that footprint. Today, us-east-1 is the primary region; multi-region residency is on the roadmap and per-tenant model residency is already expressible as policy (see model routing below).

#The request path

One governed loop, end to end:

your systems                     Fibric managed cloud (us-east-1)
────────────                     ─────────────────────────────────────────────
webhook / poll / gateway ──────> ingest ──> EventBus ──> EventRouter (glob match)
                                                             │
                                                        operator (ModelRouter)
                                                             │  proposes ExecutionPlan
                                                        DeterministicExecutor
                                                        trust gate · single-flight
                                                        · idempotency (DurableExec)
                                                             │
your systems <────────────────── connector runtime <────────┘
                                 (per-tenant creds)      receipts → ledger

Inbound, connectors declare their event sources as webhook or poll (the events map in a connector definition); hardware sources publish through a gateway that speaks the same envelope. Everything becomes an EventEnvelope at the door. Outbound, only the connector runtime touches your systems, with credentials resolved per tenant at call time, after the trust gate has disposed the action. The reasoning step sits between two deterministic layers and has no network path of its own.

#The swap-seam architecture

The kernel defines five infrastructure dependencies as interfaces, seams, in packages/kernel/src/seams.ts. Each seam has a deliberately cheap MVP implementation and a named scale-up target that drops in behind the same interface, with no application rewrite. This is one architecture serving two goals at once: the cheapest deployment that is still correct, and a clean path to scale.

The seam contract is visible in the source. DurableExec, for example, is one method:

// ── Durable execution — MVP: in-process / Postgres outbox · scale-up: Temporal ──
export interface DurableExec {
  once<T>(key: string, fn: () => Promise<T>): Promise<T>; // at-most-once per key, survives retries
}

#Model routing

No kernel code calls a model directly; every model call goes through the ModelRouter seam, and which model serves a request is policy, keyed by tenant:

export interface ModelPolicy {
  defaultModel: string; // e.g. "deepseek.v3.2"
  perTenant?: Record<string, string>; // e.g. { "city-of-x": "us.anthropic.claude-..." }
}

export class PolicyModelRouter implements ModelRouter {
  resolveModel(tenant_id: string): string {
    return this.policy.perTenant?.[tenant_id] ?? this.policy.defaultModel;
  }
}

This is load-bearing for regulated tenants: a requirement like "this tenant's reasoning must run on a US-hosted model" is one entry in perTenant, not a code branch. The routing decision keys off the same verified tenant identity the database uses for row-level security, so a tenant's model policy cannot be selected by anything a caller passes in a request body.

#What customers host

Nothing. There is no agent to install, no database to run, no queue to size. What you contribute is access:

#Availability posture

Fibric does not yet publish a public uptime SLO; enterprise agreements carry their own. What we document instead are the mechanics that make interruptions safe rather than silent: ingest deduplicates on idempotency keys so retried deliveries never double-count, side effects are idempotent so a retried plan never re-fires, and a paused stream resumes from a cursor with nothing lost. Those semantics, at-least-once ingestion, idempotent execution, single-flight serialization, replay, and backpressure, are specified in Reliability and delivery semantics. Deploys return brief 503 service_unavailable responses with Retry-After; see Errors for handling.

Continue with Reliability and delivery semantics for the failure-mode contract, the security model for what is enforced along this path, and Environments for how sandbox and production coexist on the same deployment.