A governed capability is an approved operation AI may request — not a raw API call and not uncontrolled system access. Operational Trust checks each request against identity, business role, scope, policy, approval, and certification before execution.
AI may recommend, prepare, or perform work only within the identified person’s existing authority. It cannot invent new capabilities or expand that authority.
Why it matters
Giving AI direct system access creates uncontrolled risk. Governed capabilities express work in business language (customer.search, deal.reviewPipeline, approval.prepareRequest) while the platform enforces trust controls on every request.
Users do not select arbitrary tools or paste application credentials. The AI interface provides the interaction; AI Fabrix provides the governed capability behind it and binds every action to the active person’s verified authority.
How it works
AI → governed capability → Operational Trust checks → approved operation → evidence
Before execution, AI Fabrix verifies:
- who is acting and which business role is active
- which business context and records are in scope
- whether the capability is allowed for this person and case
- which policies and human approvals apply
- what evidence must be captured
Certified does not mean currently authorised. Validation and certification prove readiness for a scope; runtime Operational Trust still decides whether this request may proceed now. When authority or required context cannot be verified, the work stops safely — cannot verify means do not execute.
How Role Assistants receive catalogs of capabilities: How Role Assistants get capabilities. Integrators declare risk and approval expectations on the Configure AI contract track. Architecture mediation: Capability gateway.
Three layers of authority
A governed capability enforces three distinct authority layers, not one:
- Business scope / ABAC — which Customer, legal entity, country, or cost centre is in scope for the identified person. See Dimensions and protection.
- Field-level authority (this page) — which attributes on an in-scope record may be read or modified.
- Operation authority (this page) — whether create, update, or delete is allowed for this capability, and whether human approval is required.
Read permission does not grant AI-initiated mutation. A person, and the Role Assistant acting for them, may be fully in scope for a Customer record under layer one and still not be authorized to change a given field. The capability exposed to AI must not itself permit a denied mutation: a prompt instruction telling the AI "don't modify creditLimit" is not the control if the underlying capability still allows that write. The control is the capability definition and the Operational Trust check before execution — not wording in a prompt.
| Role | Scope | Field | Authority |
|---|---|---|---|
| Sales Rep | Own region customers | name, owner, notes | Read, update |
| Sales Rep | Own region customers | creditLimit |
Read only |
| Finance Approver | All customers, own legal entity | creditLimit |
Update, approval required |
See Trust boundaries for where each layer is enforced in the request path, and Business meaning as governed content for why the capability contract — not a prompt — is the governed definition of what AI may do.
Business operations, not vendor APIs
The capability contract AI sees is expressed in business operations — customer.search, deal.reviewPipeline — not vendor endpoints, table names, or test/internal field labels. The technical implementation (connector, query, mapping) stays underneath the capability; AI never needs it. Enterprise Knowledge is the primary home for how that business-facing contract is defined and kept consistent across systems — see Enterprise Knowledge overview and Business metadata.
Example
A Role Assistant requests contract.checkRenewalRisk for an in-scope customer. Operational Trust confirms the identified person, role, dimensions, certification, and policy. Only then does execution proceed — with audit and evidence recorded.
Business value
Governed capabilities make AI actions accountable, auditable, and aligned with business vocabulary instead of vendor-specific APIs — under existing enterprise authority.