Controlled Standards and Requirements Register Development

Hello again. In the previous lesson, you built the link from an approved requirement to its verification method, acceptance criterion, and objective evidence. That traceability is only trustworthy if the requirement’s source is itself controlled. A statement such as “meet ISO,” “per customer requirement,” or “use FMEA” is not a usable engineering input until the team has identified exactly which document applies, which revision is governing, why it applies, and what evidence it demands.

This lesson builds that control mechanism: a standards register for the assumed EDV program. You will distinguish regulations, technical standards, management-system standards, customer-specific requirements, customer engineering documents, and automotive core tools—without treating them as interchangeable. The register will become the authoritative source index for the RTM, DFMEA, DVP&R, drawings, supplier deliverables, and later release records.

---

Why a standards register is more than a list of documents

A shared folder containing PDFs titled “ISO,” “IATF,” and “Customer Specs” is not document control. It cannot answer the questions that matter at a design review or audit:

• Is this document legally mandatory, contractually required, or merely useful guidance?
• Does it apply to this component, program phase, target market, or supplier?
• Which edition, amendment, or customer release is the governing one?
• Does it impose a product requirement, a test method, a quality-system expectation, or a required deliverable?
• What objective evidence will show that the team has applied it?
• Who must assess a revision change, and which baselines may be affected?

A controlled standards register is a deliberately maintained database or spreadsheet that answers those questions. It does not reproduce copyrighted standards or replace the standards themselves. Instead, it records controlled metadata, access location, applicability decisions, relevant clauses, and evidence expectations.

The register’s fundamental claim is modest but powerful:

Every external or internal source that affects the product or development process has a known owner, a declared applicability decision, a known revision state, and a planned evidence route.

This is particularly important in automotive work because the word requirement is used for several very different things.

Source class	What it is	Typical authority	Example outcome
Regulation	A legal requirement imposed by a government authority	Government regulator	A vehicle or product must satisfy a legally applicable safety or environmental rule in its target market.
Technical standard	A consensus document defining terminology, requirements, methods, or practices	ISO, IEC, SAE, ASTM, national body	A test method, material property, ingress code, or drawing convention is defined consistently.
Management-system standard	Requirements for how an organization manages quality processes	ISO, IATF	The organization controls documents, suppliers, change, records, audit, and improvement.
Customer-specific requirement (CSR)	A customer’s supplemental quality-system or supplier requirement	OEM or customer	A supplier follows a customer’s required quality process, portal, format, retention rule, or approval route.
Customer engineering requirement	Product- or program-specific technical input	Customer engineering or program team	A package envelope, environmental target, material grade, interface condition, or validation requirement is imposed.
Automotive core tool	A structured method used to plan, analyse, control, or approve quality	AIAG, VDA, customer	The team performs DFMEA, develops a Control Plan, evaluates measurement systems, or submits PPAP evidence.
Internal procedure or lesson learned	The organization’s own controlled method or retained knowledge	Your organization	A release checklist, FMEA template, CAD naming rule, or design-review process is followed.

A useful rule is:

• A regulation can create a legal obligation.
• A standard can become mandatory when a regulation, contract, customer document, or internal procedure invokes it.
• A CSR adds customer-specific obligations to the applicable quality-management system.
• A core tool is generally a method or framework, not a physical-product performance standard.
• A customer engineering document can set direct product requirements and may invoke all of the above.

For the simulated EDV work, do not label Rivian or Amazon requirements as real unless you have an actual controlled source. Until then, call them program assumptions, assign them an owner and confidence level, and keep them visibly separate from approved customer requirements.

---

The quality-system layer and the product-compliance layer

The following ISO 9001 model is helpful because it shows the quality management system as a process-oriented, Plan-Do-Check-Act framework. It is not an APQP chart, a PPAP checklist, or a component test standard.

At a high level:

• ISO 9001 establishes general quality-management-system requirements.
• IATF 16949 adds automotive-sector quality-management-system requirements to the ISO 9001 foundation.
• Customer-specific requirements supplement or interpret the applicable IATF and customer quality expectations.
• APQP, PPAP, FMEA, Control Plans, SPC, and MSA provide structured methods and records used to plan, demonstrate, and control product and process quality.
• Product standards and regulations govern particular characteristics, test methods, performance conditions, or legal obligations.

