Arc Skills / Technical management and design reviews

Prepare a critical design review

Use Arc Skills to prepare a critical design review around whether the detailed design is ready for the intended build step. The packet checks implementation evidence, controlled revisions, margins, prior actions and the means to verify critical behavior.

Use this skill

Use Arc Skills to prepare a critical design review.

Inputs:
- Detailed design and intended build-to configuration
- Requirements, interface agreements and worst-case analyses
- Hazard controls, verification access, prior actions and review criteria

Return a CDR readiness matrix with exact evidence revisions, gaps, build consequences and owner actions. Separate detailed-design readiness from completed qualification or operational readiness.

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
Detailed design and controlled versions	Check build-to definition	Release and consistency findings
Requirements and worst-case evidence	Check implementation support	Critical margins and unresolved analyses
Prior actions and test access	Check the next build step	An evidence-backed CDR packet

The detailed design is missing a controlled connector revision

Illustrative engineering example.

A controller’s CDR packet contains released board drawings and a worst-case latency calculation. The harness and test-access evidence expose separate readiness gaps.

Build target: board HW-C / firmware F4 / harness H3.
DRAW-12 rev D released; harness drawing still references connector rev B, while ICD-7 requires rev C.
Latency analysis: 70 + 12 + 8 = 90 ms against 100 ms, with processing assumptions stated.
Required calibration access is blocked after enclosure assembly. PDR reset action remains open.

The detailed design is missing a controlled connector revision
Review question	Available evidence	Finding	Required action / owner
Build-to consistency	DRAW-12 D, harness H3, ICD-7 C	Connector revision mismatch	Harness owner reconciles pinout and controlled build documentation
Critical timing	90 ms worst-case model versus 100 ms limit	10 ms modeled allowance under supplied assumptions	Processing owner validates bounds and accounts for omitted stages if any
Verification access	Enclosure drawing blocks calibration connector	Planned procedure cannot use the assembled article as described	Mechanical and test owners define access or an approved test stage
Prior action	PDR reset agreement still open	Detailed design depends on unresolved authority	Endpoint owners close the agreement and check affected logic
Qualification status	Qualification not yet executed	Not represented as a completed result	Review board applies the intended build gate, not an operational-readiness test

The 10 ms modeled allowance is arithmetic, not measured latency. The design packet must retain the bounds and method so the reviewer can judge whether the calculation represents the required operating case.

A drawing release label does not settle interface consistency or test access. Those gaps can directly change build instructions and should be framed as owner decisions before the relevant release.

Check implementation, configuration and verification access

Trace critical obligations to detailed implementation and controlled build-to versions.
Check worst-case calculations, interfaces, tolerances and hazard-control implementation.
Resolve prior design actions and confirm that verification can reach the required article features.
Frame issues by the build step they affect and present the project’s decision criteria with evidence.

Questions about this task

Does a CDR packet prove the product has passed qualification?

No. It can include qualification evidence where available, but detailed-design readiness and completed qualification are separate questions. Keep planned tests distinct from executed results.

Sources and further reading

NASA NPR 7123.1D, Appendix G: life-cycle review criteria: A NASA reference for different review purposes. Use your project’s governing review criteria.
NASA Systems Engineering Handbook: technical assessment: Background on measures, review evidence and action resolution.

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