Arc Skills / Configuration and change control

Prepare an engineering change request

Use Arc Skills to turn a proposed engineering correction into a reviewable change request. The packet keeps the observed problem, proposed solution, affected configuration, impact evidence and requested decision together so reviewers can assess one coherent change.

Use this skill

Use Arc Skills to prepare an engineering change request.

Inputs:
- Current configuration and observed problem
- Proposed edits with exact IDs, revisions and rationale
- Impact evidence, verification actions and change-control criteria

Return a concise review packet with before/after values, technical rationale, affected artifacts, verification plan, open decisions and requested disposition. Separate facts from assumptions and identify rejection or rollback consequences.

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
Problem evidence and current configuration	Define why a change is proposed	A precise problem statement
Proposed revisions and impact register	Define one coherent technical solution	Before/after edits with justification
Verification and approval criteria	Frame the review decision	Actions, open evidence and requested disposition

Requesting a faster recorder service path

Illustrative engineering example.

A proposed telemetry revision needs a recorder service rate of at least 5 messages/s. The current controlled design states 4 messages/s. The change request proposes a software correction; its feasibility remains to be demonstrated.

Problem: INT-09 proposed rev B requires 5 messages/s; SYS-R rev C supports 4 messages/s.
Candidate correction: recorder firmware F4 service path, measured target [approved capacity with margin].
Available: log LOG-17 showing queue growth under a sustained 5 messages/s input.
Missing: F4 timing data, worst-case processing load and accepted capacity margin.

Requesting a faster recorder service path
Packet section	Draft content	Evidence / unresolved decision
Problem	Sustained arrival exceeds controlled recorder service rate by 1 message/s	INT-09 proposal, SYS-R C and LOG-17; distinguish contract mismatch from full failure diagnosis
Proposed edit	F3 → candidate F4 service implementation; no new interface fields	Attach implementation delta and measured service capacity before release
Affected artifacts	SYS-R configuration, throughput test, queue/overflow procedure and timing budget	Trace the processing change into the tasks it actually affects
Verification	Exercise sustained load, bursts, overflow behavior and worst-case processing mode	Acceptance values and margin require owner approval
Rejected-change path	Keep F3 and the existing agreed period; do not activate proposed INT-09 B	Endpoint owners confirm the currently valid contract
Requested decision	Authorize development and verification of the candidate; release remains a separate decision	Name the project’s actual authority and closure conditions

The observed queue growth supports investigating the processing path, but it does not prove that F4 will solve the problem or preserve all other timing obligations. The request asks for a specific next decision and names the missing evidence.

A useful change packet does not promise unmeasured savings, successful verification or approval. Unrelated mechanical edits would belong in another request because they have different rationale and evidence.

Make the requested decision explicit

Start with the current configuration, observed problem and governing obligation.
Show each proposed edit by exact ID and revision, with the technical reason.
Link affected design, interfaces, procedures and evidence to a mechanism.
State verification actions, open decisions, rejection consequences and the authority requested to act.

Questions about this task

Is a change request the same as approving the change?

No. The packet gives the project’s reviewers the evidence and proposed disposition. Its preparation does not release a configuration or approve technical intent.

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.