The distinction matters because an ECU housing can pass an ingress test while its development process still lacks controlled records, approved changes, or a traceable Control Plan. Conversely, a team can maintain a well-audited quality system while still failing to demonstrate that the enclosure survives the required installed environmental exposure. Both the product and its development evidence need control.

---

Treat customer-specific requirements as controlled overlays

A CSR is not simply another standard in a list. It is a customer-owned overlay: it tells an organization how that specific customer expects relevant QMS requirements, supplier activities, records, approvals, or communication to be handled.

The Stellantis CSR document is a useful public example of this relationship. It explicitly describes a broader customer quality-requirements source and a CSR document focused on the portions most relevant to IATF auditing. It also illustrates the kind of evidence an auditor may seek: analysis of the current customer requirements, special-characteristic flow-down, FMEA records, Control Plans, PPAP status, and documented change-risk assessment.

The register should therefore never say merely:

“Customer CSR — applicable.”

Instead, it should record:

• the exact customer document title and identifier;
• the customer release, issue date, and effective date;
• the program, customer, supplier tier, plant, or commodity to which it applies;
• the relevant clause or section;
• whether it is an interpretation, supplemental requirement, required format, or mandatory customer system;
• the evidence expected;
• the person responsible for monitoring the customer source for updates.

A public CSR from Ford or Stellantis is useful for learning, but it is not a substitute for actual requirements from a different customer. In this course, do not infer a Rivian or Amazon CSR from another OEM’s document.

The following brief audit simulation reinforces the operational point: a company needs a defined way to receive, review, communicate, implement, and audit CSR changes—not just a folder where the files are stored.

---

The automotive core tools: linked methods, not six interchangeable standards

The familiar automotive “core tools” are often grouped together because they create connected quality evidence. That grouping is useful, but it can hide their different purposes.

A practical classification looks like this:

Core tool	Primary purpose	Main question it answers	Typical evidence
APQP	Plans product-quality development across phases and gates	“Have we completed the necessary planning and readiness work?”	Timing plan, gate reviews, deliverable status, open-risk log
DFMEA / PFMEA	Anticipates design or manufacturing failure mechanisms and prioritizes action	“How could intended function fail, and what will we do about it?”	FMEA study, action records, linked special characteristics
Control Plan	Defines controls used to maintain manufacturing-process and product conformance	“What will be controlled, how, how often, and what happens when it is out of control?”	Control Plan, reaction plan, inspection instructions
MSA	Assesses whether measurement results are adequate for their intended decisions	“Can our measurement system distinguish meaningful variation?”	Gauge study, bias, linearity, stability, or GR&R record
SPC	Uses statistical methods to understand and control process variation	“Is the process stable and capable of meeting its requirement?”	Control charts, capability studies, reaction records
PPAP	Collects and submits evidence that production-intent parts and processes meet agreed requirements	“Is this supplier process ready for approved production?”	PSW and the customer-required PPAP package

For example, a DFMEA is not a Control Plan. The DFMEA considers potential design failure modes, causes, effects, and design actions. The Control Plan defines recurring controls for production. They should be linked where special characteristics or prevention and detection controls flow from design risk into manufacturing, but each remains its own controlled record.

The AIAG-VDA FMEA method makes this especially clear: it begins with planning, scope, and intended functions before it evaluates failures and actions. The FMEA Handbook should therefore be registered as a risk-analysis methodology with required output records—not as an ECU environmental specification.

A register can therefore identify the AIAG-VDA FMEA Handbook with an applicability statement such as:

Applicable to all design-responsible molded components in the simulated program as the selected DFMEA method. Evidence required: controlled DFMEA study, action-priority decisions, action evidence, and links to special characteristics, validation activities, and relevant control measures.

That entry is far more actionable than “FMEA required.”

---

Design the standards register around decisions and evidence

A register needs enough fields to be auditable, but not so many that it becomes an abandoned administrative task. Use one row per controlled source document. Where a document has several independently applicable clauses, record the document once and reference the applicable clauses in a linked applicability assessment or a clearly separated clause field.

Organize the register into three groups of fields.

1. Identity and ownership

