What is it?
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 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.
Try the tools
Each tool is a single self-contained HTML file. The link below always tracks the current stable; pin to a specific version on the releases page for reproducibility.
.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.Append ?v=v0.0.4 to any URL to load a specific version for a single request — useful for sharing a link to an exact build. Direct local-folder access requires a Chromium-based browser (the File System Access API is unavailable in Firefox / Safari). Browse all versions →
zddc-server (optional)
The tools work two ways over the same on-disk archive. Pick whichever fits your team:
Local directory mode
Open a tool, click Add Directory, point it at a folder. The tool reads files via the File System Access API. No upload, no server, no account.
Enough for individual users and small teams on a shared drive (network share, Dropbox, OneDrive, syncthing).
Online mode
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 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:
- Access control, no database. Drop optional
.zddcfiles 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 → - Less to set up. The canonical project layout appears on first use, the tools are baked in and served at the right paths automatically, and a virtual
.archiveURL always resolves to the current revision of any document. - Built for regulated environments. Hardened TLS, per-request audit logging, and a pluggable policy engine (swap in Open Policy Agent with your own Rego). See the federal compliance page for the supported deployment shape.
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, configuration, and the full ACL reference: codeberg.org/VARASYS/ZDDC zddc/.
Install on your server
Two paths, no install scripts. The server has built-in fetch-and-cache for the tool HTMLs; the local-file path needs nothing more than a download.
Server: just run zddc-server
The app has the current-stable build of the tools baked in. They appear automatically at the right paths in the served tree:
- 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.
./zddc-server
No flags needed for a quick start. The served tree defaults to the current working directory; the listener defaults to https://localhost:8443/ with a self-signed certificate. --root, --addr, and --tls-cert / --tls-key override each. --help prints the full flag list.
To override a tool at any path: drop a real .html file there — that file wins over the baked-in version. To pin a different version, write an apps: entry in any .zddc file along the path:
# <project>/.zddc
apps:
browse: stable # latest stable, or v0.0.4 to pin an exact version
archive: https://my-fork.example/archive.html
URL sources are fetched once and cached in <ZDDC_ROOT>/_app/. To force a re-fetch, delete the cache file. Closer-to-leaf .zddc entries override parent ones.
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.
Learn more
- Technical Reference — the full ZDDC convention: filename format, tracking numbers, revisions, status codes, folder naming, transmittal workflow.
- Access control reference — cascade rules, common deployment shapes (paired open/closed projects + third-party-vendor folders), anti-patterns, a five-minute verify-it-works recipe, the federal-readiness gap analysis with NIST control references, and the OPA-compatible decider configuration.
- For federal evaluators — non-technical walk-through of what's already in place, the supported deployment shape, what an integrator adds during ATO, and the two-track build plan. Procurement-friendly entry point that links back to engineering detail.
- All releases — every version of every tool, with per-version pin URLs.
- codeberg.org/VARASYS/ZDDC — source code, issue tracker, contributor docs.