The project document register
that keeps its own paper trail.
Document control fails at the seams: the number that means two things, the revision nobody can prove was issued, and the transmittal that no longer matches the document it named. XO Docs is one register for drawings, calculations, specifications, RAMS, reports and programmes, built for the document controllers, project administrators and design managers who need to show who did what to them.
The record keeps its own context
Of the platform's three C's, XO Docs speaks to Compliance, and only in the narrow sense a register can honestly claim: who did what, and when.
Auditable automation, including what didn't happen
Every workflow launch attempt is recorded with a reason code, whether or not it started. Most tools record only the successes. In XO Docs, "why didn't it run?" has an answer in the record.
Snapshots, not links
A transmittal item stores the document number, title, revision and version as they were at the moment of issue, so the record stays true after the document changes.
Suggestions keep their receipts
A metadata suggestion is stored with the reader that produced it and that reader's version, so a value stays attributable long after someone applied it.
What one register changes
Three outcomes, taken straight from what the product does rather than what a brochure would like it to do.
One register, one numbering scheme, enforced by the database rather than by reminder emails.
A record of who submitted, who approved or rejected, who issued, and when. Written automatically.
Transmittals that still describe what you actually sent, months later.
One register that can account for itself
Numbering, revisions, transmittals, deliverable plans and markup, each recording what happened as it happens.
Document numbering, enforced rather than requested
Set the scheme once at company level and override it per project where a client insists on their own. Numbers are generated on upload and checked by the database, not by a reminder email.
- Company scheme, project overrideComponents, order, separators and padding, set once and inherited
- Generated on uploadThe number comes from the scheme rather than from memory
- Unique per project and document typeA database constraint, case-insensitive, so TOW-ARC-DWG-001 and tow-arc-dwg-001 cannot both exist
A document register that answers who, what and when
A revision moves from upload into review, on to Approved or Rejected, and then to Issued. Every transition is written with the actor, the time, and the status before and after.
- Actor and timestamp on every transitionWritten automatically as part of the change, not typed in afterwards
- Before and after, kept togetherEach entry records the status the revision moved from as well as the one it moved to
- Governance rules that name themselvesA blocked submit or issue returns the rule and the reason, not a generic refusal
design-review-required: no approver assigned to this document type.Transmittals that stay true to what you sent
Select the revisions, add the recipients and issue. XO Docs records the document number, title, revision and version as they were at that moment. Recipients receive the package by email with a PDF record, without ever opening XO Docs.
- A snapshot, not a pointerRe-issue or rename the document later and the transmittal still names what you sent
- A send record for each recipientAttempts, the time the mail server accepted it, and a reason when it was rejected
- Resend to one personFix the address that failed without re-issuing the package to everyone else
- Email and PDF out, no register access neededRecipients get the package without being given access to the register itself
TIDP deliverable planning next to the register
Build a TIDP plan from a company template, an Excel import, or generate it from the project's spatial hierarchy: Organisation → Project → Building → Floor → Elevation/Location → Element Type → Element Instance. Submit the version, have it approved, and let real uploads match themselves to planned items by number.
- Versioned and approvedApproving a plan version is a recorded decision with a name and a time, not an email
- Uploads match themselvesA document arriving against a planned number closes that item without anyone reconciling
- Outstanding sits next to deliveredThe gap between what you owe and what exists stops living in a spreadsheet
Drawing markup that stays with the drawing
Threaded annotations pinned to the drawing, linked to RFI conversations. The question and the drawing it is about stay together, instead of drifting apart in email.
- Pinned to the drawingAn annotation sits where the issue is, not in a separate comments file
- Threaded, not scatteredReplies stay under the annotation they answer
- Linked to RFI conversationsAn annotation can be bound to an RFI thread in XO RFI
Where XO Docs sits in the platform
Each connection below is a documented workflow in the product, not an aspiration.
Who issued this, and when?
A revision moves from upload through review to Approved or Rejected, and on to Issued, with every transition recorded and governance rules able to block submit and issue, naming the rule and the reason. Downstream, XO Field reads document approval state from XO Docs.
What exactly did we send?
Three weeks after a package goes out, the transmittal still names revision P02 v3, even though the document is now on P04. The record was written at the moment of issue, so it does not change when the document does.
The register shows what you owe
A TIDP plan can start from a company template, an Excel import, or the project's spatial hierarchy maintained in XO Spatial. Approving a plan version is a recorded decision, and arriving documents match themselves to planned items by number.
It reads the drawings; you still decide
Drag a batch into Uploads and ask for suggestions: XO Docs reads the title block and proposes the number, title and metadata, each with a confidence. Nothing changes until someone applies or rejects each suggestion. Reading image-only PDFs needs OCR, which is opt-in per tenant and off by default. Drawings with a text layer are read without it.
Approvals that start themselves, and tell you when they don't
Set a workflow rule: a document type, optionally a stage, and up to two more conditions. A matching upload starts the workflow, and every attempt is recorded with a reason code, including the ones that never started.
Markup to RFI
Threaded annotations are pinned to the drawing and linked to RFI conversations in XO RFI, so the question keeps the drawing it came from.
Frequently asked questions
Can we use our own document numbering?
Yes. You choose the components, their order, separators and padding. The scheme is set at company level, can be overridden per project, and numbers are generated on upload.
What stops two people using the same number?
A database constraint, applied per project and document type. The check is case-insensitive, so TOW-ARC-DWG-001 and tow-arc-dwg-001 cannot both exist.
Does the AI change our metadata?
No. Suggestions are written to a separate record, stored with the reader that produced them and that reader's version. Nothing reaches the document until a person applies or rejects each suggestion.
Can we send drawings to people outside the project?
By transmittal email, yes. Recipients receive an email and a PDF record. External parties cannot be given access to the register itself.
Does issuing a revision lock the file?
No. Issuing changes the revision's status, and that change is recorded with who acted and when. It does not lock the file or preserve a copy of it.
Ready to take control of your documents?
See the register, the transmittal record and the deliverable plan running against a project of your own.