Purpose
This article explains the full loop that makes Role Assistants different from prompt-first agents: the platform generates a candidate from enterprise definitions, performs work through governed capabilities under Operational Trust, and captures Evidence for learning — without maintaining static workflow diagrams.
Evidence may propose improvement; it cannot silently change a released Role Assistant. A material change creates a new candidate and returns through validation, testing, certification, and human approval.
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 |
| Silent prompt edits after production use | Propose → new candidate → validate → Make available |
Without this loop, Role Assistants look like chatbots with extra RBAC. With it, they become human-owned, role-scoped capabilities on published business entities — and the catalog stays current because generation re-reads published (and trust-gated when enabled) Business Entities rather than editing per-user tool lists. How membership works: How Role Assistants get capabilities.
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 product SSOT for membership, list vs execute, and operator limits is How Role Assistants get capabilities. Creation and Make available: How Role Assistants are created.
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? | Published Business Entity capabilities that still pass Operational Trust for the request — list presence is not enough |
Learning from evidence and task intent stay correct because the active role bounds the catalog — skill growth does not widen permissions.
Integrator declaration (summary)
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 Configure AI contract and Entity basics, types, and resource type.
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 governed surface. The protocol is open; limits are governance, not product caps — every path enforces Operational Trust, certification, and audit the same way.
Governed execution loop
Enterprise Runtime evaluates each next step from current governed context (execute, wait, complete, or stop safely) — not a fixed BPM workflow:
Intent → Task → Business Role → Enterprise Knowledge → Planning evidence → Operational Trust
→ Capability request → governed execution → Outcome evidence → Propose improvement
| 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, Business Role, dimensions, certification state, trust gates |
| Execute | Capability runs through the governed boundary — not direct vendor API access |
| Capture | Outcome evidence written from terminal task states (including deny and safe stop) |
| Propose | Findings may start a new candidate — they do not edit the released assistant |
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.
Work-step value and operator evidence
Completed work records more than a final status. A business step log can show what happened, the value created, and what AI identified, while preserving honest outcomes when work failed, was denied, expired, or is waiting. Assistants list and detail views give operators a broader evidence and trust surface; Work keeps the business result focused on the current objective.
See Business value from work steps and Conversation-first work.
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 Role Assistant planning features are enabled before treating planning evidence as operational policy.
- Production-like assistants require published Business Entity capabilities; when trust gates are enabled, trust-failed entities do not contribute. External MCP clients inherit the same execute-time enforcement.
- Integrator commands and manifest fields live under Build AI-ready systems and Certification.
Related reading
- How Role Assistants get capabilities — catalog membership SSOT
- 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