Overview

Zero Trust Data (ztd) is a zero-trust execution and evidence platform for AI agents, human operators, and distributed runtimes. Typed intent is admitted by a Gateway (Policy Decision Point) and independently re-verified and executed by a host-side Operator (Policy Execution Point). Every mutation is signed and recorded at the local execution boundary. A model can ask; it cannot directly act.

Fixed

  • First published release — The v1.0.0 through v1.0.3 tags exist but have no published release: v1.0.0 and v1.0.2 failed release verification, v1.0.1 was tagged without a matching VERSION, and v1.0.3 failed its R2 upload. v1.0.4 is the first published 1.0 release and contains everything described below.
  • Release verification — scripts/release-artifacts.sh checks the host binary using the typed ztd version --json --fips contract: version, linux/amd64 platform, source revision, clean source tree, and FIPS 140-3 approved mode.
  • Release rehearsal — The release workflow downloads and re-verifies the artifact set on every run, including no-publish rehearsals. Verification runs a private executable copy of the host binary, because artifact transfer drops the executable bit. make release-rehearse runs the workflow on main without publishing, and make release refuses to tag a commit without a successful rehearsal.
  • CI deployment lifecycle — scripts/ci/operator-deploy-lifecycle.sh provisions a master key file for its owned Gateway, so it runs on hosts without an OS key store, and prints the Gateway start and login logs on failure.
  • R2 publication — scripts/release-r2.sh publishes the website download set to the ztd-releases R2 bucket through the website's pinned wrangler, replacing the aws CLI against R2's S3-compatible endpoint. It refuses to overwrite any key of an immutable v<VERSION>/ set, reads every object back by SHA-256, and re-checks the set before promoting latest.json. Release rehearsals run it against wrangler local storage. The post-publication go install check now checks out the repository for its Go version.

Platform

  • Five-layer governance pipeline — Every governed mutation is a canonical protobuf GovernanceEnvelope that passes L1 Doctrine, L2 Consensus (K-of-N Ed25519 quorum), L3 Notary (WebAuthn or signed CLI proof), L4 Warden (pre-dispatch gate), and L5 Actuator (the sole execution boundary, which signs EXECUTING/COMPLETED/FAILED receipts). Governance posture (doctrine, consensus, ratify, notary) is fixed at Gateway startup and decides whether L2 and L3 gate execution or are audited. L1, L4, and L5 always run.
  • Gateway and outbound Operators — Operators connect outbound-only over mTLS and expose no inbound listeners. Roles (data, inference, provenance, observer) combine on one Operator, and ztd operator deploy deploys fleets locally or over SSH.
  • Local-first audit — Each executing runtime (Gateway, each Operator) is authoritative for its own SQLite audit database (which holds the execution record in events), and state root under .ztd/. Gateway-mirrored receipts are best-effort projections.
  • Store layout — Each runtime root holds one ztd.db (replay nonces, suspended transactions, audit and execution records) and one required encrypted file ledger; there are no separate replay, suspended-transaction, or execution-vault database files.
  • Ingress paths — MCP (POST /mcp or stdio), A2A (POST /a2a), governed HTTP dispatch, direct envelope submission, and CLI operator run. Direct submission and governed dispatch never synthesize missing L2/L3 proof; they fail closed at L4.
  • Protocol — Canonical Protobuf contracts in protocol/proto/ztd/ with generated Go and TypeScript bindings and JSON constant registries. Ingress transactions require protocol_version 2.
  • Console — A React and TypeScript browser console embedded in the binary and served by the Gateway at /console/: passkey sign-in, L3 and recovery approvals, platform enrollment review, Operator inventory and binding.
  • Evaluation and evidence — ztd eval campaigns with model provenance, typed grading, release-tagged campaigns, and the Evaluation Explorer; signed compliance report bundles with offline verification (ztd compliance); and a public spectator feed.
  • Autochthon — ztd autochthon runs with no Gateway, enrollment, or listener and outside the governance boundary. It samples the host and evolves a small predictor of it against persistence, recording each sample in a hash-chained tally under .ztd/autochthon/. ztd autochthon status verifies the chain, checks a recorded anchor, and reports skill. See Run an Autochthon.
  • Tooling — The single static ztd binary provides the Gateway, Operator, CLI, TUI, and eval/compliance tooling. ztd-adapter/ holds the audited adapter and contract pack for generated observe frontends.
  • Commit hygiene — scripts/check-commit-hygiene.sh runs from the pre-commit and pre-push hooks and the CI secret-scan job. It rejects ignored paths added with git add -f, blobs over 5 MiB outside vendor/, native executables, the committer's home path, and gitleaks findings (INV-SCRIPTS-09).

Distribution and configuration

  • Module and binary — Go module github.com/zerotrustdata/ztd. The ztd binary builds from cmd/ztd/ to bin/ztd-<os>-<arch> plus a root ./ztd. The Gateway component is ztdg and the Operator component is ztdo.
  • Deployment — Host processes: ztd gw start for the Gateway and ztd operator start for Operators, driven by make up, make gw, make operator, make status, and make down.
  • Configuration — The typed environment registry defines the supported ZTD_* keys. No key is required for the default host-native flow. Native commands do not load .env; platform configuration uses typed defaults or explicit flags.
  • Runtime state — .ztd/. A fresh Gateway start bootstraps a new trust domain, and each Operator enrolls against it. Operator identity is held in memory and re-issued on every enrollment.
  • Packages — Distribution is release binaries and the Go module. The five Node packages are private build dependencies and are not published.

Tests

Evidence: this section records the commands run from the final release commit and their results, and lists any command not run. The required commands are ./ztd test lint, ./ztd test unit, make console-lint console-test console-embed-check, make constants-check, make swagger-generate, and make doctrines-validate. The record is entered before tagging.

Compliance Evidence

Evidence: this section records the signed operational evidence bundle for the Gateway build assessed at release. The bundle requires a running Gateway built from the final release HEAD, governed activity from that build in the assessment window, and the release owner's report-signing key. It is generated by running ./ztd compliance release-prepare on the release commit. This section then records the bundle path, verification result, checksum root, assessment window, and source revision. The generated v1.0.0-compliance-evidence.md and v1.0.0-compliance-evidence.csv files are committed beside these notes (INV-REL-COMP-01).

Release qualification and limitations

  • ztd test release-smoke is provider-free. It exercises governed file and embedded document mutations and verifies the executing runtimes' local evidence. A passing run against the owner-frozen candidate is required before release readiness can be claimed.
  • Signed compliance evidence is a required release gate (see Compliance Evidence).
  • Evaluation executes single-model campaigns as governed tool-calling agents graded against each scenario's gold criteria, and heterogeneous system-lane formations with structural role completion. ztd eval rollout run qualifies queued models. Semantic-judge assignments fail closed as GRADER_FAILED because neither executor records judge evidence. See Evaluation Architecture.