Check where it breaks
A design holds values that were checked against published material at a stated version. Change one and results that depended on it can stop being true.
How a change is made
A change is a proposal against one revision: the inputs before, the inputs after, and a written reason. Nothing moves until the proposal is adopted, and adopting it makes a new version. A proposal that claims to answer a check finding is verified against that finding first; a claim that cannot be verified is not adopted.
What a result is bound to
A check result belongs to the revision it ran on, and carries the rule it read, the version of the pack it read it at, and a hash of its inputs.
The requirement register holds one row for each thing the design must satisfy, with the checks that verify it. The rows are derived from five places, not maintained by hand. The register opens with a score: how many requirements the checks mark at full marks, and for each one short of that, the single step that would bring it there. /score in a chat runs the checks and opens it. Scoring changes nothing in the design. The register downloads as a compliance matrix, in Excel or CSV: one row per requirement with where it is answered, its status and its owner, then the unanswered ones and those answered outside the checks.
| Where a requirement comes from | Example |
|---|---|
| The brief, as it was read | "Two bedrooms, ridge under six metres" |
| Each context package | What a country's package asks of any design under it |
| The kit's own checks | What the family requires of every design, written down or not |
| The project's intent line | An ask someone stated later, with its owner and its strength |
| The site's adopted facts | A fact about the plot that the site checks read |
Each row's state is read off the results: verified, failed, open, unverified, stale, unmet or not checkable. A row is unmet when the design no longer holds a value that was asked for, however green the check on the value it holds instead. It is stale when what it was verified against has moved.
When a pinned version moves
When a guide, table or country package gets a new version, a result pinned to the old one is marked stale rather than recomputed or left standing. One rule decides staleness, so every surface says the same thing about a result.
A sweep does the same across projects: it names the projects whose latest revision was checked against something that has since changed, and what moved. A moved kit contract is reported beside it, but does not by itself make a check stale.
Before a change is saved
In the workspace, a change set in the input list of a family design, such as a steel frame or a pipe run, is worked out before it is saved; over the API the same answer comes back for a steel portal frame or a pipe run. You see the checks it moves, with their state before and after; each of your designs that reads this one, and whether its agreed term would still hold; and what the change would leave on the current version: sign-offs, which do not carry to a new version, open review findings and whether the change removes, moves or leaves alone the part each is on, decisions still waiting for an answer, and customer offers still open.
When a check on a family design fails, you can ask why. The newest earlier version where it passed is found, and each input changed since is put back on its own and the check run again. An input whose return makes the check pass is the cause; the others are listed as ruled out, or as untestable when the design cannot be built with that input alone. When no single input explains it, it says whether all of them together do, and a check that has never passed has nothing to compare with and says so. It names what moved, not a value to set.
Designs that read each other
A pipe run or a final circuit can read a structure, such as a steel frame or a kit house, as its host. When the host is saved, each design that reads it is recalculated against the new version, with its own inputs unchanged, and its owner sees what changed in its checks. The host can be another company's design, shared with yours: its reading design is then recalculated only once the host's side has confirmed the link, and only against versions the share covers. Nothing changes in the reading design until its owner adopts the new version or keeps the old one. Where the reading design agreed a term with the host, such as the height of the lowest member, and the new version no longer keeps it, or no term was agreed, a decision goes to the reading design's responsible engineer, or to its owner when nobody holds that role.
Scope
- One step deep. A change reaches the designs that read the one changed: those in your account, and those in another company whose link to it both sides confirmed. Pipe runs and final circuits read a host, so the chain is one step long. A design shared only by its interface is told what changed at the interface.
- People approve. Expert opinion, manufacturing release and an authority decision are separate states, each given by the person responsible.
- Advisory until a professional accepts. Every result says so on its face until a named professional accepts the workflow.
Where to go next
How the engine works, the design record, for kit makers and for engineers.
Explore Nordform ↗