Apps and core resources
You do not need to learn the file formats before using Theseus. Once you know what each resource is responsible for, you can describe work to AI more precisely and confirm that the result is in the right place.
Why this matters
A simple request can involve the screen, equipment, and workflow at the same time. For example, “scan a code, look up the work order, and start the station” may require a Page, Query, Object, and QG. Knowing their boundaries helps you:
- tell AI what it may change and what must stay untouched;
- find what AI created or changed in Resources;
- determine whether a problem belongs to the UI, data, equipment capability, or workflow;
- avoid putting a long-running process in a button or a device protocol in a Page.
When you will encounter it
You will see these names when you create your first screen, connect equipment, build a multi-step workflow, integrate with MES, or review an AI change summary.
The minimal mental model
An App is a project that can be edited, built, deployed, and run independently. Every resource below belongs to an App.
| Resource | What it is responsible for | Common examples |
|---|---|---|
| Page | An operator-facing runtime screen with visual elements and interactions | Runtime dashboard, parameter screen, alarm screen |
| Component | A reusable visual template within an App, commonly used for repeated items in a list or Repeater | Station card, alarm row, I/O status row |
| Object | A device or business capability expressed in domain language, with useful state and methods | Axis, scanner, station, TableStore |
| QG | A multi-step workflow with branches, waits, and error handling; Source and Flow are two views of the same program | Start-up, homing, changeover, production-reporting flow |
| Variable | A small App runtime value; QG declares its own local and durable state | Current work order, runtime state, total output |
| Query | A reusable contract for calling an external system | Look up an MES order, read a recipe, report production results |
They usually work together like this:
- A Page shows Object state and Variable values to an operator.
- An operator action calls an Object, Query, or QG method.
- QG controls the order, conditions, waits, and error branches across multiple actions.
- A Component receives one item of data and renders the same visual structure repeatedly in a Page.
- A Query defines how to call an external system; a Page or Variable consumes the returned data.
Where should a requirement go?
| Your goal | Consider first |
|---|---|
| Add an operator screen | Page |
| Show many similar devices consistently | Component + Page |
| Add capabilities such as Home or Start to a device | Object |
| Coordinate “check → act → wait → handle timeout” | QG |
| Share a small piece of state between screens and workflows | Variable |
| Call MES, ERP, WMS, or another external service | Query |
A real task can use several resource types. The goal is not to force everything into one type, but to keep each part in the layer that owns it.
Common misconceptions
- A Page is not the whole App. It is one runtime screen within the App.
- A Component is not another Page. It is a visual template reused by a Page and has no independent runtime entry point.
- An Object is not a Page element. It expresses a device or business capability that both Pages and QG programs can use.
- Not every button needs a QG. A single action can use a Page event function; use a QG when you need sequencing, branching, waiting, or debugging.
- A Variable is not a place for large tables, images, or complete history. Use a TableStore, an asset, or an external system for those needs.
- A Query is not a stored result. It defines the external call; the real data still comes from that external system.
Next step
- Use Your first project to put these resources into one runnable App.
- Learn the hands-on workflows in Pages and Components, Objects and devices, and QG programs.
- Continue with Data and integration when you need shared state or an external system.