Build a Prolaborate dashboard

Goal

Turn a set of business questions into a Prolaborate dashboard whose widgets are each backed by a verified query, and finish it by applying a layout plan. This is for an enterprise architect or portfolio manager with edit rights on a Prolaborate dashboard. You end with a saved dashboard of correct widgets on the Prolaborate tenant, each widget's data checked against its query, plus a layout plan in grid units that you apply by hand.

Where it runs

This scenario needs browser control. It uses no MCP server operation.

How it works

An architect wants Westbrook Bank's application portfolio visible to non-modelers. The assistant probes the repository to learn what the data can support, chooses a widget for each question, writes the query each widget requires, verifies each query by its row count before saving, saves, and then hands back a layout plan. Prolaborate tiles arrive at the smallest size, and a chart is unreadable at that size, so you finish the dashboard by dragging and resizing. The assistant cannot do that step and says so.

Before you start

• Browser control (a built-in browser or Chrome) and a signed-in Prolaborate session. No server is needed.
• A Prolaborate repository that is active and that contains the model content to be charted.
• You have permission to create or edit dashboards on that repository. A read-only identity cannot save.
• The elements being counted already exist. A chart counts existing elements; it does not create them.
• Know which SQL engine the repository runs on, or let the assistant establish it. Prolaborate runs its queries on the repository's own database.

Steps

1. You Sign in to Prolaborate in the browser. The assistant never enters credentials.
2. AI Power Tools prol-start-here runs the preflight: it confirms the identity, the Prolaborate version and the active repositories. You confirm the repository and the identity the dashboard will be attributed to.
3. AI prol-dashboards takes your business questions. You supply them and say whether to create a new dashboard or edit an existing one.
4. AI Power Tools prol-dashboards probes the data in the chart wizard: first a census of what the repository holds, then a check of which tagged values are usable as measures. It reads the preview and cancels without saving. The assistant interprets the readings.
5. AI prol-dashboards chooses a widget per question, using the question-to-widget guidance, the chart-type catalog and cardinality thresholds. You approve the widget plan, including any pushback (a pie of 14 stereotypes is declined in favor of a bar, a top-N, or a pie over criticality).
6. AI Power Tools prol-dashboards establishes the SQL dialect and reads each chart type's contract from the wizard's sample. Markers in the sample show whether the engine is MySQL or SQL Server.
7. AI prol-dashboards builds each widget: it adds the tile, names it, and for a chart picks the chart type first, pastes the query and runs it.
8. AI Power Tools prol-dashboards reads the result of each run: the row count and the actual column values in the preview.
9. AI prol-dashboards works the presentation step: per-type options, label names, and for a percentage card the symbol and suffix. You answer if the assistant asks about the rich-text Security toggle; it never turns that off without asking.
10. AI Power Tools prol-dashboards saves the chart, then saves the dashboard. They are two separate saves. The assistant states the identity first when saving over a dashboard others use.
11. AI Power Tools prol-dashboards verifies from a different surface: it re-opens each widget's configuration, reads the dashboard's structure, and reads the saved chart's query from the widget's own menu.
12. AI prol-dashboards hands back the layout plan: a list of tiles in grid units (column, row, width by height) with three operating notes. You apply the plan.
13. You Apply the layout by dragging from the crosshair handle in the tile header, working top to bottom, then save the dashboard at page level.

Step 4. The probe tells the assistant which charts are possible before it builds any. A road map over a repository with no date-like tagged values renders an empty axis and looks like a styling problem, so the assistant reports what the data cannot support and stops. A tag is a usable measure only if it is numeric and varies.

Step 5. A nested pie and a heat map are rejected for "which is biggest", because they give every group an equal share, so a large cell means a small group. A "one number" question becomes a card, and a list becomes a report.

Step 6. A dialect error is reported as "No results found", which is the same as a legitimately empty result. The assistant treats an empty result as a probable query failure first and narrows it down.

Numbers that disagree with the model. Check how the connector stereotype a query filters on is stored. Element stereotypes are stored by their bare name. In the Westbrook model, the connector stereotypes the technology declares (Uses, Flows and realizes) are also stored by their bare name, with the binding to the technology held separately, and informal ones such as part-of come from no technology. Do not assume a declared connector stereotype is stored in qualified form, or that it is not. The assistant reads the resolved value from the identified placeholders the chart wizard shows when the query is executed, rather than guessing either form, because a filter written for one form fails silently on the other.

Step 7. The first interaction after a page load is often swallowed, and clicks by element reference can fail silently where a click at screen coordinates works. The assistant checks state after each click and retries once.

Step 11. A success response is a claim, not evidence. The assistant compares the rendered tile with the row count from the run. A road map silently drops rows whose date fails to parse.

Step 12. An example layout plan for Westbrook Bank:

Prompts to use

Opening:

Follow-ups that drive each phase:

• "What did the census show, and what can't the data support?" (step 4)
• "Go ahead with that widget plan, but use a bar for the stereotype question instead." (step 5)
• "Which SQL dialect is this repository, and how did you confirm it?" (step 6)
• "Show me the row count for each query before you save anything." (step 8)
• "Re-open each widget and confirm what saved." (step 11)
• "Give me the layout plan." (step 12)

Recommended models

Ratings are guidance based on the kind of reasoning the scenario needs, not measured benchmarks.

Checking the result

• Correct. For each widget, the row count and sample values from the run match the saved tile. An independent count in EA (or a separate count query in the console) matches each card. The stacked column has lifecycle on the axis and criticality as the color. No nested pie or heat map is used for a size question. Red flag: a tile that shows a different number from its own query.
• Complete. Each question from step 3 has a widget, or the assistant said why the data could not support one. Every widget was saved, and the dashboard was saved after that. Re-opening each widget's configuration shows what was entered, and reloading the dashboard shows all tiles.
• Nothing unintended changed. The assistant created or edited only the dashboard named in step 3. Blocks it did not author, including their notes field, were not touched. The rich-text Security toggle is as it was.
• Honest about layout. The final message says tiles are at the smallest size and unarranged until you apply the plan.

Variations

• Edit an existing dashboard. The assistant reads its definition first and lists its tiles. It never rewrites a block's notes field on a block it did not author, because that destroys a chart block's binding and queries.
• Read-only: what is on this dashboard? Steps 2 and 11 only.
• A repository on SQL Server. The same widgets, with the SQL Server form of the sample read. The pattern-matching expression in the tagged-value probe does not run on SQL Server as written.

Limitations

• The skill cannot arrange tiles. A single click-drag is silently ignored by the grid, and the assistant neither retries it nor claims a layout was applied. Resizing pushes other tiles, and the push cascades.
• Two widgets are blocked. The lifecycle road map needs a life-cycle definition bound to a stereotype, and the integration reports need an integration registered by the tenant owner, with external-system credentials. The assistant reports the block and never enters external credentials.
• Changing a chart type wipes the query. Settle the type first.
• Saves are visible to others immediately. Saving a change to a dashboard someone else uses changes what they see. The assistant states the identity first.