Model Checks

Overview

Verification → Model Checks runs a catalogue of rules over every item in the project and lists what each rule finds. The rules look for gaps that make a model hard to trust or review: missing names and numbers, items that stand alone, actions nobody performs, interfaces that carry nothing, requirements that are not allocated or not verified, risks without a handling plan and measures that miss their threshold.

The checks run again whenever the model changes, so the page, the Model checks card on Home and the badge on Verification always agree.

Concepts

• Rule: one check with a number (for example Requirement.10), a heading that names what it finds, a statement of what a good model looks like, and a fix. Rules are grouped by the class they check: Global (every item), Action, Asset, Conduit, Input/Output, Requirement, Risk, Test Case and Measure.
• Finding: one item that breaks one rule. A finding can name related items, for example the duplicates of a name or the children of a parent.
• Severity: each rule reports as Error or Warning, or is set to Ignore and does not run. The default is Warning.
• Ignored finding: a finding you have accepted for one item. It no longer counts, and Show ignored lists it with Restore.
• Applicable check: a rule that ran over at least one item of its class. The header line counts how many applicable checks have no finding.

How to use it

Run the checks before each review, after a large import, and whenever Home shows model check errors. They answer one question: what in the model needs attention before someone else reads it?

Work through the findings

1. Open Verification → Model Checks. The header line shows, for example, "84% of applicable checks pass", followed by the number of errors and warnings and the change since the last run.
2. The list is grouped by rule, errors first. Click a rule heading to open it; its description says why the rule matters.
3. For each finding, click Fix. The fix dialog shows the item, the rule and the suggested fix: a field to fill in, relationships to add, duplicates to merge, or a button that opens the item or its diagram.
4. Save the fix. The finding disappears and the counts update.
5. When a finding is intended (for example an action reused under two parents), click Ignore.

Focus on one area

1. In the facets on the left, tick Errors under Severity to see only errors.
2. Tick a class under Class (the class of the item with the finding), a rule under Rule or a label under Label. Ticks in one facet combine with OR; facets combine with AND. Each value shows how many findings it has.
3. Type in Filter findings to match an item name or a rule heading.
4. Click Clear facets to show everything again.

Review one item's findings together

1. Choose Group by entity next to the filter.
2. Each item is listed once with all its findings, in number order. An item with an error shows an Error badge in its heading.

Worked example: the CubeSat EO-1 demo

1. Open the CubeSat EO-1 demo project and go to Verification → Model Checks.
2. Tick Requirement under Class. The rules that remain show which requirements have no parent, no allocation (Requirement.8) or no verifying test case (Requirement.10).
3. Open Requirement.10, click Fix on a finding, and link the test case that verifies it. The finding leaves the list, and the header line moves up.
4. Choose Group by entity to see every remaining finding of one requirement at once.

Tips

• Set the rules your team treats as blocking to Error in Settings, so Home lists them as problems.
• Ignore a finding only when it is intended, and say why in the item's description or a comment. Show ignored lets reviewers see what was accepted.
• A long list of naming findings after an import is usually fixed fastest by editing names in the Database.
• Run the checks before saving a baseline, so the baseline does not carry known gaps.

The page

Top bar

Header line

• "N% of applicable checks pass": red when any finding is an error, amber when there are only warnings, green when there is nothing to fix.
• The number of findings, errors and warnings.
• The change since the last run on this device, for example "3 findings fewer than the last run." The last run is recorded when you open or leave the page and when you click ↻ Run Checks. The first visit says "First run on this device."

Toolbar

• Group by rule (default) or Group by entity. The choice is remembered on this device.
• Filter findings: matches item names, rule numbers and rule headings.
• Expand All and Collapse All open or close every group.

Facets

Counts follow the other facets and the filter, so they show what ticking a value would leave.

Findings

Each finding shows the item (or, grouped by entity, the rule), the note (for example "Vague words: adequate, TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date." or "14 children"), the related items, and the buttons Fix and Ignore, or Restore for an ignored finding. Ignore and Restore are one undo step each.

Fixes

Settings

• Children per level: Action.9 and Asset.9 report a parent with more children than this number. The default is 9, from the guideline that people handle about 7 ± 2 items at one level. Allowed values are 2 to 99; another value shows "Children per level must be a whole number from 2 to 99."
• Severity per rule: Error, Warning or Ignore. An ignored rule does not run.
• Restore Defaults sets every rule back to Warning and the children per level back to 9.

Settings are stored in the project, shared with everyone on it, and undoable.

Rules

Notes on the rules:

• Requirement-writing rules cite the INCOSEInternational Council on Systems Engineering The professional society for systems engineering. It publishes the Systems Engineering Handbook. Guide to Writing Requirements: vague words (R7, vague terms; R8, escape clauses), "shall" (R1, structured statements) and capital letters (R39, style guide). The full writing check is Requirement Quality.
• Tasks, test cases, state transitions, ports and resources are skipped by the Action and Asset rules; the Global rules still apply to them.
• A decomposed item counts as performed, fed, productive or traced when any of its descendants is.
• Ports are interface points, not parts: they do not count as children, and a conduit on a port counts for the asset that owns it.
• Use cases (Actions with the Use Case label) are exempt from the verb rule and the input/output rules.

Messages

Limits

• The list shows up to 200 findings per group; filter the list to see the rest.
• The change since the last run is kept per device and browser, not in the project.
• The public API and MCP tools return the same findings with the project's settings; they do not store results.

Related

• Verification, Traceability, Interfaces
• Help: Model Checks, Requirement Quality, Home