Field	What to record
Register ID	Stable identifier, such as STD-ENV-001, REG-US-001, CSR-SIM-001, or CT-FMEA-001
Classification	Regulation, technical standard, QMS standard, CSR, customer engineering document, core tool, or internal procedure
Document identifier and title	Full title, publisher document number, part number, and edition where available
Issuing body	For example, ISO, IEC, AIAG, VDA QMC, IATF, NHTSA, customer engineering, or internal quality
Document owner	The internal engineer, quality representative, regulatory lead, or supplier-quality owner responsible for the applicability decision
Controlled source location	Approved subscription, customer portal, PLM object, controlled intranet record, or contractual source—not an uncontrolled downloaded copy
Copyright/access status	Licensed, customer portal access, pending access, publicly available, or reference-only

2. Applicability and revision control

Field	What to record
Purpose	What the document governs: product performance, test method, QMS, drawing convention, supplier approval, risk analysis, and so on
Scope	Product families, processes, markets, lifecycle phase, supplier tier, or organizational functions covered
Applicability verdict	Applicable, partially applicable, not applicable, candidate pending review, or superseded
Applicability rationale	Why it applies or does not apply, including target market, declared customer contract, component type, or program assumption
Applicable clauses / sections	Specific clauses, tests, tables, or deliverable sections relevant to this program
Source revision	Edition, revision, amendment, release date, and effective date where stated
Revision status	Current verified, baselined for program, change under assessment, obsolete, or revision unknown
Last review and next review	Date checked, reviewer, and scheduled or event-based next review
Change impact route	Which records must be assessed if the source changes: requirements, CAD, drawing, DVP&R, DFMEA, supplier documents, or PPAP package

3. Implementation and evidence

Field	What to record
Derived requirement IDs	Links to the requirement register and RTM
Required evidence	Specific controlled artifacts expected to demonstrate implementation or compliance
Verification method	Inspection, analysis, demonstration, test, audit, document review, or a defined combination
Responsible function	Design engineering, quality, supplier quality, manufacturing, test laboratory, regulatory, or program management
Supplier flow-down	Whether the requirement must be communicated to a Tier 1 or lower-tier supplier
Maturity / status	Planned, in development, evidence under review, accepted, open gap, waived, or superseded
Open issue / ECO reference	Links to gaps, supplier issues, deviations, assumptions, or engineering changes

The required evidence field is crucial. It should state the type of evidence that must exist, not an unhelpful phrase such as “documentation available.”

For instance:

Weak entry	Stronger controlled entry
“ISO 16750 compliance”	“Approved environmental DVP&R, as-run test procedure, sample configuration record, laboratory report, result review, and RTM closure against the applicable agreed test conditions.”
“IATF applies”	“Controlled document process, design and development records, supplier controls, audit records, change-control records, nonconformance records, and management-review evidence within the simulated QMS.”
“FMEA completed”	“Released DFMEA excerpt using selected method, action decisions, evidence supporting completed actions, special-characteristic links, and review approval.”
“PPAP required”	“Customer-required submission level confirmed; PSW or equivalent approval evidence, dimensional results, material evidence, process-flow and Control Plan records, MSA/SPC evidence as applicable, and customer disposition.”

---

A practical revision-control model

“Latest revision” can be unsafe language. A document may have a newer edition available, while the customer contract, program baseline, or certification scope still identifies a specific revision. Your register should therefore keep three distinct facts:

1. Document revision available
   The most recent revision that the organization has verified through the approved source.

2. Program baseline revision
   The revision approved for use on this defined program baseline.

3. Assessment status
   Whether a newer revision has been assessed for impact, adopted, deferred, or found not applicable.

For example, an entry could read:

Field	Example
Source revision	“Edition/revision as verified from controlled source [TBD]”
Program baseline	“Baseline B01, approved for simulated ECU concept phase”
Current-source check	“Checked 2026-04-18; update review required before design freeze”
Status	“Candidate pending licensed-source verification”
Change impact	“Assess RTM, ingress DVP&R, enclosure drawing notes, supplier RFQ, and DFMEA if technical requirements change”

This approach prevents two opposite errors:

• assuming that an old downloaded PDF remains acceptable forever; and
• silently applying a new revision without assessing its effects on work already planned, tested, or released.

For the course, you may not own licensed copies of every ISO, IEC, AIAG, or SAE document. Record that honestly. A status such as “candidate; source and revision pending access verification” is professionally stronger than inventing a clause, date, or test condition.

---

An initial simulated EDV standards-register extract

