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.

​
Re-Conformity on Standard Amendment

Standards amend. New editions publish, technical corrigenda land, harmonised lists shift. When a standard you have pinned amends, every conformity claim that referenced the prior edition is potentially affected. This pattern walks the workflow from the publication-feed alert to an updated conformity claim, using the platform’s amendment-diff view, change-impact analysis, and pure-replay re-verification.
Roboticks is audit-readiness tooling, not a certified toolchain. We assemble the evidence your notified body, certification body, or QA process ingests. We do not replace tool qualification (DO-178C, ISO 26262-8 TCL) and we do not issue conformity assessments. Verify the regulatory interpretations on this page against the standard text and your accredited assessor.

​
Scenario

You shipped a product on May 15, 2027 under EU MR 2023/1230 conformity, referencing the harmonised standards stack including ISO 10218-1:2025. On August 22, 2027, ISO publishes an amendment to ISO 10218-1:2025 that touches several clauses you derived requirements from. Your conformity claim — and possibly your DoC — needs review.

​
The workflow

​
Step 1 — Feed alert

Within hours of the amendment’s publication, the publication feed detects it. The dashboard shows a banner; Slack and PagerDuty (if configured) fire. The alert payload:
  • Standard ID and amendment number.
  • Number of pinned-standard requirements derived from clauses changed by the amendment.
  • Severity (warning for an amendment with impacted requirements; critical for a withdrawal).
  • Link to the diff view.

​
Step 2 — Diff view

Open the diff view. It renders:
  • Clauses added — likely new derivation opportunities; do you need new requirements?
  • Clauses removed — derived requirements pointing to removed clauses are now orphaned; review.
  • Clauses changed — for each changed clause, every derived requirement is listed alongside the before/after clause text.
  • Renumbering — automatic remapping where the publisher provides one, flagged for confirmation.
For each derived requirement, the diff view offers three triage actions:
ActionWhen
UnaffectedThe clause change is editorial or cosmetic; the requirement text is still accurate.
Needs updateThe clause change is substantive; the requirement text or acceptance criteria need revision.
Now redundantThe clause was removed and the requirement no longer applies.
The triage is human; the platform records who triaged each and when.

​
Step 3 — Update affected requirements

For each Needs update requirement:
  1. Edit the requirement text to reflect the new clause.
  2. Update acceptance if new tests are required.
  3. Update derives_from to point at the new edition / amendment number.
  4. Commit. The new requirement version is recorded against the amendment.
For Now redundant requirements: mark them as withdrawn; they remain in history but no longer derive from a live clause. For Unaffected: the platform records the triage decision; no edit needed.

​
Step 4 — Change-impact analysis

The change-impact analysis runs over every requirement edit. For each updated requirement:
  • Which tests confirm it? Are they still adequate?
  • Which code modules implement the behaviour the requirement covers? Do they need changes?
  • Which historical releases were verified against the now-obsolete requirement text?
The change-impact output goes into a structured re-conformity work item in the dashboard. Each work item has a status (open, in_progress, resolved, acknowledged_gap).

​
Step 5 — Targeted re-verification

For each historical release affected — typically the most recent shipped release and any release still in active support: 
rbtk release reverify v3.1.0 \
  --reason "Re-verify against ISO 10218-1:2025 Amendment 1"
Re-verification is a pure replay:
  • The same pinned commit set is checked out (no code change).
  • The same test suite runs.
  • The new requirement text is in force (the platform tracks the version of every requirement against the release).
Outcomes:
OutcomeInterpretation
All tests still passConformance maintained on the same code against the amended standard. Generate updated evidence pack.
Some tests now failThe amended clause text caught a previously-tolerated behaviour. Decide: fix the code (substantial modification), document as acknowledged gap, or pull product from market.
Some tests are no longer applicableThe amended clause text no longer requires what the test verified. Update test selection; document.

​
Step 6 — Updated evidence pack

Generate a new evidence pack scoped to the re-verified release: 
rbtk test evidence-pack --release v3.1.0 --format pdf,zip,reqif
The pack:
  • Carries the re-verification timestamp.
  • References both the original verification (preserved) and the re-verification.
  • Includes the amendment-diff record showing what changed and how it was triaged.
  • Chains into the project’s hash chain as a new pack (the original pack is unchanged).

​
Step 7 — Updated DoC (if needed)

A re-verification that maintains conformance against the amendment with no code change typically does not require a new DoC issuance — the DoC referenced the harmonised standards by edition, and the amendment is now incorporated by reference in the same harmonised standard. A re-verification that found new failures, leading to code change, is a substantial modification under EU MR 2023/1230 Article 18 and requires a new conformity assessment. Verify the DoC re-issuance requirement with your notified body for any non-trivial case.

​
Step 8 — Communicate to the field (if needed)

If the amendment surfaces a previously-undetected issue, your customer-communication obligations under product-liability and post-market-surveillance rules may trigger. Roboticks’s role is the verification evidence; the customer communication is your compliance function’s responsibility. The pack documents what you knew and when.

​
Example: ISO 10218-1:2025 Amendment 1 walkthrough

A worked example:
  1. 2027-08-22 14:00 UTC — ISO publishes ISO 10218-1:2025/A1, touching §5.10.5 (PFL safety functions).
  2. 2027-08-22 14:30 UTC — Roboticks feed detects the amendment. Dashboard alert + Slack message.
  3. 2027-08-22 16:00 UTC — Engineering opens the diff view. 8 derived requirements reference §5.10.5; 6 are marked Unaffected (editorial), 2 are marked Needs update (new threshold language).
  4. 2027-08-23 — Compliance updates the 2 affected requirements; change-impact analysis identifies 14 tests that need re-run.
  5. 2027-08-24 — rbtk release reverify v3.1.0. All 14 tests still pass.
  6. 2027-08-25 — New evidence pack generated; hash-chain anchored. Pack delivered to notified body for surveillance review.
  7. 2027-09-02 — Notified body confirms continued conformity. No DoC re-issuance required.
End-to-end: 11 days. Comparable workflows without traceability tooling typically take weeks to months.

​
Maintenance pattern

Configure your team’s habits around the feed:
  • Slack channel for warning-severity standard alerts; pages to compliance lead for critical.
  • Standing weekly review of any open re-conformity work items.
  • SLA targets for triage (typically 5 business days from alert to triage decision; 30 days to complete re-verification of all affected releases).

​
Next steps

Standards feed

Where the alerts originate.

Change-impact workflow

The per-PR analog of this re-conformity workflow.

EU MR conformity

The framing conformity workflow this maintains.