Technical Reference

1. Overview

ZDDC — Zero Day Document Control — is an information management convention built on two rules:

• File naming — every deliverable filename encodes its tracking number, revision, status, and title. This makes each file self-describing and independently searchable without opening it.
• Folder naming — transmittal folders follow the same convention, date-prefixed so they sort chronologically and can be searched by the tracking numbers of the deliverables they contain.

Together, these two rules mean a plain folder on any shared drive becomes a fully searchable, auditable information management system. No server, no database, no software required to read the archive.

Because every deliverable is self-describing — its identity, revision, and status encoded in the filename itself — the convention works across organisational boundaries without requiring a shared platform. A project adopting ZDDC can extend the same convention to its clients, subcontractors, vendors, and any other party in the project ecosystem. Each party maintains their own archive; the shared naming convention makes every archive mutually intelligible. Adoption can be voluntary or contractually required. The result is a globally scalable, distributed information management system built on nothing more than agreed file naming and standard directory structures.

The tools below implement interfaces around this structure — but they're optional. The structure works without them, and any party can participate using only their file browser.

2. Filename format

The ABNF-like grammar below is a formal machine-readable definition of the filename format — primarily useful for parsers and AI systems. The human-readable explanation of each field follows in the sections below.

This grammar is the frozen part of the convention: it is what every ZDDC archive, tool and third-party implementation must agree on, and changing it is a migration. The code tables — disciplines and types in §3, statuses in §7 — are registries: separately versioned vocabulary that a project extends to suit its own work, on the terms in §1. Freezing the grammar while letting the vocabulary grow is what lets one convention serve an engineering project and a personal records archive without either becoming a dialect of the other.

Rules:

• Tracking number: no spaces, no underscores, hyphens as separators only
• Underscore _ separates tracking number from revision
• Revision: no spaces; may include ~ prefix and/or + modifier
• Space before (status)
• Space-dash-space - before title
• Extension is the original file extension, preserved exactly

Anatomy (from left to right):

Real examples:

3. Tracking numbers

A tracking number is a deliverable's permanent identifier. It never changes — regardless of revision, status, or content changes. Think of it like a passport number: your name can change, your passport number doesn't.

No spaces, no underscores — hyphens as separators only. Format is yours to define; it must be consistent within the scope it covers.

Field definitions (in order)

Tracking numbers are composed of the following fields, in order:

• originator — Organizational unit responsible for the deliverable
• project — Project identifier; a recognizable placeholder is used for corporate-scope deliverables
• [phase] — Optional phase code (e.g., ECI, EPC)
• [area] — Optional area/budget code
• discipline — Engineering or functional group (e.g., EL, ME, CV, PM)
• type — Document category within discipline
• sequence — Zero-padded integer
• [suffix] — Optional hyphenated suffix for appendices or sheets

Schema rules

Choose the schema that matches your structure. The fields within brackets [ ] are optional and must be omitted consistently across all tracking numbers when not used.

Discipline codes

Discipline codes identify the engineering or functional group responsible for the document. They are defined per project and should be documented in the Master Deliverables List.

Type codes

Type codes identify the document category within a discipline. Type codes are scoped per discipline — the same code may mean different things in different disciplines.

Rule: Avoid ambiguity. On multi-discipline projects, type codes with overlapping meanings should be avoided or a cross-discipline registry should be agreed upon and documented.

Sequence numbers

Sequence numbers make the tracking number unique given all the preceding fields. Use zero-padded integers (e.g., 0001, 0042).

A suffix separated by a hyphen can denote appendices or sheets that are structural parts of the same deliverable:

4. Revisions

The revision field indicates the iteration stage of the deliverable. It consists of an optional ~ draft prefix, a base revision, and an optional + modifier.

Base revision types

Base revisions are one of three types: letter revisions (A, B, C...), number revisions (0, 1, 2...), or date-based revisions.

Letter revisions (design/review phase)

Letter revisions are used during the design and review phase. They sort lexically, so A < B < C, etc.

Number revisions (construction/record phase)

Number revisions are used after approval, typically at the Issued For Construction (IFC) stage. They sort lexically after letter revisions.

Date-based revisions

Date-based revisions apply to documents that are updated in place under a single permanent tracking number, where the date of the revision is the most meaningful piece of information a reader needs.

Rule: Two use cases for date-based revisions:

1. Recurring documents — issued on a fixed cadence (e.g., meeting minutes). The tracking number is fixed; the revision identifies which occurrence.
2. Living documents — issued on demand (e.g., schedules, risk registers). The tracking number is fixed; the revision indicates freshness.

Rule: Contra-indication. Documents that get a new tracking number each period (e.g., monthly progress reports where each month is a distinct deliverable) use normal letter and number revisions, not date-based revisions.

Date-based revisions sort lexically in the correct chronological order — your file browser will list them in date order when sorted by name.

5. Draft prefix (~)

The ~ prefix indicates a working draft, not yet formally issued.

Examples:

6. Revision modifiers (+)

Revision modifiers associate a file with a base revision without incrementing the revision. Used for comments, backup material, native source files, and quality records. Sorts after the base revision in alphabetical order.

