Design and Engineering handbook

Design answers four questions:

• What is the current drawing? Not the one printed last month — the issued revision.
• What has been asked, and answered? Queries from site and the client, with the answer attached to the question.
• Does it coordinate? Whether the structure, the services and the architecture actually fit together.
• Who has been told? A revision nobody received is not an issue.

Because ConstruC is department-first, design owns drawings, models, specifications and the answers to queries, while Finance holds the money and Site holds the works. The value is in the seams — and design sits on more of them than any other department.

The one idea to hold onto. A drawing is not a file, it is the current answer to a question, and it has a history. Every markup, measurement, query and revision stays attached to the sheet it is about, so a year later you can see not just what was built but why it changed.

---

FIG 2.1 — the loop. It closes only when the revision reaches the people working to the old one, which is what transmittals are for.

---

FIG 3.1 — the design link map. Design issues outward to three departments and the client, and receives questions back from site and the client.

---

A live collaborative whiteboard for the department. Several people edit at once, each with a visible cursor, and comments hang off the board rather than off a chat thread somewhere else.

It is where an idea is worked out before it becomes a drawing: options sketched side by side, a card turned into a task when it becomes real work, and a board shared with the client for sign-off when a direction needs agreeing.

FIG 4.1 — the canvas is the stage before a drawing exists, and it leaves a record: what was considered, what was agreed, and what became work.

The value is that the thinking is not lost. A decision argued out on a whiteboard in a room leaves nothing behind; the same decision here keeps the options that were rejected and the comment explaining why.

---

Three levels, and the distinction matters:

FIG 5.1 — set, sheet, version. The history is the point: superseding a drawing never destroys the one people were building to.

A sheet keeps every version it has ever had. Opening a sheet gives you the current one; the history is beside it, so "which revision was on site in June" is a question with an answer.

---

The viewer is the department's working surface, not a PDF preview.

Markup layers. Annotations are drawn on the sheet and each one is either personal or shared. Personal markups are your own thinking and nobody else sees them; shared markups are the department's. That distinction is what makes a review usable — you can scribble without publishing.

FIG 6.1 — why the distinction matters: without a private layer, nobody sketches a half-formed thought on a live drawing.

Measure. Before measuring, the sheet is calibrated: you tell it a known distance and it works out the scale. Measurements taken afterwards are real dimensions rather than screen pixels, which is what makes them worth quoting.

Compare. Two revisions of the same sheet, overlaid, so what actually changed is visible instead of remembered.

Calibrate before you measure, once per sheet. An uncalibrated sheet cannot give a real dimension, and a measurement quoted from one is worse than no measurement.

---

An issue is a question or a defect pinned to a place on a sheet — not a comment on a document, a pin at a coordinate. It carries a title, a description, an assignee and a status:

Open · In progress · Resolved · Closed · Void

Pinning with an assignee raises the query formally and puts it on somebody's list, rather than leaving it in a conversation.

---

This is the most controlled sequence in the department, because it ends with a drawing changing.

FIG 8.1 — the resolution workflow. It always returns to the person who asked.

Three rules are enforced, not merely expected:

• Only the assignee or a manager may submit a resolution. The person asked to answer is the person who answers.
• Only the requester or a manager may approve one. The person who asked decides whether they have been answered.
• You cannot approve your own submission. If you submitted the revision, somebody else signs it off.

Where an issue is escalated to a formal RFI, the two stay in step: submitting a resolution moves the RFI to in review, approving it closes the RFI, and rejecting it sets revise and resubmit.

---

An RFI is the contractual version of a query: a numbered request for information, with a type, an assignee and a due date, moving through:

Draft · Pending · In review · Approved · Approved as noted · Revise and resubmit · Rejected · Closed

"Approved as noted" exists because real answers are often conditional, and forcing a conditional answer into a plain approval loses the condition.

An RFI can be pinned to a drawing sheet or to a point in a 3D model, so the question and the geometry it is about are not two separate records somebody has to correlate.

