Documents & drawings

The document and drawing register in IssuesId is built on three principles: immutable revisions, withdraw-not-delete, and pins survive uploads. Together they give you a record that holds up when someone asks "what was actually issued on the 14th?"

Immutable revisions

When you upload a new version of a document, the old version isn't replaced — it's archived as a prior revision. Every revision keeps:

→The original file, byte-for-byte.
→The uploader, timestamp, and any revision notes.
→The list of distributions that referenced it.
→The pins (for drawings) that were placed against that revision.

You can scroll back through a document's full history at any time. Nothing is ever overwritten.

Withdraw, don't delete

If a document is no longer current — superseded, cancelled, or issued in error — you withdraw it. Withdrawing:

→Marks the document inactive (it disappears from default registers and search).
→Preserves the file and its full history for audit.
→Leaves prior distributions intact so the proof-of-receipt trail isn't broken.

There is no "delete" for issued documents. This is intentional — if you could delete a document, the audit trail couldn't be trusted. The withdraw-not-delete model is what makes the register defensible.

Drawings and pins

Drawings are documents with one extra trick: you can drop pins (and free-form Fabric.js markup) on them to flag defects, locations, RFIs, or inspections.

Pins and markup are tied to a specific drawing revision. That has two practical consequences:

→Looking at rev B later, you see exactly what was pinned on rev B at the time — the markup is preserved with the file it was drawn on.
→Uploading a new revision starts a fresh markup canvas on that revision. Existing pins stay on the prior revision; they don't auto-migrate to the new geometry (which is usually what you want, because the layout has likely shifted).

The underlying defects, RFIs, and inspections the pins represent are independent of any single revision — they live in their own registers and survive new uploads. The pin is the visual marker; the defect or RFI is the record.

The register

The register is the searchable, filterable list of every document and drawing on a project:

→Filter by status (current / withdrawn / superseded), type, revision, or discipline.
→Sort by upload date, name, or revision date.
→Bulk download a current revision set as a single zip.
→Cross-tenant search is disabled by design — you only see documents from projects you're a member of.

Versioning by revision letter or number

Each revision has two fields: an ordinal (auto-incrementing integer used internally) and a label that's free text. The label is what users see and what appears in registers and distributions, so use whatever convention your organisation already follows:

→A, B, C… for design-style versioning.
→00, 01, 02… for engineering-style versioning.
→2025-04-12 for date-stamped revisions.

Pick one convention and stick with it across a project — mixing styles inside the same register gets confusing fast.

Upload, sign-off, distribute

The typical drawing flow:

01Upload a new revision with a short note ("Updated stair geometry per RFI 14").
02Mark superseded any prior revision the new one replaces.
03Distribute to the recipients who need to know (with acknowledgement required for contract documents).
04Track acknowledgements from the distributions panel.

The distribution carries the revision number forward, so even if you upload rev D tomorrow, the recipients of rev C have a record of what they actually got.