Demo quick track

Use this track for a small demo with prepared data and an established app setup. Aim to turn one complete prompt into a working page in under one minute. This is a target to measure, not a guaranteed build time. For unfamiliar data, new model authoring or a larger app, use the full dashboard workflow.

Prepare before the demo

The standard App build requirements apply to this track too. Complete them during preparation and recheck anything that has changed:

• Data: explore the semantic layer, verify the intended metrics and execute the selected Business Questions. Save missing questions and complete any required publication before the timed run. Retain exact references, query meaning and representative results; do not substitute static results for live data.
• Capabilities: prepare the semantic-layer and chart capabilities with their question/view bindings and expected results. Record unsupported or inapplicable items; a required feature that is missing must be addressed before the timed build.
• App setup: prepare a frontend with installed dependencies, working authentication and a verified query and mounting path. Use the matching Data App or externally hosted app quickstart. Check the local browser session and build command. Keep credentials outside the prompt and authored source.
• Presentation: choose one layout and style, the chart forms and the components. Use an expert guide during preparation if helpful. Check the selected types against the installed package, including any less common chart. Reuse those decisions during the run.
• Scope: select one page with three or four views and, if needed, one shared filter. State the reading order and one interaction that demonstrates the app’s flow. Use the reusable demo starter or prepare an established shell for layout, loading, empty and error states; leave the requested dashboard content to generate during the demo.

Keep this context in a short demo brief beside the project. Include the documentation links for the chosen implementation path. Do not repeat exploration, installation or design selection during the timed run when the prepared context is still valid.

Keep the brief small and complete

Map each view to its saved question and state the intended aggregation, grain, units and date scope once in the brief. An example project may contain period comparisons or a different selection mode: reuse its integration while implementing the brief’s meaning. Reuse live metadata and query evidence from preparation; values in that evidence are verification targets, never data to hard-code into the page.

Keep unlike units in separate encodings. Revenue and cost can share a dollar comparison; return on ad spend is a ratio and needs its own clearly labelled scale or view. Choose a less common chart only when the data contains the relationship it communicates; a top-down page layout does not imply that its data forms a conversion funnel. See Choose a chart.

Build in one pass

Give the assistant the complete brief and ask it to implement directly. Reuse the app shell and verified integration, resolve live metadata once, and implement the chosen views together. Fetch only documentation needed for a missing detail; avoid reading unrelated design catalogs. Keep supported initial settings in definitions and use named operations for other settings.

If a required reference, capability or access check fails, report it and return to preparation. Do not invent values or remove a requested behavior merely to meet the timer.

Demo prompt

Replace every bracketed value with verified context before starting. Use the storytelling with data examples to prepare the demo’s narrative.

Use the demo quick track to build this page in one pass. Implement directly using the prepared
project and verified context below. Target a working local app and successful validated build
within 60 seconds; measure the actual time and report any overrun.

Project: [absolute path; existing shell and supported build command]
Delivery: [Data App or externally hosted app; established local session]
Audience and question: [who uses it and what they should learn or do]
Data: [semantic layer and exact saved Business Question references]
Verified query meaning: [grain, units, filters, parameters, ranking and date coverage]
Capabilities: [period calculations, semantic groups, additional semantic/chart features,
               question/view bindings, expected results and reasons for omissions]
Views: [three or four named views, each mapped to its question and supported chart type]
Layout and style: [selected layout variant and style; reuse the shell's responsive behavior]
Flow and components: [reading order, one interaction, required controls and explanatory text]
Documentation: [storytelling with data examples, verified implementation path and selected chart types]

Make the demo impressive through a data-backed story: establish context, reveal a clear finding
in each view and lead to the audience's next decision. Use the storytelling examples in the
linked documentation; derive takeaway titles and annotations from live results.
Use Astrato visualizations for charts and analytical data tables. Choose native numbers or ordinary
app UI for scalar KPIs according to the presentation needed; decorative SVG and ordinary UI need
no exception. Follow /app-compose/#chart-rendering-policy before
substituting a chart or analytical-table solution. Styling requests and the timer do not authorize it.

Use live governed data. Preserve each question's meaning. Reuse the prepared layout, states and
integration. Make the page readable at desktop and narrow widths. Check all views render, compare
displayed values and selected capabilities with retained query evidence, exercise the named interaction and run the
supported build command. Do not publish. Report the result, elapsed time and any skipped checks.

Time the result honestly

Start when the complete prompt is submitted. Stop when the requested page renders live data, the named checks pass and the local build completes. Include documentation fetches, code generation, compilation, rendering and repairs during that interval.

Report preparation time separately, alongside the environment and package versions, time to first live render and total completion time. Record whether dependencies and caches were warm. A cold setup that installs packages or needs login is a different benchmark. If the run exceeds a minute, report the actual result and identify the slow stage before the next demo; a generated page or a successful query alone does not count as completion.