The number after the modifier letter — +C1, +C2, and so on — is simply a sequence counter for uniqueness. If two reviewers each return a separate set of comments, they become +C1 and +C2. The same applies to all modifiers: the number distinguishes multiple files of the same type attached to the same revision.

A modifier can itself be in draft. A+~C2 is a working draft of the second set of comments on Rev A, and sorts immediately before A+C2 — the same rule as a draft revision in §5, applied to the modifier instead of the base. Modifiers on the same revision sort by letter in the order B, C, N, Q, then by number.

Modifier table

7. Status codes

Status codes indicate the approval or review state of a deliverable. They appear in parentheses in the filename.

Primary status codes

Primary status codes are used on formally issued deliverables. The status field in a draft filename shows the intended status when issued.

Rule: the status codes are a registry, not a closed set. The table below is the base registry — the codes every ZDDC archive is expected to understand. A project may add codes to it under the harmonization rule in §1: add only where a gap exists, and never reuse an existing code with a different meaning. The base registry carries its own version, so adding a code to your project does not change the convention, and a future addition to the base registry does not change the filename grammar in §2.

Rule: No DFT status. Draft status is not encoded as a status field. It is indicated by the ~ prefix on the revision, and must also be physically marked in the file itself (e.g., a DRAFT watermark or stamp).

Review status codes

Review status codes are used as the status on +C (client or reviewer comments) and +Q (internal quality check) files. They record the outcome of the review — what the reviewer concluded and what action is required on the base document.

Rule: review codes require a modifier. A review status code is only valid on a file whose revision carries a + modifier — that is, on +C and +Q files. A review outcome belongs to the review, never to the deliverable itself. This is a rule about which codes are meaningful where, so it lives here with the registry rather than in the §2 grammar.

Typical review cycles

8. Folder naming

Transmittal folders follow the same convention as filenames — date-prefixed so folders sort chronologically:

Format: YYYY-MM-DD_trackingNumber (status) - title

Two tracking numbers in play

Two tracking numbers are always in play:

• Deliverable tracking number — embedded in each filename; permanent; unchanged across all packages it ever travels in
• Submittal package tracking number — in the folder name; reused by the response (same number, different date/status/optionally different title); a resubmittal gets a NEW tracking number

Submittal, response, and resubmittal rules

The status on a package folder is the lowest review outcome across all deliverables inside it. It summarises the package; it does not override the outcome of any individual deliverable.

Tracking individual deliverables

Search the deliverable's own tracking number across all transmittal folders in issued/ and received/. Every folder containing that number is part of its history: which package first carried it, what the response was, which resubmittal carried the revision, and what the final outcome was.

9. Project layout (Workflow Extension)

Core stops at names. How those files are arranged into a working project — and the procedure that moves a deliverable from draft to permanent record — is specified separately, as the Workflow Extension.

It was part of this document until 2026-09; it moved because it mandates how an implementation behaves (a write-once archive, a commit operation, a document-controller role) rather than what a name looks like. Those are real rules, but they are rules you can decline while still using ZDDC names, and mixing the two made it unclear which parts of this page an archive had to obey.

Two things from it are load-bearing here, so they stay:

• A ZDDC archive is conventionally organised into working/, reviewing/, staging/ and archive/, each scoped by party one level down, with staging/ the mutable twin of the write-once archive/.
• A submittal and its response share one tracking number, which is what keeps the two linked as one thread — the rule the folder-naming section above depends on (see §8).

Read the Workflow Extension →

10. Conformance and extensions

Everything above — sections 2 through 8 — is ZDDC Core: what a filename means and what a folder name means. An archive conforms to Core by producing and reading names that follow those rules. Nothing in Core requires particular software, a server, or a database.

Conformance levels: reader and writer

Core asks different things of software that reads names and software that writes them, so an implementation declares which it is. Most tools are both.

• Reader. Parses names, orders revisions, and is deliberately tolerant: it accepts whatever sits between the parentheses as the status — (ifr), even (Issued For Review) — and returns it exactly as written, so a name that does not conform can still be listed, searched and repaired.
• Writer. Composes names and produces only names that follow the grammar in §2 and §8 exactly. Given a field that breaks the grammar — a lowercase status, a tracking number with a space — it refuses to write the name rather than writing it anyway.

Both levels have conformance vectors; every vector names the level it tests. Tolerating a name on the way in is not the same as endorsing it: a reader that is also a writer still writes conforming names, including when it renames a file it could only just read.

Within Core, the grammar in §2 is the frozen part. The code tables — disciplines and types in §3, statuses in §7 — are registries, versioned separately, which a project adds to where it has a gap under the harmonization rule in §1.

Extensions

Optional on-disk formats layer on top of Core. You need not implement any of them; an archive using only Core is a complete ZDDC archive. But if you do implement one, doing it as written is what makes it interoperate rather than merely work.

Writing an implementation

The ZDDC tools are a reference implementation, not the definition of ZDDC. The on-disk conventions are the contract, and anything that follows them interoperates. If you are building software that reads or writes ZDDC archives — or you want the conformance vectors, the version scheme, or the extension catalogue — that material is on its own page:

Implementing ZDDC →

Looking for the tools themselves? They are on the releases page, which is generated from the versions that actually exist.