This is an extension, not the core convention. ZDDC Core specifies filenames and folder names — the part baked into your files, and the part every ZDDC archive shares. This document specifies something narrower: one way of arranging those files into a working project, and the procedure for moving a deliverable from draft to permanent record.
You can adopt Core without this. A party can participate in a ZDDC exchange using only a file browser and the naming convention. The layout below is what the reference implementation does, written down so a second implementation can match it — see implementing ZDDC.
Status: draft. Unlike Core and the Custody Extension, this document has no conformance vectors yet, so it describes behaviour rather than pinning it. Treat it as descriptive until it does.
1. Project layout
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.
A project root holds a set of canonical folders. Party-scoping sits one level below each of them — a {party} subfolder per organisation you exchange with, and one for yourselves.
How it flows. staging/ is the mutable mirror of archive/ — same {party}/{issued,received}/ shape. Your team drafts in working/ (outbound) or reviewing/ (responses), lines the finished transmittal up in staging/{party}/issued/, and the document controller commits it by moving the folder to the exact same path under archive/. Inbound works the same way: files are classified in staging/{party}/received/, then committed to archive/{party}/received/. A submittal and its response share one tracking number so they stay linked. Everything under archive/ is write-once — once committed, it stays exactly as filed; only a superadmin can alter a sealed record.
The commit is one operation, not two. Moving a transmittal folder from staging/ to the identical path under archive/ is what "issuing" and "accepting" both are. Because the path is the same on both sides, nothing about a deliverable's identity changes when it becomes a record — only which half of the mirror it sits in.
2. Transmittal workflow
Five steps take a received transmittal from arrival to permanent record.
| Step | Actor | Action | Verification |
|---|---|---|---|
| 1 | Receiver | Files the received transmittal into staging/{party}/received/ and classifies it |
Filenames match ZDDC convention |
| 2 | Receiver | Validates filenames, completeness, and SHA-256 checksums | All checksums match |
| 3 | Document controller | Commits the folder from staging/{party}/received/ to archive/{party}/received/ (same-path move) |
Permanent record established |
| 4 | Receiver | Saves acknowledgment with SHA-256 hashes | "Official" version recorded |
| 5 | Receiver | Notifies sender and distribution list | Hashes included in notification |
What SHA-256 gives you: Mathematical fingerprint of file contents. Single byte change → hash changes. When acknowledgment records hashes, you can verify years later that the file is identical to what was transmitted.
Checksums recorded this way are a plain integrity check, and anyone holding both the file and the acknowledgment can repeat it. Binding a transmittal to a signing key, so a third party can verify who issued it decades later, is a separate concern — that is the Custody Extension.
3. 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:
- For a submittal in
archive/{party}/received/, start a review folder underreviewing/{party}/— so every open response is in one place. - Draft your reviewer notes and the response itself in
reviewing/{party}/, reusing the submittal's tracking number so the two stay linked. - When the response is ready, Stage the files into
staging/{party}/issued/. - The document controller commits the package from
staging/{party}/issued/toarchive/{party}/issued/(the same-path move).
The shared tracking number is what makes a submittal and its response one thread rather than two documents — that rule belongs to Core §8, not to this extension.