Quickstart

Go from an empty account to a live operator that takes a real, governed action, then read the receipt that proves what it did. Five steps, about ten minutes. Everything runs against a sandbox connector, so no live system is touched.

Create a workspace at app.fibric.io. A workspace is your tenant, and its data is provably walled off from every other tenant from the first row written. Grab an API key from Settings → API keys and export it so the CLI can use it.

# export the API key from Settings → API keys
export FIBRIC_API_KEY="sk_live_…"
export FIBRIC_WORKSPACE="acme-ops"

Install the CLI globally and confirm it can reach your workspace. That is all this quickstart needs; requirements, the browser login flow, project scaffolding, and troubleshooting are covered in Installation.

npm install -g @fibric/cli
fibric whoami

A connector plugs Fibric into a system you already run and is built on MCP. For the quickstart, connect the sandbox order system. It speaks the same capability interface a real order system would, so nothing else on this page changes when you later swap it for the real thing.

# browse what is installable, then add the sandbox order system
fibric connectors search orders
fibric connectors add sandbox-orders --as orders

# confirm the capabilities it now exposes
fibric capabilities ls

You bound the connector to the role orders. Operators ask for the capability orders.hold, not for a vendor by name, and that indirection is what makes swapping one order system for another a config change rather than a rewrite.

An operator is a named AI worker that senses through connectors, reasons with a base model, and proposes action. It never acts directly. A guardrail is the fail-closed policy the deterministic executor enforces before any proposed action runs. Create operator.ts; this one watches orders and proposes a hold on any order that will miss its ship date.

import { defineOperator } from "@fibric/sdk";

export default defineOperator({
  name: "ship-risk",
  capabilities: ["orders.read", "orders.hold", "orders.notify"],
  goal: "Hold any open order that will not ship on time, and notify the owner.",

  async run(ctx) {
    const orders = await ctx.orders.read({ status: "open" });
    // the model reasons over what it sensed and PROPOSES a plan.
    // it returns proposed actions; it never executes them itself.
    return ctx.propose(orders
      .filter(o => o.willMissShipDate)
      .map(o => ({ capability: "orders.hold", args: { id: o.id } })));
  },
});

Now the guardrail. Policy is the deterministic half of the loop: it approves or blocks what the model proposes, and anything not explicitly allowed is refused.

# fail-closed: anything not allowed here is refused
version: 1
allow:
  - orders.hold
  - orders.notify
limits:
  orders.hold:
    max_per_run: 25      # cap the blast radius of any one run
    single_flight: by_order_id   # one in-flight action per entity
require_receipt: true

fibric operators deploy ./operator.ts --policy ./policy.yaml

Run the operator once and tail its receipts. Each receipt is the immutable record of one action: what was proposed, the policy decision, and the outcome.

fibric operators run ship-risk --once
fibric receipts tail --operator ship-risk

Open any receipt to see the full record: the envelope that triggered it, the proposed plan, the policy evaluation, and the idempotency key (ship-risk:SO-10884:hold) that guarantees the same action is never applied twice.

fibric receipts show rc_5b21 --json

#What just happened

You ran the full Fibric loop. The operator sensed through a connector, reasoned over what it saw and proposed a plan, and the deterministic executor checked that plan against your policy, running each action once, never twice, and leaving a receipt for every step. That is exactly the shape a production operation runs in; the only change is swapping the sandbox connector for a real one, bound to the same orders role, with your operator and policy unchanged.

#Next steps

• Installation: full CLI setup, authentication modes, and troubleshooting.
• Your first operator: the complete tutorial against a live connector, from naming to first receipts.
• Architecture: how the envelope, router, trust layer, and executor fit together.
• The event envelope: the one canonical shape every event travels in.