ZDDC — Zero Day Document Control

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 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.

Read the full specification →

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.

Archive Browser

Search the formal record. Filter by tracking number, discipline, revision, status, or free text; group rows by transmittal to see each deliverable's lifecycle; export the current selection as a ZIP. Read-only — the archive is preserved as-issued.

Open Archive Browser →

Browse

File-tree navigator for the whole project. Edit markdown in place with live preview, YAML front matter, and a table of contents pane; download any markdown source as DOCX, HTML, or PDF on demand; classify inbound files to ZDDC names, draft transmittals, and manage the project tree end-to-end.

Open Browse →

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 Browser 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:

Lazy folder creation, case-fold matching. Drop a .zddc file into an empty directory and the canonical project layout (working/, staging/, archive/<party>/{mdl,incoming,received,issued}/) materialises on the first write into each path — never on bare reads. 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 working/<your-email>/ entry; first write makes it real.
Virtual .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.
Access control via .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.
Roles for human-readable grants. A .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
```
Role definitions cascade like everything else; a child .zddc redefining the same role name shadows the ancestor for that subtree.
WORM archive folders. Anything under 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.
Cascade tracer for operators. Admins can hit /.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.
Per-request access logging keyed to the authenticated user; conservative HTTP timeouts; optional file-tee for offline audit (production deployments typically leave logs on stdout for the orchestrator's pipeline to handle).
TLS, ETags, conditional GET, CORS, autoindex. The mundane glue.
OPA-compatible policy decider. Federal and other regulated customers can swap the built-in evaluator for an external Open Policy Agent server with their own audited Rego policies — set 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.
Designed for regulated environments. Hardened TLS (NIST SP 800-52 Rev. 2 cipher allowlist + HSTS), pluggable policy engine, federal-mode strict-least-privilege Rego shipping out of the box, structured audit logging, documented vulnerability-disclosure process. Specific federal-track work (FIPS-validated build, signed-token proxy↔server channel, code-signed tool fetches) is on a clear roadmap — see the federal compliance page for the supported deployment shape and what an integrator adds during ATO.

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.

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 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:

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
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.