Role Assistants are built around tasks — units of business work with an objective, context, expected outcome, and evidence — not endless chat threads.
Why it matters
Conversations are poor units for enterprise accountability. Tasks connect work to roles, capabilities, approvals, results, and learning. They make “what was done” and “what happened” auditable for operators and compliance teams.
Evidence attaches to task outcomes, not chat transcripts. See Evidence vs conversation history.
How it works
Role → Role Assistant → Task → Governed Capability → Outcome → Evidence
A task includes:
| Element | Meaning |
|---|---|
| Objective | What business work is being performed |
| Context | Customer, project, contract, or other scoped entities |
| Capabilities | Governed actions the worker may request |
| Outcome | Accepted, corrected, rejected, escalated, or completed |
| Evidence | What was used, decided, and learned |
Workers may continue or create tasks; outcomes feed Evidence Fabrix for operational memory and skill growth.
Outcome states (conceptual)
- Completed / accepted — Human confirms result; evidence recorded
- Corrected — Human edits; learning signal without blame-only logging
- Rejected / escalated — Policy or human decision; still auditable
- Blocked — Capability denied; operator may need certification or role fix
Exact UI labels vary by deployment; the structural model is consistent.
Limits
Task lifecycle UI and automation depth vary by deployment. Core Role Assistant task APIs and evidence collection may be partial in some environments — check certification status for your platform version.
Example
A Project Assistant runs a “weekly status review” task: gathers project context, identifies risks, drafts recommendations, requests follow-up tasks through governed capabilities, and records outcome and evidence when the manager accepts or corrects the result.
Business value
Clear work units, measurable outcomes, and a path from assistance to provable business results.