Skip to main content

​
Release Scoping

An evidence pack belongs to either a Release or an ad-hoc branch + commit_set. The Release form is what auditors expect; the ad-hoc form exists for debugging, customer escalations, and sandbox runs.

​
Releases — the canonical form

A Release in Roboticks is an immutable pinning of:
  • A specific commit on every linked repository.
  • A snapshot of every requirement at the moment the Release was cut.
  • The verification results — every test run that fed verification, every MCAP, every coverage report.
  • A reference to the pinned standards and their edition / amendment level at cut time.
Once a Release reaches state verified, none of the above can change. Re-verifying a Release is a pure replay: the platform re-runs the same tests on the same commit set; the outcomes are added to the Release’s verification history without altering the original. Auditors see the full re-verification history alongside the original results.

​
The Release state machine

A pack generated against a verified Release is identical to one generated against the same Release after it transitions to shipped. The transition is metadata; it does not alter evidence.

​
Cutting a Release

1

Create the Release

From the dashboard: Releases → Cut new release. Or from CLI: rbtk release cut --tag v1.4.0. Provide a tag, a title, and the commits to pin (one per linked repository — defaults to the most recent commit on the chosen branch).
2

Snapshot requirements

The platform automatically snapshots every pinned requirement. This is a deep copy — the snapshot is immutable even if the live requirement is later edited.
3

Run verification

The platform dispatches every required test to the runner pools. Status moves from draft → verifying.
4

Reach verified

On full pass, the Release auto-promotes to verified. On any required failure, it returns to draft for fix-and-recut. (Optional acknowledged-gap workflow lets you promote with documented gaps; the pack records the acknowledgment.)
5

Generate the pack

See Generation.
6

Mark as shipped

When you actually ship the build to customers, mark the Release shipped. This is the trigger that starts the 10-year retention clock.

​
Re-verification semantics

A Release can be re-verified at any time. Re-verification is intentionally constrained:
  • The exact pinned commits are checked out — no latest substitution.
  • The same requirement snapshot is in force.
  • The same test selection runs.
  • The original results are retained; the re-verification adds a new run alongside.
This is what powers Re-conformity on amendment: when a pinned standard amends, you re-verify the affected Releases against the same commits to demonstrate continued conformance — or to surface the specific tests that now fail against the new clause.

​
Ad-hoc commit sets

For investigations that do not correspond to a shipped Release — bisecting a regression, evaluating a customer-reported failure on a specific commit, exploring “would this hypothetical patch pass” — generate a pack scoped to a branch + commit_set:
The pack:
  • Is fully signed, enters the hash chain, and is retained per the project’s retention policy.
  • Is watermarked NOT FOR RELEASE in the PDF.
  • Does not appear in the posture dashboard or in conformance rolls.
  • Is suitable for engineering forensics, customer support evidence, and internal QA, but not for regulator hand-off.
The watermark is intentional: an auditor seeing a NOT FOR RELEASE pack should reject it. The scoping protects you from accidentally handing an ad-hoc inspection to an external party as if it were a release artefact.

​
Which to use

​
Multi-repository releases

Most production robotics codebases span multiple repositories — firmware, messages, simulation worlds, deploy tooling. A Roboticks Release pins commits across all of them via the project’s linked repositories configuration. When you cut a Release, the dashboard shows every linked repository and lets you pick the commit (or branch HEAD) for each. The pack records all of them in release.repositories.

​
Next steps

Generate a pack

From a Release or an ad-hoc commit set.

Re-conformity workflow

Re-verifying a Release after a standard amends.

Internal release gate

Using Releases as your internal QA gate.