Functional Tests
Run functional performance tests against expected values with witness signatures and attempt history, and verify TAB reports against the design
Functional Tests covers the energized, watched procedures: functional performance tests (FPTs), and TAB report verification against the design.
Functional performance tests
An FPT is the unit put through its sequences with each step held to an expected value while somebody watches. Functional tests run on the same inspection engine as Checklists, narrowed to the functional-test template type, with three things the engine already had that make it read as a test rather than a checklist:
- Expected values. Every line carries the value and unit it is checked against, snapshotted onto the record when it is stamped, and printed beside the answer on the report.
- Witness signatures. The performer signs, the commissioning authority countersigns, and both identities are recorded.
- Attempts. A failed test is rerun as the next attempt. Answers that passed carry over, and every earlier attempt stays readable rather than being overwritten. See Reinspection for how the chain works.
TAB verification
TAB verification is a sibling activity with its own spec-driven engine: balancing reports checked against design values, not a checklist anybody performs in the field.
Determine what is required
Press Determine required reports on the empty state, or Re-check specs from the header.
Struxen reads the project specifications and lists every testing, adjusting and balancing report the project requires, with the acceptance criteria for each one taken from the spec that governs it. Nothing here is a generic list: an item is on it because a spec section asks for it.
Upload and verify
| Report status | What to do |
|---|---|
| Awaiting upload | Upload the balancing report |
| Uploaded | Run verification |
| Reviewing | The run is in flight |
| Verified or Issues found | View results |
A verification pulls every measured value out of the report, matches each unit to its design schedule, and checks the reading against the spec tolerance. The results table gives one row per unit: Design, Measured, Tolerance, Citation, and the Result.
The citation column is the point of the exercise. Each row says where the design value or the tolerance came from, so a reading you dispute can be checked against the source rather than argued about.
Export PDF report produces the verification as a document you can send.
Struxen reads the first 20 pages of an uploaded TAB report. A long report with its summary tables past page 20 is verified from the pages that were read, not from the whole document.
Runs
Report determination and TAB verification both run on the server. Starting one opens a run view showing what the run is doing; the work continues if you navigate away. Both are metered AI operations and spend the project's compute credits. See Billing and access.
A TAB verification writes into the project's findings queue, so a failing check is triaged in the same place as everything else.
Limits
| Pages read from an uploaded TAB report | First 20 |
Troubleshooting
A verification reports fewer checks than the report contains. Check the page limit above. The uploaded document may carry its measurements past the pages that are read.
Everything is disabled. You are on the shared demo project, which is read only.