A non-technical entry point for federal evaluators answering "can this
go in our environment, and what would need to be added during ATO?" —
the question that today only has an answer buried in the engineering
README.
Six sections, written for the procurement / decision-maker audience
with engineers as the secondary reader:
1. Hero: ZDDC is designed to be deployed in regulated environments.
2. What's already in place — hardened TLS posture, pluggable OPA
policy engine, federal-mode strict-least-privilege Rego, audit
logging, vulnerability-disclosure policy, documented access-
control model with a 5-minute verify-it recipe.
3. Supported deployment shape — diagram showing zddc-server on
loopback behind a TLS-terminating proxy on a RHEL/UBI base.
4. What you'd add for full ATO — table of five integration items
(FIPS-validated crypto, authenticated proxy↔server channel, RBAC,
policy export, code-signed tool fetches) with plain-language
summaries.
5. The two-track build plan — explains why the standard binary
stays pure-Go and a parallel zddc-server-fips build is the right
answer for federal customers.
6. Engineering reference — links into the in-repo gap analysis,
ARCHITECTURE.md security section, and access-control reference
for implementors.
Linked from index.html in two places: a new feature bullet on the
zddc-server (optional) section pointing at the page, and a "For
federal evaluators" entry in the Learn-more list at the bottom.
No engineering content here — federal.html is the procurement entry
point. The deeper detail (NIST control numbers, library choices,
effort estimates) lives in zddc/README.md § Federal-readiness gap
analysis where engineers will look for it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
