Operational Trust and Enterprise Knowledge share one idea: AI must reason about business entities (customer, contract, document), not vendor object codes. Resource types are the catalog names that make that translation enforceable.
Why it matters
Integrations expose technical schemas — contacts, deals, driveItems. Without a business layer, governance rules cannot say “Sales Managers see customers in EMEA.” Resource types connect datasource manifests to the same vocabulary architects use in policies, dimensions, and Role Assistant capabilities.
How it works
Vendor object → field mappings → resourceType (catalog key)
↓
Capabilities (customer.list, deal.reviewPipeline)
↓
Roles + dimensions + protection
| Layer | Question it answers |
|---|---|
| resourceType | What business entity is this datasource? |
| entityType | How is it stored (record, document, vector, message)? |
| Capabilities | What actions may AI request on that entity? |
| Certification | Is metadata trustworthy for agents? |
Architects approve catalog keys (customer, deal, document) before integrators publish. Changing a resource type after certification triggers re-validation — capabilities and governance tests depend on stable names.
Trust lens vs integrator checklist
This page is the trust and architecture view. Integrators implement resource types in manifests, run catalog commands, and link resourceType in Business Entity JSON on Entity basics, types, and resource type.
Architects review:
- One primary resource type per datasource (avoid mixed semantics)
- Alignment between CRM “account” and CLM “customer” when linking systems
- Capability naming that matches resource types (
customer:*not vendor paths)
Example
A deal datasource uses resourceType: deal. Pipeline capabilities use deal.reviewPipeline. Governance certification proves a Sales Manager in Nordics sees only deals whose dimension fields match their scope — because deals and customers share consistent resource types and foreign keys.
Common mistakes
| Mistake | Impact |
|---|---|
| Skipping catalog registration | Validate fails or capabilities compile to opaque keys |
| Reusing resource type for unlike objects | Wrong governance scope |
| Linking systems without shared identifiers | Cross-system relationships break silently |
Business value
Shared business entity names make policies portable across systems — the foundation for trustworthy AI at enterprise scale.
Limits
Catalog contents and required fields evolve with platform releases — confirm current catalog behavior on the configure track before locking enterprise standards.