Nordform Connect

Keep design changes connected to their consequences. Nordform brings messages, proposed revisions and declared interfaces into one review process, so teams can see what changed and what needs an answer. People review and adopt each change before connected designs follow it.

Explore the interactive connection diagram ↗

Follow a change across designs

Nordform Connect covers two cooperating functions: the design hub keeps messages and proposals with a design’s history; interface connections record how designs relate and help compare supported alternatives. In supported comparisons, cooling and electrical inputs feed support calculations; reviewed pipe-size, cable-containment and support-spacing changes can create new native design revisions. Adopting those revisions into a delivery package remains a separate decision.

The checks cover their stated inputs and methods and list missing evidence and unresolved interfaces. Engineering approval comes from your engineer.

Review one deliverable set

The delivery overview brings together what changed, what needs your decision and whether you can issue. A delivery-owner administrator can regenerate adopted pipe-run and cable-route packages from their own pinned personal designs into a private bundle of IFC models, SVG drawings, CSV quantities and supporting evidence. One manifest ties the files to the reviewed dependencies. The Waiting view lists what each company owes the others, oldest first, with dates. Each company sees only the packages and interfaces it is shown.

Missing outputs, changed dependencies and unresolved review requirements block issue. After reviewing a complete, current bundle, its preparer can record an immutable issue receipt. The receipt records a concept review of pipe-run and cable-route packages; distributing the files and approving them are separate steps.

Why a design needs an address

The fabricator, the engineer and the owner rarely work in one file. They talk about the design in mail threads, chat channels, review comments and meetings, and the model sits somewhere else. Months later nobody can say which version a comment was about, which request was ever tried, or why a value changed.

Connect makes the design itself the party in the thread. A message is kept on the design as it arrived, and a review comment names the version its reviewer was looking at. What it asks for is tried, not promised. The answer goes back to the thread it came from. And when two firms' designs meet at an interface, the record says who changed what, who accepted it and what is still in dispute.

How a message moves

1. An address. The owner opens an address on the design. It is shown once, can be replaced or closed at any time, and anything that can send an HTTP request can post to it: a Slack channel, a mail forwarder, a Teams or Zapier flow, a shell one-liner, another tool.
2. The message is kept. It is stored as it arrived, with its sender, its channel and its subject, and it never changes. It appears in the design's own chat at the time it arrived.
3. The message is read. The decision model reads it as one of four things: a change request, a decision, a question, or information. The reading is shown with how sure the model was. A message it could not read waits for a person.
4. A change request runs as scenarios. The request runs as a proposal on the latest version, on its own if the owner chose that, or when the owner presses run. Each candidate comes back as a scenario with its checks. On a house design, the chat says above the adopt button which locked dimension, sign-off, selected baseline, hard requirement or recorded decision the scenario touches, and holds the button while the scenario’s check results are out of date. A scenario can be kept, so it outlives its run: it is stored with its check results, pinned to the version it answered, and waits for a decision (see Where it shows in the workspace).
5. The design answers. A question on one of your own designs is answered from the design's record, and nothing is sent until you press Send (see Questions answered from the record). For anything else, once a message has an outcome, the design answers once where it came from: one line in the Slack thread, seconds after the message arrived when it mentioned the app and nothing had to run, or a mail to a sender the owner approved, saying how the message was read and how many scenarios ran, on a personal design with a link to a read-only page of the message and its scenarios. The page stays readable for thirty days. A channel message that was read as no change and did not mention the app gets no reply.
6. A person adopts. A scenario becomes a version only when the owner adopts it, on the same card a chat proposal uses, with the same sign-off questions. There is no approve button in Slack or mail.

A message changes a design only when a person adopts the change, and approval always comes from a person.

Questions answered from the record

When a message on one of your own designs is read as a question, the design drafts an answer from its record. The record is the latest version's inputs, with the version each value last changed in, the checks of a finished run on that version, the decisions that stand, the sign-offs given on that version and the requirements still in force. Each fact in the answer names its source: the version, the check, the decision, the sign-off or the requirement. No run starts, no credits are spent and no model writes the answer. When nothing in the record answers the question, the draft says so and names the version it read.

