The pipeline is green. Automated checks have finished, and the release manager can point to a completed run. It feels reasonable to say that the release decision is already documented.
A build artifact and a release decision answer different questions. The artifact can show that a process produced a result. A separate record can connect that result to the version, named owner, evidence considered, unresolved exception, rollback condition and next review. That six-part record is a PARAVEILUX inference, not a claim that NIST, CISA or another framework requires this exact form, and it does not make a release safe.
Fact: official sources provide development and vulnerability context
NIST publishes SP 800-218, Secure Software Development Framework v1.1, published in February 2022. It recommends high-level secure-development practices in a voluntary US institutional context.
That official material provides secure-development context within its own institutional scope. It does not require this article’s release-record form or establish that a particular release is safe, authorized, compliant or unaffected by vulnerabilities.
Signal: “the pipeline passed” has become the whole file
Automation produces logs, timestamps and a dashboard result. Human judgment may instead sit in a meeting note, chat or an engineer’s working file. Investigate when a build has no linked decision owner, an exception appears only in chat, rollback steps have no invocation condition, or a release note identifies the version but not the evidence reviewed.
Counter-signals include a stable version, dated evidence set, named owner, visible exception state and review trigger. They make the reasoning inspectable. They do not certify the release.
Action: preserve the decision around the result
For a material release, record the product or service and exact version; the named decision owner and role; the security, change and service evidence actually considered; unresolved exceptions with source and status; the condition that prompts rollback or another decision; and the next review event and person responsible for reopening the file.
These are illustrative fields, not a universal control list. A lower-risk automated change may use a smaller path. A material version change, new exception, catalog match, failed control or rollback event may justify deeper review.
The hidden variable is the decision evidence around the build. Release engineering owns build facts. Security may supply security input. A product or service owner weighs business impact. Counsel may need to review an external assurance. The owner remains the decision-maker by asking: “Can the organization show what it decided, on which evidence and what would change that decision?”
Owner Q&A
Must every release use the same record?
No. Start with materiality and what qualified reviewers need to reconstruct. Make the scaling rule visible.
Does an exception require stopping?
This article does not decide that. A useful record can preserve the exception, evidence, owner, treatment and revisit trigger without predetermining the outcome.
What is the smallest useful test?
Ask someone outside one recent release to identify its version, evidence, exception owner and rollback trigger. Record what the file cannot answer.
Next verification
Ask whether someone outside one recent release can reconstruct the version, owner, evidence, exception and rollback trigger. Before making a customer promise or regulatory, contractual or legal-effect statement, check the current rules, agreement, product facts and evidence for that specific release.
Limitations: the record does not certify the release
A release-decision record does not prove security, authorization, compliance, product quality or absence of defects. A green pipeline does not prove those outcomes, and a record creates no liability shield.
Product applicability, release safety, vulnerability treatment and legal effect remain Not assessed. This is general risk education, not professional or certified advice. NIST supplies bounded US institutional context; whether a comparable issue can arise for you depends on current local rules, product, version, release process, contracts and evidence.