Review a business model with AI

Model Review is a heavyweight AI analysis that reads your business model against requirement documents and returns a scored, severity-tiered report. Use it when you want a structured second opinion on whether your model covers the right concepts, honors naming conventions, and aligns with your organization’s documented standards. It is separate from the deterministic lint checks that run automatically in the background: lint is instant, rule-based, and always on; Model Review is advisory, runs on demand, takes a minute or two, and costs AI tokens.

When to run a Model Review

Run a Model Review when:

• You have finished a draft model or a significant revision and want to check it against your requirements before reviewing with stakeholders.
• You have loaded or updated requirement documents in the knowledge base and want to see how the current model measures up.
• Lint findings are all clear but you suspect gaps in coverage, naming, or business alignment that rules cannot catch.

Model Review does not replace lint. Lint fires continuously and catches schema-level rule violations immediately. Model Review reads intent: it uses the model’s purpose, requirement documents, and your organization’s foundations to judge whether the model is heading in the right direction.

Before you start

Model Review reads your requirement documents as its primary reference. If you have not yet uploaded your requirements to the knowledge base, do that first (see Upload documents). The review is only as useful as the documents you give it.

Launch a review

Open the Ask AI panel from the business model you want to review and select Review business model from the skill list. The launch form has three sections.

Requirement documents. Pick the documents from your knowledge base that the model should be measured against. The picker shows documents that are Ready and not archived, grouped by organization and project. Select as many as are relevant; the form shows a count of what you have chosen. At least one document is required.

Depth. Choose how thorough the analysis should be:

• Fast: focuses on the highest-confidence gaps, things clearly missing or misaligned. Faster and cheaper. Use it for a quick directional check.
• Balanced (the default): covers the main coverage, naming, and alignment findings without going deep on edge cases. The right choice for most reviews.
• Thorough: the most thorough pass, covering coverage, naming, alignment, relationships, business rules, and edge-case gaps. Takes longer and uses more tokens. Use it before a formal design review or when you know the model is complex.

Cost and time confirmation. Because Model Review involves a multi-step analysis across potentially large documents, it shows you an estimated token cost and approximate run time before you confirm. Review the estimate, then click Start review to proceed. The review runs in the background; you can watch it progress in the Ask AI panel or come back to it from the panel’s history control.

Read the report

When the review finishes, the report appears in the Ask AI panel, and you can reopen it later from the panel’s history control. It is organized into recommendations, each with:

Severity tier. One of three levels:

• Critical: the model has a significant gap or misalignment that would likely cause problems in downstream use. Address these before the model is finalized.
• Recommended: an improvement that would make the model clearer, more complete, or more aligned with your requirements. Worth acting on but not blocking.
• Optional: a minor refinement, a stylistic suggestion, or an observation. Low priority; consider it when you have time.

Score. A numeric signal reflecting how well this area of the model currently meets the requirement. Higher is better. Use scores to prioritize: two Recommended findings at very different scores are not equally urgent.

Why context. Each recommendation carries three parts:

1. What the model currently has (or does not have) in this area.
2. What the requirement document says should be there.
3. Why the gap matters and what a good resolution looks like.

Reading all three tells you whether the finding is a genuine gap or a judgment call, and gives you enough to act without switching back to the requirement document to re-read the relevant section.

Act on findings

Each recommendation has one or more actions depending on its type.

Actionable recommendations (those with a clear, specific change the AI can propose, such as adding a missing entity, adjusting a definition, or renaming an element to match your conventions) show an Apply button. Clicking Apply opens a preview of the exact change the model will make: review it, then confirm. The change goes through the normal branch-and-review flow, so nothing is applied to main until you commit.

Advisory recommendations (observations about alignment, coverage gaps, or structural decisions that require human judgment) cannot be applied automatically. They have two responses:

• Acknowledge: marks the finding as seen and intentional. Use this when you have read the finding, understood it, and decided it reflects a deliberate design choice or a known trade-off. Acknowledged findings are still visible but are styled to show they are resolved.
• Dismiss: removes the finding from the active list without acknowledging it as intentional. Use this when the finding is not relevant to your model’s purpose.

Re-run and the suppression reveal

You can re-run Model Review at any time from the same launch form. Each run is independent: it re-reads the documents and the current model, so findings from a previous run that you have since resolved should not reappear.

Findings you dismissed in a previous run are suppressed by default in new runs for the same model and document set. If you want to see dismissed findings again, the report carries a line counting them, reading something like 2 previously-dismissed suppressed (show). Select show on that line. This reveals the full list, including dismissed items, so you can reconsider a dismissal or confirm it still applies after the model has changed.