Certification

Enterprise AI Certification is durable qualification evidence for a Connected System candidate: operations, agent metadata trust, governance, and the lifecycle report. Select the required checks on upload; deploy consumes qualified current input rather than rerunning the ladder in the client.

Prerequisites

• Green local validate and a terminal successful upload qualification result
• Integration and protection uploaded; scoped subject user for governance
• Test ladder understood

Where it lives

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

Static custom packages (syncBridge disabled) skip live E2E inside verify-operations — this is a skip, not a FAILED verdict. There is no flag to force live E2E on a static custom package; the operations pillar still runs validate, unit, and integration checks for it.

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

1. Validate and upload the current candidate:

aifabrix validate <systemKey>
aifabrix upload <systemKey> --gate full --subject-email scoped-user@example.com

The CLI waits by default. upload --no-wait returns a job id; upload --resume <jobId> returns to that same job. A terminal timeout or Ctrl-C detaches without cancelling server qualification.

2. Inspect or diagnose individual pillars when needed:

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

For a narrower policy, select only the required checks on upload:

aifabrix upload <systemKey> --gate operations,trust
aifabrix upload <systemKey> --gate governance --subject-email scoped-user@example.com
aifabrix upload <systemKey> --gate full --subject-email scoped-user@example.com

Plain upload does not run these optional checks. Do not select governance until protection, identity, and scenario-pack prerequisites are available. Re-upload changed content to requalify it; a standalone pillar command is diagnostic evidence, not a replacement for current-candidate qualification.

3. Optional auto-fill gaps:

aifabrix lifecycle <systemKey> --run

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

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

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-upload and requalify the changed candidate when auth, fieldMappings, dimensions, or vendor APIs change — do not rely on a prior trust result 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.

Requalify after protection manifest batch uploads when they change the candidate's governance proof — old results may be stale even when integration JSON is 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 the upload job and pillar evidence with the same release tag so auditors can correlate qualification and promotion without re-running expensive E2E suites.

The supported qualification contract does not itself prove cross-system live reload reliability in every current environment; that acceptance work remains open. Treat a specific job's result as its scope of evidence, not a blanket connector guarantee.