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.

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.

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 (closed set)

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

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 (closed set)

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.

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 & transmittal workflow

A ZDDC project mirrors the natural lifecycle of an engineering deliverable: drafted in private, lined up for issue, formally exchanged, kept as record. Each folder maps to one of those stages, so file location alone tells you where a document is in its lifecycle. You only create the folders you need, when you need them.

How it flows. working/ → staging/ → issued/ is a one-way progression: your team drafts freely in working/, lines finished files up in staging/ for the document controller to sign off, and the document controller publishes the package into issued/ as the permanent record. Treat received/ and issued/ as write-once — once a document lands there, it stays exactly as filed.

5-step transmittal workflow:

Drafting a response transmittal

Submittals from counterparties (tracking numbers containing -SUB- at status IFR or IFA) require a response transmittal whose status starts with RS (RSA, RSB, RSC, …). The flow follows the same lifecycle:

1. For a submittal in received/, start a review folder under reviewing/ that points back to it, so every open response is in one place.
2. Draft your reviewer notes and the response itself in working/.
3. When the response is ready, move the files into staging/ for the document controller to sign off.
4. The document controller issues the package from staging/ into issued/ via the standard 5-step transmittal flow.

10. Tools

Single-file HTML applications — each is complete and self-contained. Save one locally and it works forever, without internet, without updates, without a subscription. None of them require any configuration to run; optional .zddc files only add to them. Together they cover the full ZDDC workflow: browse to look at anything; classify to name incoming files and build transmittals; archive to search and export the formal record.

To open a folder directly from your computer, use a Chromium-based browser — Chrome, Edge, or Brave. That feature relies on the browser's File System Access API, which Firefox and Safari do not yet support.