This page explains what actually happens between a click and a filled table — useful when designing non-trivial apps, and when something doesn’t behave the way you expected.

​
The catalog

Apps in the product navigation lists every app you can see, as cards showing the app’s name, home ontology, author and creation date. Users with app-editing permission also get the authoring actions there: New App, Import, and per-card Export / Edit / Delete. Opening a card runs the app.

​
Pages and variables

An app with several pages renders them as tabs. Three rules define the runtime model:
  1. One ontology per page. Each page is bound to exactly one ontology, and everything on that page — concepts, parameters, columns — resolves against that ontology’s lineage. Different pages may use different ontologies.
  2. Pages keep their state. Switching pages never discards another page’s inputs or results; every page stays alive in the background.
  3. Each page has its own variables. Page variables are named values: inputs publish their value (statusPick), forms publish their fields (searchForm.region), and selectable tables publish the clicked row (selectedLead). Run-group bindings ({{…}} references) read them. Variables never leak across pages.

​
The run-group lifecycle

When a run group fires — whatever the trigger — the same four steps happen:
  1. Resolve bindings. Every params template is resolved against the page’s variables (unset values are dropped); every facts template must resolve to at least one record-group row, or the run stops with a message asking the user to submit the form first.
  2. Serialize facts. Record-group rows become Vadalog ground facts, one per row, arguments in the record group’s declared field order — strings quoted, numbers bare, booleans as #T/#F. These travel with the run as preamble facts: they exist only for that execution and are never persisted.
  3. Execute. Each concept in execute runs in order, with the resolved parameters and preamble facts, and with intermediate concepts materialized — which is why an output tap can read any concept computed along the way, not just the executed one.
  4. Fetch taps. Each output tap’s results are fetched and handed to the widgets bound to it.

​
Triggers, precisely

​
Tables at runtime

A rich_table’s pagination, sorting and search are server-side: the table fetches pages on demand rather than loading the whole result. Large results are therefore fine to tap directly — the first page arrives quickly and the rest is fetched as the user navigates.

​
Where apps live

An app is stored in its home ontology — the ontology you picked when creating it (its pages may reference other ontologies). Along with the definition, the platform keeps the version history: every save appends a checkpoint, bookmarked and published checkpoints are kept forever, and unbookmarked history is pruned oldest-first beyond the 50 most recent.

​
The API surface

Everything the catalog and editor do goes through the Apps API — apps are fully manageable programmatically, and the same save-time validation applies regardless of who calls it: See the Apps API reference for request and response shapes. The AI assistant uses the same operations through its MCP tools, so apps it creates obey the same validation as apps you build in the editor.

​
The pieces, end to end