The following table is an assumption-based training example. It does not state the actual requirements, target market, contracts, vehicle specifications, or supplier obligations of Rivian or Amazon. Items marked [TBD] require controlled-source access and program approval before release use.

ID	Class and issuer	Purpose and likely scope	Applicability decision	Revision status	Required evidence
QMS-001	QMS standard; ISO	General quality-management-system requirements across the organization	Applicable to the simulated program’s QMS framework	ISO 9001:2015 recorded; current-source review required at program start	Document-control procedure, internal-audit records, design records, nonconformance and improvement evidence
QMS-002	Automotive QMS standard; IATF	Automotive supplements used with ISO 9001 for relevant production and service-part organizations	Applicable as the simulated automotive QMS framework; actual certification scope is not assumed	IATF 16949:2016 recorded; licensed-source status [TBD]	Design planning, supplier controls, documented information, change management, audit, and retention evidence
CT-APQP-001	Automotive core tool; AIAG	Structured product-quality planning and development readiness	Applicable to all three course projects as the planning framework	Handbook edition must be verified against program/customer expectation	Timing plan, gate deliverables, risk log, cross-functional reviews
CT-FMEA-001	Automotive core tool; AIAG and VDA	DFMEA and PFMEA methodology for systematic failure analysis and risk optimization	Applicable to design-responsible project components	Selected handbook baseline [TBD]	DFMEA/PFMEA, action evidence, special-characteristic links, review approval
CT-PPAP-001	Automotive core tool; AIAG	Production-part approval evidence and submission process	Applicable only when production-intent supplier approval is in scope	Customer-required PPAP edition and submission level [TBD]	PPAP plan, PSW or equivalent, dimensional/material/test records, Control Plan, MSA/SPC records as applicable
STD-GDT-001	Technical standard system; ISO GPS	Establishes the declared drawing and tolerancing framework	Candidate for all released drawings if ISO GPS is selected rather than ASME Y14.5	Exact standards and editions to be baselined before drawing release	Drawing convention plan, datum strategy, GD&T application, inspection approach
STD-ENV-001	Technical standard; ISO	Environmental conditions and testing for road-vehicle electrical/electronic equipment	Candidate for ECU requirements only; applicable parts and conditions must be selected deliberately	Relevant part and edition [TBD]	Requirements allocation, DVP&R entries, test procedure, laboratory report, configuration record
STD-IP-001	Technical standard; ISO or IEC	Ingress-protection classification and test conditions	Candidate for ECU enclosure only if an approved ingress target invokes it	Selected code, standard, and revision [TBD]	Installed-configuration test procedure, conditioning record, test report, post-test inspection and functional checks
REG-US-001	Regulation; U.S. authority [TBD]	U.S.-market vehicle or interior-material compliance, where applicable	Candidate only after target market and vehicle/component applicability are declared	Regulatory source and effective version to be verified	Applicability assessment, test plan, accredited or suitable test evidence, compliance record
CSR-SIM-001	Simulated customer requirement; program authority	Defines course-specific deliverable format, EDV assumptions, review gates, and PLM evidence	Applicable to this learning program only; not a real OEM CSR	Revision A, controlled in the course project record	Approved assumptions log, design-review package, traceability, release and ECO records
INT-PLM-001	Internal procedure; simulated engineering organization	Defines part numbering, document metadata, release state, approval, baseline, and ECO conventions	Applicable to every project artifact	Revision A; change-controlled within project workspace	Part and document register, revision history, approval record, EBOM/MBOM reconciliation, ECO links

Notice what this extract does not do:

• It does not claim that every ISO or IEC standard applies to every component.
• It does not convert a possible U.S. regulation into a confirmed requirement without a target-market decision.
• It does not treat a public Stellantis or Ford CSR as a requirement for the simulated EDV program.
• It does not claim that an FMEA Handbook is the same thing as IATF 16949.
• It does not hide missing source access behind invented clause references.

That caution is a design-strength, not a weakness. Early in a real program, many sources are candidates. The job is to close uncertainty through ownership, evidence, and approved decisions.

---

Connect the register to your RTM and PLM records

The standards register is the source-control layer; the RTM is the requirement-to-verification layer. Keep them separate but linked.

