FactVerse AI Agent Core Concepts

FactVerse AI Agent is a governed tool and context layer for industrial workflows. Every useful workflow depends on tenant context, asset context, scopes, source references, and approval boundaries.

Runtime model

Client request
  -> MCP endpoint
  -> API key resolves tenant and scopes
  -> allowed tools
  -> FactVerse Platform, DFS, Designer, Inspector, knowledge, or simulation service
  -> response with source context and governance boundary

The client should discover available tools at runtime. The Tool Reference documents tool names, scopes, descriptions, and parameters for planning, while customer environment configuration and customer scopes decide what a key can actually call.

Tenant and asset context

The API key resolves the tenant. Once the tenant is resolved, each workflow should attach the relevant asset, site, facility, line, room, equipment, or scene context.

Good Agent outputs usually include:

• the asset or scene being discussed;
• the source systems used;
• the timestamp or freshness of the data;
• missing evidence or quality notes;
• whether the output is a draft, analysis, recommendation, or approved action.

Endpoints, slices, and scopes

FactVerse exposes tools through governed slices. Each slice has its own endpoint. Scopes decide which tools can be called.

Slice	Endpoint	Scope examples	Notes
Base	/mcp/base/	base.read, base.compute.run, base.action.write	General asset reads, knowledge, data quality, simulation, optimization, and approved write actions.
Predictive maintenance	/mcp/pdm/	pdm.read	Equipment health, summaries, anomalies, and component intelligence.
Traffic operations	/mcp/trafficops/	trafficops.read	People, vehicle, checkpoint, and traffic operation tools.
Telco operations	/mcp/telcoops/	telcoops.read	Network health and capacity tools.
Semiconductor operations	/mcp/semiops/	semiops.read	Cleanroom, fab, utility, SMT, and environment tools.
Aviation	/mcp/aviation/	aviation.analysis.read	Aviation reliability analysis tools.

Physical AI workflows use the current base and module endpoints together with scenes, simulation-ready asset packages, DFS-prepared operating data, and simulation services.

Tool calls and source references

Tool calls should be treated as governed access to product capabilities. A workflow should preserve enough source context for a human reviewer to understand why the Agent produced an answer.

For example:

• Facility operations should cite assets, meters, inspection records, and work orders.
• Predictive maintenance should cite signal history, data quality, asset history, and maintenance evidence.
• Physical AI should cite scene version, model asset version, component geometry, simulation assumptions, runtime parameters, and validation notes.

Data readiness

Agent quality is limited by source readiness. Before promising a workflow, confirm:

Area	Questions
Platform assets	Are assets, locations, ownership, and permissions modeled?
DFS data	Are source systems connected, transformed, and quality checked?
Inspector records	Are inspections, alarms, work orders, and operator notes available?
Designer scenes	Are scenes, assets, and relationships versioned and usable?
Documents	Are manuals, SOPs, and procedures accessible to the tenant and scope?

When data is missing, the Agent should report the gap and identify assumptions that cannot be confirmed.

Read, compute, and write boundaries

Use read scopes for investigation. Use compute scopes for simulation, optimization, forecasting, and comparison. Use write scopes only when the customer access policy allows controlled actions.

Write actions need extra care:

• they should be explicit, not hidden inside an analysis step;
• they should create drafts unless the customer has approved automation;
• they should be recorded in Inspector or the connected operation system;
• they should include enough evidence for a responsible operator or supervisor to approve.

Digital twins and simulation context

Digital twins in Agent workflows carry spatial context, asset relationships, behavior assumptions, and operational meaning.

Physical AI and simulation-oriented workflows should keep these items versioned:

• Designer scene;
• simulation-ready asset package;
• operational constraints;
• simulation configuration;
• validation result;
• field feedback.

This keeps fast simulation useful without overstating certainty. Engineering review and customer approval remain required before real-site changes.

Governance pattern

A complete workflow should follow this pattern:

1. Resolve tenant, asset, endpoint, and scope.
2. Retrieve allowed data, documents, scenes, and tools.
3. Produce analysis with source references and assumptions.
4. Keep write actions behind approval and audit.
5. Record completed work and field feedback.
6. Use feedback to improve later analysis.

Use this pattern as the baseline when writing workflow guides, integration guides, and troubleshooting pages.