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

How to set

1. Complete field mappings — capabilities without metadata produce empty AI context.

2. 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.

3. Repair expose flags when scaffold left datasources unpublished:

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

4. Upload:

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

5. Test execution path:

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

6. Align RBAC — Configure roles and permissions permission names match exposed keys.

7. 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
    }
  ]
}

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

Defaults and examples

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

Root identity fields required before exposed compiles:

Authoring an upsert candidate

aifabrix datasource capability upsert <file-or-key> --dry-run --json previews
composition from existing create/update capabilities, business identity and an
exact lookup in the materialized vendor contract. Static success means a
candidate was authored, not that writes are safe. Validate the resulting
manifest and prove identity lookup, first write, repeated write without a
duplicate, and cleanup through the full datasource E2E scenario. Do not filter
that proof to the single upsert operation. Retain source limitations until the
actual production transport and caller scope pass.

Validate

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

Common mistakes

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.