What the draft may say depends on who asked. A member of the project is told everything. A reviewer is told the version, its checks, decisions and sign-offs, but not the requirements. Anyone asking in Slack, and a mail sender with no other standing, is told about the version only. What is withheld from the asker is left out before the draft is written, so it is never stored in the draft either.

When the message states a quantity, such as "the door is 900 mm wide, is that right?", the draft compares it with the version at the precision it was stated and says whether they agree. It does not add a tolerance. A bare number is tried as millimetres and as metres, and when neither fits, the draft says the unit is unclear. Each comparison is a suggestion you tick into the answer.

The draft waits in Waiting on you as Send answer. Send posts it in the message's Slack thread, or mails a sender the owner approved a link to a page showing what was sent. Dismiss sends nothing. While the draft waits, the automatic Slack reply to the question says only that an answer has been drafted, unless the question names Engineering (see below).

Where messages come from

• Slack. Connect Slack installs the Nordform Slack app into your workspace in one click; you pick the channel on Slack's own consent screen, and messages and mentions there reach the design. Through the Nordform Slack app, a reply in a thread is read with the last six earlier messages of that thread, so a follow-up does not start over. The design speaks there through up to four AI roles, each under its own name: the Lead answers what a message was read as and posts a meeting's follow-up; Engineering says when a new version breaks a check and, when a message to the app names Engineering, answers with the latest check results and the failing checks it still remembers; Fabrication says how many frame members a new version adds, removes or changes, with the member count and total metres before and after; and Cost says which rows of the bill of materials moved and, where the design has a fully priced saved estimate for its construction system, the cost change at the estimates' rates, split into what the quantities moved and what changed rates and allowances moved; otherwise it says why it cannot price the change. Without a saved estimate Cost gives quantities only and says so. Engineering, Fabrication and Cost speak on a personal design, about a new version whose checks have run beside an earlier version's. Fabrication speaks only for the timber-frame house kit and Cost only for house designs. When more than one role has something to say about a version, the first posts and the others reply in its thread, and each says it once. Engineering is on for a design whose address is opened from now on; on an earlier design the owner switches it on under the project's roles. Fabrication and Cost start off, and the owner switches them on there. No role signs, adopts or changes the design. On a personal design the owner can also have the roles say what was done in the workspace: with the setting turned on in the setup that opens from where the design listens in its header (it starts off), the Lead says in the channel when a package is issued, a decision recorded or a version kept, and Engineering when a sign-off is given, one line for each, naming no one and said once. The roles also keep a short memory of each design they are on for: on a personal design, the checks that newly stopped a package and still do, the latest frame and bill figures, and a meeting's decisions and open questions with the words that were said; on a company design, the meeting's decisions and open questions. It is listed under What the roles remember, in the setup that opens from where the design listens in its header, where the owner, or an editor or administrator of a company design, can mark a line as not true any more. The same list keeps, under Engineering and whether or not the roles are on, each change a design run proposed that a failing check stopped from being packaged, with the run that checked it (room layouts aside): the next run of that design is told about the eight most recent and does not propose those designs again, and Try it again takes the line off so a later run may. Where the app was connected before the roles had their own names, the role's name opens the message until the app is connected again. The app reads the channel it joined and nothing private. A Slack app of your own can post to the design's signed Slack link instead; a message posted there is kept but gets no answer.
• Mail. A forwarder posts the mail to the design's mail address: a Gmail script, SendGrid, Mailgun or Postmark. The reply is kept without the quoted thread under it, and a forwarder that fires twice stores one message.
• Reviews. A comment or a change request a reviewer leaves on one of the design's reviews arrives as a message, tied to the version they were looking at. Reviewers are told so above the box they write in. The owner can switch this off.
• Other tools. Notes brought back from a BCF file, and comments on the parts of a delivery document that are drawn from a saved version, arrive the same way.
• Your own code. A JSON or form post to the address. Three webhook events say what happened to a message: hub.message.received, hub.scenarios.ready and hub.run.failed. Four more say what a person did in the workspace on a design that has an address: hub.package.issued, hub.signoff.given, hub.decision.recorded and hub.version.adopted. All seven carry identifiers only. The developer documentation has the addresses, the Apps Script for a Gmail forwarder and the MCP tools.

