On this page
- Give a new named release its own evidence and assessment context.
- Keep the newest attempt separate from the last completed baseline.
- Compare components and findings without transferring decisions by assumption.
- Retained evidence makes a record reconstructable; it does not prove deployed behaviour.
Use the release as the unit of explanation
Suppose version 2.4 used one dependency set and version 2.5 introduced a new update mechanism. A current inventory cannot explain both versions, and the older test report cannot demonstrate the new updater. Keep product identity, source snapshot, component inventory, tests and decisions associated with the release they concern.
Article 31 and Annex VII of the CRA frame technical documentation around the relevant product. The release-record approach described here is an engineering method for maintaining that evidence, not a prescribed regulator database schema or a claim that every software update requires a wholly new legal procedure.
Create the next assessment without losing the earlier one
Named release versioning is a Continuous capability. A source update carries the validated release label into a new product release and assessment context. A run refers to its own source and supplied SBOM input, rather than resolving whichever document happens to be active later.
When a new run is queued, running or failed, ConformOps keeps the newest attempt separate from the last completed baseline. The last usable result remains accessible, with its age and invalidation state visible. A failed new assessment is not evidence that the old result now describes the new input.
Read a comparison as a change investigation
The History comparison can show component additions, removals and version changes between completed runs, along with provenance and inventory-source changes. It retains full counts beside bounded samples. Stable three-part semantic versions in supported ecosystems can have a direction; other version strings may remain direction-unknown.
Start with changes that affect the product's attack surface, shipped dependencies, update path or support assumptions. A removed library is not necessarily replaced by a newly added one. A newer version is not automatically safer. Compare the relevant security evidence and document the engineering explanation before closing the review.
Inspect the lineage when a reviewer asks why
The evidence-lineage view projects recorded relationships between releases, snapshots, runs, evidence, artifacts and decisions. Select the run being reviewed and inspect its links and notices. It is useful for locating the record behind a claim; it does not invent a causal link simply because two findings appeared in the same assessment.
The lineage view has collection limits and discloses incomplete windows. Its optional JSON export excludes source paths, contents and personal details. Use the assessment export for the fuller evidence collection rather than treating the graph download as the entire technical file. Historical access depends on the retained-history capability.
Make approval changes visible
An affectedness decision, classification approval or accepted risk has a subject and a context. Do not carry it to another release merely because the product name is unchanged. ConformOps retains append-only decision history and tracks supersession, so a later conclusion can be distinguished from the earlier record.
For the new updater in version 2.5, retain the new tests and review any changed product facts. For an older supported version, keep its own vulnerability investigation and corrective path understandable. The team may be maintaining several branches at once; release evidence should reflect that reality.
Export a record that survives the next review
Download the assessment artifacts with their release and run identity and file-level hashes. A hash helps detect a changed retained artifact; it does not prove who authored the source, that a deployed binary matches it or that the product is legally compliant. Reconstructable records are valuable precisely because their claims are bounded.
Use the CI/CD integration guide to connect repeatable evidence work to your pipeline. A passed engineering gate evaluates recorded conditions and does not approve legal compliance. For the work before your first baseline, follow the self-assessment guide.
Frequently asked questions
Does a failed rerun remove the last completed assessment?
No. ConformOps keeps the latest attempt separate from the last completed baseline. The older result remains accessible with its scope and state, rather than being presented as a successful assessment of new input.
Does a component upgrade carry over a not-affected decision?
A decision must be read in its release and component context. A version change does not by itself justify carrying the same conclusion into the new release.
Does reproducible evidence mean the next scan is identical?
No. It means the retained inputs, outputs and decisions can be identified and reconstructed. Live intelligence and later assessments can change, and those changes should be visible.