Deploy the Operations Analyst

Operations Analyst (op-radar-analyst) answers the questions an operator on shift actually asks: why did response time slip yesterday afternoon, which orders reopened twice this week, who is waiting longest right now. Every number in an answer comes from your governed data and carries its source, and when an answer points at a fix, the operator proposes the action as a validated plan that a human confirms before anything runs. This guide installs it from the marketplace, binds it to your connected systems, walks through asking a question, explains how grounding works, and turns an answer into a vetted, receipted action.

#What the operator does

Most operational questions die in a dashboard scavenger hunt: the number you need exists, but it is three filters and two tabs away, and by the time you find it the standup is over. Operations Analyst sits over the same governed data your dashboards read and answers in plain language instead. It senses three things through the connectors you bind it to:

• Governed metrics with one canonical definition per number, each tagged with its source.
• Support conversations, order state, and call records inside your tenant.
• The history of past questions and confirmed actions, kept on the record.

An answer is not a paragraph of model prose. It is a set of numbers, each traceable to the event envelopes it was computed from, with the reasoning laid out next to them. When the answer points at a fix, the operator goes one step further: it proposes an ExecutionPlan, the same validated shape every Fibric operator produces, and parks it for your confirmation. The deterministic executor carries a confirmed action out exactly once, under the same trust policy, single-flight locks, and idempotency keys that govern every other operator. See Operators for the general model.

The operator holds no credentials of its own. It reads through the connectors you have already authorized, and it can only see your tenant; revoking a connector revokes the analyst's view of that system with it.

#Prerequisites

Operations Analyst binds to capabilities, not vendors. It needs at least one read capability to answer questions over, and one write capability if you want answers to become actions. The table shows a typical CX binding; a commerce-only or voice-only binding also works, and the operator answers over what it can see.

You also need the CLI installed and authenticated (CLI reference), and permission to apply policy in the workspace if you intend to confirm actions. Check that the capabilities you plan to bind are healthy:

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. Bind every capability you want the analyst to answer over; the write capabilities are what its proposed actions can reach later.

fibric operators create --from op-radar-analyst --name ops-analyst \
  --bind conversation.read=cn-kustomer \
  --bind conversation.note.write=cn-kustomer \
  --bind order.read=cn-magento \
  --bind order.hold=cn-magento \
  --bind call.read=cn-amazon-connect

Unlike a scheduled operator such as Order Risk, the analyst has no trigger loop by default: it senses continuously so its picture is current, but it reasons when you ask. And it never executes anything unattended. confirm-required is the pack's floor, not a setting you loosened into existence; the analyst proposes, a person disposes.

Ask from the console or the CLI. Questions are plain language; the analyst decides which governed data answers them and shows its work. There is no query language to learn, and no question can cause a side effect: asking is a read, always.

fibric ask ops-analyst "why did first response time slip yesterday afternoon?"

Every claim in the answer is a number with a definition, not an impression. If the analyst cannot ground a claim, it does not make the claim: a question about data outside its bindings, or about a window with no envelopes, gets an explicit statement of what it cannot see rather than a plausible guess.

Questions and answers land in the operator's history, so a follow-up like "and the week before?" resolves against the question it follows. The history itself is on the record: your team can read what was asked, what was answered, and what the answer was grounded in.

Everything a connector senses becomes an EventEnvelope: one canonical shape carrying event_id, source, event_type, correlation_id, and the payload, stamped with your tenant_id. The analyst computes over envelopes and governed metric definitions, never over free text it retrieved from somewhere it cannot name. That gives every number in an answer a provenance chain you can walk:

fibric ask ops-analyst --show-sources --last

This is the property that makes the answers usable in an argument: when the analyst's number disagrees with someone's spreadsheet, you expand the sources and settle it against the envelopes, not against who sounds more confident.

When an answer points at something fixable through a bound write capability, the analyst attaches a proposal. The proposal is a full ExecutionPlan: each action names its connector and tool, carries its entity_key for single-flight and its idempotency_key for dedup, and has already been evaluated against your trust policy. Nothing in it has run.

fibric ask ops-analyst "which paid orders have sat unfulfilled past their promise date?"

Confirm it, in whole or in part, and the deterministic executor takes over:

fibric plans confirm pl_4e8a02
# or confirm selectively:
fibric plans confirm pl_4e8a02 --only order.hold:SO-11418

Confirmation is not a bypass. The confirmed plan still passes the trust policy, still takes its single-flight lock per entity_key, and still deduplicates on its idempotency_key; confirming the same plan twice produces DEDUP receipts, not duplicate holds. A declined plan is receipted too, with your reason, so the record shows what was proposed and why it did not run. See Single-flight & idempotency for the mechanics.

Every disposed action leaves a receipt: the proposal exactly as the analyst made it, who confirmed it, the policy decision, the idempotency key, and the outcome. Declines and dedups are receipted with the same fidelity as executed actions.

fibric receipts tail --operator ops-analyst

Because the analyst's answers are also on the record, a receipt is never orphaned: from any receipt you can walk back through the plan to the question that produced it and the envelopes the answer was grounded in. fibric receipts show rc_… --json prints the full chain, and fibric receipts export --since 7d exports the ledger for audit. The receipt's anatomy and immutability guarantees are covered in Receipts & audit; standing queries and alerting are covered in the monitoring guide.

#Guardrails that apply

The analyst is governed like any other operator, plus two constraints of its own. The general policy machinery is fail-closed: anything a rule does not explicitly allow is refused, and an empty policy denies everything.

• Reads are ungoverned by design, writes never are. Answering a question invokes only non-side-effecting tools, which need no policy. The moment a proposal contains a write, the trust policy applies in full.
• Confirm-required is the pack's floor. Every side-effecting action the analyst proposes waits for a human, regardless of what your policy would allow unattended. A rule that says allow: order.hold lets a confirmed hold run; it does not let the analyst hold orders on its own.
• Your policy still bounds the confirmed action. Rate limits, value ceilings, and single-flight apply after confirmation exactly as they do for scheduled operators. A person confirming a plan cannot push it past a limit.max the policy sets.

# policy.yaml: governs the ops-analyst operator
policy: ops-analyst-guardrails
applies_to: ops-analyst

rules:
  # findings written back as internal notes: allowed, capped
  - allow: conversation.note.write
    limit:
      per: hour
      max: 30

  # confirmed holds: allowed, rate-limited, single-flight per order
  - allow: order.hold
    limit:
      per: hour
      max: 15
    single_flight: order_id

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

fibric policy apply ./policy.yaml
fibric policy validate ops-analyst-guardrails --against ops-analyst

#Troubleshooting

#Next steps

• Deploy the Order Risk operator: put a scheduled operator on the orders the analyst keeps finding.
• Guardrails: value caps, confirmation tiers, and how policy composes with confirm-required packs.
• Monitoring operators: standing receipt queries over the analyst's confirmed actions.
• Receipts & audit: the full anatomy of the record every answer and action leaves behind.
• Operators: the concepts behind sense, reason, and act.