Robotics change impact analysis follows a proposed change through its requirements, interfaces, implementation dependencies and supporting evidence. For a perception-model substitution, review the exact old and candidate configurations, give each affected domain an owner and record its finding, evidence and open action. A requirement can stay unchanged while the evidence supporting it needs reassessment.
One model changes, several owners need an answer
“We are only replacing the model” sounds like a small scope. It is a useful starting claim to check. The new model may use the same output fields while changing when a detection arrives, what its timestamp means or which runtime assumptions it relies on. None of those consequences can be settled from the model filename.
The review needs a concrete dossier: the declared substitution, the dependencies each owner inspected and the decision the available evidence supports. NASA's requirements-management guidance assesses change across requirements, architecture, design, interfaces and operating concepts. That supplies a transferable review principle. A commercial robotics programme defines its own decision authority.
Define the M1-to-M2 substitution before assessing it
WR-01 is a fictional supervised indoor warehouse replay bench. CR-014 is a teaching proposal to replace perception model M1 with M2. Its identifiers, 80 ms target and evidence states are invented for the exercise. They provide no customer result, safe stopping distance, physical operating release or safety acceptance. Actual execution, measurement and review facts are not supplied.
CFG-A = H1/L1/F1.4/M1/CAL-07/MAP-03 is the accepted historical teaching state. Candidate CFG-B = H1/L1/F1.4/M2/CAL-07/MAP-03 has only M1 → M2 declared to change.
| Manifest element | Historical teaching CFG-A | Candidate teaching CFG-B | Declared difference |
|---|---|---|---|
| Hardware | H1 | H1 | None declared |
| Lidar | L1 | L1 | None declared |
| Firmware | F1.4 | F1.4 | None declared |
| Perception model | M1 | M2 | M1 → M2 |
| Calibration | CAL-07 | CAL-07 | None declared |
| Map | MAP-03 | MAP-03 | None declared |
Unchanged labels alone do not prove artifact identity, dependency independence or evidence applicability. The configuration owner would need actual references or digests and an account of the model's execution dependencies.
SYS-PER-01 v1 remains the teaching obligation:
For DSET-07 v1 under LOAD-02, elapsed time from replayed sensor-frame arrival to detection delivery at IF-DET-01 v1 shall not exceed 80 ms.
TEST-LAT-01 v1 names the procedure. EVID-LAT-A is an assumed fictional historical pass for CFG-A, with no measured value or execution date. EVID-LAT-B remains Pending for CFG-B, with no candidate run or result supplied. RUN-042 is a teaching run label only.
The change therefore raises an evidence question even though the requirement text stays at v1. M2 sits on the path being timed. What the new model does on that path, and whether any earlier evidence contributes to its acceptance, remain owner questions to investigate.
The CR-014 change record — Keep the record tied to the proposal revision each owner actually inspected. The teaching entries deliberately leave real provenance unknown. Accountable owners below are roles to assign.
| Change field | CR-014 teaching entry | What the responsible role must supply |
|---|---|---|
| Origin and baseline | The proposal compares candidate CFG-B with historical teaching CFG-A. | Change author identifies the real source baseline, branch/revision and affected programme records. |
| Candidate scope | H1/L1/F1.4/M2/CAL-07/MAP-03, with only M1 → M2 declared. | Configuration owner compares actual artifacts and runtime dependencies. Any additional change requires a revised scope. |
| Reason and originating evidence | A model-substitution proposal, with no supplied benchmark or improvement claim. | Change author records the reason, source request and evidence, including its limits. |
| Author and accountable roles | Change author, systems owner, perception/controller owners, configuration owner and verification owner. | Programme authority assigns responsibility and identifies who may make each decision. No actual assignments are supplied. |
| Artifact identities | H1, L1, F1.4, M1/M2, CAL-07 and MAP-03 are labels. Actual references/digests are unknown. | Configuration owner provides model, firmware, runtime, calibration, map and fixture identities for both states. |
| Requested decision | Determine what the substitution affects and which evidence needs review. | Separate permission to investigate, approval to implement, evidence acceptance and baseline acceptance. |
| Reviewed proposal revision | No real branch, revision or reviewed diff supplied. | Each reviewer records the proposal and source revisions inspected. Changed context needs a refreshed finding. |
| Current decision and actions | Candidate performance, compatibility and applicability are unresolved. | Authorised owner records the actual decision, rationale, limits, actions and resulting baseline when they exist. |
NASA's configuration-management guidance supports consistency between product versions and their information, with current and historical change status retained. For this dossier, that means keeping the declaration and the observed artifact facts distinguishable.
The seven-domain dependency matrix
Use the matrix to ask each owner a bounded question. It is a starting sweep for this substitution. Missing relationships remain investigation gaps, and wider robot or hazard coverage needs its own scoped review.
| Domain | Dependency to inspect | Owner check | Present disposition | Evidence needed | Open action |
|---|---|---|---|---|---|
| Source need: NEED-01 | The substitution may affect the timely-perception bench intent beyond its single timing obligation. | Systems owner checks the need and behaviour assumptions with perception. | Unknown continued satisfaction. | Source rationale and scoped account of affected behaviours or assumptions. | Identify gaps in the need-to-requirement path and decide which additional review is needed. |
| SYS-PER-01 v1 | M2 lies on the sensor-frame-to-detection path under DSET-07 v1 and LOAD-02. | Perception and verification owners check dependencies and TEST-LAT-01 v1's suitability. | Affected verification claim. EVID-LAT-B remains Pending. | Candidate evidence with valid events, clocks, load and actual configuration, or an applicability argument addressing the changed dependency. | Resolve measurement gaps and propose repeat, supplement or justified applicability for review. No candidate pass or fail is supplied. |
| IF-DET-01 v1 | Outputs may change timestamp meaning, units, detection association, frame handling or missing/invalid-data behaviour. | Perception and controller endpoint owners compare producer and consumer meanings. | Compatibility unknown. | Both endpoint definitions and relevant compatibility evidence with explicit time and spatial conventions. | Resolve semantics and propose a controlled interface revision if the definition must change. |
| Hardware and firmware: H1/L1/F1.4 | M2 may depend on runtime, preprocessing, resources or deployment details hidden by labels. | Hardware, firmware and configuration owners inspect actual artifacts with perception. | Impact unknown, with no hardware or firmware change declared. | Manifests/digests and execution-dependency evidence for H1/L1/F1.4. | Reconcile candidate artifacts and revise CR-014 if additional implementation changes are required. |
| Calibration and map: CAL-07/MAP-03 | Changed interpretation or preprocessing may affect calibration, coordinates or map assumptions. | Calibration/localisation owner checks references and dependencies with interface owners. | Applicability unknown. | Exact references, transform/preprocessing dependencies and scoped applicability rationale. | Establish which assumptions remain valid and whether supplement, recalibration or revised scope is needed. |
| Prior evidence: EVID-LAT-A | The historical timing claim includes M1 and its assessed context. | Verification owner considers each result's original claim and proposed CFG-B use separately. | Preserve the assumed fictional CFG-A pass. Candidate reuse remains unresolved. | Original claim/context plus a dependency argument, supplementary evidence or repeated test. | Record the proposed evidence action and obtain the applicability judgement in the companion ledger. |
| Operating and hazard assumptions | A model change may affect assumptions relevant to physical operation beyond this replay bench. | Systems and relevant hazard owners identify the review boundary and affected assumptions. | Wider effects unknown. | Separate assumption/hazard records and evidence for any proposed operational claim. | Define the additional review before making a wider claim, with its own authority. |
The most useful rows explain a possible consequence rather than just listing a linked item. “IF-DET-01 unchanged” does not answer whether the controller receives timestamps with the same meaning. “F1.4 unchanged” does not answer whether M2 needs a different runtime or uses resources differently.
Actual clock basis/resolution, event capture, dataset/load content, frame definitions, artifact digests, reports and reviewer/execution dates are unknown in WR-01. The rows give those gaps a responsible role and an evidence request, rather than a favourable disposition.
Check interface behaviour as well as its schema — NASA's interface-management guidance uses interface definitions and approved changes as verification inputs. For a model substitution, compare both endpoints' meanings and assumptions. Matching field names are only part of that check.
ROS REP 103 illustrates why units and conventions need agreement. It lists seconds as the base time unit, while WR-01 explicitly states milliseconds. REP 105 distinguishes continuous but drifting odom coordinates from map coordinates that can jump. These are ROS conventions for an interface owner to assess, with documented adoption or exceptions. The WR-01 labels establish neither ROS use nor a chosen frame.
Make the disposition explain the finding — Use “affected” when a credible dependency requires action. Use “justified no impact” when an owner has inspected that dependency and supplies a reason and evidence for the stated claim. “Unknown” keeps an unresolved question visible. “N/A” needs a reason showing that the item is outside the assessed boundary.
The teaching dossier has no completed no-impact finding. A firmware owner could later establish one for a particular property, but the evidence, inspected revision and accountable reviewer would need to be recorded.
The evidence action follows that reasoning. Reuse needs a justified applicability decision. Supplement closes a defined gap. Repeat assesses the claim in the candidate context. A changed obligation needs a controlled requirement revision. NASA's product-verification guidance connects verification with the product, requirements, plan and enabling products. The robotics evidence ledger owns the result-level applicability decision.
Carry the findings to a decision on the same proposal
Begin with the real source baseline, candidate manifest and exact diff. Ask domain owners for findings against that revision. Bring their evidence requests, disagreement and outstanding questions into the review alongside the proposed evidence actions.
If an owner discovers that M2 also needs a firmware or calibration change, preserve the discovery and revise CR-014. Refresh findings that depended on the earlier model-only scope. A review of one proposal cannot silently cover a wider candidate.
Keep decisions separate as the dossier moves forward. Authorising an investigation, applying a change, accepting evidence and accepting a programme baseline answer different questions. After a real baseline acceptance, the configuration owner still needs to confirm that implementation matches the authorised manifest.
For WR-01, the dossier identifies work to resolve before a candidate acceptance decision. It does not decide M2's performance or declare earlier evidence applicable. Retain the historical record, each owner's inspected revision and any rejected argument so the next reviewer can understand why a test or supplement was requested.
The general change-impact guide explains the wider dossier structure. This article's artifact is the exact model substitution and its seven domain questions. The AI-enabled systems guide covers broader model and data assurance.
Two questions to settle during the sweep
Can a missing traceability link be marked no impact?
A missing link means the maintained record cannot answer the dependency question. Ask the responsible owner to inspect the underlying design or behaviour and repair the relationship where appropriate. A no-impact finding needs evidence for the stated claim, including why the dependency is irrelevant or unchanged.
How should a rejected reuse argument be kept?
Preserve the original evidence, proposed applicability argument, inspected revision and reviewer's reason. Record the next action, such as a supplement or repeated test. A later accepted argument may supersede the first without erasing why it was rejected.
Review one substitution with its owners
Compare one proposed model substitution's actual manifests. Ask each of the seven domain owners for a finding, evidence and next action against the same proposal revision. Use the unresolved rows to define the decision that can be made now. This also gives an Arc workflow evaluation a concrete review exercise without assuming a product API, connector or automatic completeness guarantee.