Changes slow down.
An approved wording or layout change becomes implementation work, a deployment, and another round of regression risk.
Your product sends the document. Your company must know it is right.
Dokus gives software companies one system to keep every document their products generate controlled, correct, and explainable.
Import an approved Microsoft Word (.docx) file, connect the parts that change to application data, and generate each document from your server.
- Controlled change
- Exact versions
- Recorded origins
- Browser viewing
SERVICE AGREEMENT
Statement of work
This agreement is made betweenNorthstar Logisticsand Dokus Labs on28 August 2026.
ServiceHoursAmountImplementation24$4,800Training8$1,200
This clause appears when support is included.
Authorized signatureDate
- Customercustomer.nametext
- Agreement dateagreement.datetext
- Service rowservices[]repeat
- Support clauseshow when support = truerule
One document can be simple.
Then come customer data, optional sections, repeating tables, regional wording, revised clauses, browser viewing, retries, and years of finished outputs. Every addition is reasonable. Together they create a document platform.
- documentsapproved sources
- versionsevery revision
- customersreal data
- rulesconditions and repeats
- localeswording and layout
- historyevery delivered copy
- a document platformthat nobody planned to build, staff, or own
Reliability becomes combinatorial.
The common case renders correctly while one real combination of customer data, clauses, and repeating rows fails later, in front of a customer.
Support becomes an investigation.
A bad copy sends the team through source files, application code, input data, storage, and rendering to reconstruct what happened.
Product work becomes platform work.
Engineers gradually own import, templating, preview, versions, output history, browser viewing, and eventually editing.
As documents grow, the work spreads across the company.
Soon, nobody owns the complete path from the approved document to the copy a customer received.
- Approved document
- Application code
- Business data
- Rendering
- Storage
The questions stay simple. The answers become expensive.
Ownership gaps turn a document defect into a cross-system support investigation. The same people who should improve the product end up reconstructing its document machinery.
- Which document version did we send?The template lives in a repository, a shared drive, and a database column. Each copy is slightly different.
- Which data did it contain?The request was logged. The values it resolved to at render time were not.
- Why did this section appear?A condition in code, a flag in the data, and a comment in the file each had an opinion.
- Can we show exactly how it was produced?Only by rebuilding the state of five systems as they were on that day.
If the product depends on documents, the system has to exist.
Without a dedicated system, the company gradually builds and maintains each of these responsibilities itself. Read the list as a hiring plan.
Dokus is the alternative to building that platform by accident. It gives the company one place to control document behavior, preserve versions, produce outputs, display them, and explain their origin.
- Source fidelity. Keep the document people already review and approve.
- Document behavior. Define typed fields, repeats, and conditions without hiding instructions in text.
- Version control. Keep document and behavior revisions distinct and identifiable.
- Rendering. Validate real input and create the requested output.
- Browser experience. Display documents inside the product instead of treating them only as downloads.
- Run history. Retain the origin needed to explain a delivered copy later.
- Editing foundation. Prepare for selection, changes, comments, and collaboration without starting over.
The document has an owner. The application has an owner. Dokus owns the machinery between them.
Those responsibilities may belong to the same team or different teams.
The document owner controls its meaning.
Product, legal, operations, compliance, or the same engineering team can own the wording and layout. Dokus does not invent that responsibility.
Your application owns the business state.
Customers, cases, calculations, permissions, and project remain in your product. Dokus does not become a second system of record.
Dokus owns the machinery between them.
Dokus keeps the document, its fields and rules, every version, and the render history needed to explain each copy.
Start with the document your company already stands behind.
Keep the approved .docx, connect only the parts that change, and generate the finished document from your server.
Import the approved file
Upload the .docx your team already uses. Dokus keeps the original and creates an exact document version with its supported layout, fonts, tables, headers, and numbering.
Mark the parts that change
Turn names, dates, and amounts into typed fields on the approved text. Point rules at real paragraphs, tables, rows, and cells. Nothing hides inside the document text.
Generate from your server
Send your data through the API. Dokus validates it, creates the PDF or DOCX, and records the exact version, blueprint, and input it used.
One document model. Two ways to work on it.
Studio is for the people who hold the document. TypeScript is for the people who hold the application. Neither gets a private dialect, so nothing has to be translated between them.
Studio · fields on this documentversion 7
- Customer
customer.nametext - Agreement date
agreement.datetext - Service row
target.row("service")repeat
const blueprint = defineBlueprint({
inputSchema,
rules: [
values({
"customer.name": input("customerName"),
"agreement.date": input("agreementDate")
}),
repeat(target.row("service"), input("services"))
]
});
await dokus.documents.render(
{ documentId, versionId, blueprint, data },
{ idempotencyKey }
);Today
Studio creates and manages the fields on the approved document. Blueprints that bind values, show blocks, and repeat rows are written in TypeScript and saved through the API. Visual blueprint authoring in Studio is being built against that same canonical blueprint, with no UI-only rules.
- Document text stays clean
- Rules target real document structures
- Published versions never change
- Every output retains its recorded origin
Use the public alpha today. The editor comes later.
Available in public alpha
Generate and display documents
Import a .docx, define its fields and rules, generate documents on the server, and display them in the browser.
- DOCX import and exact published versions
- Fields in Studio, blueprints in TypeScript
- Server rendering to PDF and DOCX, with run history
- Read-only WASM document viewer
Coming soon
An editor for your own application
We are building a separate WASM editor so users can change documents inside your product. The current public viewer does not edit or save documents.
Questions worth settling before you build it yourself.
The boundaries, tradeoffs, and current capabilities should be explicit.
Who should use Dokus? Who should not?
Dokus is for software companies whose products rely on documents: customers sign them, wording has consequences, structures vary, or historical copies must remain explainable. An occasional simple export that nobody needs to version, inspect, or reproduce does not need this system.
How is this different from token and template tools?
Dokus never scans document text for generation instructions. Fields are typed objects attached to ranges of ordinary text, and conditional or repeat logic lives in a separate validated blueprint compiled to a render plan.
Do we have to modify the approved DOCX before importing it?
No. Import the file as approved. Its text remains ordinary text; fields and structural targets are attached afterward in Studio or through the SDK.
What is the source of truth after import?
Dokus keeps the original DOCX and an exact DKSD document version. Your application remains the source of truth for customer, case, and other business data.
What happens when the document changes?
A revised file becomes a new draft version, and published versions never change. Blueprints stay pinned to the exact version they were written for. A person rebinds them after a compatibility check; Dokus does not guess from position, similar text, or source order. Older outputs remain linked to the version and blueprint that created them.
Is Studio mandatory, or can blueprints be authored in code?
Neither tool is mandatory, and both work on the same document model. Today, Studio creates and manages the fields on the approved document, while blueprints that bind values, show blocks, and repeat rows are written in TypeScript and saved through the API. Visual blueprint authoring in Studio is being built against the same canonical blueprint, without a UI-only dialect.
Where is the line on what a blueprint does?
A blueprint describes document behavior: what fills, what repeats, and what appears. Business computation, project, permissions, and user data stay in your application. Dokus is not a form builder, project engine, or second database.
Can users view or edit documents inside our product?
The public WASM viewer can display documents and select text, fields, blocks, tables, rows, and cells. It cannot edit or save. Those capabilities will come in a separate embedded editor.
What does preserving the document mean for fidelity?
Dokus keeps the original file and renders from the imported document structure. It preserves the fonts, tables, headers, numbering, and layout that the current engine supports. Dokus does not rebuild the document as HTML or claim support for features it cannot render.
Is the public alpha ready for a production dependency?
Use it to evaluate the model with real documents. Dokus does not yet publish production support terms, an SLA, public pricing, or a data-residency commitment. The Trust page separates what is implemented today from what has not been promised.
Choose what you want to see next.
See the complete flow
Import, fields, rules, versions, and output.
See the SDK boundaries
Four public packages and what each one does.
See the editor direction
How editing will fit inside another product.
Check the current boundaries
Recorded evidence, exports, and what the alpha does not promise.
You should be able to explain every document your product sends.
If that system has to exist, Dokus is the alternative to building and maintaining all of it yourself. The public alpha is open: sign up with an email address and import a real document.