Guides

Guides

Five end-to-end walkthroughs that take you from a system you operate to a governed action with a receipt. Every guide is copy-and-go: real commands, real config, no placeholders. Pick one and ship it.

Connect a system #

Sensing starts with a connection. A connector is how Fibric plugs into a real system, a CRM, a building controller, a warehouse WMS, a Magento store. Connectors are built on MCP and expose their capabilities as tools. You reach systems through a capability, not a brand, so swapping one vendor for another later is config, not a rewrite.

Install a connector from the marketplace, then create a connection that holds the credentials for your specific account.

# browse what's available, then install a connector
fibric marketplace search "support inbox"
fibric connector install kustomer

# create a connection. credentials live in the vault, never in code
fibric connection create \
  --connector kustomer \
  --name "support-prod" \
  --secret KUSTOMER_API_KEY=$KUSTOMER_API_KEY

# verify the connection can reach the system
fibric connection test support-prod

A healthy connection reports the capabilities it exposes. These are what an operator will be allowed to sense and act through.

{
  "connection": "support-prod",
  "connector": "kustomer",
  "status": "healthy",
  "capabilities": [
    "conversation.read",
    "conversation.note.write",
    "customer.read"
  ]
}

Define an operator #

An operator is a named AI worker that runs one operation, an order-risk watcher, a comfort tuner, a triage analyst. It senses through the capabilities you grant it, reasons with a base model, and proposes an ExecutionPlan. A deterministic executor disposes of that plan: the model never acts directly.

Operators are declared in a small manifest. Grant only the capabilities the job needs, and mark side-effecting steps so they route through the governed executor.

# operator.yaml: an order-risk watcher for a paper & print company
operator: order-risk-watcher
description: Flag orders that will not ship on time, before the carrier scans.

# what it is allowed to sense (read) and act through (write)
capabilities:
  read:
    - order.read
    - shipment.read
  write:
    - conversation.note.write   # leave an internal note
    - order.hold                # side-effecting: routes via the executor

# the base model that does the reasoning
model: fibric/reason-1

# how often it runs. on-event or on a schedule.
trigger:
  schedule: "every 30m"

Deploy it. The operator now runs on its trigger, senses through its connections, and proposes plans, but every side-effecting step waits for the executor and your policy.

fibric operator deploy ./operator.yaml --connection support-prod

# watch it think and propose, without letting it act yet
fibric operator run order-risk-watcher --dry-run

Write a trust policy #

A trust policy is the deterministic gate every action passes through. Policies are fail-closed: if no rule allows an action, it is denied. The model proposes; the policy and executor dispose. This is how a runaway action, the classic 657-message flood, becomes structurally impossible rather than merely unlikely.

Policies are plain, reviewable rules. Allow what the operation needs, cap what could run away, and require a human for anything irreversible.

# policy.yaml: governs the order-risk-watcher
policy: order-risk-guardrails
applies_to: order-risk-watcher

rules:
  # allow internal notes freely
  - allow: conversation.note.write

  # holding an order is allowed, but rate-limited and single-flight
  - allow: order.hold
    limit:
      per: hour
      max: 25            # a flood cannot exceed this
    single_flight: order_id   # never two holds in flight for one order

  # anything touching money needs a person to confirm
  - require_confirmation: refund.issue

# default is deny. nothing not listed above can act.
default: deny

Attach the policy and validate it before it ever sees a live plan. Validation is static: it tells you what the operator can and cannot do, without running anything.

fibric policy apply ./policy.yaml
fibric policy validate order-risk-guardrails --against order-risk-watcher

Review receipts & audit #

Every action Fibric takes leaves a receipt: what was proposed, which rule allowed it, the idempotency key that made it exactly-once, and the result. Receipts are not a log you opt into, they are the record of the action itself. If it is not in the receipt ledger, it did not happen.

List recent receipts for an operator, then open one to see the full chain from proposal to disposition.

# the last 24h of actions taken by this operator
fibric receipts list --operator order-risk-watcher --since 24h

# open one receipt in full
fibric receipts show rcpt_8f2a91c4

{
  "receipt": "rcpt_8f2a91c4",
  "operator": "order-risk-watcher",
  "action": "order.hold",
  "entity": "order:SO-44817",
  "idempotency_key": "order.hold:SO-44817:2026-06-13",
  "proposed_by": "fibric/reason-1",
  "reason": "Proof not approved + ship-by in 18h; will miss carrier cutoff.",
  "policy": { "rule": "allow order.hold", "decision": "allow" },
  "single_flight": "acquired",
  "result": "ok",
  "tenant_id": "t_paperco",
  "at": "2026-06-13T14:22:07Z"
}

Add a connector to the marketplace #

Built a connector for a system the marketplace does not cover yet? Publish it so any workspace can install it. A connector is defined with the SDK (see SDKs & CLI), declares the capabilities it provides, and is packaged with a manifest the marketplace reads.

The lifecycle is five steps:

1. Scaffold.

   Generate a connector project from the template, then implement your tools against the system's API.

2. Declare capabilities.

   Map each tool to a capability such as order.read so operators bind to the capability, not your brand.

3. Validate.

   Run the conformance check. It confirms auth works, side-effecting tools are marked, and every tool is reachable.

4. Publish.

   Push a versioned build to the marketplace as private (your workspace) or public (everyone).

5. Maintain.

   Ship new versions with semver. Installs pin a version, so an update never silently changes behavior.

# scaffold a new connector
fibric connector scaffold acme-wms --lang ts

# validate it meets the marketplace contract
fibric connector validate ./acme-wms

# publish a version (private to your workspace, or --public)
fibric connector publish ./acme-wms --version 0.1.0 --private

Once published, your connector behaves exactly like a first-party one: installable from the marketplace, bound by capability, and governed by the same policies and receipts as everything else on Fibric.