The design record

A review has a scope. A reviewer gets the revision you name and returns findings anchored to it, each with a severity and the change requested. A professional's report is signed in their own name, against one revision hash, with their limitations stated. A signature stays with its revision.

A version in a product family other than the house (a steel portal, a fabric hall, a pipe run and the rest) is reviewed the same way. A comment can name a part the family lays out for that version and keep the view it was written on. "View change" sets the reviewed version beside another saved version of the same design and marks the parts that differ: for the steel portal and the fabric hall, piece by piece by the family's own comparison (what stays, moves, is new, comes out or is made again); for the other families, by comparing the parts the model draws and their counts and lengths, which is stated as such.

The findings can be tracked as a case and answered with another saved version, an invited reviewer can report against a package built from the reviewed version, and a scoped expert's statement binds to that version. When a later version is shared, the statement stays with its own version, and the later version gets its own review.

A workflow counts as qualified for a family and a jurisdiction only when four things hold at once: a golden fixture set exists, its fixtures cover the boundary of the envelope and not only its interior, the expected results were verified by somebody other than the kernel that produced them, and a named professional in that jurisdiction accepted the check definitions at a stated version on a stated day. Until then every result reads advisory and lists the conditions that remain.

A revision is checked by the drawing check, the company library audit and the regulation rule sets a named engineer selects. Each finding stays connected to its source, rule version and design revision, and the result shows what was checked, what needs attention and what remains unassessed.

The first use is an audit of designs that already exist. A customer's designs are imported, their recurring components, patterns and checks are written down as a library an engineer accepts, and each existing design is then compared with that library and its context. The audit lists weaknesses and faults with a recommended fix for each, and lists what it could not assess. This is scoped pilot work with a named engineer, supported in Nordform by a rule-based check of an attached PDF or DXF drawing (title block, parts list, profile and dimension conflicts), and a company Standards workspace.

It records each catalogue and model with the permission the importer states, reads a catalogue spreadsheet, or a PDF catalogue with a text layer, into components, and keeps a library in which each component and each of the company's own property thresholds is accepted by a named engineer. It audits an IFC model against a published version of that library: members for profile, grade and stock length; walls, slabs and footings for the named product, its thickness and, for a block wall, the block's module, where the model states them (a thickness or length that is off is recommended as a fix, not written).

It compares the parts lists of checked drawings with the model's members where a design has both, and shows a revised model beside the original, member by member, with the values that changed. The audit can also test transcribed regulation rule sets a named engineer selects, against facts the IFC model states or the engineer states; a rule without its facts is listed as not assessed.

From the model it reads storey count and storey height (a level holding only the roof is not counted), building height where the building states its ground elevation and the top storey its height, exit and internal door widths where a door states its clear width (an overall width is never read as a clear one), room height from each space's finished ceiling height, occupant numbers where the spaces state them, the building's stated fire class and sprinklers, fire ratings of load-bearing elements, stair risers and goings, and guard heights.

A fact is read only when every element it covers states it; otherwise the fact table names the elements, and an engineer can state it instead. Which doors are on the internal route, travel distances and compartment areas are left to the engineer. Anyone in the company can report a fault found in the workshop or on site against a design revision, with photos; a named engineer confirms or rejects it, it is listed with the findings and in the audit record as a field report, and a fault confirmed at two design revisions on the same profile or property can be proposed as a house rule, which counts only once an engineer accepts it.

When the library changes, the workspace shows which designs and steel-portal designs use each component, and which members of each design audited against the earlier version would newly fail or pass; a named engineer chooses which designs to audit again, and earlier audits stay as recorded. A Measures step reads from the record the days from a design’s registration to its acceptance, correction rounds, confirmed findings per design, confirmed workshop and site reports per accepted design and rework after release, each beside a baseline the company states with its source; hands-on hours are only what people log.

The same workspace answers plain requests typed in the chat (English or Finnish; the answers are in English): what is open on a design, an audit run, why a finding was raised and what it recommends, where a library component is used or what dropping it would change, and a workshop or site report prefilled to file. The answers are read from the workspace record, not written by a model, and a decision reserved for the named engineer appears only as a button for that engineer.

Engineering approval stays with the named engineer.

A context pack is source material. A requirement becomes a check through an explicit check definition and engineering review of the applicable jurisdiction, edition and project scope. Automated findings support a responsible engineer's review; compliance and approval come from that engineer and the authority.