Purpose
Before AI systems automate work against enterprise data, operators and architects need confidence that business meaning, trust evidence, and live policy are aligned. Agent metadata trust is how AI Fabrix answers that question without exposing raw vendor APIs or unconstrained tool access.
Integrators author business knowledge in datasource manifests. The platform validates that knowledge, publishes safe contracts, and returns per-request context so agents and Role Assistants act on governed capabilities — not guessed fields or hidden admin diagnostics.
Why it matters
Enterprises routinely fail AI pilots because models infer semantics from sample payloads. A field named status in one system may mean pipeline stage; in another it may mean compliance state. Without layered metadata, automation produces confident wrong answers, over-broad queries, or destructive actions that bypass approval.
Agent metadata trust separates concerns that are easy to conflate:
| Question | Where the answer lives |
|---|---|
| What did integrators declare? | Manifest configuration (authoritative semantics) |
| Is it fit to trust? | Validation evidence (generated, not config) |
| What may agents discover at design time? | Published OpenAPI and MCP contracts |
| What happened on this request? | Runtime response context |
| What are the business facts? | Normalized record metadata after mapping |
Trust before automation: check validation outcomes and certification pillars before customer-facing agents or Role Assistants depend on a datasource.
Refuse or escalate when trust is notTrusted — do not compensate with larger prompts or broader capability exposure.
How it works — five metadata layers
AI Fabrix exposes datasource business knowledge through five layers. Each layer answers a different question; agents must not assume one layer contains everything from another.
What this shows: how manifest configuration, validation, published contracts, runtime context, and record metadata relate — each answers a different question.
What this is not: a CLI ladder, manifest field reference, or certification command list. Those live on configure and publish articles.
%%{init: {
"theme": "base",
"themeVariables": {
"fontFamily": "Poppins, Arial Rounded MT Bold, Arial, sans-serif",
"fontSize": "16px",
"background": "#FFFFFF",
"primaryColor": "#F8FAFC",
"primaryTextColor": "#0B0E15",
"primaryBorderColor": "#E2E8F0",
"lineColor": "#E2E8F0",
"textColor": "#0B0E15",
"borderRadius": 16
},
"flowchart": {
"curve": "linear",
"nodeSpacing": 34,
"rankSpacing": 34,
"padding": 10
}
}}%%
%% diagram-type: connection-map
flowchart LR
classDef base fill:#FFFFFF,color:#0B0E15,stroke:#E2E8F0,stroke-width:1.5px;
classDef medium fill:#1E3A8A,color:#ffffff,stroke-width:0px;
classDef primary fill:#0062FF,color:#ffffff,stroke-width:0px;
A["A — Manifest"]:::medium
B["B — Validation"]:::medium
C["C — Published contract"]:::medium
D["D — Runtime context"]:::medium
E["E — Record metadata"]:::primary
A -- "declares" --> B
A -- "feeds" --> C
B -- "gates publish" --> C
C -- "bounds discovery" --> D
D -- "returns facts" --> E
Configure next: Agent metadata and trust (configure)
Layer A — manifest configuration
The integrator-authored source of truth for field meaning and exposure. Structured fields include filterable field lists, business ordering across datasources in one system, semantic descriptions on attributes, capability keys with human-readable descriptions, resource type catalog keys, and optional runtime enrichment flags.
Do: read manifest semantics when designing prompts or explaining fields before live calls.
Don't: infer field or operation meaning from sample payloads instead of manifest capability descriptions and resource type catalog keys.
Layer B — validation evidence
Persisted separately from configuration. Surfaces a safe subset only: trust decision, confidence, validation status, timestamps, and high-level warnings. Full findings and observed business models remain admin-only — they do not appear on public contracts or routine runtime responses.
Do: gate bulk automation on trustDecision; escalate on notTrusted.
Don't: assume validation rows replace manifest edits — integrators apply recommended fixes explicitly.
Layer C — published contract
Design-time discovery through REST and MCP OpenAPI. Extensions describe intent, safe retry hints, side effects, recommended sequences, filterable fields aligned with manifest lists, and per-datasource validation summaries. Dangerous operations are derived from capabilities and execution shapes — not maintained as a parallel override list.
Do: discover operations and permissions from published contracts before calling.
Don't: invent filter fields absent from the published filterable list.
Layer D — runtime context
Every successful governed response includes baseline tracing, capabilities, governance, and integration summaries. When runtime enrichment is enabled, additional business blocks echo ordering, recommended filters, dangerous operations, and capped semantic fields. Error responses omit business and validation blocks.
Do: use capability and policy evaluation context on every call.
Don't: assume runtime context includes the full manifest or admin validation findings.
Layer E — record metadata
Normalized storage fields after integration pipeline mapping. This is the answer set for business questions — not vendor raw JSON.
Do: answer users from metadata keys present in authorized responses.
Don't: expose or guess fields omitted by schema exposure or authorization.
Trust and governed capabilities
Role Assistants and external AI agents do not receive open API access. They request governed business capabilities compiled from integrator definitions. Agent metadata layers feed that compilation: manifest semantics become enterprise capability meaning; validation evidence gates publish; published contracts bound discovery; runtime context enforces per-request policy.
Read Governed capabilities, not agents for the Role Assistant boundary story. Certification's trust pillar evaluates whether business metadata is sufficient for AI-assisted use — operations and governance pillars prove runtime and access scope separately.
Example
A sales operations team connects a CRM and a document library. Before enabling a Role Assistant:
- Integrators complete semantic descriptions on primary keys, label fields, and filterable attributes.
- Validation runs after manifest changes; trust must not be
notTrusted. - Architects confirm published contracts list the same filterable fields agents will use.
- Operators require green verify-trust (and full certification ladder) before pilot activation.
An agent that skips layer B and guesses filter names from sample JSON will eventually query fields users cannot access — or worse, fields that do not mean what the model assumes.
Business value
Layered metadata turns integration work into durable business knowledge instead of prompt engineering debt. Security teams gain explainable gates. Operators see certification evidence. Role Assistant owners activate Role Assistants only after trust, operations, and governance pillars align on a declared scope.
Limits
Validation profiles, extension names, and optional runtime enrichment flags evolve with platform releases. This article describes the model — not your tenant's manifest or certification profile requirements.
Enterprise compilation and enterprise context aggregates add cross-system maps between manifest facts and Role Assistant discovery. Confirm your deployment generation before automating against optional enrichment flags.