Certification

Run the Enterprise AI Certification ladder after upload — operations, agent metadata trust, governance, and lifecycle report.

Continuous Certification

Certification runs automatically whenever capabilities, policies, integrations, or AI-exposed behavior changes. AI changes too quickly for manual certification processes. Certification is part of promotion readiness and operational trust.

See also Validation and certification for the business framing and Operational trust gates for how certification is enforced on publish and runtime paths.

Prerequisites

Green validate + upload (upload --probe then publish)
Integration and protection uploaded; scoped subject user for governance
Test ladder understood

Where it lives

Pillar	Command	Proves
Operations	`verify-operations`	validate → test → integration → E2E
Agent metadata trust	`verify-trust`	Business metadata for agents
Governance	`verify-governance`	Subject-scoped ABAC keys
Report	`lifecycle`	Consolidated certification summary

Certification evaluates published online config — local-only JSON does not certify.

Green certification is required before Role Assistants compile capabilities from Business Entities in production-like environments. See Role Assistants, Evidence, and governed execution for how certified scope feeds assistant catalogs.

How to set

Upload and test base:

aifabrix upload <systemKey> --probe
aifabrix upload <systemKey>
aifabrix test-integration <systemKey>
aifabrix test-e2e <systemKey>

Run pillars in order:

aifabrix verify-operations <systemKey>
aifabrix verify-trust <systemKey>
aifabrix verify-governance <systemKey> --subject-email scoped-user@example.com
aifabrix lifecycle <systemKey>

Optional auto-fill gaps:

aifabrix lifecycle <systemKey> --run

Refresh local state when online changed:

aifabrix validate <systemKey> --cert-sync
aifabrix download <systemKey>

Fix failures in the phase where they originate — governance failures rarely resolve by re-running trust alone.

Defaults and examples

Pillar	Typical prerequisite
Operations	Credentials + E2E green
Trust	`fieldMappings`, `resourceType`, `exposed` uploaded
Governance	Dimensions + protection + identity sync

Illustrative datasource identity checked by trust pillar:

{
  "key": "example-customers",
  "displayName": "Customers",
  "systemKey": "example-crm",
  "entityType": "recordStorage",
  "resourceType": "customer",
  "primaryKey": ["externalId"]
}

Never treat verify-trust alone as full certification.

Validate

aifabrix lifecycle <systemKey>

Review CLI output and dataplane UI certification signals before Role Assistant pilots.

Common mistakes

Mistake	Fix
verify-trust only	Full ladder
Certify before upload	`upload --probe` first
Admin subject for governance	Scoped test user
Skip E2E	Operations pillar fails at runtime

Limits

Certification profiles and scenario pack contents evolve — --certification-profile bronze is the default starting point; production may require stricter profiles per org policy.

Governance pillar requires live protection and dimension catalog state — uploading integration JSON without protection upload produces false confidence until verify-governance runs with a scoped subject.

Re-run all three pillars when auth, fieldMappings, dimensions, or vendor APIs change — not verify-trust alone.

Bronze profile success in dev does not automatically satisfy production governance policies — confirm required certification profile with your platform operator before Role Assistant pilots in regulated environments.

Archive lifecycle CLI output with release tags — auditors compare pillar timestamps with upload records when investigating scope incidents.

Subject-scoped governance proof requires a real business role mapping — using the integration developer's platform admin email always passes connectivity checks but fails the intent of the governance pillar.

Schedule certification reruns after protection manifest batch uploads — governance pillar results become stale even when integration JSON unchanged.

Bronze profile artifacts are starting points — capture lifecycle JSON in CI for trend analysis across weekly integration builds.

Operations pillar failures after green validate usually mean stale vendor credentials or missing execution blocks — fix auth and CIP before re-running trust or governance.

Production promotion may require stricter profiles and additional manual sign-offs beyond CLI lifecycle output — treat certification commands as necessary but not sufficient for regulated go-live.

When lifecycle --run auto-remediates gaps, re-download local JSON before the next manual edit — online auto-fixes can overwrite in-flight git changes if teams skip show --online diffs.

Trust pillar success with failing governance usually means dimensions or protection manifests are incomplete — re-run subject-scoped verify-governance after every protection batch upload, not only after integration JSON edits.

Archive pillar CLI logs with the same release tag as upload artifacts so auditors correlate publish time with certification evidence without re-running expensive E2E suites.

Documentation Index