Arc Skills / Configuration and change control

Assess the impact of an interface change

Use Arc Skills to compare an interface before and after a technical change, including both endpoint configurations. Get a delta table and a focused impact register covering compatibility, budgets, integration tests and evidence reuse.

Use this skill

Use Arc Skills to assess the impact of this interface change.

Inputs:
- Before and proposed interface revisions
- Both endpoint designs and supplier specifications
- Linked requirements, budgets, integration tests and results

Return the technical delta and a two-endpoint impact register. Show the mechanism, evidence, proposed check and responsible owner for each impact. Separate proven mismatches from unconfirmed effects.

Set up the toolkit · Read the skill instructions

What you provide and what you get

Inputs and outputs
What you have	How it is used	What you get
Interface revisions and endpoint IDs	Compare the controlled exchange	Changed parameters and conditions
Endpoint capacity and design data	Check both producer and consumer	Compatibility findings
Integration procedures and evidence	Assess each tested aspect	Reuse, revision or targeted test actions

A 200 ms status period reaches a slower consumer

Illustrative engineering example.

An interface agreement changes its status-message period. The producer can support the new rate, but the consumer’s processing capacity and queue behavior require different checks.

INT-09 rev A: one 80-byte status message every 1 s.
INT-09 rev B proposal: one 80-byte status message every 200 ms.
Producer capacity: 10 messages/s. Consumer sustained capacity: 4 messages/s.
Framing, fields and byte order unchanged; prior evidence covers framing only.

A 200 ms status period reaches a slower consumer
Aspect / endpoint	Before → proposed	Finding	Next evidence or action	Owner
Producer rate	1 → 5 messages/s	Within stated producer capacity of 10 messages/s	Confirm that capacity uses the same mode and software version	Producer owner
Consumer rate	1 → 5 messages/s	New sustained arrival rate exceeds stated processing capacity by 1 message/s	Change processing, buffering or the agreed period; bound the burst behavior	Consumer owner
Payload traffic	80 → 400 bytes/s	Fivefold payload traffic; transport overhead is absent	Recalculate link use with framing and retransmission overhead	Transport owner
Integration procedure	Checks a 1 s period	Acceptance step measures the superseded contract	Update timing and overload tests	Integration owner
Format evidence	Fields and framing unchanged	Potentially reusable for format only	Verify the exact endpoint configuration; do not extend it to new-rate performance	Verification owner

The new frequency is 1/0.2 = 5 messages/s. For an indefinitely sustained arrival rate of 5 and service rate of 4, an unbounded ideal queue would grow by 1 message/s; the actual finite-buffer consequence depends on its size, policy and bursts.

A format report answers a different question from a capacity report. The interface owner must reconcile both endpoints before declaring the new contract workable.

Check both sides of the exchange

Identify changes in voltage, geometry, data meaning, timing, direction or fault behavior, not just document text.
Compare each changed parameter with both endpoints’ controlled designs and operating conditions.
Recalculate affected budgets using explicit aggregation rules; list missing inputs.
Select evidence by tested aspect and configuration, then give each owner a specific compatibility or integration action.

Questions about this task

Can unchanged message fields make the old integration result reusable?

They can support reuse of format findings. They do not demonstrate that the new arrival rate, latency or overflow behavior is acceptable.

Sources and further reading

NASA Systems Engineering Handbook: configuration management: Background on identifying configurations and controlling baseline changes.

References inspected on 3 October 2026. The worked output is an authored example using the stated inputs.