The 30-second answer
An EVSE sample is not controlled by calling it “latest,” “golden,” or “approved.” A useful sample revision record connects one physical unit to the configuration that was reviewed, the changes since the prior unit, the evidence generated from it, the unresolved issues, and the decision for the next project gate.
Use seven fields:
- sample identity;
- configuration baseline;
- change delta;
- evidence index;
- open issues;
- disposition;
- next-gate conditions.
This is a project-control template, not certification, market-entry or production-release advice. Set acceptance criteria and required approvals with the responsible engineering and compliance specialists for the exact product and destination market.
Why a sample name is not enough
“Sample B” may be clear during one meeting and ambiguous three weeks later. The enclosure can look unchanged while the cable, connector, firmware, label, protective component or test setup has moved to another revision. A photograph proves appearance, but it does not establish the complete configuration.
ISO 10007:2017 provides configuration-management guidance applicable from concept through disposal and remains the current edition after confirmation in 2023. NASA's public configuration-management guidance similarly treats controlled item lists, current baselines, change dispositions, reports and audits as connected work products.
For an OEM project, the practical lesson is simple: identify what the sample is before deciding what its result means.
A test result becomes useful project evidence when the tested unit and configuration are identifiable.
The seven-field sample revision record
| Field | Record | Why it matters | Stop signal |
|---|---|---|---|
| 1. Sample identity | Unique sample ID, build date, custodian, physical label and photo reference | Distinguishes the unit from look-alike samples | The unit cannot be matched to the record |
| 2. Configuration baseline | Drawing, BOM, firmware, connector, cable, label and packaging revisions that apply | Defines what was actually reviewed | A critical component or document revision is unknown |
| 3. Change delta | Each change from the prior sample, reason, owner and affected evidence | Prevents a change from disappearing inside “new sample” | The team cannot explain what changed |
| 4. Evidence index | Test/report ID, setup, date, result and sample ID for each linked activity | Separates evidence for this unit from evidence for another configuration | A result cannot be mapped to the sample |
| 5. Open issues | Issue ID, severity, owner, due date and containment | Keeps unresolved findings visible at the gate | A release-affecting issue has no disposition |
| 6. Disposition | Accept, accept with conditions, rework, replace, or reject; decision owner and time | Makes the meeting outcome durable | “Approved” has no named scope or decision owner |
| 7. Next-gate conditions | Required closures, documents, repeat checks and baseline to carry forward | Defines what must be true before progression | The next team receives only the physical unit |
The record can live in a controlled spreadsheet, PLM/QMS record or project database. The medium matters less than stable identity, controlled access, visible status and traceable decisions.
Step 1 — label the physical sample and the record together
Assign a unique identifier before testing or review begins. Put that identifier on the sample in a durable, non-damaging way and repeat it in the register, photographs, test request and meeting record.
A compact identity block can include:
- project and sample ID;
- product family and intended evaluation purpose;
- build date and build location;
- hardware, firmware and label revision;
- connector and cable configuration;
- custodian and current location;
- photo or scan reference.
Avoid using a customer name, certificate number or commercial promise as the identifier. Those fields can introduce permission or scope problems and still fail to distinguish one physical build from another.
Step 2 — freeze the reviewed configuration
The sample record should point to controlled documents rather than paste an uncontrolled description into a chat thread. List the exact revisions that define the unit and identify any intentional deviation.
NASA's public configuration-management standard separates configuration identification, configuration control, status accounting with traceability, and verification/audit. That separation is useful here: identifying a sample does not approve a change, and approving a change does not prove it was implemented or verified.
Use a baseline table such as:
| Configuration item | Applicable revision | Evidence of application | Deviation |
|---|---|---|---|
| Assembly drawing | Rev C | Build traveler reference | None |
| Bill of materials | Rev C.2 | Issued component list | One temporary substitute, separately recorded |
| Firmware | 1.4.2 | Device readout and load record | None |
| Cable/connector | Controlled part and lot reference | Incoming record and assembly trace | None |
| Rating/identity label | Artwork Rev B | Photo reference | Country mark omitted for this engineering sample |
The example is illustrative. The responsible project team decides which items are critical for its product and evaluation purpose.
Step 3 — record changes as deltas, not stories
A revision record should answer four questions for every material change:
- What changed?
- Why did it change?
- Which requirements, documents, tests or risks may be affected?
- Who approved the disposition?
Keep before/after references concise. Link to the controlled change record instead of copying large documents. If a cable, connector, protective component, firmware behavior or label changes, ask which prior evidence remains applicable and which evidence needs review. Do not assume the answer from the visual similarity of two samples.
Gate rule: a changed configuration with inherited evidence needs an explicit applicability decision. Silence is not evidence transfer.
Step 4 — link evidence to the exact unit
The evidence index should identify the sample, setup and result without turning the revision register into a laboratory report.
Record:
- evidence or report ID;
- activity and purpose;
- sample ID and configuration reference;
- date and responsible party;
- setup or condition reference;
- result status;
- issue IDs raised;
- storage location and access owner.
This structure prevents two opposite errors: rejecting a useful result because nobody can find it, or reusing a result for a different configuration without review.
Step 5 — separate issues from the gate decision
An issue list and a gate disposition are related but different. A sample can be accepted for a limited next step with conditions, while a release-affecting issue remains open. Conversely, closing every small issue does not automatically approve the sample for production.
Use bounded dispositions:
- Accept for next gate: the defined criteria for that gate are met.
- Accept with conditions: named closures are required by a stated date and owner.
- Rework and re-review: the same unit will be modified and presented again with a new revision entry.
- Replace: a new physical sample is required; do not overwrite the old record.
- Reject: the unit does not satisfy the defined review purpose.
Write the scope beside the disposition. “Accepted for engineering fit review” is not the same as “approved for production,” and neither is a certification or market-access conclusion.
The sample record provides a controlled handoff; production release remains a separate decision with its own criteria.
A neutral worked example
Suppose Sample EVSE-S03 changes the cable assembly and firmware from EVSE-S02. The enclosure and user interface are unchanged.
The revision record would not simply say “new cable, firmware updated.” It would record the new cable part/revision and firmware version, link the change reasons, identify the checks run on S03, list any prior evidence being retained with its applicability review, and state the gate disposition.
If the team accepts S03 for a pilot build subject to closing one documentation issue, the record should name that condition, owner and deadline. S02 remains historically visible; S03 does not overwrite it.
Five checks before the next project gate
Use this short gate review:
- Identity: Can the physical unit be matched to one record?
- Configuration: Are critical document, component and firmware revisions known?
- Delta: Is every material change from the prior sample explained?
- Evidence: Do results and issues point to this exact unit and setup?
- Disposition: Is the decision scoped, owned, dated and conditional where necessary?
If any answer is no, keep the record open and state the missing closure. Do not solve ambiguity by renaming the sample “final.”
How this page fits the OEM decision path
Use the portable EV charger OEM sourcing guide when the decision is whether a supplier's evidence and project controls are sufficient. Use the EV connector RFQ checklist when the decision is whether quotation inputs are complete enough for comparable supplier replies.
This page begins after a sample exists and ends with a traceable next-gate disposition. Keeping those page roles separate avoids turning one broad “OEM checklist” into several competing URLs.
Turn the template into a controlled review
When you contact SUPERGENIE, send the current sample ID, applicable revisions, change summary, linked evidence and open issues.
That gives procurement, engineering and the supplier a concrete starting point: which physical configuration was reviewed, what changed, what evidence belongs to it, and what must close before the next gate?
Frequently asked questions
Is a “golden sample” label enough?
No. The label is useful only when the physical unit, controlled configuration, evidence and approval scope remain traceable. Record those elements and preserve superseded versions.
Should a revised sample reuse the old ID?
Keep the prior record immutable. Use a new sample ID or a clearly controlled sub-revision that cannot be confused with the prior physical state, according to the project's identification rules.
Does sample acceptance approve mass production?
Not automatically. State the exact gate and scope. Production release, compliance decisions and commercial commitments require their own criteria and authorized owners.
What if only firmware changes?
Record the firmware revision and assess affected requirements, evidence and risks. A non-visual change can still alter what prior evidence remains applicable.
