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.

​

Internal QA Release Gate

Not every product ships into a regulated market. But every shipped product carries product-liability exposure, customer-quality expectations, and an organisational interest in shipping things that work. This pattern uses Roboticks as an internal QA release gate — without any external notified-body involvement — to enforce a defensible, repeatable release discipline. The pattern is also a useful starting point for organisations that intend to pursue external certification later. The artefacts produced here are exactly the artefacts the external pattern needs; adopting them now means certification adds process around evidence you already have, rather than retroactively assembling it.

​

Scenario

You ship a robotics product. There is no external conformity-assessment regime you must satisfy today — perhaps your jurisdiction does not require it, perhaps your product class is exempt, perhaps your customers do not demand it. But:

• Your customers have quality expectations.
• Your organisation carries product-liability exposure.
• Engineering wants a stop-the-line discipline rather than firefighting every regression in the field.
• Leadership wants a posture dashboard that says “today, are we shippable.”

This pattern gives you that, without dragging in the external-assessment overhead.

​

Project setup

​

The posture dashboard

The release-readiness view is the daily artefact for engineering leadership and QA:

• Coverage: of pinned requirements, how many have at least one passing confirming test.
• Gaps: requirements with no confirming test, or confirming tests that fail.
• Acknowledged gaps: requirements with documented rationale for not having coverage (e.g., feature deferred to next release).
• Regression streak: how many days since the last test that was passing has failed.
• Pinned standards: any open amendments not triaged.

The dashboard is the answer to “are we shippable today.” A green dashboard does not guarantee a flawless product; a non-green dashboard says explicitly what is unresolved.

​

The release-state machine

Even without external certification, use the Release state machine: Each transition can require a sign-off. Configure approvers per project — typically the engineering lead and the QA lead — and the platform records who signed off, when, and with what comment.

​

Sign-off workflow

Recommended sign-off configuration:

• draft → verifying: any engineer with project write access.
• verifying → verified: automatic on full test pass; manual if you allow acknowledged gaps.
• verified → shipped: required sign-off from engineering lead and QA lead. Optional: PM or compliance.

Sign-off records appear in the evidence pack as a “release sign-off” section. Even without an external auditor, this is the evidence you want in the file when a customer escalation or warranty claim arrives months later.

​

Evidence retention for product liability

You may not be filing technical files with notified bodies, but you do carry product-liability exposure. Many jurisdictions impose a 10-year (or longer) product-liability tail. The evidence-pack archive lifecycle (Archive) gives you that retention automatically:

• 90 days hot.
• Then 10 years (or your configured floor, up to 25) in S3 Glacier Deep Archive.
• Verifiable years later via the hash chain.

When a customer reports a defect 18 months after delivery, the evidence pack for that build is the documented record of what your verification covered, what passed, what was deferred. It is what you hand to your legal team.

​

Without standards pinning

If you have no use for standards subscriptions, the pattern still works:

• Author requirements with derives_from: []. They live in Roboticks but reference no external clause.
• Generate evidence packs the same way; the pack omits the “standards conformance” section.
• The hash chain, retention, traceability matrix, and posture dashboard all function normally.

The standards subscription is the bridge to external compliance; without external compliance, the rest of the platform remains valuable.

​

When to graduate to external certification

Common triggers for moving from this pattern to an external-certification pattern:

• A target market begins regulating your product class (e.g., EU MR 2023/1230 application date arrives).
• A major customer requires conformity declarations.
• Insurance pricing makes certification cost-effective.
• A field incident triggers a review that recommends certification.

The graduation cost is low: every artefact this pattern produces is exactly the artefact the certification patterns need. You pin the relevant standard, run the Re-conformity workflow (treating your existing requirements as the “before” state and the standard-derived requirements as the “after”), and continue.

​

Maintenance

​

Next steps