Purpose
A Connected System can be connected but not ready for AI-assisted work. Operational trust gates make certification enforceable: when enabled, the platform blocks publish, promotion, execution, or AI exposure until a Business Entity is trust-ready — so Role Assistants only consume published, certified scope.
Gates enforce readiness. Runtime Operational Trust still decides whether this identified person may proceed now — certified does not mean currently authorised. When authority cannot be verified, work stops safely.
This article relates gates to Validation and certification and Role Assistants, Evidence, and governed execution.
Why it matters
Integrators may upload manifests; operators may see datasources in the UI — yet Role Assistants must not compile capabilities from entities that fail trust evaluation.
Trust gates make that boundary enforceable in production-like environments instead of relying on manual discipline alone.
Business stakeholders should expect:
- Uncertified or failing Business Entities do not feed Role Assistant capability catalogs when gates are on
- Publish and runtime paths return clear deny reasons rather than silent partial behavior
- Certification is the readiness proof; gates are the platform enforcement
Integrators run certification on the Build certification track.
Deployment settings (portal)
Platform operators configure trust posture through deployment portal inputs (labels vary by installer). Typical settings:
| Setting | Business effect |
|---|---|
| Trust policy level | Default strictness when no explicit policy matches: strict, standard, or relaxed |
| Publish gate | Blocks Business Entity publish when trust evaluation denies the datasource |
| Promote gate | Blocks Connected System publish/promote until active datasources pass trust at promote scope |
| Runtime gate | Blocks CIP capability execution and Role Assistant generation inputs when trust fails at runtime scope |
| AI exposure gate | Blocks AI document-storage prompt generation when trust fails at AI exposure scope |
In development, gates are often disabled so integrators can iterate quickly. Production-like and marketplace deployments typically enable publish, promote, and runtime gates so only certified scope reaches Role Assistants.
Your platform operator confirms which gates are active per environment — do not assume defaults from a lab tenant.
Trust scopes and when they apply
Each gate maps to a trust scope evaluated against a Connected System and Business Entity:
Integrator certifies → Upload / publish → Trust gate (if enabled) → Published online config
→ Role Assistant catalog → Runtime capability execution (authority checked again)
| Scope | Typical gate | What it protects |
|---|---|---|
| Publish | Publish gate | Prevents marking a Business Entity published when metadata trust fails |
| Promote | Promote gate | Prevents promoting a Connected System when child entities fail trust |
| Runtime | Runtime gate | Prevents capability execution and Role Assistant catalog / generation when trust fails |
| AI exposure | AI exposure gate | Prevents LLM prompt generation for document storage when trust fails |
Trust evaluation uses persisted certification artifacts and policy rules. Allowed or warned outcomes may proceed; deny or review outcomes block gated paths.
Relationship to certification
Gates enforce what certification proves. Integrators produce readiness evidence on the Build track; gates apply that evidence on product paths.
| Certification pillar | What it proves | Gate (platform) |
|---|---|---|
| Operations | Integration behavior | Indirect — test evidence feeds trust |
| Agent metadata trust | Metadata trustworthy for AI | Publish / promote / runtime / AI exposure when enabled |
| Governance | Subject-scoped visibility | Complements trust |
Certification is readiness proof for a scope. Trust gates are automatic enforcement so uncertified Business Entities cannot supply Role Assistant capabilities when gates are enabled. Runtime Operational Trust still fail-closes on current authority.
Integrators: Certification (build)
Operators: Operator overview
Impact on Role Assistants
Role Assistant capability catalogs compile from published Business Entities bound to the role’s subscriptions. When runtime trust gate is enabled:
- Entities that fail runtime-scope trust are excluded from generation inputs and Role Assistant datasource bindings
- Users do not receive “extra” capabilities from draft or failing integrations
- Administrators still Activate for AI per role — activation does not bypass trust gates
Only certified, published, trust-ready Business Entities contribute resource types and capability keys to the assistant catalog in gated environments.
See How Role Assistants are created and Role Assistants, Evidence, and governed execution.
Operator checklist
Before expanding Role Assistant scope or headcount:
- Confirm target Business Entities show published status in the dataplane UI
- Request integrator certification / lifecycle report — operations, trust, and governance green for the scope
- Confirm trust gates are enabled on production-like environments (ask platform operator)
- Treat trust deny on publish or task execution as a certification or metadata gap — not a user error
- Re-run certification after vendor API changes, dimension updates, or protection edits
Integrator checklist
Before expecting Role Assistant surfaces after upload:
- Green validate → test → end-to-end ladder
- Trust and governance certification for subject-scoped scope
- Consolidated lifecycle / readiness report
- Upload with publish; verify entity reaches published without trust deny
- In gated environments, confirm capabilities appear in assistant preview only after trust passes
Example
A CRM customer Business Entity passes validation in development with gates off. After promotion to a gated staging tenant, publish gate blocks publish until trust artifacts allow publish scope. Once published and runtime gate enabled, the Sales Manager Role Assistant catalog includes customer search and read from that entity only — not from a parallel draft datasource that failed trust.
Business value
Trust gates align business readiness with platform enforcement: executives and auditors see certification as more than a report — it is what the platform allows for AI-assisted work. Operators gain explainable deny paths instead of assistants that silently lack capabilities or over-reach from uncertified data.
Limits
- Exact portal input names and default values depend on deployment preset — operators configure through the installation portal, not integrator manifests.
- Additional publish-time checks (for example strict agent metadata publish gate) may apply separately from
TRUST_*gates — confirm with your platform operator. - Gates do not replace human Activate for AI or dimension/protection policy — they add a certification enforcement layer on product paths.