Conducting Company-Style Design Reviews with Controlled Documentation

Hello. You now have a controlled simulated EDV package baseline, a named Onshape version, and a Baseline Manifest. The next professional habit is to use that configuration to make a decision—not merely to present CAD.

A design review is a structured decision forum. Its purpose is to determine whether a defined product baseline is mature enough for a stated next step, what conditions apply, and who owns the work needed to close remaining uncertainty. In this course, the review is explicitly based on the assumed Rivian-built Amazon EDV context, not on proprietary vehicle information.

By the end of this lesson, you will be able to prepare and run a concise preliminary design review (PDR) or critical design review (CDR) using five connected controls: a controlled presentation, decision log, risk register, assumptions log, and action tracker.

---

A review is a decision against a controlled baseline

The previous lesson distinguished an editable workspace from a controlled version, a released revision, and a baseline. A review must refer to one of those controlled configurations. Otherwise, attendees may be discussing different CAD states, different requirement interpretations, or different sets of open issues.

For the current simulated vehicle-context review, use:

• Review ID: EDV-REV-PDR-001
• Review purpose: authorize the assumed EDV package context for component concept development
• Product baseline: BASE-VEH-G1-01
• CAD authority: EDV-SIM-VEH-PKG, V0.2_G1_Package_Baseline
• Assumptions authority: EDV-SIM-VEH-ASM-001 Rev A
• Interface authority: EDV-SIM-VEH-ICM-001 Rev A

The review deck is itself a controlled document. For example, label the title slide and the exported PDF:

EDV-REV-PDR-001 Rev A
PDR candidate presentation
Baseline: BASE-VEH-G1-01
Date, author, and review chair

That label does not release the CAD or authorize tooling. It tells the review board exactly what evidence was considered when it made its decision.

PDR and CDR answer different questions

Both reviews use the same control structure, but their expected maturity differs.

Review	Core decision	Evidence expected for this course
Preliminary Design Review (PDR)	Is the proposed technical direction credible enough to proceed into detailed design?	Requirements baseline, concept rationale, package and interface definition, initial feasibility, key trades, assumptions, risks, verification approach, development plan
Critical Design Review (CDR)	Is the detailed definition mature enough to proceed into the authorized build, validation, or release activity?	Mature CAD and interfaces, drawings, manufacturing assessment, detailed verification evidence or plan, unresolved-risk disposition, configuration status, approval conditions

A PDR should not pretend that every dimension, supplier, mold feature, and test result has been finalized. Conversely, a CDR should not rely mainly on broad concept sketches and unsupported confidence statements.

For the present G1 vehicle-context baseline, a PDR is the appropriate review. The decision is not “the EDV is designed.” It is closer to:

Authorize the ECU housing, door-trim carrier, and HVAC-outlet teams to begin component concept design using BASE-VEH-G1-01, subject to stated package-assumption closure conditions.

This wording defines the scope and prevents later misuse of a concept baseline as a production-authorized vehicle definition.

---

Use independent-review discipline without copying a NASA process

NASA’s Standing Review Board Handbook is not an automotive standard and should not be treated as one. Its review logic is nevertheless useful: assess readiness before the event, review against stated criteria, record findings clearly, and use closed-loop actions.

A useful adaptation for an automotive component team is:

1. Check review readiness. Confirm that the baseline, requirements, interfaces, risk and assumptions records, and intended decisions are available.
2. Present claims with evidence. A requirement is not “covered” because it appears on a slide; the slide should link to the requirement, analysis, package model, drawing, trade study, or planned verification.
3. Classify outcomes. Separate decisions, risks, assumptions, existing issues, and actions.
4. Close the loop. An action is complete only when its evidence is reviewed and accepted by the person or function entitled to accept it.

---

The five connected review controls

A reliable review does not bury every uncertainty in a presentation. It uses separate records with different purposes, then links them through IDs.

1. Controlled presentation: the argument

The presentation is the narrative used to support the decision. It should explain:

• what is being decided;
• which baseline is under review;
• which requirements and interfaces drive the design;
• what evidence supports the technical direction;
• what remains uncertain;
• what decision and conditions are requested.

A practical PDR deck for a component project can be 10–14 slides:

1. Title, purpose, decision request, and baseline reference
2. Program context and scope boundaries
3. Requirements status and traceability summary
4. Package, interfaces, and ownership
5. Concept architecture and selected approach
6. Trade-study summary and rationale
7. Manufacturing and assembly feasibility
8. Preliminary verification strategy
9. Top risks, assumptions, issues, and dependencies
10. Schedule, key gates, and supplier or cross-functional inputs
11. Decision request, conditions, and proposed actions
12. Appendix or evidence index

Each slide should answer a reviewer’s likely question: What is the claim, what evidence supports it, and what configuration does that evidence describe?

Avoid weak review language such as “CAD is mostly complete” or “manufacturability looks good.” Replace it with evidence-based statements:

• “The concept fits within the V0.2_G1_Package_Baseline keep-out boundaries at nominal condition; tolerance and service-envelope verification remain open under ACT-EDV-014.”
• “The chosen concept preserves the assumed harness approach direction; connector ownership and final mating geometry remain assumptions ASM-VEH-007 and ASM-VEH-008.”
• “This review requests authorization for concept development only, not tooling release or production validation.”

2. Decision log: the organization’s memory

A decision is an intentional choice between alternatives made by an authorized person or group. The decision log preserves the context so that a later engineer does not have to reconstruct why the design took a particular path.

Field	Example
Decision ID	DEC-VEH-001
Decision statement	Use BASE-VEH-G1-01 as the authorized simulated vehicle package reference for component concept work.
Decision type	Gate / configuration
Alternatives considered	Continue with unbaselined workspaces; delay all concepts pending additional data
Rationale	A controlled concept baseline enables traceable development while preserving explicit limits on its intended use.
Evidence	Baseline Manifest, interface matrix, assumptions log, PDR deck
Authority	Simulated Vehicle Integration Lead
Decision date	Enter actual review date
Affected objects	CFG-VEH-001 Rev A, package CAD version, three component projects
Conditions	High-impact package assumptions must be resolved before detailed-design release.

Do not use the decision log as a task list. “Check the connector clearance” is an action. “Adopt a 20 mm connector service clearance requirement after package confirmation” may become a decision once authorized.

3. Assumptions log: uncertainty temporarily treated as true

An assumption is an unverified proposition the team is using to proceed. It is not a fact, and it is not automatically a requirement. Every significant assumption needs an owner and a planned validation or retirement route.

Field	Example
Assumption ID	ASM-VEH-014
Statement	The simulated ECU mounting region provides at least 35 mm nominal clearance above the cover envelope.
Basis/source	Course package model; no production vehicle data available
Confidence	Low
Affected work	ECU housing package, connector orientation, service-removal study
Owner	Vehicle Packaging Lead
Validation method	Confirm against controlled packaging input or revise component envelope
Needed by	Before ECU detailed-design baseline
Status	Open

The high-risk habit to avoid is silently converting an assumption into “truth” because several CAD features have been built around it. A good review makes assumptions visible early enough that the team can change course cheaply.

4. Risk register: a future uncertain adverse event

A risk is a potential future event or condition with an adverse effect. It is not the same as an issue.

• Risk: “The mounting bracket interface may shift after body-team package refinement, causing an ECU interference.”
• Issue: “The current package model intersects the proposed ECU service-removal path.”

A useful risk record contains a cause, event, and effect:

Because the mounting-interface geometry is assumption-based, the bracket may move during package refinement, which could invalidate the ECU mounting scheme and delay detailed design.

Use a consistent scoring system. For this course, score likelihood and impact from 1 to 5, then calculate:

$$\text{Risk exposure}=\text{Likelihood}\times \text{Impact}$$

The score supports prioritization; it does not replace engineering judgment. A low-likelihood electrical-safety concern may still warrant immediate escalation because its consequence is unacceptable.

Field	Example
Risk ID	RSK-VEH-006
Cause, event, effect	Assumption-based bracket geometry may change, causing ECU-mount interference and redesign.
Likelihood	4
Impact	4
Exposure	16
Trigger	Approved package update changes hardpoint coordinates by more than the allocated envelope.
Mitigation	Use a master skeleton with controlled mounting references and preserve adjustment space where functionally acceptable.
Contingency	Repackage ECU orientation and issue an ECO if the interface change exceeds the allocated envelope.
Owner	ECU Design Lead
Residual risk	To be reassessed after package confirmation
Status	Open