Designs that connect to each other

A plant is not one design. The cooling package, the power feed, the structure and the controls are designed by different firms, and they meet at interfaces: a heat load in kilowatts, a supply temperature, a load on a slab, a footprint on a site.

In a company delivery, Connect declares those interfaces between packages: the two designs it joins, the quantities they share, their units and the tolerance within which the two sides agree. When a package's new revision is adopted, every interface value it moved is sent to the firm on the other side. That firm accepts it, objects with the value it can take, or asks a question as a request for information. An objection marks the interface disputed and holds the release of both packages until it is settled.

The workspace shows the connected designs of a delivery in its header, each with the state of its interfaces and a mark when your company has to act, and a site map shows the packages where the owner placed them, with links suggested where two packages name the same tag or system or their footprints touch. Values are compared with what the other side states, not with its capacity, and nothing is redesigned on its own.

An interface can also join a structure to the services that run through it: the largest opening the services need and the structure allows, the depth under the structure they occupy and it leaves free, and the load they hang from it and it carries. A pipe run or a set of circuits states its side from its own openings and supports; the structural side states what it allows. When a signal lands on a package whose design has an address, the signal is posted to that design as a message, so it arrives in the thread where the design is worked on and is held there for a person. Inside one building, a services design can also read the structure directly: it names the house or the steel portal it passes through, at one version, and lists the openings it would need through the real members. When the structure gets a newer version, the services design is run again against it with its own inputs unchanged, and what that changed is shown beside the version it read: the checks that moved, and where its package now states a different opening or depth. It becomes a new version of the services design only when someone adopts it, and the structure shows the same result from its side. A package's stated values change only when its firm records a revision.

Designs in other companies

