FactVerse AI Agent Core Concepts

FactVerse AI Agent is not a free-form chatbot wrapped around industrial data. It is a governed tool and context layer. 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 generated reference documents the current public catalog for this build, but deployment configuration and customer scopes decide what a key can actually call.

Tenant and asset context

The API key resolves the tenant. The client should not send a tenant identifier as a replacement for authorization. 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.

The retired physical endpoint should not be used for new work. Physical AI workflows should use the current endpoints and the Designer, SimReady asset, and simulation toolchain.

Tool calls and source references

Tool calls should be treated as governed access to product capabilities, not direct database access. 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, asset version, simulation assumptions, 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?

If data is missing, the Agent should report the gap instead of filling it with unsupported assumptions.

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 deployment 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 are not only visual references. They carry spatial context, asset relationships, behavior assumptions, and operational meaning.

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

• Designer scene;
• SimReady asset;
• 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.