Validation proves that metadata, schemas, mappings, access logic, and capabilities behave as expected. Certification turns validation and governance outcomes into enterprise readiness — proof that a system, datasource, or capability is ready for AI-assisted work.
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.
Why it matters
Enterprises cannot safely expose AI to integrations that have not been tested against business rules. Validation catches misconfiguration before production use. Certification makes readiness visible to architects, developers, and operators — across operations, agent metadata trust, and governance.
How it works
Configure integration → Validate rules and behavior → Certify readiness → Allow governed AI use
Validation checks include schema correctness, field mappings, dimension behavior, capability definitions, and test execution against real or sandbox systems.
Enterprise AI Certification (three pillars)
After upload, the Builder CLI runs three certification pillars in recommended order:
| Command | Pillar | What it proves |
|---|---|---|
verify-operations |
Operations | Validate → test → integration → E2E for each datasource |
verify-trust |
Agent metadata trust | Business metadata is complete and trustworthy for AI agents |
verify-governance |
Governance | Subject-scoped ABAC visibility matches policy expectations |
Then read the consolidated lifecycle report in the Builder CLI (see Certification for the command ladder).
Certification sync can refresh status in the local system file when online. Certification is readiness proof, not a guarantee of zero risk.
Granular validate, test, and repair commands remain for step-by-step debugging on the configure track.
Operators should treat failed governance certification as a release blocker for Role Assistant tasks that depend on the affected datasource or protection scope.
When operational trust gates are enabled on the deployment, certification outcomes also enforce publish, runtime, and AI exposure paths — see Operational trust gates.
When to recertify
Re-run certification when integration manifests change materially: new datasources, dimension key changes, protection scenario updates, authentication method changes, or vendor API upgrades that alter field mappings.
Architects document which environments require full three-pillar certification versus operations-only checks for hotfixes. Production Role Assistant scope should always include governance verification for subject-scoped data access.
Evidence from certification reports belongs in operational records alongside change tickets — not only in developer workstations.
Executives should see certification as evidence of readiness for a scope — which integrations, roles, and capabilities are approved for AI-assisted work in each environment.
Separate validation (configuration correctness) from certification (enterprise readiness decision). Teams may validate frequently in development while certifying only before production Role Assistant use.
Board and risk stakeholders care about governance pillar outcomes — subject-scoped visibility proofs — as much as operational test passes.
Example
Before a customer-search capability is available to a Sales Assistant, the underlying datasource passes validation (mappings, dimensions, test payloads) and certification pillars. Uncertified or failing sources remain blocked or limited until remediated.
Business value
Validation and certification reduce production surprises, make AI-ready systems visible, and support governance reviews with evidence of readiness — not ad hoc checklists.