Purpose
Operational trust gates connect certification to runtime behavior. When enabled on a deployment, the platform blocks publish, promote, execution, or AI exposure until a Business Entity passes operational trust evaluation — so Role Assistants and AI clients only consume published, trust-ready integrations.
This article explains the gates in business terms and how they relate to Validation and certification and Role Assistants, Evidence, and governed execution.
Why it matters
A Connected System can be connected but not ready for AI-assisted work. 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 (
TrustPolicyDenied) rather than silent partial behavior - Certification CLI (
verify-trust,lifecycle) is the integrator proof; gates are the platform enforcement
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 (CLI) → Upload / publish → Trust gate (if enabled) → Published online config
→ COM compile / Role Assistant catalog → Runtime capability execution
| 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 CIP execution and workforce generation bindings 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. Decisions of ALLOW or WARN permit the operation; DENY or REVIEW block gated paths.
Relationship to certification
Gates enforce what certification proves:
| Certification pillar | CLI (integrator) | Gate (platform) |
|---|---|---|
| Operations | verify-operations |
Indirect — E2E and test evidence feed trust |
| Agent metadata trust | verify-trust |
Publish / promote / runtime / AI exposure when enabled |
| Governance | verify-governance |
Subject-scoped ABAC proof; complements trust |
| Summary | lifecycle |
Consolidated readiness report |
Certification is readiness proof for a scope. Trust gates are automatic enforcement on product paths so uncertified Business Entities cannot supply Role Assistant capabilities when gates are enabled.
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 (COM compile and digital-worker 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
lifecyclereport — operations, trust, and governance pillars green for the scope - Confirm trust gates are enabled on production-like environments (ask platform operator)
- Treat
TrustPolicyDeniedon 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 manifest edits
Integrator checklist
Before expecting Role Assistant surfaces after upload:
- Green validate → test → E2E ladder
verify-trustandverify-governancefor subject-scoped scopelifecycleconsolidated 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 verify-trust artifacts show ALLOW for publish scope. Once published and runtime gate enabled, the Sales Manager Role Assistant catalog includes customer:search and customer:read from that entity only — not from a parallel draft datasource that failed trust.
Business value
Trust gates align business readiness with technical enforcement: executives and auditors see certification as more than a CLI 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.