Direct answer
The ZeroUI Decision Evidence Record (DER) is an unvalidated public reference draft designed to make governed software change decisions portable and reconstructable. It connects actor and agent identity, authorized scope, changed artifacts, policy versions, supporting evidence, rationale, outcome, approval, remediation, re-check, and release context.
Minimum record
Twelve questions the record should answer.
Decision
What identifier, time, required status, and schema version describe the record?
Actor
Who or what proposed the change, and under whose authority?
Agent
Which assistant, agent, automation, or tool session participated?
Scope
Which repository, service, known target environment, tenant, data, and tool actions were authorized?
Artifacts
Which commits, files, configurations, packages, or release digests changed?
Policy
Which policy IDs and versions were evaluated?
Evidence
Which tests, scans, simulations, approvals, or protected references supported the decision?
Rationale
Why did the evaluated context produce this outcome?
Outcome
Did the decision guide, allow, warn, hold, block, correct, re-check, record evidence, or route for approval?
Accountability
Which owner and approver were responsible for the decision?
Remediation
What needed to change before the next evaluation?
Re-check and release
Did the final artifact pass, and where was it released or observed?
Canonical machine values: guide, allow, warn, hold_for_review, block, correct, recheck, record_evidence, route_for_approval.
Abridged illustrative record
Readable by people and machines.
The inline record omits required fields for readability. The downloadable example includes every required field in the v0.1 schema. A production implementation should also apply access control, integrity protection, retention, redaction, and privacy requirements appropriate to the evidence.
{
"schema_version": "0.1",
"decision_id": "der_01J...",
"actor": { "type": "ai_agent", "accountable_owner": "team:payments" },
"scope": { "repository": "payments-api", "environment": "production" },
"policies": [{ "id": "SCG-RV-07", "version": "3.2" }],
"outcome": "hold_for_review",
"rationale": "Sensitive dependency change requires independent approval.",
"evidence": [{ "type": "test_result", "digest": "sha256:..." }],
"recheck": { "status": "pending" }
}Evidence safety
Record proof without creating a new exposure.
Reference sensitive material.
Use controlled identifiers, digests, and locations instead of embedding secrets, proprietary code, prompts, or personal data.
Protect integrity.
Bind evidence to immutable artifact digests, policy versions, timestamps, and identities; define who may append or correct a record.
Keep scope explicit.
A complete record supports review but does not independently prove control effectiveness, legal compliance, or product security.
Primary references
Evidence in a broader assurance system.
- NIST Secure Software Development Framework — Organizational secure development practices and evidence context.
- CISA Secure by Demand Guide — Customer questions and supplier transparency context.
FAQ
Decision evidence questions.
What is a Decision Evidence Record?
The ZeroUI Decision Evidence Record is a public reference draft designed to provide a structured, portable record of the context, policy, evidence, rationale, outcome, accountability, remediation, and re-check associated with a governed software change decision.
Is the ZeroUI Decision Evidence Record a compliance certification?
No. It is a ZeroUI reference specification. A complete record may support review and assurance, but it does not by itself prove that a control was effective or that an organization complies with a standard.
Should evidence include prompts or source code?
Only when policy requires it and handling is appropriate. Records can reference protected evidence by identifier, digest, or controlled location instead of copying sensitive prompts, code, secrets, or personal data into the record.
Can the record represent human and automated decisions?
Yes. The model separates the proposing actor, evaluating system, accountable owner, and approving actor so that human, assistant, agent, and automation roles remain explicit.