Skip to main content

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

​
Step 6 — Updated evidence pack

Generate a new evidence pack scoped to the re-verified release:
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.