These controls ship in every release today. No federal-specific build required to use them.
.zddc file declares named roles whose members are email patterns; permissions reference role names rather than pasting the same wildcards across every directory. Role definitions cascade and child files shadow ancestors for that subtree, so federation between an organisation-wide role definition and a project-specific override is built in. Maps cleanly to AC-3(7) "role-based" enforcement and AC-2 account-management workflows.r read, w overwrite, c create, d delete, a admin / edit ACL. A grant of rc means "this principal can read existing files and create new ones, but cannot modify or delete what's already there" — exactly the permission shape an immutable archive needs. Empty grants ("") are explicit denies that beat any other grant at the same level.archive/<party>/issued/ or archive/<party>/received/ are protected by a server-enforced verb mask: ancestor grants are reduced to read-only when crossing the WORM boundary, regardless of what an upstream .zddc says. A separate .zddc placed at the WORM folder itself can grant rc to specific principals (the doc-controller dropping a fresh transmittal) — that survives the mask. Root admins bypass the mask only as the deliberate escape hatch for mis-filed documents, with bypasses visible in the audit log..zddc cascade chain to /v1/data/zddc/access/allow; the customer's OPA returns allow/deny. Default in-process engine and OPA-delegated engine speak the same wire format, so customers swap by setting one environment variable. Failures fail closed by default; ZDDC_OPA_FAIL_OPEN=1 flips it for the rare case where availability outranks confidentiality.zddc-server --print-rego=federal emits it for use with the customer's OPA./.profile/effective-policy?path=<url> on a running server to see the resolved ACL chain at any path — every directory's grants, the role evaluation, and the final verb-set returned for the requesting user. A security reviewer can confirm "yes, this person has exactly these rights at this path" without reading the source. Helpful during accreditation and for incident response..zddc ACL model has documented invariants — root-only admin escalation gate, subtree-author authority limited to their subtree, default-deny when any .zddc exists. The access-control reference includes a five-minute verify-it recipe a security reviewer can run on their own deployment..zddc model grants access by email pattern. Federal AC-3(7) wants role-based grants populated from the customer's identity provider. The cascade syntax extends to express role allow/deny alongside email allow/deny; roles flow through the same OPA hook so customers running their own Rego pick them up automatically..zddc model — see the "Role-based access control" row above. What an integrator adds for federal is a sync layer that populates a role's members: list from the customer's identity provider (Active Directory groups, Okta, EntraID) on a schedule, so role membership tracks the IdP rather than being maintained by hand. The cascade format already accepts role members; this is the wiring that keeps them in sync..zddc change produces a diff that reviewers approve before deploy. NIST CM-3./.profile/effective-policy) already returns a resolved policy for any single path. What's missing is a batch export — a command that walks the entire served tree and emits every directory's resolved access policy in JSON / Markdown / CSV. The change-control workflow checks the export into a Git repo; every .zddc change produces a diff that reviewers approve before deploy. NIST CM-3.A project is a directory containing a single .zddc file. The server materialises the canonical folders below on the first write into them — drop a .zddc in an empty directory, point zddc-server at it, and the layout comes to life as content arrives. Folder names are matched case-insensitively, so a manually-created Working/ is reused rather than shadowed by a new working/.
A ZDDC project mirrors the natural lifecycle of an engineering deliverable: drafted in private, lined up for issue, formally exchanged, kept as record. Each canonical folder maps to one of those stages, so file location alone tells you where a document is in its lifecycle. An operator only needs to create one file — a .zddc in an empty directory — and the rest of the layout populates as work happens.
mdl.table.html).
- Default schema is built into the
- server; per-party overrides via a
- tables: { mdl: ./mdl.table.yaml }
- entry in the party's .zddc.
- incoming/ ← that party's drop point. Auto-own
- .zddc grants the creator of each new
- subfolder full control.
- received/ ← permanent record of incoming we've
- accepted (WORM — write-once read-many).
- issued/ ← permanent record of what we sent to
- that party (WORM).
+ .zddc ← the only file an operator must create
+
+ working/ ← Where staff draft. Each person has their own
+ subfolder here (named by email) and works on
+ documents in private until they're ready to
+ issue. Markdown opens in mdedit; arbitrary
+ files are dropped in via the browse tool.
+
+ staging/ ← The "about to issue" lane. A folder in here
+ declares a planned outbound transmittal: its
+ name carries the planned issue date and tracking
+ number, so anyone can see what's queued up and
+ when. Files in staging are the finalised set;
+ drafting still happens in working/.
+
+ reviewing/ ← One place to see everything we owe a response
+ on. Each row pairs an inbound submittal we've
+ accepted with our in-progress response draft —
+ saves staff from hunting across per-party
+ folders to find what's open.
+
+ archive/ ← The permanent record. Everything we've ever
+ formally exchanged with a counterparty lives
+ here, organised one folder per party.
+ {party-name}/ ← One per counterparty; one for ourselves.
+ We treat our own organisation as just another
+ party so internal deliverables get the same
+ tracking treatment as external ones.
+ mdl/ ← The party's Master Deliverables List —
+ what they're going to produce, planned and
+ in-flight. Opens as a grid editor; rows are
+ individual yaml files, one per deliverable.
+ incoming/ ← Where that party drops things for us. Acts
+ as a quality-check buffer before content
+ becomes part of the permanent record.
+ received/ ← What we've accepted from that party. Immutable;
+ the historical record of inbound documents.
+ issued/ ← What we sent to that party. Immutable; the
+ historical record of outbound documents.
Mechanics: folders materialise on first write, names match case-insensitively, the staging↔working pairing is automatic, the immutable folders enforce write-once via an ACL mask, and a virtual <your-email>/ entry under working/ creates your personal subfolder on first save. None of that needs to be in your head when you're using the system — drop files where the lifecycle says they go and the layout takes care of itself.
5-step transmittal workflow: