What Got Shipped Today - 4/9/26 - Submittals land end to end, the Document Register reaches DS Site, and a certified value stops rewriting itself

4 September 2026 Features Submittals, from the register to the reviewer and back again "We build the shop drawing pack in the Document Register, then email it to the architect and lose it. Their comments come back as a PDF with a red pen on it, and we transcribe them into a spreadsheet so we can tell the subbie what to change." Before Submittals lived outside the platform. A contract administrator built a pack by hand from the Document Register, attached it to an email, and then had nowhere to put the answer. The reviewer's verdict arrived as a marked-up PDF in an inbox. Whether an item was approved, approved with comments, or rejected was a fact that existed only in someone's memory of reading that email. There was no register column to look at, no audit trail, and no way to see which items were still out. After Submittals are now a first-class object in the Deep Space web app. You select documents in the Document Register, build a pack from them, and issue it. The reviewer gets an external read-only link, no licence and no login required. They answer item by item: a verdict per item, their own markup uploaded against it, and a signature block at the end of the review. The builder sees the answer come back in place. Every verdict sits against the item it belongs to, the reviewer's markup is attached where you would expect to find it, and the Document Register carries a Submittals column so the state of every pack is readable from the register itself. Impact The shop drawing loop stops leaking into email. A contract administrator can answer "what is still out with the architect, and what came back rejected" from one screen instead of reconstructing it from a mail folder. Because the verdict, the markup and the signature all land against the item, the approval history is defensible months later when someone asks why a detail was built the way it was. Known limitations The reviewer's link is read-only and answer-only. Reviewers cannot start a submittal or add documents to a pack. Building a submittal pack from the Document Register. Name the pack, confirm the documents and the exact revision of each one, pick who reviews it, and issue. The pack can also be saved as a draft before it goes out. Push the Document Register straight to DS Site "The register is the only list I trust. But the crew on site are looking at their phones, and getting the current revisions in front of them means someone re-uploading files into DS Site by hand." Before Pushing documents to DS Site only worked from the Explorer: one file, a multi-select, or a folder. Nothing pushed from the Document Register, which is the list that actually says what is current and approved. The DS Site project page had no place to put a register even if you could send one. Getting the registered set onto phones meant a person copying files across, and that person's copy went stale the moment a revision landed. There was also a trap underneath. DS Site will not allow two pages with the same name. Under the old naming pattern, two projects with a folder called "Structural", or two parent folders with the same child name, collided. The second push failed outright, and a same-named PDF from another project could quietly overwrite the first. After The Document Register now has a "Push to DS Site" action alongside Edit metadata, Download ZIP and De-register. Select the registered documents you want on site, push them, and they arrive as a Document Register page on the DS Site project page, sitting under Drawings and Subfolders as a third section. Each document is pushed at the revision the register itself holds, not the newest row in the series, so what the crew opens is what the register says is current. Page and resource names now carry the folder path and the project identifier, so nothing collides across projects and nothing gets silently overwritten. A file pushed both from its folder and from the register is one file attached to two pages, not two copies. Folder pushes were tightened at the same time. A folder push now rebuilds the full ancestor chain and re-parents pages that had been attached flat, so the tree on site matches the tree in the platform. And the Recent jobs drawer reports the result honestly: "N pushed, M failed", per job, rather than leaving you to guess. Impact The register becomes the single source for what is on site. A document controller stops being a courier. Site sees current revisions on a phone without anyone maintaining a parallel copy, and a builder running twenty jobs with the same folder names no longer trips over a naming clash they had no way to see. Known limitations The push is manual and selection-based today. There is no whole-register mode, and no automatic push when a document is promoted or revised. Automatic push is a project setting still in build. Non-PDF registered documents are skipped. Select registered documents, then Push to DS Site from the More menu. The same selection also drives Create Transmittal and Start Submittal, and the register's own Transmittals and Submittals columns show where each document has already been sent. Create a transmittal from the Document Register, numbered per project "I have the documents selected right here in the register. To transmit them I start again somewhere else and re-pick every one of them." Before A transmittal was built from its own screen, from scratch. The register selection you had already made counted for nothing. Worse, transmittal numbers were not sequential within a project, so the numbering a client saw did not read as a clean series and could not be quoted back with confidence. After Create Transmittal now starts in the Document Register, from the documents you have already selected. The pack carries across. Transmittal numbers are now issued sequentially per project, so the series a client receives reads as one continuous run for that job. Impact The transmittal follows the selection instead of the other way round, which removes the re-picking step that made people batch it up and send late. Per-project sequential numbering makes a transmittal number quotable in correspondence, which matters the moment a dispute turns on whether a document was actually issued. Spot a broken Xero link on a supplier invoice, and relink it "The invoice says it went to Xero. Xero has never heard of it. Nobody found out until the month-end reconciliation, and by then there were nine of them." Before Once a supplier invoice had been pushed to Xero, the platform assumed the link held. If the Xero-side record was later deleted, voided or replaced, nothing on the Deep Space side noticed. The invoice still presented as linked. There was no way to re-point it at the right Xero record, so the only remedy was to unwind and redo the push, and the only way to find the problem was to reconcile by hand. After Broken Xero links on supplier invoices are now detected and surfaced in the Invoice Register, so a dead link is visible where the invoice lives rather than at month end. Where a link is broken, the invoice can be relinked to the correct Xero record in place, without unwinding the claim. Impact Finance stops discovering integration drift during the close. The register becomes the place where the state of the Xero relationship is readable, which is the difference between a five-minute fix and a reconciliation exercise. Improvements The portal takes you to the work, not to a picker "Our subbie's foreman signs in and lands on a workspace chooser with one thing in it. Then a wall of projects, most of which he cannot open. Then he clicks one and it does not say whose job it is." Before Portal users were routed through the builder's sign-in furniture. A portal-only user still had to pass a workspace picker even when there was only one workspace to pick. The portal home wall listed projects the user could not actually enter, so the first click was often a dead end, and an empty wall said nothing about why it was empty. Users who belonged to more than one builder got the wrong destination on some workspace rows. Once inside, the left nav did not state which builder's project you were standing in, which matters when a subcontractor works for four of them. After Portal-only users now skip the workspace picker entirely and go straight in at sign-in. The home wall shows only the projects you can actually enter, and when there is nothing to show it says why instead of presenting a blank. Users who hold both builder-side and portal-side access get the right destination on each workspace row. The Company entry on the portal home now follows the union of your portal roles across builders, rather than resolving to one of them. And the left nav states the builder and the project at the top, so you always know whose job you are in. Impact A subcontractor's site foreman gets from sign-in to the job in one step instead of three, and never clicks into a project he cannot open. For a subcontractor working across several builders on the platform, the portal stops being ambiguous about which relationship is on screen, which is the single most common cause of the wrong thing being submitted to the wrong builder. Known limitations Portals are enabled per workspace as builders come online, so this only changes what a portal user sees on workspaces where Portals is switched on. Every builder's tender invitations in one view "We tender to five builders on this platform. Five portals, five logins, five lists of invitations to keep straight." Before A subcontractor's tender invitations were scoped to one builder at a time. Working with several builders on Deep Space meant checking each one separately to know what was out for price and what was closing. There was also a duplicate tender path inside the portal, a second implementation of the same read that could disagree with the first. After Tender invitations from every builder now appear in one view for the subcontractor. Tender package invitees are queryable by company, with a company-level read behind it, so the list is assembled once and consistently. The duplicate portal tender path has been retired, so there is a single source of truth for what has been invited. Impact An estimator at a subcontractor sees the whole pipeline of invitations in one place and prices against real closing dates, instead of maintaining a private spreadsheet of which builder asked for what. Retiring the second code path removes a class of "the portal says one thing and the builder says another" disagreements. Known limitations As above, this is visible on workspaces where Portals is enabled. Jump to the subcontract from a payment schedule or a claim "I am certifying a claim and I need to know the contract position. Committed, claimed to date, retention held. So I open another tab, find the subcontract, and try to remember what I was looking at." Before A payment schedule and a subcontract claim detail view showed the claim, but not the contract behind it. Checking the position meant navigating away to the subcontract and back, from memory, mid-certification. After There is now a "View subcontract" shortcut on both the payment schedule and the subcontract claim detail, taking you to the contract position directly from the record you are working on. Impact Certifying a claim against the contract stops being a two-tab exercise. The contract administrator checks the position without losing their place, which is the difference between certifying accurately and certifying quickly. A total row on the Invoice Register "I filter the register to one project and one month, and then add the column up on a calculator." Before The Invoice Register listed invoices with no total. Any question that started with "how much" ended with someone exporting to a spreadsheet or adding a column by hand, and filtering the register did not give you the filtered sum. After The Invoice Register now carries a total row. Impact The register answers "how much" for whatever you have filtered it to, which is most of what anyone wants from it. It removes a daily export from a finance person's routine. The Invoice Register total row, sitting above the invoices and summing both inclusive and exclusive of GST, per currency. It follows whatever status tab and filter you have applied. KAI drafting is signposted from the page people go looking on "Someone told me the platform could draft a scope for me. I went to the Scope of Works page, found nothing, and wrote it myself like always." Before KAI can draft scopes, but the entry point was not on the Scope of Works page. People looking for it in the obvious place did not find it, concluded it did not exist, and went back to writing scopes from a previous job. After The Scope of Works page now points people at KAI drafting from where they are already standing. Impact A capability the platform already had stops being invisible. Discovery of KAI drafting no longer depends on someone having been shown it in a training session. Fixes A certified value no longer rewrites itself to the claimed amount on approval "I certified it down. I approved it. It went out at the full claimed amount. Nothing on screen told me it had changed." Before On a subcontractor payment schedule, a certified value that had been reduced below the claimed amount could silently revert to the claimed amount when the schedule was approved. There was no warning, no flag, and no visible difference. The document that went out to the subcontractor carried a figure the certifier had not certified. This is the most serious class of defect a commercial module can carry. A payment schedule is a statutory instrument under security of payment legislation, and a figure that changes itself between certification and issue is both a commercial exposure and a compliance one. After The certified value now survives approval exactly as certified. The reversion path has been closed on both the platform side and the record side, and the behaviour is pinned so it cannot return quietly. Impact What you certify is what goes out. A commercial manager can approve a schedule without re-reading the generated document line by line to confirm the platform did not overwrite them. A purchase order sent for e-signature now actually arrives, and a voided signature can be re-issued "I sent the purchase order for execution three days ago. The supplier never got it. And when I voided it to start again, there was no way to send it out a second time." Before A purchase order sent for e-signature was never delivered to the recipient. From the builder's side it looked sent. From the supplier's side nothing arrived, so the order sat unexecuted while both parties waited on the other. Voiding the signature to start again made it worse: there was no path back to sending it for execution, so the record was stuck and the only way forward was to raise a new purchase order. After The e-signature request now reaches its recipient. And where a signature has been voided, the purchase order can be sent for execution again rather than being abandoned. Impact Purchase orders stop stalling in a state where everyone believes it is with somebody else. Document production and execution is where a new customer forms their first judgement about whether the platform can be trusted with a commitment. Supplier invoices that would over-commit a purchase order are refused at submission "We approved invoices past the value of the purchase order. The guard was there. It just was not looking at the right moment or the right numbers." Before The over-commitment guard on purchase orders counted only invoices already marked paid, and it never ran at the moment of commitment. So an invoice that would push committed value past the purchase order total could be submitted and approved, with the breach only becoming apparent later when the numbers were reconciled against the budget. After The guard now counts the full committed position, not just paid invoices, and it runs at submit-for-approval. A supplier invoice that would over-commit its purchase order is refused at the point of submission, where the person who can fix it is still looking at the screen. Impact Over-commitment is caught at the gate rather than discovered in a budget review. The purchase order stops being a number that reality is allowed to drift past, which is the whole point of raising one. Client and consultant portals no longer offer an invite they were never meant to have "Our client's contract administrator was invited into the portal, and the portal offered him a button to invite his own people. That is a subcontractor feature." Before The invite entry point appeared in client and consultant portals as well as the subcontractor portal, where it belongs. A client or consultant user could see, and reach, an employee invite flow that was never designed for their relationship with the builder. After The invite affordance has been withheld from the client and consultant portals, and employee invites originating from a non-subcontractor portal are refused on the platform side as well as hidden in the interface. Impact Each portal now offers only what that relationship is supposed to be able to do. Access into a builder's project stays where the builder put it. We build in the open, and we ship on what you tell us. If something here is not quite right, or there is something you need next, raise it through the feedback portal in the platform. We read every one.