Governed capabilities

Publish business capabilities (<resourceType>:<operation>) from datasource exposed config so Role Assistants and Enterprise MCP use governed keys — not raw vendor APIs.

Prerequisites

Datasource JSON with resourceType, fieldMappings, and operations defined
Entity basics, types, and resource type registered in catalog

Where it lives

Location	Purpose
Datasource JSON	`exposed` block — which operations publish as capabilities
Upload/compiler	Dedupes into enterprise capability keys online
RBAC	`rbac.yaml` permissions match capability names

How to set

Complete field mappings — capabilities without metadata produce empty AI context.
Configure exposed on datasource JSON:

{
  "exposed": {
    "enabled": true,
    "autoRbac": true,
    "openapi": {
      "operations": {
        "listCompanies": {
          "method": "GET",
          "path": "/crm/v3/objects/companies"
        }
      }
    }
  }
}

With autoRbac: true, permissions default to <resourceType>:<operation> when operations lack explicit scopes.

Repair expose flags when scaffold left datasources unpublished:

aifabrix repair <systemKey> --expose --dry-run
aifabrix repair <systemKey> --expose
aifabrix validate <systemKey>

Upload:

aifabrix upload <systemKey> --probe
aifabrix upload <systemKey>
aifabrix show <systemKey> --online

Test execution path:

aifabrix test-integration <systemKey>
aifabrix datasource test-e2e <datasourceKey> --app <systemKey> --test-crud

Align RBAC — Configure roles and permissions permission names match exposed keys.
Document capability metadata on each datasource — business descriptions and Role Assistant placeholders:

{
  "capabilities": [
    {
      "key": "list",
      "description": "List customer records with governance filters applied.",
      "riskLevel": "low",
      "approvalRequired": false
    },
    {
      "key": "update",
      "description": "Update customer attributes in the external CRM.",
      "riskLevel": "high",
      "approvalRequired": true
    }
  ]
}

Field	Integrator note
`description`	Non-empty for every exposed operation — `verify-trust` fails sparse metadata
`riskLevel`	`low` \| `medium` \| `high` \| `critical` — signals certification and Role Assistant review
`approvalRequired`	When true, document expected approval path in business concept pages

High-risk capabilities without descriptions or with approvalRequired: true on undocumented flows surface as highRiskCapabilityWithoutApproval or trust warnings during verify-trust.

Defaults and examples

Practice	Reason
Business keys (`customer:search`)	Auditors understand logs
One outcome per capability	Easier certification
Avoid vendor names in keys	Survives API swaps
E2E with `--test-crud` before certify	Proves execution, not schema only

Custom transforms belong in CIP execution — capabilities remain the governed entry point.

Root identity fields required before exposed compiles:

Field	Capability impact
`resourceType`	Permission prefix (`customer:read`)
`entityType`	Execution/sync path
`externalId`	Governed search joins
`fieldMappings`	Agent metadata trust

Validate

aifabrix validate <systemKey>
aifabrix upload <systemKey> --probe
aifabrix verify-operations <systemKey>
aifabrix verify-trust <systemKey>

Common mistakes

Mistake	Fix
Exposed without field mappings	Complete mappings first
Upload skipped after JSON edits	`upload --probe`
Raw OpenAPI paths to AI	Use compiled capability keys via Enterprise MCP
RBAC names mismatch	Prefix with datasource `resourceType`

Limits

Compiler output and online capability keys depend on upload environment and schema version — verify with show --online after publish.

Each capability assumes datasource root fields are valid — key, displayName, systemKey, entityType, resourceType, primaryKey, and indexed externalId. autoRbac generates permission names from resourceType — mismatched catalog keys break governance even when validate passes. Run verify-trust after exposed changes — agent metadata tests depend on field mappings, not capability names alone. Use show --online to confirm compiled capability keys match rbac.yaml permission strings before verify-governance.

MCP exposure reuses compiled capability keys — publishing raw OpenAPI operation ids to agents bypasses Operational Trust even when exposed.enabled is true locally.

Prefer one governed outcome per resourceType operation so certification logs remain auditable; bundle complex vendor calls behind CIP when multiple HTTP steps are required.

Online compiler dedupes duplicate operation keys across datasources — use distinct resourceType values per entity file to avoid permission collisions in rbac.yaml.

Changing exposed without re-upload leaves Enterprise MCP tools stale — always pair JSON edits with upload --probe and show --online before verify-trust.

Capability names visible to operators come from displayName and compiled keys — keep business vocabulary consistent across datasources sharing related resourceType prefixes.

Operations certification requires live vendor mutation when --test-crud is enabled — read-only sandboxes may pass trust while failing operations until CRUD-capable tenants are provisioned.

Treat autoRbac as a convenience default — explicit permission names in rbac.yaml remain the audit source of truth after first upload.

Documentation Index