Deploy the Order Risk operator

Order Risk (op-order-sentinel) watches every open order next to its support thread and shipment record, and scores how likely each one is to miss the date you promised. When the score crosses your threshold, it proposes a hold, a reroute, or a notice to the account owner, and the deterministic executor carries the action out exactly once. This guide installs it from the marketplace, binds its connectors, tunes the threshold, writes its guardrail policy, and reads its first receipts.

#What the operator does

The signal Order Risk works from is upstream of the carrier. A proof approval that has sat for two days, a paid order with no fulfilment, a customer who has already written in twice: by the time tracking says late, the risk has usually been visible in the order for a week. The operator senses three feeds through the connectors you bind it to:

• Open orders with line items, promise dates, and proof-approval state.
• Support conversations tied to each order, including reopen and escalation history.
• Shipment and tracking events from the moment a label is created.

From these it produces one risk score per open order. When a score crosses the threshold you set, the operator proposes an ExecutionPlan: place or release an order hold with the reason on the record, propose a reroute or expedite, or notify the account owner with the order, the signal, and the recommended fix. The plan is only a proposal. Every action in it passes through your trust policy before anything touches a live system, and every disposition leaves a receipt.

The operator holds no credentials of its own. It runs inside your tenant and acts through the connectors you have already authorized; revoking a connector revokes the operator's reach with it.

#Prerequisites

Order Risk requires three connector roles. Each role accepts more than one connector, and the operator binds to the capability, not the vendor, so swapping Magento for Shopify later is a config change, not a redeploy.

You also need the CLI installed and authenticated (CLI reference), and permission to apply policy in the workspace. Confirm the connectors are healthy before installing the operator:

fibric connectors list
fibric capabilities ls

Marketplace operators install as packs. fibric operators create --from pulls the pack, walks capability binding, and asks you to accept the guardrails the pack declares as its floor. New operators start in propose-only mode: they sense, reason, and propose, but no side-effecting action runs until you switch them live.

fibric operators create --from op-order-sentinel --name order-risk \
  --bind order.read=cn-magento \
  --bind order.hold=cn-magento \
  --bind conversation.read=cn-kustomer \
  --bind conversation.note.write=cn-kustomer \
  --bind shipment.read=cn-shipstation

The operator now runs on its trigger, but every proposal parks instead of executing. That is the correct state to tune thresholds in: you can watch what it would do against real orders before anything is allowed to act.

Configuration is a JSON block passed at create time or updated later by re-running create with the same name. The parameters below are the pack's public surface; anything not listed keeps its default.

fibric operators create --from op-order-sentinel --name order-risk \
  --config '{"risk_threshold": 80, "propose_window_hours": 48, "max_holds_per_run": 5}'

Start high. A threshold of 80 with a 48-hour window produces few, high-confidence proposals; watch a week of dry runs, then lower the threshold until the operator catches the orders your team was catching by hand. Tightening later is a config change; loosening should follow evidence in the receipts.

The trust policy is the deterministic half of the loop, and it is fail-closed: anything a rule does not explicitly allow is refused. The pack's configuration bounds what the model proposes; the policy bounds what can execute, and the policy wins. This is the mechanism that makes a runaway action, the classic 657-message flood, structurally impossible rather than merely unlikely.

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

rules:
  # internal notes are low-risk; allow them freely
  - allow: conversation.note.write

  # holds are 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

  # owner notices are allowed, capped per hour
  - allow: notify.send
    limit:
      per: hour
      max: 25

  # rerouting or expediting a shipment costs money: a person confirms it
  - require_confirmation: shipment.reroute

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

Apply the policy and validate it statically. Validation tells you exactly what the operator can and cannot do, without running anything.

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

A --dry-run shows you the exact ExecutionPlan the operator would submit, scored and ordered, but executes nothing. Run it a few times across a business day before you trust the threshold.

fibric operators run order-risk --once --dry-run

When the proposals match what your team would have done by hand, switch the operator live. Live mode does not bypass anything: every action still passes the trust policy, still takes its single-flight lock, and still deduplicates on its idempotency key.

fibric operators create --from op-order-sentinel --name order-risk --mode live
fibric operators run order-risk --once

If you need to stop it, fibric operators pause order-risk halts new runs immediately; in-flight actions complete under their single-flight locks and nothing new is proposed.

Every disposed action leaves a receipt: the proposal exactly as the operator made it, the policy decision, the idempotency key, and the outcome. Blocked and deduplicated actions are receipted with the same fidelity as executed ones. Tail the stream to watch the operator work:

fibric receipts tail --operator order-risk

Each disposition answers a different operational question:

Open any receipt in full with fibric receipts show rc_… --json, and export the ledger for audit with fibric receipts export --since 7d. The receipt's anatomy, immutability guarantees, and query filters are covered in Receipts & audit. Ongoing observation, standing queries, and alerting on BLOCK rates are covered in the monitoring guide.

#Troubleshooting

#Next steps

• Guardrails: value caps, confirmation tiers, and how to promote an ALERT action to unattended.
• Monitoring operators: standing receipt queries and what a healthy BLOCK rate looks like.
• Deploy the Operations Analyst: ask why an order slipped, in plain language, over the same governed data.
• Operators and Operator packs: the concepts behind what you deployed.