Skip to main content

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 Graph. 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.

ResourceWhat it is responsible forCommon examples
PageAn operator-facing runtime screen with widgets, interactions, and page permissionsRuntime dashboard, parameter screen, alarm screen
ComponentA reusable visual template within an App, commonly used for repeated items in a list or RepeaterStation card, alarm row, I/O status row
ObjectA device or business capability expressed in domain language, with useful state and methodsAxis, scanner, station, RecordStore
GraphA multi-step workflow with branches, waits, error handling, and breakpoint debuggingStart-up, homing, changeover, production-reporting flow
VariableA small runtime value that may be shared by the App, persisted across restarts, or local to a GraphCurrent work order, runtime state, total output
QueryA reusable contract for calling an external systemLook up an MES order, read a recipe, report production results

They usually work together like this:

  1. A Page shows Object state and Variable values to an operator.
  2. An operator action calls an Object, Query, or Graph method.
  3. A Graph controls the order, conditions, waits, and error branches across multiple actions.
  4. A Component receives one item of data and renders the same visual structure repeatedly in a Page.
  5. A Query defines how to call an external system; a Page, Graph, or Variable consumes the returned data.

Where should a requirement go?

Your goalConsider first
Add an operator screenPage
Show many similar devices consistentlyComponent + Page
Add capabilities such as Home or Start to a deviceObject
Coordinate “check → act → wait → handle timeout”Graph
Share a small piece of state between screens and workflowsVariable
Call MES, ERP, WMS, or another external serviceQuery

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 screen widget. It expresses a device or business capability that both Pages and Graphs can use.
  • Not every button needs a Graph. A single action can use a Page method; use a Graph when you need sequencing, branching, waiting, or debugging.
  • A Variable is not a place for large tables, images, or complete history. Use a RecordStore, 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