AI-Built Dashboards: Connect the Figures to Real Records

Imagine a small design studio reviewing an AI-built project dashboard. The screen says there are twelve active jobs. The studio has three. Someone changes the displayed total by hand, and the page looks reassuring again. But a question remains: when another project starts, which record will change that figure?

This fictional example captures a practical leadership responsibility. Before a dashboard informs staffing, customer updates or a launch announcement, its figures need an explainable connection to the business. That connection includes the source records, the counting rule and the circumstances in which the display can no longer provide a trustworthy answer.

A connected database can still hold a demonstration

A persistent value is not necessarily an observed business result. v0’s database documentation discusses adding persistence to support mocked application flows. Database integration can therefore be part of building a realistic demonstration, as well as part of a working service. Its presence alone does not establish what the records represent.

Supabase’s seeding documentation describes populating a database with initial data, including sample or default records for development and testing. That is useful engineering work. The review question is which records are examples, which are legitimate reference data and which document actual business activity. The word “seeded” does not, by itself, answer all three.

For the studio, start by asking where the twelve came from. Was the value written directly into the interface, stored as an editable setting, calculated from demonstration projects or derived from current project records? Each answer calls for a different correction. Replacing the visible numeral leaves that investigation unfinished.

Give each operational figure a short definition

Choose one card and write what it is intended to mean. For this example, “Active projects” will mean projects belonging to the studio whose current status is active, excluding demonstration records. Draft, completed and archived projects are outside the count. This is the studio’s chosen operational definition, not a universal definition for every business.

Keep a compact source note beside the implementation documentation:

• Source: the project register or service supplying the records.
• Scope: the business or account, relevant statuses and any date boundaries.
• Exclusions: demonstration records and other entries outside the definition.
• Timing: when the source was last read successfully and how updates reach the display.
• Owner: the person who can explain the definition and investigate a mismatch.

Use plain language the owner can understand. A database table name may help a developer, but the studio also needs to know whether the card concerns current work, all projects ever created or jobs started during a particular period. Those are different management questions.

Test the connection with controlled records

Use a separate, appropriately configured test environment for the proposed workflow. Give the test projects identifiers that let a reviewer follow them from the register to the dashboard. In this hypothetical test, two projects begin as active, one as draft and one as archived.

• The initial active-project count should be two.
• Changing the draft project to active should bring the count to three.
• Archiving one of the active projects should return it to two.
• Reopening the page should show the result from the saved source state, under the documented refresh behaviour.

Record what happened and when. If the source changed but the card did not, investigate the connection, filtering or refresh process. If a manually edited total reverted after reopening, establish which value the application actually treats as authoritative. Give an AI coding assistant the expected transitions and observed results so the requested repair has a concrete target.

Passing this exercise establishes only the tested behaviour with those test records. It does not turn them into real client work. Before relying on a live figure, compare it with authorised current records from the intended business account and confirm that the same definition applies.

Keep test success distinct from business activity

Payment testing provides a clear example. Stripe documents general sandboxes for testing functionality without real money movement; payments created there are not processed by card networks or payment providers. A completed test flow can provide evidence about that integration path. It cannot, by itself, support a claim about customer sales.

Apply the same distinction to demonstration sign-ups, generated customer profiles and simulated completed jobs. These can help test an application, provided their status remains clear. Label a demonstration where its figures appear, and preserve the distinction in exports or screenshots intended for other people.

Define zero, unavailable and manually maintained

Specify what the card should show when the source cannot be read. For the studio’s definition, zero means a successful check found no eligible active projects. A failed request does not establish that result. Ask for a clear unavailable state, or a clearly dated last-verified figure when retaining an earlier value is appropriate.

Test that condition in the controlled environment too. The review should reveal whether a missing connection substitutes a sample number or an unexplained zero. Agree what the owner should see and who investigates before the dashboard becomes part of a daily decision.

Some figures legitimately come from people. A capacity target, planning estimate or owner-maintained assessment may be useful. Label its basis and last update, and identify who maintains it. An editable planning number can serve its purpose honestly when readers understand how it was produced.

Approve the evidence before sharing the figure

If a dashboard figure will appear in a product listing, sales presentation or public update, review its supporting records for that particular claim. The MaryChuks.com guide to building a listing evidence pack offers a broader way to organise claims, sources, dates and limitations.

Keep a short release record for the dashboard itself: the version reviewed, definitions agreed, test cases checked, live-source comparison and unresolved issues. Assign responsibility for checking it again when the underlying workflow changes. A new project status, for example, requires a decision about whether it belongs in the active-work count.

The leadership question is whether someone can explain the path from a business event to the displayed figure, and recognise when that path has failed. A modest dashboard with traceable records can support a more useful conversation than an impressive total whose origin nobody can establish.

Sources

• v0: Databases — persistence and database integration.
• Supabase: Seeding your database — initial, sample and default records.
• Stripe: Sandboxes — testing without real money movement.

Documentation checked on 25 October 2026. The design studio, project figures and test sequence are hypothetical; the review routine is editorial guidance.