The customer’s order, readable by their own tools

When a company orders a design, the work lands on their side as an email with a link. Until now that link opened one offer: the drawings, the offer text, and three buttons to accept, decline or ask for changes. That covers a yes. It does not tell the buyer what they have been sent over the weeks, what changed between versions, or what the design actually rests on.

The page behind the link is now the customer's order.

What the customer sees

• Where the order stands. Which of the designs sent to them is on the page, whether the designer has saved a newer version since, what they answered, and how many of their change requests are still open.
• What stands behind the design. The status the record gives the version: not checked, advisory checks only, or signed off by name and date. If there is a signed statement for this exact version, the page shows what it covers, what it does not assess and its limitations, and whether it was signed on the same inputs the page shows. The page also says what it does not share, such as the reviewers' comments.
• Every version they were sent, oldest first, with what changed between each pair: dimensions, openings, frame members and member length, recomputed from the saved inputs of both versions. Versions the designer has not sent them are not described.
• Every file with its hash. Under each drawing and document is the SHA-256 of the exact bytes they will receive, so a copy in their own document system can be checked against what was sent.
• One file with everything. A JSON export of the order: the design inputs in metres, every version sent with its input hash, every file with its hash, the evidence, their answer and their requests.

Asking for a change

A change request is the customer's own words, recorded against the version on their page. It changes nothing by itself. The designer reads it in the workspace and resolves it once, either by naming the saved version that carries the change or by declining with a reason. The customer sees the resolution on their page. A request can be made on an offer that has been answered or overtaken by a newer version, because asking for a change is how the next version starts. Only an offer the designer has withdrawn refuses one.

Their own tools

Buyers increasingly have an assistant of their own, or a purchasing system that would rather read an order than have someone retype it. From the order page the customer can make a connection token for that. A client that signs in through the browser, such as a connector in the Claude app, can be pointed at Nordform and connected by the customer pasting the same link they were sent.

The connection reads exactly what the page shows: the order, the versions and what changed, the files and their hashes, the evidence and the change requests. It can download a file and export the order. It can do the two things the customer can do on the page, ask for a change and answer the offer, and an answer must name the version on the page so it can never apply to a design nobody looked at. It cannot change the design, start work, spend anything or reach any other order. It ends when the link ends, stops at once if the designer withdraws the offer, and the customer can revoke it from their page. Every request it makes is recorded without its content.

Scope

• Site data, the customer's own standards and existing drawings come in by email.
• A new offer is announced by email. A resolved change request shows on the page.
• The page computes what changed between versions of a house design. For other kinds of design, the designer explains the change.
• An answer records that the customer said yes or no to a design and an offer. Engineering approval, permits and purchases happen outside the page, and nothing is charged there.