Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.roboticks.io/llms.txt

Use this file to discover all available pages before exploring further.

​
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

StateWhat it meansPack generation
draftRelease exists, commits pinned, but verification has not startedNot allowed
verifyingTests are running against the pinned commit setNot allowed
verifiedEvery required test passed; the Release is ready to shipAllowed
shippedMarked as released to customers; appears in posture dashboardsAllowed
archivedBeyond active support; evidence in Deep ArchiveAllowed; requires Glacier restore
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: 
rbtk test evidence-pack \
  --branch fix/imu-drift \
  --commit-set 9b14ab8 \
  --format zip
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

ScenarioScope
Shipping a build to customersRelease
Submitting evidence to a notified bodyRelease
Customer asks “what does the May 2026 build look like under ISO 10218-1:2025?”Release
Bisecting a flaky test across 8 commitsAd-hoc per commit
Producing evidence for an internal change-control board on an in-flight branchAd-hoc
Demonstrating that a proposed patch fixes a regressionAd-hoc

​
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.