The problem
Assembly is a person, not a process
On a large document, every team holds a full copy of the whole thing. Making one document out of twenty copies is manual work, and it is where documents go wrong.
Twenty teams
- Marine
- Electrical
- Civil
- Planning
- Commercial
- Safety
- QA
- +12 more
Twenty full copies
One person copy-pasting it together
Numbering breaks
Headings drift
Cross-references dangle
Nobody knows which version is inside
The change
No copy exists, so nothing needs reconciling
Contributors write into one canonical document. Each person owns their sections and can change nothing else. There is no second copy to merge.
Contributors
- DLDenise
Document Delivery Manager - YYYusof
Senior Marine Engineer - FIFarah
Electrical Engineer - RMRavi
Project Manager
One document
- 1Executive summaryDL
- 2Marine worksYY
- 3Electrical & controlsFI
- 4Programme & phasingRM
Numbering, headings and contents are generated from this structure.
The mechanism
What stops a document going wrong
Each guarantee is enforced by the server when a change is written. None of them is a convention or a note in a style guide.
1
You start from revision 12
Your draft records the revision it was cut from.
2
You publish
The request carries revision 12 with it.
3
Server compares
Has the master moved since revision 12?
Still 12
Accepted. Becomes revision 13.
Now 14
Refused. You are told, and nothing is overwritten.
The document
- r12Published · 14 Feb
- r13Published · 18 Feb
- r14Current
Everyone sees this.
Your draft
- checkpoint09:12
- checkpoint11:40
- workingUnpublished
Only you can see this.
Source manifest
- 1 Executive summaryr12
- 2 Marine worksr13
- 3 Electrical & controlsr7
- 4 Programme & phasingr9
The same record travels with the Word, PDF, HTML and JSON export.
- Private drafts. A saved draft never changes published content.
- Stable section identity. Renumbering a section does not break what refers to it.
- Automatic numbering. Insert a subsection and the whole document recomputes.
Capabilities
What is in the product today
Everything below works. The limits come after.
Writing
Sections you own
Give a person or a whole team their own part. They can edit that part and nothing else.
Private drafts
Work in progress stays yours until you choose to publish it into the document.
Publishing that cannot clobber
If the document moved since you started, publishing is refused instead of overwriting someone's work.
Rich editing
Headings, tables, images, links and lists, in an editor built to feel like a document.
Style and help
One style for everyone
The owner sets type and formatting once. Everyone writes inside it.
Writing help
Grammar, phrasing and sentence rewrites, scoped to your own section. You review every change as a diff.
Full history
Every version of the document, and of each person's own work, is kept. Compare any two.
Named versions
Label a working draft or a published master, so a checkpoint has a name you will recognise later.
Governance
Automatic numbering
Insert a section and the whole document renumbers. Contents follow.
Groups and roles
Assign a section to a person or a whole team. Editing rights are checked server-side on every action, not once at sign-in.
Contributors write only their own sections
A contributor can change the sections they hold and nothing else. Everything else is read-only for them, enforced on the server.
Owner control
Structure, assignments, settings and restore are owner-only.
Checked on every request
Entitlement is evaluated server-side per action, so a revoked role takes effect immediately.
Publishing
A real cover and contents
Formal front matter, document control and a cover you can design.
Word and PDF export
Download the finished document, with a record of which revision of each section it contains.
Four formats
Word, PDF, an HTML intermediate and a JSON source manifest.
Built to be reviewed
Every export states exactly what is inside it. Unpublished sections are marked, never invented.
On the roadmap
Bringing in vendors and contractors
Today a contributor has to be a project member, and a member can read every published section. That works for a team writing internally. It does not work when a vendor needs to develop one section of a competitive bid, because they would see the parts they are not meant to see.
The planned model treats an external contributor as a scoped principal rather than a member: they belong to a project for named sections only, read only those, write only those, and the scope ends on a date you set.
- Section-scoped visibility — filtered on the server, so a section outside the scope is absent from the response, not merely hidden in the interface.
- Scoped writing — the same section ownership rules, applied to someone who is not an employee.
- Time-boxed access — the invitation carries an expiry, so access ends without anyone having to remember to revoke it.
- Recorded access — which sections an external could read, and when.
Not built yet. It is described here because it changes who can contribute; until it ships, contributing requires project membership.
Not available yet
- Approval workflows and separation of duties
- Word document import — there is no one-time onboarding import yet
- Email verification, password reset and invitation mail
- External contributors — read access is per project, not per section, so a vendor cannot be scoped to their own sections yet
- Billing — pricing is published, but nothing is charged
These are named here rather than left off the page, because a reader deciding whether Doxifi fits should know what they are not getting.
Bring one real document.
We will set it up with your team's sections so you can see it working on something that matters.