5. Action tracker: the closure mechanism

An action is a discrete piece of work needed to resolve a review finding, condition, risk response, or information gap. It needs a deliverable—not merely a vague promise.

Field	Example
Action ID	ACT-VEH-012
Source	RSK-VEH-006, PDR condition 2
Action	Publish a revised interface-control record confirming ECU mounting-point coordinates, keep-outs, and ownership.
Owner	Vehicle Packaging Lead
Due date	Enter planned date
Evidence expected	Controlled interface-control matrix and approved package-model version
Verifier / acceptor	ECU Design Lead and Vehicle Integration Lead
Status	Open
Closure criteria	Both approvers confirm that the record resolves the PDR condition or formally escalates the remaining variance.

A closed action must have evidence, a verifier, and an explicit closure decision. “Discussed with the team” is not closure.

---

A RAID view helps expose what is different

The RAID matrix is a useful single-page review view because it places Risks, Assumptions, Issues, and Dependencies together. Its main limitation is that it should not replace the detailed records where a risk mitigation, decision rationale, or verification result needs stronger traceability.

Use the categories precisely:

Category	Meaning	EDV-context example
Risk	Future uncertain threat	HVAC outlet bezel could clash with a later instrument-panel update.
Assumption	Unverified condition currently used for design	A nominal duct-center location is accepted for concept packaging.
Issue	Existing problem requiring containment or correction	Current nominal door-carrier envelope conflicts with a known window-regulator keep-out.
Dependency	An external input, decision, or deliverable needed by the work	The ECU team requires connector-envelope data from electrical integration.

One item can be linked across records without being duplicated carelessly. For example:

• ASM-VEH-014 records that the ECU clearance is assumed.
• RSK-VEH-006 records the adverse consequence if that assumption proves wrong.
• ACT-VEH-012 assigns confirmation of the mounting geometry.
• DEC-VEH-001 records the conditional authorization to proceed despite the open assumption.

The IDs create the traceability chain.

---

Prepare the review before the meeting begins

A meeting cannot compensate for an uncontrolled or incomplete package. Before inviting reviewers, create a one-page Review Charter. This is a lightweight course adaptation of a formal terms-of-reference document.

Charter field	What to define
Review ID and type	EDV-REV-PDR-001, Preliminary Design Review
Purpose	The specific decision sought
Scope	Included components, interfaces, and configuration
Exclusions	What the review explicitly does not authorize
Baseline	Baseline Manifest ID, CAD version, requirements and interface records
Entry criteria	Evidence required before the meeting can begin
Exit criteria	Conditions for proceeding, holding, or repeating the review
Decision authority	Role authorized to accept, conditionally accept, or reject the request
Core reviewers	Engineering, packaging, manufacturing, quality, electrical, service, supplier interface as applicable
Recorder / configuration owner	Person responsible for minutes, actions, and final record
Ground rules	Evidence over opinion; assumptions declared; actions have owners and dates; no silent scope change

PDR readiness checklist for the simulated EDV program

Use the following as your entry criteria. If a needed item is missing, either delay the review or visibly record a waiver and its risk.

• The review purpose and requested decision are written in one sentence.
• The product configuration is identified by baseline and exact CAD version.
• The requirements baseline and traceability status are available.
• Assumption-based vehicle inputs are clearly labelled with source and confidence.
• Interfaces have named owners and unresolved ownership conflicts are visible.
• At least one feasible concept is available, with its selection logic or open trade.
• The top technical, manufacturing, schedule, and integration risks are recorded.
• The review deck, RAID summary, decision log, and action tracker have consistent IDs.
• Required reviewers receive the package early enough to identify evidence gaps.
• A person has been assigned to capture decisions and actions during the meeting.

For this course, do not confuse “all reviewers attended” with “the review passed.” Attendance is evidence of participation. A gate decision must name the decision authority, outcome, conditions, and controlled record.

---

Run a 60-minute company-style PDR

A good review is facilitated, not simply narrated. The chair should protect the decision purpose and make sure technical disagreements are captured accurately rather than hurried aside.

Suggested agenda