A draft is not a question. An RFI left in draft has been asked of nobody. If it matters, submit it.

---

The submittal register tracks what has been submitted for approval and where each item stands. It reads from the same records as RFIs, filtered to submittal-type items — so a project with no submittals shows an empty register rather than a broken one.

---

A transmittal is the formal record of what was sent, to whom, and when. It lists the documents issued and the recipients, and each recipient gets their own link rather than an account.

Because each link is per-recipient, opening it is evidence that the issue reached that person. Links can be given an expiry and can be revoked, and a revoked or expired link stops working rather than quietly continuing to serve the documents.

FIG 11.1 — a transmittal is the proof half of issuing. A revision nobody received is not an issue.

---

Revit, DWG and IFC models are uploaded, translated, and opened in a 3D viewer in the browser — no desktop licence needed to look at the model.

The point is not the viewer, it is what you can pin to it. An issue or an RFI can be anchored to a point in the model, so a clash between a beam and a duct is recorded where it physically is, and the person who opens it lands on the geometry rather than reading a description of it.

Models are also where quantities come from for takeoff, which is why QS cares about them as much as design does.

---

Models carry an owning department, and this is worth understanding because it decides visibility.

FIG 13.1 — model visibility. The card on the list tells you which of these applies, in words.

A model uploaded now takes its uploader's department automatically. A model with no owner is a legacy upload from before sharing existed, and it stays visible to everyone deliberately: turning sharing on was never allowed to hide a model somebody was already using.

Check the label. The models list says "Owned by Design · shared with QS" or "Project-wide" on each card. If it says Project-wide and it should not be, share it deliberately instead.

---

Site photographs something that does not match the drawing, notes it, and raises it. Design turns it into a task or an RFI.

This is the loop that normally happens by phone and is therefore never recorded. Here the photograph, the observation, the question and the answer stay attached to each other.

Why this is called out. It used not to work. An observation took the department of whoever raised it and was shared with nobody, so one raised by site was invisible to design — the department it is addressed to. Site raised it; design never saw it. Observations raised outside design are now addressed to design on creation, and design stays on the list whoever else is added later.

---

Work packages and their owners, shared with other departments. One owner per package, task completion rolling up into the package, with a manual override where the roll-up does not reflect reality.

Design uses it to see who owns which package, so a query goes to a person rather than to the department in general.

---

Both exist and both hold their data. They are currently hidden from the menu while they are reworked, at the firm's request — the routes, the API and the records are untouched, and putting them back is a two-line change.

• Finishes is the finishes and materials schedule — what goes where, room by room.
• Specifications is the register of written specs by division, which is what a data sheet is checked against downstream in procurement.

---

Separation of duties on resolutions. Only the assignee submits, only the requester approves, and never the same person for both.

Markup privacy. Personal markups are yours; shared markups are the department's. The distinction is enforced, not a naming convention.

External links are evidence, not accounts. A transmittal recipient gets a link scoped to their own record. It can expire, it can be revoked, and everything it serves is resolved from the link itself rather than from anything the visitor can type.

Roles.

Your company's data is yours alone. Every sheet, model, issue and transmittal carries the company that owns it, and every query is scoped by it. Which company you belong to comes from your signed-in session, never from anything the request can set.

Department boundaries hold. A design lead reads design and the shared programme. Finance, QS, procurement, site and equipment screens are refused at the data layer, not merely hidden from the menu.

---

The working discipline

1. Calibrate a sheet before quoting any dimension off it.
2. Keep personal markups personal until the review is ready to publish.
3. Pin questions where they are — on the sheet, or in the model.
4. Answer what is assigned to you; let the requester close it.
5. Check field observations — that is site telling you something does not fit.
6. Transmit revisions. A drawing nobody received has not been issued.

---

This handbook describes Design & Engineering as built. Where a screen says a model is project-wide or a link has expired, that is the platform being explicit about who can see what.