A file-naming convention and two single-file HTML tools — archive and browse — for managing project deliverables. Self-contained, offline-capable, dependency-free.
+A file-naming convention plus a few single-file HTML tools for managing project deliverables. Start with Browse — open any folder, no setup. Self-contained, offline-capable, dependency-free.
ZDDC is a convention, not a platform. Every deliverable's filename encodes its tracking number, revision, status, and title; every transmittal folder is date-prefixed and self-describing. A plain shared folder becomes a fully searchable, auditable information-management system — no server, no database, no software required to read the archive.
-The two tools below are optional interfaces around this structure. Each is a single self-contained HTML file that works two ways: open it locally and point it at a folder on your disk, or put it behind any web server (including the optional zddc-server described below) and use it over the network. Same on-disk layout either way.
The tools below are optional interfaces around this structure, and each needs nothing to run. Every one is a single self-contained HTML file: open it and point it at a folder on your disk, or put it behind any web server (including the optional zddc-server described below) and use it over the network. Same on-disk layout either way. The extra niceties — friendly labels, per-folder tools, permissions — come from optional .zddc files you can add later, or never.
.zddc files and the same tool gains friendly folder labels, per-folder tools, permissions, and transmittal actions — leave them out and it's still a complete browser.Take the same local directory and put it behind any web server (nginx, Caddy, Apache, or zddc-server). The Archive Browser tool talks to the server's directory listings instead of the local filesystem — read-only, works in any browser.
Take the same local directory and put it behind any web server (nginx, Caddy, Apache, or zddc-server). The Archive tool talks to the server's directory listings instead of the local filesystem — read-only, works in any browser.
zddc-server is a small Go binary purpose-built to serve ZDDC archives. Any web server gives you online mode; zddc-server adds things a generic web server can't:
zddc-server is an optional web-server app, purpose-built to serve a ZDDC archive over the network. Any web server gives you read-only online mode; zddc-server adds the things a generic one can't:
.zddc file into an empty directory and the canonical project layout (archive/<party>/{mdl,rsk,incoming,received,issued,working,staging,reviewing}/) materialises on the first write into each path — never on bare reads. archive/ is the only physical project-root child; ssr, mdl, rsk, working, staging, reviewing sit beside it as virtual aggregators that synthesise listings across parties. Folder names are matched case-insensitively, so an existing Working/ is reused rather than shadowed by a new working/ sibling. Each authenticated viewer sees a virtual archive/<party>/working/<your-email>/ entry; first write makes it real..archive URL space. GET /Project/.archive/123-XYZ.html resolves to the canonical revision file at request time. Computed from filenames; no cache, no separate index file..zddc files. Behind a reverse proxy that authenticates users and sets an X-Auth-Request-Email request header, zddc-server consults YAML .zddc files at every directory along the path. The cascade walks root→leaf; the closest match wins. Five verbs (r read, w overwrite, c create, d delete, a admin / edit ACL) gate every operation. An empty grant (e.g. "*@vendor.com": "") is an explicit deny. A subtree that wants to start fresh — vendor folder, regulated workspace — can declare inherit: false to fence off ancestor grants and roles, then list the principals it does want. Common shapes (paired open/closed projects, third-party-restricted vendor folders) are documented with worked examples in the access-control reference. No database, no admin UI..zddc may declare named roles whose members are email patterns; permissions then reference the role name instead of pasting the same wildcard everywhere:
-roles:
- qc-reviewers:
- members: ["*@quality.org", "alice@example.com"]
-acl:
- permissions:
- qc-reviewers: rwd
- "*@example.com": r.zddc redefining the same role name shadows the ancestor for that subtree.archive/<party>/issued/ or archive/<party>/received/ enforces write-once via a verb mask: ancestor grants are reduced to r only, while a .zddc placed at the WORM folder itself can still grant rc (create-but-not-overwrite) to specific principals — that's how a doc controller drops a fresh transmittal into the immutable record. Root admins (the admins: list in the root .zddc) bypass the mask as the deliberate escape hatch for mis-filed documents./.profile/effective-policy?path=<url> to see the resolved ACL chain at any path — every level's grants, the role evaluation, the final verb-set. Useful when a permission isn't behaving the way the operator expected.ZDDC_OPA_URL and the server POSTs the request's user, path, action, and the full .zddc cascade chain to /v1/data/zddc/access/allow. Decisions are cached per (user, path, action) with a configurable TTL (ZDDC_OPA_CACHE_TTL); failures fail closed by default (ZDDC_OPA_FAIL_OPEN=1 flips it). The bundled NIST AC-6 strict-cascade preset is dumpable via --print-rego=federal. Default mode adds zero new dependencies; external mode is a configuration flip..zddc files along the tree to say who can read, write, create, or delete each folder — by email, wildcard, or named role. Write-once (WORM) archive folders keep the issued record immutable. How the cascade works →.archive URL always resolves to the current revision of any document.The on-disk layout is the same in both modes. Stop the server and the directory is still a perfectly valid ZDDC archive that opens in local-directory mode. The server is convenience, not lock-in.
-Source, environment-variable contract, and ACL syntax: codeberg.org/VARASYS/ZDDC zddc/. Pre-built binaries are published as Codeberg release assets; example Helm charts (production + dev) live under helm/ in the repo and compile from source at deploy time.
Source, configuration, and the full ACL reference: codeberg.org/VARASYS/ZDDC zddc/.
.zdd
Server: just run zddc-server
- The binary has the current-stable build of both tools baked in at compile time. They appear automatically at the right paths in the served tree:
+ The app has the current-stable build of the tools baked in. They appear automatically at the right paths in the served tree:
- - archive.html at every
archive/ path — the read-only search-and-export view of the formal record
- browse.html at every directory (the slash form of any path) — the file-tree navigator, in-place markdown editor, and inbound-file handling surface
+ - archive.html at every
archive/ path — the read-only search-and-export view of the formal record
+ - classifier.html wherever a folder opts into it — assign tracking numbers and build transmittals
- index.html (the project picker) at the deployment root
Which tool serves at a given URL is decided by the .zddc cascade — the embedded defaults map archive/ subtrees to the archive tool and everything else to browse, but operators can override per folder via default_tool:. Folder names are case-insensitive — Working/, working/, and WORKING/ all match the same rule.
@@ -187,8 +186,9 @@ apps:
Local: just download the .html file
No server, no install — open in any modern browser.
Right-click → Save As. Each tool is a self-contained HTML file with everything inlined; works from file:// or any static host.
diff --git a/reference.html b/reference.html
index e2f257c..45c9471 100644
--- a/reference.html
+++ b/reference.html
@@ -40,14 +40,18 @@
@@ -97,7 +101,7 @@
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 two 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.
+ 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.
Convention harmonization. The convention is designed to be applied at multiple organisational scopes simultaneously — corporate, client, project, department — and the code registries at each scope should be harmonized so they do not conflict. A corporate discipline code such as HR (Human Resources) does not exist at the project level, so there is no clash. But a code that means one thing corporately and something different on a project would create ambiguity in a unified archive. The ideal is that conventions flow down: corporate establishes the master code registry, projects inherit it and extend it only where gaps exist, and no code is reused with a different meaning at a lower scope.
@@ -123,9 +127,10 @@ modifier = modLetter 1*%x30-39 ; e.g. C1, N2, Q1, B1
modLetter = "C" / "N" / "Q" / "B"
status = "IFA" / "IFB" / "IFC" / "IFD" / "IFI" / "IFP" / "IFR" / "IFU" / "REC"
/ "RSA" / "RSB" / "RSC" / "RSD" / "RSI"
- / "---"
+ / "TBD" / "---"
; Constraint: RSA / RSB / RSC / RSD / RSI (review status codes) are only valid
; when modifier is present (i.e. on +C and +Q files).
+; "TBD" marks a planned deliverable whose issue status is not yet decided.
; "---" indicates no status assigned; used on working drafts.
Rules:
@@ -860,6 +865,11 @@ ACME-123456-PM-LST-0001_2506-02 (IFI) - Critical Milestones List.pdf
Issued For Record
Final as-built or archived version
+
+ TBD
+ To Be Determined
+ Planned or forecast deliverable — issue status not yet decided. Used as a placeholder when a transmittal folder is set up ahead of the document; assign a real status before issuing.
+
---
No status
@@ -1270,23 +1280,29 @@ request until you populate it..."
11. Tools
- Two single-file HTML applications — each is complete and self-contained. Save them locally and they work forever, without internet, without updates, without a subscription. Together they cover the full ZDDC workflow: archive for searching and exporting the formal record; browse for navigating, editing, and managing the project tree.
+ 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; .zddc files and zddc-server 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.
-
- Archive Browser
- Search and filter the formal record. Filter by tracking number, discipline, revision, status, or free text. Group rows by transmittal to see the lifecycle of any deliverable. Download the current selection as a ZIP. Read-only — the archive is preserved as-issued.
- Open Archive Browser
-
-
Browse
- File-tree navigator for the project. Edit markdown in place (live preview, YAML front matter pane, table of contents). Download any markdown source as DOCX, HTML, or PDF on demand. Drop in files, classify them to ZDDC names, draft transmittals, and prepare deliverables — every workflow happens here.
+ Open any folder on your disk — no setup. A file-tree navigator with live preview, plus in-place markdown editing (YAML front matter pane, table of contents) and export to DOCX, HTML, or PDF. Optional .zddc files add friendly labels, per-folder tools, permissions, and transmittal actions; without them it is still a complete browser.
Open Browse
+
+
+ Classify
+ Turn incoming files into properly named ZDDC deliverables. Drop files onto a tree to assign each a tracking number, revision, and status, then organize them into dated transmittal folders ready to issue. Spreadsheet-style editing; writes renamed, sorted copies back to disk. No server required.
+ Open Classify
+
+
+
+ Archive
+ The read-only window into the formal record. Filter by tracking number, discipline, revision, status, or free text. Group rows by transmittal to see the lifecycle of any deliverable. Download the current selection as a ZIP. The archive is preserved as-issued.
+ Open Archive
+
- Local directory access relies on the Chromium-based browser File System Access API. It does not work in Firefox or Safari. Run both tools through zddc-server for any browser, network access, and ACL enforcement.
+ Local directory access relies on the Chromium-based browser File System Access API. It does not work in Firefox or Safari. Run the tools through zddc-server for any browser, network access, and ACL enforcement.