The Trust Layer

"Trust me, it works" is not an engineering artifact. SDTK's trust layer is the set of mechanisms that back every claim with a file you can open: evidence, guardrails, review packets, verification, and reports.

Evidence over vibes

Every SDTK phase closes with an artifact, not an assertion:

Claim	Backing artifact
"The code is verified"	sdtk-code verify --evidence output, attached to the feature
"This PR is ready"	Review packet produced by the ship flow
"The design was reviewed"	docs/design/reviews/DESIGN_REVIEW_YYYYMMDD.md
"The deploy succeeded"	ops-verify evidence closing the journey
"The agent run finished"	sdtk-agent run report — every task, gate decision, and evidence file

Guardrails (SDTK-CODE)

sdtk-code ships a guardrails subsystem that constrains what an implementation session may touch:

sdtk-code guardrails init     # set up guardrails for a feature
sdtk-code guardrails check    # validate current state against them
sdtk-code guardrails scope    # inspect/adjust the allowed scope
sdtk-code guardrails trace    # trace what was touched vs. what was allowed

Alongside it, sdtk-code readiness --feature-key <key> reports whether a feature is actually ready to progress, and sdtk-code doctor checks the workspace itself.

Sleep Mode is preflight, not autopilot Shipped

sdtk-code sleep plan and sleep report are shipped dry-run preflight tools: they let you assess what an unattended work session would involve and report on the plan. Sleep unattended execution is Gated — not shipped today. The related agent-team sleep-execute verb is bounded to docs/governance Markdown authoring — it is not arbitrary code execution.

Safety in the kernel (SDTK-AGENT)

The agent runtime applies trust mechanics before any dispatch:

• Path containment — every write is checked against the run-ledger root before touching disk; .env and project files outside the ledger are never touched by the controller.
• Binary allowlists — the shell and sdtk-cli adapters only dispatch allowlisted binaries; unknown binaries fail closed with no evidence written.
• Argument policy — shell metacharacters and network-mutating flags are rejected before dispatch. On Windows, .cmd/.bat shims run under a strict argument policy where any token containing %, ^, " or control characters fails closed.
• Secret redaction — secrets are redacted (parity-tested against sdtk-code's redactor) before evidence or reports are written to disk.
• Fail-closed adapters — the currently published npm Hermes Kanban adapter refuses mode:"live" fail-closed; it only compiles dry-run plans. See Hermes Adapter.

Trust boundaries to know

• Evidence trust is same-machine in v0.x. The ledger records what was written on this machine; there is no remote-worker authenticity protocol yet.
• Local-first, not air-gapped. Repo-owned artifacts stay local; external model/API/runtime calls happen only when you explicitly invoke a runtime.
• The full shipped-vs-gated picture lives in Maturity & Versions.

Where to go next

SDTK-CODE guideThe governed implementation workflow the trust layer wraps.

The Governance KernelLedger, state machine, and adapters underneath the trust layer.

Maturity tableWhat is Shipped, Preview, Pro, Gated, or Unpublished.