Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

How Role Assistants get capabilities

Prev Next

Purpose

This page is the product story for how governed capabilities reach a Role Assistant, what operators can and cannot change, and the three different meanings of “available.” It is not a skill-tier guide and not an agent builder.

Generation produces a candidate catalog from published Business Entities. Make available is the operational release gate. Runtime allow still requires Operational Trust for each request — list presence is not authority.

Why it matters

Teams often confuse certifying a Connected System, generating a Role Assistant catalog (candidate), Make available, and runtime allow. Mixing those produces invented operator steps (assign capabilities, Activate for AI as a compile gate) and false expectations that anything listed on Assistants will always execute.

How it works

What a capability is on a Role Assistant

A capability is a business action key (for example customer.search) on a Business Entity surface that the platform generated for the Role Assistant. It is not a raw vendor API, not an LLM call or embed tool, and not a row operators add by hand.

How capabilities get onto the assistant

Published Connected System Business Entities
  → generation bindings (publish required; operational trust gates when enabled)
  → generated datasources on the Role Assistant (ra-{role} surface)
  → Assistants capability catalog

Typical triggers:

  • Business-domain Enterprise Knowledge publish or certify
  • Subscription-driven generation after a feeding Connected System publishes, changes runtime availability (available ↔ unavailable), or is archived
  • Operator refresh of generated assistants (re-reads the catalog — not a builder)

Publishing an LLM provider or regenerating unified LLM Enterprise Knowledge must not drive Role Assistant capability membership or lifecycle status. See Role Assistant status and availability.

Connected System available vs Role Assistant Make available

Control Owner Effect
Connected System / Business Entity runtime availability Integrator / operator on the feeding system Soft-off without archive. Unavailable systems are excluded from generation bindings after subscription-driven Enterprise Knowledge regen.
Connected System archive Operator soft-delete Soft-deletes the system; platform events drive regen so Role Assistant catalogs stop listing those entities.
Role Assistant Make available Operator on the assistant Clears Draft so an already-generated catalog can enter Active — does not publish or re-enable a Connected System.

Three meanings of “available”

Meaning What it answers
Role Assistant status Active The assistant is in service for the business role (after Make available when capabilities exist).
Listed on Assistants Operators can inspect the live catalog for that assistant. List presence is not a promise that every call succeeds.
May execute now Runtime still fail-closes through Operational Trust, RBAC/ABAC, certification, and allow-lists for that request.

Make available does not compile or assign capabilities. It only clears Draft so an already-generated catalog can enter Active (or Suspended if published with no live surface).

What operators do not do

  • Add, remove, enable, or assign capability rows on a Role Assistant
  • Treat Activate for AI role-readiness flows as the capability compile path
  • Expect list “Available” to mean every capability will execute for every user and task

Integrators declare capabilities on Connected System Business Entities. The platform generates the Role Assistant surface. Operators decide when Draft enters service.

Operational Trust and certification

Publish is required for an entity to contribute. When operational trust gates are enabled on the deployment, trust evaluation further gates which entities may be composed into Role Assistant generation. List views do not silently drop rows by certification tier alone; execute remains fail-closed.

How AI chooses among capabilities

Role Assistants and Enterprise MCP discover meaning from business descriptions on entity and capability metadata — not from guessing vendor operation names. Integrators rewrite technical import text into when-to-use / when-not language on the Build track: Configure AI contract.

What this shows: generation from published Business Entities into a Role Assistant catalog, separate from Make available and from runtime allow.

What this is not: a workflow engine, a per-user tool picker, or LLM provider setup.

Mermaid diagram

Example

A CRM companies entity publishes with customer.search and customer.update. Domain Enterprise Knowledge regenerate produces those keys on the Sales Role Assistant. The assistant stays Draft until an operator uses Make available. At runtime, a search may still be denied by dimension policy even though Assistants listed the capability as Available.

Business value

Capability membership stays auditable and current without per-user tool lists. Operators control who is in service; integrators own meaning; runtime owns allow.

Limits

  • Exact environment flags for trust gates vary by deployment — confirm with your platform operator.
  • This page does not replace certification ladders or CIP configure how-tos under Build AI-ready systems.