The structure a services design passes through can belong to another company. An administrator of that company shares the design with your company as a host, either from one version onward or from one version through a later one. The share is at one of three levels: Interface only (the outer box, connection points, the support loads its equipment makers state and the spaces that must stay free), Model only (the model of each shared version) or Design context (the model with that version's brief and context). A share made in the workspace lasts 90 days. Revoking it cannot be undone, and the share stays listed with who revoked it. In the workspace, the recipient is chosen from the companies yours already works with, in a delivery or through an earlier share.

In a pipe run or a set of final circuits, Passes through lists hosts shared with you under Shared with you. Choosing one asks the host's side for a link, and the design says it is waiting for them. The host's side confirms the link, and either side can withdraw it. Only a confirmed link is followed. When the host gets a newer version that the share covers, the reading design is run again against it with its own inputs unchanged, and its owner sees what changed. Recalculating spends nothing on either side. A version the share does not cover is not read, and once the share is revoked, the host is not read at all.

A design that is shared only the interface is told when a newer version changes the interface: which connection points, stated support loads, free spaces or outer box changed, measured against the version it reads.

Where it shows in the workspace

When you open Nordform without a link and anything is waiting on you, it opens on Waiting on you: one list across your designs and deliveries of the messages held for you, the tasks handed to you, the designs that follow one you changed, the interface values your firm has to answer, the decisions asked of you, what your company owes in a delivery (requests for information, changed values to answer, objections to settle, releases to sign, packages to issue and links to confirm), what reviewers sent back, the scenarios kept on your designs, the answers drafted for you to send, and the links from another company's design that your side has to confirm. A message that was handed to you as a task is listed once, as the task. Rows are grouped by design, with the designs that need you first. Each row is one sentence and one action. A task is marked done or refused, a decision answered, and a design that follows another updated or kept, in the list itself; any other action opens the place where it is decided. Nothing in the list changes a design until you press its button, and nothing is adopted from Slack or mail. A row from a company design or delivery says so, because its runs use the company allowance. When nothing is waiting, the workspace opens on the last project you had open.

A design's header shows where it listens (its Slack channel, and whether it takes mail) and the interface signals that reached it; on your own designs it also shows the designs that read it or that it reads. Each opens its setup or its list in a side panel. A filter shows only what came from outside in the design's chat. When scenarios have been kept on the design, the header counts the ones waiting and opens them in a list, where each is adopted or dismissed. A kept scenario is marked out of date when the design's inputs, the kernel it was computed with, or the version or rule pack of one of its checks has moved on since it was kept; its adopt button is then held, and it offers to run again on the current version.

On your own designs, the header also has a Graph: the design in the middle, what it reads on one side, what reads it on the other, and the packages it shares an interface with below. A read is drawn as a solid line, an interface as a dashed line and an open recalculation as a dotted line, coloured by state: agreed, pending, or disputed or failing. A withdrawn link stays on the graph, drawn grey. Every line opens the place where it is decided: the link between the two designs, the delivery with that interface selected, or the recalculation on the design that would adopt it. The graph shows one step around the design.

What a person does in the workspace is also written to the design's stream while the design has an address: a package issued, a sign-off given, a decision recorded and a version adopted. Each shows in the chat as one line under the version it happened on, and goes to webhooks as identifiers. If the owner turns it on, the roles also say it in the design's Slack channel (see Where messages come from).

Before you adopt a change in the chat, the adopt card says what adopting would touch: each design that reads this one, worked out again against the version you would make, with the opening, zone depth or support load it would then state; who holds a package of an earlier version; and where the message the change came from was answered. After you adopt, the chat lists what went out with the new version, with each design that follows linked to its own chat.

For companies

A company project can be given an address too. Administrators and editors manage it, everyone with access reads what arrives, and a change request runs as a company run on the company allowance, started by an editor with run authority, never on anyone's personal credits. Administrators and editors can keep a company run's proposal as a scenario, and kept scenarios wait in their Waiting on you. Company webhook destinations hear the three message events; the four workspace action events are for personal designs only. A company administrator shares the design with another company as a host, and confirms or withdraws the links that read it, under Share › Links.

Scope

• Adoption happens in the workspace. An answer in Slack or mail links the page to read.
• When the other firm cannot take a change, its owner decides whether to start a proposal on their design.
• In a company design's own Slack channel, the design answers a question, a run's result or a message it could not read, in its thread, whether or not the app was mentioned.
• A Microsoft Teams flow can post to a design. Answers go to Slack and mail.
• A change request that runs is answered when its run has ended, within minutes. A mail answer, and a message the decision model reads on a second pass, arrive within a few minutes.
• A thread read through the Nordform Slack app carries its last six earlier messages to the design. A mail follow-up is read on its own, and a message through your own Slack app's signed link is kept on the design.
• Reviews, document comments, meeting notes and the other sources are read on a pass every five minutes.
• Answers are drafted from the record on your own designs. A company design answers a question in its Slack channel directly. On your own designs, when Engineering is switched on, a question that names Engineering is answered by Engineering with the latest check results.
• A drafted answer uses the facts the question names, by tag, object, word or kind, and otherwise says "the record does not say". Of a version's inputs, the house inputs are read: width, length, height, roof pitch, storeys, overhang, doors and windows. A design without them is answered from its checks, decisions, sign-offs and requirements. Each quantity comparison waits for you to tick it.
• The Graph and the design's stream cover your own designs.
• A pipe run or a set of final circuits reads a host, one step along the chain.
• In the workspace, a host share goes to a company yours already works with. A first share with any other company is made through the API.
• The adopt card shows what adopting would touch on your own house designs. A family design's change shows what it reaches on its own sheet, and the list after an adoption is kept for the latest version.
• The address is a public URL by construction. Anyone who has it can post, within a limit per hour and per design; closing the address stops that, and reopening gives a new one.

See it

Watch a Slack message move a pump tells one change on a cooling plant: versions, proposals, checks, review, interface contracts, releases and feedback. The plant, its checks and the delivery record run in your browser; the people and what they write are scripted.

Developer documentation · Connectors · The design record · Discuss a project