> For the complete documentation index, see [llms.txt](https://docs.mozark.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mozark.ai/no-code-studio/concepts/core-concepts.md).

# Core concepts

Everything in App Studio is built out of a handful of things. Learn these once and the rest of the product explains itself.

## The building blocks

### Element

Something on the screen: a button, a text field, a label.

You never type an element locator by hand. When you right-click an element on the device screenshot, App Studio captures its **primary XPath plus a set of fallback locators** (resource id, accessibility name, visible text). At run time the engine tries each in turn, then falls back to matching by visible text and finally OCR.

That cascade is why a recorded test survives small UI changes that would break a hand-written XPath.

### Step

One action on one element: *Press Element*, *Enter Text*, *Assert Presence*.

A step is made of a **keyword** (what to do) and its **parameters** (what to do it to, and how). Some parameters take a literal, and some take a `${variable}`.

### Keyword

The action vocabulary: about 50 of them, grouped into Element Actions, App Actions, Validation, Device Actions, Source & Inspection, and Waits. See the [Keyword reference](https://docs.mozark.ai/no-code-studio/reference/keyword-reference).

### Module

A named, reusable group of steps: *Login*, *Add to cart*, *Complete payment*.

Modules are **versioned and immutable**. Editing a module creates version 1.1 rather than changing 1.0. Every test that uses a module **pins** the exact version it was built against, so improving a module never silently changes a test that was passing. See [Modules](https://docs.mozark.ai/no-code-studio/authoring-tests/modules).

### Test case

An ordered list of steps and module blocks. This is the thing you run.

### Data set

A table of values with a **key column**. One row per device, per test, or per whatever you key it on. See [Test data](https://docs.mozark.ai/no-code-studio/authoring-tests/test-data).

### Variable

A named value written as `${name}`. Four kinds:

| Source  | Where the value comes from                      | Who creates it                                                             |
| ------- | ----------------------------------------------- | -------------------------------------------------------------------------- |
| Static  | A literal you typed once                        | You, on the Variables screen                                               |
| Lookup  | A cell in a data set, matched on the key column | Created for you when you bind a data-set column to a step                  |
| Runtime | Read off the screen by an earlier step          | Created for you by *Extract value into variable*                           |
| Context | Injected by the runner for every run            | Always available: `${test_name}`, `${device_serial}`, `${iteration_index}` |

## How they fit together

```
Elements  ──►  Steps  ──►  Modules  ──►  Test case  ◄──  Data set
(locators)    (actions)   (reusable)     (the flow)      (the values)
                                              │
                                              ▼
                                        Test Suites
                                  Job ──► Devices ──► Report
```

You author each thing once and combine them. A locator lives in the step that recorded it, a repeated flow lives in a module, a value lives in a data set, and the test just references them.

## Where things live

| Screen        | What it holds                                                             |
| ------------- | ------------------------------------------------------------------------- |
| Test Creation | The free-device pool and your uploaded app builds. Where sessions start   |
| Workspace     | The live device screenshot and the step builder. Where tests are recorded |
| Test Cases    | Every test in the project                                                 |
| Modules       | The reusable module library, with version history                         |
| Elements      | A named-locator reference library                                         |
| Variables     | Every variable in the project and where its value comes from              |
| Data Sets     | Your data tables                                                          |
| Test Suites   | Where runs are launched and scheduled                                     |
| Test Reports  | Results                                                                   |

## Sessions vs runs

These are two different things and mixing them up causes confusion.

|                | Session (authoring)                                  | Run (execution)                          |
| -------------- | ---------------------------------------------------- | ---------------------------------------- |
| What it is     | A live device you are driving by hand                | An unattended job on one or more devices |
| Where          | The Workspace                                        | The Test Suites                          |
| Started by     | **Start Testing** on the Test Creation screen        | **Run now** on the Test Suites screen    |
| App launch     | Already open: you opened it                          | Generated from the app you select        |
| `${variables}` | Previewed with the value this device will really use | Resolved per device from your data set   |
| Ends when      | You stop the session                                 | The job finishes                         |

While authoring, a bound variable shows the value the device you are on would really use, so what you see typed on the device screenshot is what a real run will type.

## What App Studio does for you at run time

Two things are added to your test automatically, which is why you never author them yourself:

* **The app launch.** Your test has no launch step because your session was already open when you recorded it. The app you pick on the run screen is what gets installed and launched.
* **The test data.** If your test reads data-set columns, the right row for each device is loaded before the test starts.

Your references are also checked before the run begins. A broken variable, data-set column, element or module link stops the run immediately, on screen, before any device time is used. A rejected run costs you nothing but the time to read the list.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mozark.ai/no-code-studio/concepts/core-concepts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.