> ## 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

> Handling re-conformity after a pinned-standard amendment. Feed alert → diff view → impacted requirements → change-impact analysis → targeted re-verification → updated evidence pack and DoC.

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

<Warning>
  **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.
</Warning>

## 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

```mermaid theme={null}
%%{init: {"theme": "neutral", "themeVariables": {"primaryColor": "#4040ff"}} }%%
flowchart LR
    Alert["Feed alert"] --> Diff["Diff view"]
    Diff --> Triage["Triage impacted requirements"]
    Triage -->|"derived requirement unaffected"| Doc["Document unchanged"]
    Triage -->|"derived requirement needs update"| Update["Update requirement text + acceptance"]
    Update --> CIA["Change-impact analysis"]
    CIA --> Reverify["Targeted re-verification"]
    Reverify --> Pack["New evidence pack"]
    Pack --> DoC["Updated DoC (if needed)"]
```

## Step 1 — Feed alert

Within hours of the amendment's publication, the [publication feed](/standards/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:

| Action            | When                                                                                         |
| ----------------- | -------------------------------------------------------------------------------------------- |
| **Unaffected**    | The clause change is editorial or cosmetic; the requirement text is still accurate.          |
| **Needs update**  | The clause change is substantive; the requirement text or acceptance criteria need revision. |
| **Now redundant** | The 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](/compliance/change-impact-workflow) 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:

```bash theme={null}
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:

| Outcome                                 | Interpretation                                                                                                                                                               |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **All tests still pass**                | Conformance maintained on the same code against the amended standard. Generate updated evidence pack.                                                                        |
| **Some tests now fail**                 | The 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 applicable** | The 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:

```bash theme={null}
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

<CardGroup cols={2}>
  <Card title="Standards feed" icon="rss" href="/standards/feed">
    Where the alerts originate.
  </Card>

  <Card title="Change-impact workflow" icon="code-pull-request" href="/compliance/change-impact-workflow">
    The per-PR analog of this re-conformity workflow.
  </Card>

  <Card title="EU MR conformity" icon="flag" href="/compliance/eu-mr-2023-1230-conformity">
    The framing conformity workflow this maintains.
  </Card>
</CardGroup>