1
Definition and execution are clearly separated
Canonical types, field mappings, flow templates, and model versions are published before runtime applications use them.
01 · Executive read
The core advantage is a shared industrial context reused across products.
The earlier atlas showed which product areas exist. These 33 captures show how an asset, schema, KPI, model, or alert moves across interfaces before it becomes a decision or an application.
Core conclusion
SymphonyAI reuses the same industrial context for analysis, agent workflows, app generation, and Copilot. Applications are outputs; the reusable asset is the governed data and context underneath.
2
People approve the points that can affect operations
P&ID entities are verified one by one, models require an explicit deployment choice, and generated applications can be inspected through code, diff, and preview before deployment.
3
The CIP runtime is the most useful pattern for Produce
Flow overview → current step → measurement → step detail → alert queue. This is much closer to Produce's operating loop than a KPI dashboard.
4
Forge and Flows solve different problems
Forge generates editable applications. Flows orchestrates reasoning, tools, and people. Neither is a canvas for physical production routing.
5
A recommendation is not yet an action
Impact Analysis and merit-order screens produce recommendations, but the captures do not show approval, execution, or outcome verification.
6
Breadth creates usability cost
The launcher, stacked tabs, repeated filters, and dense dashboards suit power users, but make first use harder to understand.
02 · Evidence & method
The research follows the same sequence as the official demo.
The earlier document covered 176 pages and 304 UI fragments across SymphonyAI and Ethon. This deep dive uses 33 captures from the 30 Jan 2026 demo, plus related first-party sources, to reconstruct the interaction flow.
How to read the evidence
● Observed on screen
● Stated by SymphonyAI
● Inferred from sequence
Each screenshot card only describes controls and states visible in that frame. Flows connect frames by capture order. Any capability not shown on screen is used only when an official source confirms it, and is labeled accordingly.
Research boundary
Demo data may be sample or sanitized. A generated application is not automatically a fixed SymphonyAI module. The captures do not include player timestamps, so S01–S33 indicate capture order rather than exact video time.
An unseen state is never treated as a proven capability. Missing error, permission, approval, or outcome states are recorded as evidence gaps—not as proof that the product lacks them.
03 · Product architecture
Product areas share one context layer but serve different jobs.
The demo moves through one connected stack, but the interaction model changes with the job: model the plant, diagnose, orchestrate, build, operate, or ask.
FoundryConnect · namespace · schema · govern
Cortex / MLRelate · diagnose · model · deploy
IRIS FlowsOrchestrate agents, tools, and people
IRIS ForgeGenerate · inspect · deploy applications
Generated appsRole-specific runtime and monitoring
IRIS CopilotNatural-language interaction on shared context
| Product area | Primary object | Configured before runtime | Runtime output | Primary user |
|---|---|---|---|---|
| Foundry Data Hub | Source, namespace, type, mapping | Connect and publish context | Queryable industrial model | Data/OT engineer, architect |
| P&ID / Cortex | Entity, asset, relation, KPI | Verify topology | Contextual navigation and diagnosis | Process/reliability engineer |
| ML Studio | Experiment, run, model version | Train, test, register | Deployed predictive model | Process/ML engineer |
| IRIS Flows | Resource, agent node, flow, run | Compose and bind resources | Orchestrated reasoning/action | Automation builder, FDE |
| IRIS Forge | Prompt, project, file, deployment | Generate and edit app | Governed application | Domain expert, developer |
| Generated app | Cycle, step, KPI, alert | Configured by app/schema | Operational work and monitoring | Manager, supervisor, engineer |
| Copilot | Question, evidence, answer | Uses existing access/context | Role-specific summary or guidance | Any operational role |
04 · Demo timeline
From raw data to an operational answer.
Select any stage to jump to its detailed flow.
01
Prepare the data foundation
Turn scattered source data into trusted operational context.
02
Use data to analyze and act
Explain what is happening, then coordinate the next response.
03
Deliver the capability to users
Package the shared context into the interfaces people use at work.
This is the core product logic—not a strict one-way journey that every user must complete from start to finish.
01 · Find the right place to startS0102 · Connect data and preserve its structureS02–S0303 · Turn a drawing into verified plant contextS04–S05–S06–S0704 · Standardize local schemas into one reusable modelS08–S09–S1005 · Move from an abnormal KPI to an explainable diagnosisS11–S12–S1306 · Train, review, and approve a modelS14–S15–S1607 · Build an agent workflow from governed resourcesS17–S1808 · Generate an app without hiding its implementationS19–S2009 · Run a CIP/SIP cycle from progress to exceptionS21–S22–S23–S24–S25–S2610 · Monitor operations across sites and unitsS27–S28–S29–S30–S31–S3211 · Ask without leaving operational contextS33
05 · Flow deep dives
Each flow shows the user action, the data that changes, and what happens next.
The flows below follow capture order. Open a screenshot or its ID to inspect the full-resolution image and a control-level explanation.
Jump to a workflow
01 · Find the right place to start
02 · Connect data and preserve its structure
03 · Turn a drawing into verified plant context
04 · Standardize local schemas into one reusable model
05 · Move from an abnormal KPI to an explainable diagnosis
06 · Train, review, and approve a model
07 · Build an agent workflow from governed resources
08 · Generate an app without hiding its implementation
09 · Run a CIP/SIP cycle from progress to exception
10 · Monitor operations across sites and units
11 · Ask without leaving operational context
01 Platform admin · data/OT lead
Find the right place to start
Why this starts: The user needs to know which capability or installed application to open first.
- Open the IRIS Foundry capability hub.
- Select a capability or installed application.
- Favorite frequently used areas; use New App or Manage to maintain the portfolio.
ResultAn entry point into the correct product area; no operational object has been created yet.
Product read
Foundry communicates platform breadth well, but requires users to understand its product taxonomy. Minder should keep that breadth underneath and start the homepage from the factory, workflow, or issue currently in operation.
02 Data engineer · OT architect
Connect data and preserve its structure
Why this starts: Data is spread across historians, PLC/SCADA systems, cloud streams, databases, and CMMS tools.
- Choose the appropriate connector template.
- Configure the source and ingest its data into Foundry.
- Browse or import a namespace to preserve each source's asset and process hierarchy.
ResultSource data now has a namespace and a defined place in the hierarchy.
Product read
Connector breadth is infrastructure, not the end value. Product value appears when a source enters a shared context that applications, models, flows, and Copilot can all reuse.
03 Process engineer · asset engineer
Turn a drawing into verified plant context
Why this starts: A P&ID is still a PDF or image; AI does not yet know its assets, tags, or topology.
- Open the verification queue and select Ingest P&ID.
- Choose an extraction model and upload the file.
- Track each page while it is being analyzed.
- Review entities by category and confidence on the drawing canvas.
- Correct existing entities or add missing ones until verification is complete.
ResultP&ID entities and topology have been confirmed by a person.
Product read
The strength is not OCR alone. It is the combination of a queue, confidence scores, human verification, and downstream mapping—a useful pattern whenever AI extraction affects operations.
04 Industrial data architect · FDE
Standardize local schemas into one reusable model
Why this starts: Four sites describe the same maintenance object with different fields and nesting.
- Create or open a canonical type.
- Define its properties and required settings.
- Map each source schema to the canonical fields.
- Save the mapping, review it, and publish the type.
ResultA published type that applications, models, and flows can all reuse.
Product read
This is strong evidence for separating definitions from runtime values. The mapping canvas can quickly become tangled, so the UI should focus on one field or path at a time and surface unresolved conflicts.
05 Reliability engineer · plant analyst
Move from an abnormal KPI to an explainable diagnosis
Why this starts: A KPI such as Net Power Export P1 changes unexpectedly.
- Select the asset and KPI in the Knowledge Graph.
- Open Impact Analysis and mark the relevant time window.
- Compare the critical paths.
- Read each path's contribution, possible causes, and recommendations.
- Hand the finding to someone authorized to act.
ResultAn evidence-backed diagnostic path with a recommendation.
Product read
The diagnostic flow is explainable, but it ends at a recommendation. Minder should continue the same decision thread through proposed action → approval → execution → outcome verification.
06 Process engineer · ML engineer
Train, review, and approve a model
Why this starts: A versioned anomaly model is needed, with a clear gate before deployment.
- Configure an experiment and start a run.
- Track draft and completed runs.
- Review anomaly trends, alerts, and parameters.
- Retrain or retest if needed; choose Use in Deployment only when the evidence is sufficient.
- Manage the model and its versions in the registry.
ResultA model version that has been deliberately approved for use.
Product read
Minder P0 does not need to expose an ML Studio. The transferable pattern is evidence beside the decision gate, versioned objects, and explicit promotion.
07 Automation builder · FDE · developer
Build an agent workflow from governed resources
Why this starts: The team wants to standardize root-cause analysis as a multi-step agent workflow.
- Find APIs, tools, data, and language models in Resource Manager.
- Open the KPI RCA template.
- Inspect inputs, nodes, resource bindings, and outputs.
- Choose Use Template, then configure it for the use case and site.
- Run the flow and review its trace in Runs Explorer; this state is not shown in the captures.
ResultA draft agent flow built from reusable resources.
Product read
The agent graph and the production graph represent different things. Minder should not place reasoning nodes on the same canvas as physical production routing.
08 Domain expert · developer · product owner
Generate an app without hiding its implementation
Why this starts: A role-specific app for enterprise asset health is needed without manually setting up a project.
- Describe the desired outcome in natural language.
- Choose Foundry Application and relevant resources, or let Auto choose.
- Forge creates the project files.
- Review Code, Diff, Preview, locks, and terminal output.
- Refine the result through prompts or direct code edits.
- Deploy through a governed pipeline.
ResultAn application project with editable code, a preview, and a deployment path.
Product read
Forge is an app builder, not a dashboard image generator. For Minder, app generation is a later platform capability; near term, generate bounded operator and manager views from the shared schema.
09 Production manager · process engineer · supervisor
Run a CIP/SIP cycle from progress to exception
Why this starts: The team needs to know where the cycle is, whether parameters are within range, and which alerts need action.
- Open the generated CIP Process Twin application.
- Check the current step, progress, warnings, and live parameters.
- Select a step to compare duration, target, and actual values.
- If a threshold fails, open the alert queue.
- Assign an owner and start handling the issue.
- Compare the process twin with history or a golden run when needed.
ResultA process exception with context, an owner, and history.
Product read
This is the closest benchmark for Produce: flow overview → step execution → measurement → issue queue. The captures do not show how work resumes or how the outcome is verified after resolution.
10 Operations executive · plant manager · energy/safety lead
Monitor operations across sites and units
Why this starts: The team needs to compare performance by estate, station, unit, and time range.
- Choose the facility or station and the time range.
- Choose a domain: operations, environment, safety, or analytics.
- Compare current, target, and trend by unit.
- Drill down to a detailed table or recommendation.
- Hand the action to the plant team.
ResultA scoped performance view or recommendation.
Product read
The context controls are powerful, but the hierarchy is deep and time filters sometimes repeat. Dashboard breadth should not be the MVP; prioritize one operational question and one actionable queue.
11 Engineer · supervisor · operator
Ask without leaving operational context
Why this starts: The user needs a summary of active alerts without manually combining multiple screens.
- Open the IRIS drawer inside the current product area.
- Ask: “Give me a summary of active alerts.”
- Review the structured table, timeframe, and written summary.
- Open Show AI’s work, give feedback, regenerate, or ask a follow-up.
ResultA contextual answer that keeps references to the relevant assets, alerts, and timeframe.
Product read
Copilot works best as an interaction layer over real operational objects. Minder should return decision packets and typed actions, rather than turning chat into a separate workspace.
06 · Micro-feature inventory
Small controls shape the product's interaction model.
Not every feature should be copied. The goal is to understand its role in the operating loop.
| Product area | Find / scope | Create / configure | Inspect / diagnose | Act / govern |
|---|---|---|---|---|
| Foundry home | Capability columns, favorites, installed apps | New App, Manage | Docs, Guides, Release Notes | User access, logging, system monitoring |
| Data Hub | Connector catalog, namespace search, hierarchy tree | Import Namespace, Create Type | Type/status/properties tables | Draft vs Published |
| P&ID | File search, category/confidence filters, entity search | Model select, file upload, Add Entity | Overlay canvas, verification count, confidence summary | Edit P&ID, human verification, mapping handoff |
| Unified model | Type search/filter, Properties/Map View | Edit properties, field connections | Mandatory settings, source schema comparison | Save Mapping, Publish |
| Cortex | Search, date range, node path, graph filters | Select KPI/time window | Details/Documents/Lists, critical paths, contribution | Recommendation only in shown state |
| ML Studio | Project breadcrumbs, search, status, system/custom | New run, Configure, parameters | Anomaly trend, testing/training, registry/version | Retrain, Retest, Use in Deployment |
| IRIS Flows | Global/My/Shared, resource types, template library | Create Resource, Use Template | Node/resource binding, zoom/pan/lock | Deployments and Runs Explorer exist in nav; run state not captured |
| IRIS Forge | Foundry Application, Auto choose, files/search/locks | Prompt, attachments, voice, code generation | Code/Diff/Preview, terminal, task progress, token count | Save, Reset, Download Code, VS Code, Deploy |
| CIP runtime | Process phase, current step, process-twin tabs | Generated/configured elsewhere | Step status, duration, targets, measurements | Select step; issue action moves to Alerts |
| Alert queue | Open/In-process/History, severity queue | Settings | Impact, affected systems, recommended actions, history | Assign, Start; close/resume not shown |
| Copilot | Current asset/time context | Natural-language prompt | Structured result, table, Show AI’s work | Feedback, regenerate, export; typed action not shown |
07 · Object & state model
Object lifecycles show how the product operates beyond individual pages.
States shown with a solid path are observed. States labeled “inferred” are logical transitions that do not appear directly in the captures.
Selected→Analyzing→Unverified→Partially verified→Verified / mapped · inferred
Draft→Properties edited→Mapped→Published
Draft→Completed / tested→Retrain or retest→Use in Deployment
Template preview→Use Template→Configured · inferred→Run/trace · inferred
Prompt→Initial files→Code/Diff/Preview→Deploy→Managed app · stated
Pending→In progress→Warning / Error→Completed
Open→Assigned→Started / in-process→Resolved / history · inferred
Question→Structured response→Show work / feedback→Follow-up or export
Important evidence gap: the captures show states from definition through recommendation, but do not fully show
approved → executed → succeeded/failed → verified outcome.
08 · Applied use cases
From interface patterns to real work in a plant.
“Observed” means the flow appears in the captures. “Stated” means SymphonyAI describes the use case in an official source.
P&ID onboarding for a plant model
A process engineer turns a PDF into verified assets, tags, and topology before using it in a predictive model, HAZOP, digital twin, or agent.
- Input: drawing + extraction model
- Decision: is the entity correct and confidence sufficient?
- Output: verified context
Investigating a KPI deviation in power generation
A reliability engineer selects an abnormal period and reviews critical paths and contributions before proposing checks on the turbine, fuel quality, or heat exchange.
- Input: KPI series + graph relations
- Decision: which critical path is credible?
- Gap: execution and outcome are not shown
CIP/SIP monitoring for food and beverage
A supervisor sees the current cycle step, out-of-range parameters, steps that need inspection, and alerts that need an owner.
- Input: flow, target, live measurements
- Decision: continue, inspect, or escalate
- Output: issue with an owner and history
Multi-site power operations
An operations team scopes by station, unit, and time to monitor generation, safety, environmental KPIs, and merit-order recommendations.
- Input: enterprise/site/unit context
- Decision: prioritize a unit or adjust load
- Risk: recommendation lacks an approval control
Location-specific lab inspection
An inspector scans the lab entrance to open the correct 5S workflow. An upstream answer routes the next branch, while technical specifications and video remain inside the task.
- Input: location + procedure + prior answer
- Decision: route, document issue, initiate action
- Claim: 100% execution compliance
Paperless shift inspection
A video shows how to inspect a machine, while a reference 5S image sits inside the procedure. At handover, deviations are photographed for follow-up across production, maintenance, HSE, and quality.
- Input: work instruction + reference image
- Decision: conforming or deviation
- Output: photo-backed follow-up record
Progressive predictive-maintenance adoption
Across 32 plants with different generations of ERP, historians, and equipment, Novelis began with rule-based alerts, then gradually added AI/ML alerts to build trust before scaling.
- Input: heterogeneous plant + asset data
- Decision: is the alert reliable enough for the workflow?
- Claim: reduced unplanned downtime across facilities
Finding failure modes missed by classical monitoring
Predictive models monitor compressors, turbines, and purifiers alongside vibration and oil analysis. Anomalies are shared across technical roles for review and action.
- Input: critical source data + asset context
- Decision: which anomaly needs corrective action?
- Claim: prevented unplanned stoppages
09 · Product critique
A practical assessment of strengths, limitations, and evidence gaps.
This critique is based on public demo states, not a usability test in a live tenant.
What works well
- Shared context runs from connectors and schemas through graphs, models, applications, and Copilot.
- Human verification appears before P&ID context is trusted.
- Draft/Published states and model promotion create clear governance checkpoints.
- Forge keeps its output inspectable through code, diff, preview, locks, terminal, and deployment controls.
- The CIP runtime keeps flow, status, measurements, and step detail in one mental model.
- The alert queue combines severity, context, recommended actions, ownership, and history.
- Copilot keeps asset and timeframe context and offers Show AI’s work.
What to treat cautiously
- Foundry home reflects product taxonomy rather than a role- or job-based starting point.
- Green status styling for “Unverified” could be misread as complete or safe.
- The mapping canvas has many crossing lines and no obvious focus for conflicts or unmapped fields.
- The Knowledge Graph is broad, but the current node path and investigation are not prominent enough.
- Generated dashboards appear template-heavy and information-dense.
- Time, site, and unit context sometimes repeat across rows, making the active query scope harder to audit.
- The recommendation table does not show approval, action ownership, or execution results.
- Error, permission, stale-data, and rollback states are mostly absent.
10 · Minder implications
What Minder should adopt, adapt, and leave for later.
The mapping below follows the current Product Context: a generic workflow; StepDefinition and FieldDefinition; item runtime; Manager Monitor; decision packets; approval; and append-only history.
| Minder area | Adopt | Adapt | Avoid |
|---|---|---|---|
| FDE configuration | Draft/Publish, versioned definition, source mapping, unresolved queue | AI generates a bounded workflow and field schema for FDE review | A Foundry-style mega catalog or blank industrial canvas |
| Node inspector | Typed properties, required settings, mapping, preview before publish | Notion-like fields plus source, unit, tolerance, gate, role, and provenance | Hard-coded fields by vertical, or runtime values stored inside the node |
| Produce runtime | Current step, status legend, actual vs target, step drill-down | Item or batch context, owner, material lot, evidence, and deterministic gate | An OEE dashboard before execution data is reliable |
| Manager Monitor | Flow overview → select node → step/item detail | Flow and Table as two projections of the same events, with persistent filters | Separate dashboards by vertical or manually edited counters |
| Issue handling | Open/In-process/History, severity, owner, age, event history | Acknowledge → assign → resolve → resume original task → verify | An alert with only a recommendation or “Mark all as read” |
| Minder AI | Contextual drawer, structured result, show evidence or work | Decision packet: evidence, assumption, risk, typed action, approval, outcome | A chatbot detached from tasks, items, and issues, with unaudited actions |
| Agent tooling | Reusable resources, explicit bindings, run trace, governed modes | Agent playbooks beneath the operational graph, exposed only as needed by role | Mixing agent reasoning nodes with physical production routing |
| Platform later | Applications inherit context and governance | Generate bounded operator and manager views from the shared schema first | Building a generic Forge or ML Studio before the P0 loop works in production |
Build now
- Versioned workflow and field definitions.
- Runtime StepExecution and FieldValue.
- Flow and Table views in Manager Monitor.
- Issue queue with owner, age, and history.
- Minder decision packet, approval, and outcome.
Reference later
- Industrial connector catalog and source-schema mapping studio.
- Generic agent resource manager and reusable templates.
- Prompt-to-app generation and editable code workbench.
- ML experiment registry and deployment UI.
- OEE, environmental, safety, and enterprise optimization dashboards.
11 · Screenshot index
Search all 33 screenshots.
Search by title, module, object, state, or tag. Open a card to view the full-resolution screenshot and a screen-level explanation.
No screenshots match this search.
12 · Sources
First-party sources used to validate each screen interpretation.
Company claims and case outcomes are treated as vendor-reported unless independently verified.
-
01
Official demo page — IRIS Foundry: Industrial DataOps Platform
Confirms the demo scope: data and context, P&ID, UDM, graphs, Forge, Flows, generated applications, and Copilot.
-
02
IRIS Foundry
DataOps, contextualization, P&ID, ML, governance.
-
03
P&ID Ingestion
Ingest → extract → verify → map; confidence scoring and human verification.
-
04
Unified Namespace
Asset and process hierarchy with shared industrial context.
-
05
Knowledge Graph
Asset/Performance Cortex, relationship exploration, and lineage.
-
06
ML Studio
Experiments, model registry, deployment, and retraining.
-
07
IRIS Flows
Agent orchestration, human approval, and controlled autonomy.
-
08
IRIS Forge
Prompt-to-app, editable code, preview, and governed deployment.
-
09
CIP/SIP case and product walkthrough
Live cycle steps, golden run, analytics, and compliance framing.
-
10
Manufacturing Workflow Intelligence
Production orchestration, material tracking, quality, and cross-site workflow.
-
11
Connected Worker
Guided work, inspections, evidence capture, and frontline execution.
-
12
GSK Connected Worker case
Location-specific inspection workflow; vendor-reported operational outcome.
-
13
Vandemoortele paperless operations case
Shift inspections, reference photos, and deviation follow-up.
-
14
Novelis predictive maintenance
Asset monitoring and predictive maintenance at industrial scale.
-
15
Nippon Gases predictive asset intelligence
Predictive monitoring and automated cause/advisory pattern.