Purpose
This article explains the full loop that makes Role Assistants different from prompt-first agents: the platform compiles enterprise knowledge, plans work using resource-scoped evidence, executes through governed capabilities under Operational Trust, and captures outcome evidence for learning — without maintaining static workflow diagrams.
Read this when you need one story that connects Role Assistants, Evidence Fabrix, and Operational Trust.
Why it matters
Most enterprise AI asks employees to re-describe the business on every request. AI Fabrix instead compiles what the enterprise already knows and learns what it cannot fully define upfront from governed outcomes.
That split is the differentiator:
| Traditional AI | AI Fabrix |
|---|---|
| Workflow-centric | Resource-centric |
| Prompt and tool lists | Compiled roles, resource types, capabilities |
| Approve individual API calls in isolation | Approve the proposed process when policy requires |
| Chat memory as “learning” | Evidence from completed governed work |
Without this loop, Role Assistants look like chatbots with extra RBAC. With it, they become role-scoped operators on certified business entities — and the catalog stays current because only published, certified capabilities compile in; when trust fails or a new system joins, operators re-certify and the platform recompiles rather than editing per-user tool lists.
The five compiled primitives
AI Fabrix builds Role Assistants from five enterprise primitives (see also Business context replaces prompts):
| Primitive | Business meaning | Role Assistant use |
|---|---|---|
| Resource types | What business objects exist (Customer, Deal, Deployment, Contract) | Scope tasks and evidence retrieval |
| Dimensions | Who may see which slice (country, department, project) | Bound context and capability scope |
| Capabilities | Governed actions (customer:search, deal:update) |
Only execution surface — not raw APIs |
| Business outcomes | What success looks like for a role | Task objectives and improvement targets |
| Evidence | Planning expectations + outcome proof | Plan work and learn after completion |
Compile what exists. Learn what does not. Metadata, relationships, permissions, and exposed capabilities come from certified integrations. Patterns that emerge in production become evidence suggestions — not silent prompt edits.
Two evidence modes
Evidence Fabrix serves two complementary modes. Both are resource- and capability-scoped; neither is chat history.
Planning evidence (operational expectations)
Planning evidence describes how work involving a resource type is normally performed — in business language, not workflow XML.
Each item typically includes:
| Field | Meaning |
|---|---|
| Resource type | Customer, Deal, Deployment, Contract, … |
| Role (optional) | Business role the expectation targets |
| Order | Preferred planning sequence |
| When | Situation in natural language (for example “Deal amount exceeds threshold and status is Approved”) |
| Expected behavior | What should happen in that situation |
| Approval | Whether the proposed process requires human approval before execution continues |
| Status | Active or disabled |
Example (Deal):
| Order | When | Expected behavior |
|---|---|---|
| 10 | Amount exceeds policy threshold | Procurement review before purchase |
| 20 | Stage is Closed Won | Create onboarding task |
| 30 | Region requires compliance check | GDPR validation step |
When a user starts a task, the assistant identifies the primary resource type, retrieves relevant planning evidence only (environment, role, status, semantic match to the objective), and assembles a dynamic execution plan. No pre-authored workflow engine is required.
Process approval: When evidence requires it, a human approves that the proposed sequence of steps is correct — not each capability call in isolation. After approval, the assistant continues through governed execution automatically.
Outcome evidence (completed work)
Outcome evidence records what happened after governed execution — the mode described in Evidence Fabrix overview:
- Task objective and active role
- Business context and policies applied
- Capabilities requested and results
- Denials, corrections, approvals
- Patterns for operational memory and skill growth
Outcome evidence feeds Learning from completed work. It does not expand permissions or remove approval requirements.
How Role Assistants get resource types and capabilities
Role Assistants do not let users pick capabilities at activation. The platform compiles a catalog from certified integrations — and recompiles when published metadata or trust state changes.
Why business-role binding
| Question | Answer |
|---|---|
| Why bind to a business role? | Intent, planning evidence, and outcome evidence are role-scoped — a Sales Manager assistant must not inherit Contract Steward scope |
| Why not user-picked tools? | Capabilities change when systems join, certifications lapse, or vendor APIs drift — manual lists are too slow and unauditable |
| What may execute? | Only capabilities from published Business Entities that pass operational trust for the relevant scope |
Learning from evidence and task intent stay correct because the active role bounds the catalog — skill growth does not widen permissions.
Compilation path
Connected System + Business Entities (manifests)
→ upload / publish (status = published)
→ operational trust evaluation (when trust gates enabled)
→ Enterprise Knowledge composition (role subscriptions)
→ Role-scoped capability catalog (resourceType + actions)
→ Admin Activate for AI
→ User receives {Role} Assistant
→ Recompile when publish, trust, or subscription scope changes
What integrators declare
On each Business Entity datasource manifest:
resourceType— business vocabulary key (for examplecustomer,deal,document)capabilities/exposed— governed keys the entity exposes (read,search,create, …)- RBAC role bindings — which business roles may use those capabilities
See Governed capabilities (build) and Entity basics, types, and resource type.
What the platform compiles
Generation follows subscription filters (role keys and system kinds) — not hardcoded vendor names:
External systems → Datasources → Composition → Subscription filters
→ Role-scoped runtime → REST + MCP + OpenAPI → Activate for AI → User provisioning
Only published Business Entities contribute. When operational trust gates are enabled on the deployment, entities must also pass trust evaluation for the relevant scope before they appear in Role Assistant capability catalogs or COM compile inputs. Draft, uncertified, or trust-failed entities do not supply capabilities — there is no shadow catalog for power users.
Administrators Activate for AI per business role when metadata is ready. Users receive an assistant name and channel preferences — not a capability picker.
Multiple assistants and MCP (no artificial ceiling)
Complex programs use several Role Assistants (one per business role) and/or standard Enterprise MCP clients against the same certified surface. The protocol is open; limits are governance, not product caps — every path enforces Operational Trust, certification, and audit the same way.
Detail: How Role Assistants are created.
Governed execution loop
Runtime execution follows a fixed stack:
Intent → Task → Role → Enterprise Knowledge → Planning evidence → Operational Trust
→ Capability request → CIP execution → Outcome evidence → Learning
| Stage | What happens |
|---|---|
| Plan | Assistant uses role context, enterprise knowledge, and retrieved planning evidence to propose steps |
| Process approval | Optional human gate on the proposed plan (evidence-driven) |
| Trust | Identity, role, dimensions, certification state, trust gates |
| Execute | Capability runs through CIP — not direct vendor API access |
| Capture | Outcome evidence written asynchronously from terminal task states |
Capability risk level on the resource type catalog provides a baseline when no planning evidence applies:
| Risk level | Default behavior when no evidence matches |
|---|---|
| Low | Execute when trust checks pass |
| Medium | Execute; clarify if confidence is low |
| High | Process or capability approval typically required |
| Critical | Human approval always required |
Planning evidence refines the plan; risk level remains the minimum safety floor.
See Governed work execution and Governed capabilities, not agents.
Why this works with large language models
LLMs reason best with small, relevant context. Evidence Fabrix retrieves only evidence tied to the current resource type, role, and objective — not hundreds of workflow rules.
The model combines business expectations into a plan; the platform enforces permissions, trust gates, capability authorization, and audit. Chat transcripts are not the system of record.
Example
Objective: Deploy a new integration to production.
Primary resource type: Deployment
Planning evidence retrieved (examples):
- Production target → security review step
- Public API change → architect review step
- Critical capability → business approval on the proposed plan
Assistant proposes: build → test → security review → architect review → deploy.
An architect approves the process. The assistant then requests governed capabilities (deployment:validate, deployment:promote, …) through Operational Trust. Each outcome becomes outcome evidence for the next similar deployment.
Business value
Organizations maintain business rules and expectations — not prompt libraries or BPMN diagrams. Role Assistants stay aligned when permissions, systems, or capabilities change because the platform recompiles from certified metadata instead of asking each user to refresh a tool list. Proof accumulates by resource and capability for audit and continuous improvement.
Limits
- Planning evidence management UI and process-approval steps may roll out ahead of full operator self-service in some tenants. Outcome evidence, skill aggregation, and governed task execution are the primary live surfaces today.
- Confirm with your platform operator which Evidence Fabrix datasources and worker planning features are enabled before treating planning evidence as operational policy.
- Certified capabilities only is non-negotiable for production-like assistants — external MCP clients inherit the same enforcement.
- Integrator commands and manifest fields live under Build AI-ready systems and Certification.
Related reading
- Evidence Fabrix overview — outcome evidence, audit, skill growth
- Operational trust gates — publish, runtime, and AI exposure gates
- From integrations to Role Assistant — phased adoption path