> For the complete documentation index, see [llms.txt](https://help.tellius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tellius.com/tellius-6.4/kaiya/kaiya-apps/plans-and-versions-in-kaiya-apps.md).
# Plans and versions in Kaiya Apps
Read a Kaiya App's plan before it is built, see which analysis powers each section, review the plan, and publish, rename and manage the App's versions.
Kaiya shows you an App's plan before anything is built, and keeps every version you publish. You can see what the App will contain, where each number on it will come from, and which version people see when they open it.
This page explains the parts of App chat that help you shape an App: the follow-up suggestions, the **How Kaiya got this** panel, the **Plan** and **Analysis** tabs and the plan review. It then covers publishing and the version menu. For the ways to start an App, see [How to create a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-create-a-kaiya-app).
### **Open an App's conversation**
App chat is the conversation where you build and change an App. To work on an App you already have, open it and select **Open app assistant**, the chat icon at the left of the **Plan**, **Analysis** and **App** tabs. This opens the App's own conversation, with the App in a panel beside it. An App built before Tellius 6.4 opens the same way, with its earlier messages. See [Apps built before Tellius 6.4](https://help.tellius.com/kaiya/kaiya-apps/apps-built-before-tellius-6-4).
### **Follow-up questions and actions**
After each response, Kaiya suggests what you could do next, in two groups:
* **Follow-up questions** are questions about the data that Kaiya can answer in the chat. They don't change the App.
* **Actions** are changes Kaiya could make to the App, each written as a specific request. After a change has been saved as a draft, one of the actions is often to publish it.
Selecting a suggestion works the same as typing its text in the composer. When Kaiya has more suggestions than it lists, a link such as **Show 2 more** reveals the rest.
### **Follow Kaiya's work in How Kaiya got this**
Each of Kaiya's replies in App chat has a **How Kaiya got this** panel (named **Thought process** in earlier releases) with Kaiya's reasoning for the turn. While Kaiya works, a status line above it shows what Kaiya is doing and how many steps it has taken, for example **Saving the app**. When the turn ends, the panel header shows **Done** and how long the turn took. Use the **Detailed view** switch in the expanded panel to show more detail about each step. The panel lists the steps Kaiya took:
* the schema it read
* the skills it loaded
* the queries it ran, and what each one returned
If Kaiya is set up with a reasoning model, the panel also shows that model's thinking live, as Kaiya works through the turn. The panel has a set height and scrolls. While Kaiya is working, it follows the newest content. Select the panel's header to expand or collapse it.
### **Read the Plan tab**
An App's page has three tabs: **Plan**, **Analysis** and **App**. An App opened in the panel beside the chat shows the same tabs in the same order.
The **Plan** tab lays out the App before it is built. Read it from the top down:
* **Purpose.** The first lines say what the App is for, then how it is put together and how a reader moves through it.
* **Counts.** A short line gives the number of pages, sections and analyses. Each round of changes updates the counts, so you can see the effect of a change before the App is built.
* **What it's for.** The goals the App is meant to meet, one per line, followed by **Audience**, the kinds of people the App is designed for.
* **Pages & Sections.** Each page of the App, with its name and a description of what it shows. Select the arrow at the right of a page or section to collapse it, and select it again to expand it.
Each section in a page has a number, a label for the kind of section it is, such as **KPI**, **CHART (BAR)**, **CHART (LINE)** or **TABLE**, and a name. Under the name:
* **Summary** describes exactly what the section will show: which measures, how they are grouped and sorted, and how values are formatted. Select the copy icon to copy the summary, for example to paste it into a request for a change.
* **Data from** names the analysis that supplies the section's numbers. Before anything is built, you can see where each number on the page will come from.
At the bottom, **Analyses** lists every analysis the App uses. Expand one to read what it computes from your data.
While you revise an App that has already been published, the plan on screen is the active version's plan. A new draft version is created when a new plan is written, not before.
On older Apps, the **Plan** tab shows the plan as formatted text, with headings and bullet lists. A version that has no plan to show displays **No Plan Available**.
To copy the whole plan as text, open the App's three-dot menu and select **Copy**, then **Copy Plan**. **Copy Code** copies the App's generated code.
### **See what powers what in the Analysis tab**
The **Analysis** tab shows the steps that produce the App's data. It has two views.
* **Outline** lists the analysis steps in order. Each step shows its number, its type, such as **SQL**, and a one-line description. Expand a step to see **What this step does** in plain words. Expand **Sql instructions** to read the query the step runs. The bottom line names the step's **Output** and the **Business View** it reads from.
* **Diagram** draws the same steps as a flow, from left to right. The Business View feeds each step. Each step produces a view, and each view feeds an App section. Follow a line to see which data ends up in which part of the App.
### **Review the plan before a build**
Before Kaiya builds or rebuilds an App, it shows the plan for your review and asks what you want to do with it. Your answer is kept in the conversation, so you can see later what you approved. You have three choices:
* **Approve it.** The build goes ahead.
* **Cancel it.** Every part of the App is restored together: the plan, the data, the views and the code. The App is never left with a plan that describes one thing and data that describes another.
* **Ask for a change.** Kaiya revises the plan and shows it again, naming the change it made.
### **Publish and manage versions**
Your changes collect in a draft. The draft appears in the version menu with the next version number and a **Draft** badge, for example **V2**. Publishing turns it into a published version. Until then, people you share the App with keep seeing the version that is already published, so you can keep working without changing what they see. After a change, Kaiya tells you when it was saved as a draft and which version is still live.
If the App changes while you have it open, for example when Kaiya saves a new draft, a banner at the top of the App says that it has changed since you opened it. Select **View latest** to load the newest version. While you look at a draft, the refresh icon is greyed out, because a refresh updates the published version.
You can publish in four ways:
* Ask in the chat, for example *"publish the App"*.
* Select a publish suggestion under **Actions**.
* Open the App's three-dot menu and select **Publish**.
* Select **Publish** on the draft banner. While you edit a draft, a banner reminds you that viewers keep seeing the active published version until you publish your changes.
When you publish from the banner, the **Publish Version** dialog asks you to confirm. It has no fields to fill in. Select **Publish** to make this version the live, active version of the App, or **Cancel** to keep working on the draft.
Some things to know about versions:
* **When to publish.** Kaiya prompts you to publish at logical checkpoints. The interface also offers to publish once an App has produced its first screen. Publishing then captures a working state, so the next edit doesn't overwrite it.
* **One draft at a time.** An App has at most one draft. A published version can't be changed, apart from its name and description.
* **The active version.** The active version is the one people see when they open the App. The most recently published version becomes the active one.
* **A new App starts unpublished.** Until you publish it, the App has only a draft and appears only in your own list.
* **Who can manage versions.** The App's owner and administrators can publish, set a version as active and delete versions. People you share the App with can open it but can't change it.
* **Scheduled refreshes.** A scheduled refresh updates the data of the active version. It doesn't create a version or change your draft.
#### **The version menu**
Select **Version** at the top right of the App to list its versions, newest first. Each version shows its name, a **Draft** or **Published** badge, the date and time it was saved or published, and a description of what changed. The active version also has an **Active** badge, and a check mark shows the version you are viewing.
Select the three-dot menu on a version for these options:
* **Rename version:** give the version a name of your own. See [Name or rename a version](#name-or-rename-a-version).
* **Change description:** rewrite the note that says what the version changed, so others can tell versions apart.
* **Set as active:** make an earlier version the one people see. Use this to go back to a version that worked better. It then becomes the active version shown in the App chat.
* **Remix:** start your own copy of the App from this version. Changes to the copy stay separate from the original, and the copy links back to the App and version it came from. If that App or version has since been removed, the link explains why it is unavailable.
* **Delete version:** remove the version. Tellius asks you to confirm first.
**Set as active** and **Delete version** appear only on versions that are not active, so the version people are using can't be removed by mistake.
#### **Name or rename a version**
Versions are numbered **V1**, **V2** and so on. A version can have a name of your own in place of its number, which makes a particular version easier to find later. You can rename any version, active or not, and it keeps its published state.
1. Select **Version** at the top right of the App.
2. Select the three-dot menu on the version you want to rename.
3. Select **Rename version**.
4. Type the new name in **Version Name** and select **Save**. Select **Cancel** to keep the old name.
Tellius confirms with the message **Version renamed successfully.**
{% hint style="info" %}
Tellius keeps a set number of versions for each App, 10 by default. When an App passes that number, its oldest versions are removed. The active version and an App's last remaining version can't be deleted.
{% endhint %}
### **Best practices**
* **Settle the plan before a big build.** The bigger the App, the more a build uses warehouse time. Read the plan and ask for changes before you approve it.
* **Check where the numbers come from.** Read **Data from** on each section, or the **Diagram** in the **Analysis** tab, before you approve a build.
* **Publish working states.** Publish when Kaiya suggests it, or once the App has its first screen.
* **Check the version before you judge a change.** After Kaiya saves a draft, the App can still show the published version until you select **View latest** or pick the draft in the version menu.
* **Name the versions you may return to.** A clear name and description make the right version easy to find and set as active.
### **Related pages**
* [Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps)
* [How to create a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-create-a-kaiya-app)
* [How to customize a Kaiya App](https://help.tellius.com/kaiya/kaiya-apps/how-to-customize-a-kaiya-app)
* [Apps built before Tellius 6.4](https://help.tellius.com/kaiya/kaiya-apps/apps-built-before-tellius-6-4)
* [Anatomy of a completed app](https://help.tellius.com/kaiya/kaiya-apps/anatomy-of-a-completed-app)
* [Live data in Apps](https://help.tellius.com/kaiya/kaiya-apps/live-data-in-apps)
* [Mastering prompts for Kaiya Apps](https://help.tellius.com/kaiya/kaiya-apps/mastering-prompts-for-kaiya-apps)
---
# 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://help.tellius.com/tellius-6.4/kaiya/kaiya-apps/plans-and-versions-in-kaiya-apps.md?ask=&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.
