A bundle's claims need to distinguish the components actually included

Fix the contents from records, not the bundle name

Start with what the customer actually receives. Pull the bundle's component list from the product configuration, the fulfilment or picking record, and any variation options, and write it as a list of specific items with their own product identifiers. A marketing name for the kit is not a contents list, and a bundle whose components rotate with stock needs the record of which configuration a given page describes.

Check the page against that list in both directions. A component shown in the image but absent from the fulfilment record, or an item shipped that the page never mentions, is a contents discrepancy to resolve before any claim is assessed. Every later step assumes the contents list is real; if it is not, stop there.

Assign each claim to the component it describes

Copy each specification, evidence statement and quality phrase from the bundle page and mark which component it belongs to. A purity figure printed beside component A describes component A. A report linked from the page names the sample and lot it names. Where the page layout places one component's document beside wording about the whole kit, record that placement as its own finding, because layout is how a narrow document becomes a broad impression.

Some statements are genuinely about the bundle as a package: total item count, combined weight, a single price, what ships together. Those need bundle-level records, which the fulfilment configuration supplies. The error to catch is the crossover — a component-level fact presented as a package-level fact, or a package-level convenience presented as a component-level property.

Component evidence does not generalize across the package

If the bundle page links a report for one component, that document supports statements about that component's identified sample and lot. It says nothing about the other items in the box, about other lots of the same component, or about future configurations of the bundle. This is the same scope discipline as any claim-to-evidence comparison, applied across a package: match product, batch, dates and property, and treat each unmatched dimension as an open gap.

The FTC's substantiation policy requires that an objective claim's evidentiary basis exist before publication. Applied to a bundle, the claim 'each item meets specification X' needs a basis for each item, not a basis for the item that happens to have paperwork. This page does not interpret the science in any report and does not authenticate documents; it maps which statements have a record and which do not.

Watch for the quiet version of the same problem: a badge or heading earned by one component's documentation that the template repeats across the whole bundle page. A visual element that implies package-wide coverage needs package-wide support, and repositioning it beside the component it belongs to is often the honest fix.

Decide what the complete offer can promise

For each statement, the matrix yields one of three outcomes. Supported: the claim names the component or the package, and a genuine record covers exactly that scope; keep it. Scopable: evidence exists for some components, and the wording can be narrowed to name them; rewrite it so a reader can tell which items carry the statement. Unsupported: nothing covers the statement as published; remove it while the business decides whether to obtain evidence, and do not substitute vaguer wording with the same reach.

Record the owner of the bundle page and the trigger for review, because bundles change silently — a swapped component, a new lot of one item, a discontinued item replaced with a near equivalent. Any of those events can orphan claims that were accurate when written, so the matrix should be re-run on each contents change rather than on a calendar.

For a Prism website-review consultation, bring the bundle URL, the component list and a summary of which statements lack component-level support. Scope, responsibilities, fees and terms are agreed before work. A review examines the public representations within the agreed scope; it does not validate any report, certify the bundle or affect a provider's eligibility decision.

Bundle claim-and-component matrix

Use one matrix per bundle configuration. List real components first, then test every public statement against them. Mark each statement supported, scopable or unsupported; never extend one component's record to the whole package.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.