Operators support Role Assistants and monitor connected systems day to day. They need visible certification, explainable allow/deny decisions, and evidence from completed work — not opaque chat logs or unconstrained API access.
Purpose
This guide explains what “AI-ready” means in operations: which systems are certified, which roles may use which capabilities, when integrators must re-certify, and how to interpret lifecycle status and certification reports.
Operators do not configure integration JSON. They consume the trust boundaries integrators and architects defined — and escalate when certification, scope, or evidence gaps block legitimate work.
What operators care about
| Concern | What to look for |
|---|---|
| Certification status | Operations, AI trust, governance, and lifecycle status |
| Role boundaries | Active role defines what a Role Assistant may request; not everything the employee can do in a vendor UI |
| Explainability | Why AI was allowed or blocked; which capability, policy, or dimension applied |
| Evidence | Proof from completed tasks — not conversation history |
| Lifecycle | When integrators re-upload, repair, or re-certify after vendor or policy changes |
A system can be “connected” but not certified for AI-assisted work. Treat uncertified capabilities as out of scope until integrators complete the certification ladder.
Certification in operator terms
Integrators complete certification checks before operators expand Role Assistant use:
| Pillar | Operator takeaway |
|---|---|
| Operations | Tests pass against live/sandbox APIs — sync and capabilities work |
| Agent metadata trust | Business fields and labels are complete for AI context |
| Governance | A scoped test user sees only the data their role should see |
Ask integrators for the lifecycle report when onboarding a new system or after major changes. Do not accept the agent metadata trust pillar alone as full certification.
Day-to-day scenarios
Starting governed work — People normally state a business objective in conversation. Confirm the active role matches the task type, the underlying system is certified for required capabilities, and any approval gates are understood before execution. Work is used for plan review, Ask or Approval tasks, activity, and a focused Review Workspace when a richer decision is needed.
Blocked capability — Check certification status, role assignment, and dimensions. Escalate to governance or integrators if policy is correct but certification is stale.
After vendor upgrade — Request integrators revalidate and re-certify the operations pillar before expanding Role Assistant scope.
Audit request — Use Evidence Fabrix artifacts from completed work and Assistants evidence views. Conversation may start work, but it is not the system of record.
Why a result changed — Use Why? to understand an allow, deny, or wait outcome in business language. Escalate a suspected control or certification problem with that explanation and the relevant evidence.
Recommended reading
- Executive overview — four-pillar story
- Operating model — roles and cadence
- Operational Trust — validation and certification
- Conversation-first work
- Human tasks, approvals, and Why
- Business value from work steps
Related
Limits
Certification reports, role catalogs, and Role Assistant activation flows vary by deployment generation and tenant configuration. Confirm which pillars your integrator has certified before expanding operator scope.