Time	Topic	Intended output
5 min	Opening: purpose, scope, baseline, ground rules	Shared understanding of what decision is in scope
5 min	Entry-criteria confirmation	Proceed, delay, or record a stated waiver
10 min	Requirements, interfaces, and configuration status	Agreement on the governing inputs and open gaps
15 min	Concept and feasibility evidence	Review of concept rationale, package fit, and key technical claims
10 min	Risks, assumptions, issues, and dependencies	Prioritized RAID items and agreement on escalation needs
10 min	Decision request and action review	Decision wording, conditions, owners, due dates, acceptance criteria
5 min	Read-back and close	Confirmed record of decisions, actions, and next review point

The review chair should ask focused questions:

• “Which requirement is this geometry intended to satisfy?”
• “Which baseline version does this clearance claim refer to?”
• “Is this a risk, an existing issue, or an assumption?”
• “What observable evidence will close this action?”
• “Who has authority to accept the residual risk?”
• “Does this condition limit concept development, detailed design, tooling, or release?”

When a reviewer challenges an assertion, avoid defending the slide immediately. First classify the result. A missing test plan may become an action. An uncertain package input may become an assumption and risk. A conflict between two required clearances may become an issue requiring a formal decision or trade study.

Make the final gate outcome unambiguous

Use one of four clear outcomes:

Outcome	Meaning
Proceed	The baseline is adequate for the requested next activity.
Proceed with conditions	Work may continue within defined limits; listed actions must close before a stated later gate.
Hold	The evidence is insufficient or a significant issue prevents the requested progression.
Reconvene / delta review	A specified evidence update or design change requires a focused follow-up decision.

For the current vehicle-context example, a credible result could be:

Outcome: Proceed with conditions.
BASE-VEH-G1-01 is authorized for simulated component concept development. It is not authorized for detailed-design release, tooling commitment, or validation claims. High-impact package assumptions ASM-VEH-014 through ASM-VEH-018 require closure or approved re-baselining before the ECU, door-trim, or HVAC projects pass their component PDRs.

That decision is useful because it permits work while preventing false certainty.

---

Build your review record

Spend the final part of this lesson assembling a short simulated PDR package for the vehicle context. Create the five records below in a spreadsheet, document-control folder, or your course templates. Use links or file references to the controlled Onshape version rather than copying uncontrolled screenshots into several locations.

1. Controlled presentation: Draft the 10–12 slide sequence and place the baseline ID in the footer of every slide.
2. Decision log: Add DEC-VEH-001 and leave its final outcome blank until the review closes.
3. Assumptions log: Add three package assumptions from your previous vehicle-context model. State confidence, owner, and needed-by gate.
4. Risk register: Add at least the risk created by each high-impact package assumption. Include a trigger and a planned response.
5. Action tracker: Add actions that produce controlled closure evidence, such as an updated interface-control matrix or revised package version.

At the end of the review, issue a concise Review Record containing:

• the agenda and attendee roles;
• the final presentation PDF revision;
• the baseline manifest and evidence index;
• decisions made, including any conditions;
• open risks and assumptions;
• actions, owners, dates, and closure criteria;
• the next review or escalation point.

Store this record beside the Baseline Manifest. In a production PLM environment, many relationships would be represented by managed objects and workflows. In the Onshape-plus-template workflow used here, the discipline comes from stable identifiers, named versions, controlled documents, and explicit approval records.

---

Key takeaways

A company-style design review is a controlled decision process, not a CAD presentation.

• The review must identify the exact configuration being assessed, including the baseline and authoritative CAD version.
• A PDR tests whether a concept is credible enough for detailed development; a CDR tests whether the detailed definition is mature enough for an authorized build or release activity.
• The presentation explains the case; the decision log preserves authorized choices; the risk register manages uncertain future threats; the assumptions log exposes unverified inputs; and the action tracker closes gaps with evidence.
• Risks, assumptions, issues, dependencies, decisions, and actions are related but not interchangeable.
• “Proceed with conditions” is often the most realistic review outcome, provided the conditions, owners, evidence, and next gate are explicit.

Next, you will begin the polymer-selection and injection-molding-design module. The review discipline established here will carry forward: material choices, DFM rules, and manufacturing risks will need traceable evidence and clear design decisions rather than informal preference.