Validation proves that metadata, schemas, mappings, access logic, and capabilities behave as expected. Certification turns those outcomes into enterprise readiness — proof that a system, datasource, or capability is ready for AI-assisted work in a defined scope.
Certification runs whenever capabilities, policies, integrations, or AI-exposed behavior changes. AI changes too quickly for one-off manual certification. 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, operators, and risk stakeholders — across operations, agent metadata trust, and governance.
Certified does not mean currently authorised. A conversation or a green report does not become operational truth by itself. Runtime Operational Trust still verifies the identified person, role, scope, and approvals for each case.
Certification of Connected Systems is one proof. It does not prove that a Role Assistant still completes the role’s work and gives correct governed answers for an identified person. Those are independent proofs before production — Proving Role Assistants. Agent SDK evals and encoded workflow graphs do not replace either proof.
How it works
Describe the business and integrations
→ Validate structure, permissions, and behavior
→ Certify readiness for a scope
→ Human approval / make available
→ Governed AI use (runtime checks continue)
Validation checks include schema correctness, field mappings, dimension behavior, capability definitions, and tests against real or sandbox systems.
Certification aggregates readiness across three pillars:
| Pillar | What it proves |
|---|---|
| Operations | Integration behavior against live or sandbox systems |
| Agent metadata trust | Business metadata is complete and trustworthy for AI |
| Governance | Subject-scoped visibility matches policy expectations |
For a Connected System, upload qualifies a particular candidate and records the proof durably. A managed deploy then promotes the qualified current candidate; it does not create new proof by repeating the whole test ladder at promotion time. Changed content must be qualified again. A closed terminal or expired interactive wait does not erase an in-progress upload job, and operators can return to its result. Qualification is evidence for the candidate and scope it checked, not a promise that every connector's live reload behavior has been accepted in every environment.
Integrators run the detailed command ladder and lifecycle report on the Build track — Certification. This page stays at the business meaning of readiness.
When operational trust gates are enabled, certification outcomes also enforce publish and runtime paths — see Operational trust gates.
Technical readiness vs business/semantic readiness
Technical readiness is whether the capability can execute safely and correctly: authentication, connectivity, schema validation, field mappings, and integration or end-to-end tests passing against real or sandbox systems.
Business/semantic readiness is whether the published interface accurately communicates what its resources, fields, relationships, measures, and operations mean to an AI reader — not only whether the underlying call succeeds. This is the same concern as the Agent metadata trust pillar above, named explicitly: business/semantic readiness and Agent metadata trust are one idea, not two separate pillars.
A datasource can pass every technical check — auth, connectivity, schema, mappings, integration tests, and live E2E — and still fail Agent metadata trust: an operation description that says nothing to an AI reader, a measure without a definition, or a test field name leaking into a business-facing contract. Certified does not mean semantically ready. Both technical readiness and Agent metadata trust must pass; a technical pass does not imply a semantic pass. See Business meaning as governed content for why business meaning is governed separately from the code and configuration that execute it, and Validate and test for how Connected System and Role Assistant proofs divide technical from business/semantic proof in practice.
When to recertify
Re-run certification when integrations change materially: new datasources, dimension key changes, protection updates, authentication changes, or vendor API upgrades that alter field mappings.
Production Role Assistant scope should include governance proof for subject-scoped data access. Evidence from certification belongs in operational records alongside change tickets — not only on 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 frequent validation in development from certification before production Role Assistant use.
Example
Before a customer-search capability is available to a Sales Assistant, the underlying datasource passes validation and certification for that scope. Uncertified or failing sources remain blocked or limited until remediated. Even after certification, each request still runs under Operational Trust for the identified person.
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.
Limits
Qualification proves the candidate and checks recorded by its job; it does not override per-request authorization or prove that all live connector reload paths have passed current-environment cross-system acceptance. Operators should inspect the job result and required policy evidence for the environment they promote into.