Record	Main purpose	Example link
Standards register	Determines whether a source applies and what evidence it expects	STD-IP-001 identified as applicable to ECU ingress verification
Requirements register	Converts an applicable source into an approved, measurable product or process requirement	ECU-ENV-001 defines the approved installed ingress requirement
RTM / DVP&R	Plans and records how the requirement will be verified	VFY-ECU-ENV-001-T01 defines the test configuration and pass criteria
DFMEA	Evaluates how the intended function may fail and what actions reduce risk	Gasket displacement or sealing-land distortion linked to ECU-ENV-001
Drawing / CAD / BOM	Defines the released configuration being built and checked	Gasket groove, compression stops, gasket part number, material callout
PLM baseline / ECO	Preserves configuration and assesses the impact of change	A gasket-material change triggers review of the applicable requirement, test evidence, DFMEA, drawing, and PPAP impact

This connection avoids a common mistake: writing “ISO 20653 compliant” on a drawing or slide without an approved requirement, a declared applicable code, an installed test configuration, and controlled test evidence.

---

Build the first controlled register for this course

Create a workbook, database, or controlled Onshape-adjacent template named:

EDV_Program_Standards_and_Source_Register

Use at least these tabs or linked tables:

1. Source Register
   One row per standard, regulation, CSR, customer document, core tool, or internal procedure.

2. Applicability Assessments
   One row per source–component pairing. A standard may apply to the ECU but not the door trim; a flammability source may apply to interior trim but not an underhood housing.

3. Revision and Change Log
   Records source updates, review dates, impact assessments, disposition, and resulting changes to requirements or deliverables.

4. Evidence Index
   Links required evidence to controlled files, PLM records, CAD versions, DVP&R reports, supplier submissions, and approval records.

Use stable IDs. Do not encode revisions into the ID.

Object	Example stable ID
Source-document register entry	STD-ENV-001
Requirement derived from it	ECU-ENV-001
Verification activity	VFY-ECU-ENV-001-T01
Evidence report	TR-ECU-ING-001
Applicability assessment	APP-ECU-STD-ENV-001
Change assessment	CIA-STD-ENV-001-002
Engineering change	ECO-ECU-002

For your first baseline, populate at least:

• ISO 9001 and IATF 16949 as the selected simulated QMS foundation;
• APQP, PPAP, AIAG-VDA FMEA, Control Plan, MSA, and SPC as separately classified core tools;
• a declared ISO GPS or ASME Y14.5 drawing-system candidate;
• ECU environmental and ingress-protection source candidates;
• interior-trim flammability source candidates for the future door-trim and HVAC projects;
• the simulated customer/program requirements document;
• the internal simulated PLM, design-review, change-control, and supplier-interface procedures.

For each entry, write an applicability verdict. “Not applicable” is an acceptable and valuable outcome, provided the rationale is credible and approved. For example:

Not applicable to ECU housing: interior-trim flammability test method. Rationale: source is retained for future interior door-trim and HVAC-outlet assessment; ECU placement and material scope require separate confirmation.

---

A review checklist for each register update

Before baselining a register revision, review these questions:

• Is the document correctly classified as regulation, standard, CSR, core tool, engineering requirement, or internal procedure?
• Is the issuing body identified correctly?
• Does the title, identifier, edition, release date, and effective date match the approved source?
• Has applicability been decided for each relevant component and lifecycle phase?
• Does the rationale state why, rather than simply saying “required”?
• Are the specific clauses, tests, deliverables, or methods that matter identified?
• Is the expected evidence explicit and linked to a responsible function?
• Is an inaccessible or unverified source visibly marked as such?
• Has a newer revision been assessed rather than silently substituted?
• Does a revision change trigger a documented impact assessment of requirements, CAD, drawings, DVP&R, DFMEA, suppliers, and release status?

---

A controlled standards register is the disciplined boundary between vague references and usable engineering obligations. It distinguishes laws from standards, standards from customer overlays, and core-tool methods from product-performance requirements. It also makes revision status, applicability, ownership, and evidence visible before the team relies on an external source.

For the simulated EDV program, keep real public documents, customer-specific inputs, internal procedures, and engineering assumptions clearly separated. This will make your later requirements baseline and verification records credible—and will make change impact much easier to manage.

Next, you will map ISO 9001, IATF 16949, customer-specific requirements, APQP, PPAP, Control Plans, and AIAG-VDA FMEA to simulated development gates and deliverables without confusing their different roles.