A Product-Version Matrix for US/EU Toy Safety Planning

A brand selling several toy variations in the US and EU may need to manage many reports, samples, package files, and decisions. Without a clear record of which version each item concerns, teams can mistake a review for one configuration as evidence about another.

This guide explains how to construct a product-version matrix for buyer-side safety planning. It does not determine legal obligations or certify a toy. A qualified reviewer must assess the actual product, evidence, and destinations under current requirements.

Define the dimensions that distinguish product versions

Assign a product code and revision to each configuration. Capture user group, intended use, components, materials known, dimensions or design references, instructions, package version, and destination markets. A SKU or marketing name alone may not show all differences relevant to review.

Toy safety relates to product characteristics and use, ^[1] so define which details can change and which are controlled. A different accessory, material, color treatment, age range, or instruction may be relevant depending on the product. Do not decide technical significance from appearance alone.

Create a variant table with one row per configuration and columns for current sample, reports, package, reviewer, market, status, and open questions. Use explicit labels such as draft, reviewed, approved for a stated purpose, or superseded.

Keep shared components visible but do not assume they make complete products equivalent. If two toys use a common part, record the same component revision and note how its use differs in each product. Ask qualified reviewers whether evidence transfers to each context.

Link standards questions and evidence to each market

For each destination, list the standards or legal questions that a qualified adviser has identified. ASTM F963 is a US toy-safety reference, ^[2] while EN 71 is a European standards series. The matrix should record which reviewer determined applicability, which version or provisions were considered, and what evidence is expected.

Do not assume a US report automatically resolves EU questions or that an EU report covers all US obligations. Ask whether evidence can be reused and obtain confirmation from the laboratory or competent adviser. Record the scope of any such determination.

For each report, capture issuer, date, sample code, product revision, configuration, tests or reviews, market, and limitations. If the report does not identify a current configuration, ask for clarification before relying on it.

Keep certifications and test reports distinct. Certification is a defined process; ^[3] the matrix should show exactly what the certificate covers and whether it applies to a company system, component, model, or specific product. Do not treat a mark or certificate title as universal proof.

Track samples, package versions, and approvals

Every sample should have a version, date, configuration, known substitutions, review purpose, and reviewer. A concept model can address appearance, while a later sample may support other questions. Record what each sample could not demonstrate.

Link the sample to package artwork and instructions. If a package claims a particular component or user range, the matrix should point to the sample and approved content supporting that statement. A visual sign-off may not cover safety or legal text.

For each approval, record the approver, purpose, conditions, date, and open actions. Distinguish visual, content, technical, and market review. If a change occurs after approval, determine which decisions must be reconsidered.

Retain superseded package and sample references but mark them clearly. This makes it possible to understand historical decisions without accidentally using old artwork or an outdated test record for a current product.

Use change impact rather than blanket carryover

When a product changes, identify the affected fields in the matrix: component, material, instruction, package, user, destination, or claim. Ask the responsible reviewer whether existing evidence remains relevant and record the answer.

A change request should name the reason, product revision, affected documents, reviewer, approver, and effective date. If a shared component changes, list all variants that use it and assess each product context rather than applying a blanket decision.

If information is not yet available, mark the item as pending. Do not carry an old approval forward simply to make the matrix look complete. Assign an owner to obtain updated evidence or a qualified applicability decision.

Keep the matrix connected to the controlled specification. A spreadsheet can organize information but cannot make the legal determination. Use it to show who needs to review what and ensure the right evidence follows the right product version.

Create a release view for buyers and project teams

Before a release discussion, filter the matrix by product and market. Confirm that the current sample, instructions, package, and evidence all refer to the same configuration. List pending tasks and identify which decisions block the next step.

K&M’s public US/EU toy-safety guide can be used to frame questions about standards, documentation, and marks. toy safety compliance US EU Have qualified advisers confirm applicability and evidence for each product version; public information does not establish a particular toy’s certification or compliance.

Share only the relevant documents with each reviewer, while protecting confidential information. Ensure a laboratory, importer, or regulatory adviser receives enough information to assess the correct version and destination.

A product matrix is useful when a buyer can answer: which version is this, what evidence applies, who reviewed it, and what remains open? It makes the process more transparent without implying that documentation alone guarantees safety or compliance.

Frequently asked questions