Quickstart reference walkthrough

This page illustrates the intended Fibric developer flow: establish a tenant boundary, bind a connector by capability, define a governed operator, and inspect an action receipt. It is a product-contract walkthrough, not a runnable hosted quickstart today.

In the target platform, a workspace maps to a tenant boundary and every request is evaluated in that tenant context. The current app.fibric.io surface is the BearScope product sign-in, not a public Fibric developer console, and it does not issue the API keys described elsewhere in this reference.

The intended CLI would authenticate to one tenant-scoped workspace and make that context visible before any action. The package and commands below are proposed syntax only; @fibric/cli is not currently published for public installation.

# PROPOSED INTERFACE — not executable today
npm install -g @fibric/cli
fibric whoami

The target contract routes an intent such as orders.read through a connector bound to the orders role. This proposed sandbox flow demonstrates the indirection; it does not describe a sandbox service you can connect to today.

# PROPOSED INTERFACE — no public sandbox is available
fibric connectors search orders
fibric connectors add sandbox-orders --as orders

# confirm the capabilities it now exposes
fibric capabilities ls

The design goal is that operators ask for orders.hold, not for a vendor by name. A compatible replacement can then be configured behind the same capability contract, subject to connector-specific validation and migration work.

In the reference contract, an operator senses through connectors, reasons with a base model, and proposes action. A deterministic execution layer validates that proposal against policy before dispatch. The TypeScript below illustrates that contract; the import path is proposed and the package is not publicly available.

// REFERENCE EXAMPLE — @fibric/sdk is not publicly available
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 } })));
  },
});

The companion policy shows the intended fail-closed shape: explicitly allow bounded capabilities, limit the blast radius, and require an action receipt.

# REFERENCE POLICY — 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

# PROPOSED INTERFACE — no public deployment target exists
fibric operators deploy ./operator.ts --policy ./policy.yaml

The final stage of the target flow is an action trace: what was sensed, what the model proposed, which policy decision applied, and what the connector reported. The command and output below are illustrative, not a trace from a public Fibric sandbox.

# PROPOSED INTERFACE — illustrative command sequence
fibric operators run ship-risk --once
fibric receipts tail --operator ship-risk

A receipt is intended to retain the triggering envelope, proposed plan, policy evaluation, connector result, and idempotency key. Idempotency and single-flight controls are designed to suppress duplicate application during retries; they do not remove the need for connector-specific reconciliation and compensating actions.

# PROPOSED INTERFACE
fibric receipts show rc_5b21 --json

#What this models

This walkthrough models the Fibric contract: sense through a connector, reason and propose a plan, then validate and dispatch deterministically with a receipt. The repository contains a reference kernel for that design. The live BearScope product uses a governed application path today, but it is not evidence that the generalized public CLI, API, SDK, sandbox, or kernel runtime described in these docs is available.

#Next steps

• Architecture: the target envelope, router, trust, and executor contract.
• Governance & trust: the safety model these reference interfaces are designed to enforce.
• BearScope: the live product surface currently built from Fibric's governed operating principles.
• Contact Fibric: discuss managed access and confirm what is available for your use case.