One case can gain many names and numbers. These may name the event, product, build, supplier case, public notice, or flaw. Do not force them into one field. Record which one names the case, which one names the product, and which one links to proof.
Begin with the governing content
The 72-hour notice for a flaw under active attack has set content. It gives known facts about the product, flaw, and attack. It also gives fixes or ways to cut the risk that are ready or in use.
The notice for a severe event is different. It gives known facts about the type of event and a first view of it. It also lists fixes or ways to cut the risk.
These rules make the product and case names vital. They do not require a given public ID to exist first. Do not delay an early report while the team waits for one.
Give the case one internal anchor
Give the case a neutral and stable ID when review starts. Use it for the fact review, legal choice, report stages, user notes, and proof index. Do not put a draft legal view or secret product name in the ID.
The ID should link to records, not replace them. Link the maker, report track, awareness choice, due times, products, and filed copies.
If two alerts join, keep both old IDs and note why they joined. If one case splits into two product events, give each a new ID. Preserve the link between them.
Separate product identity from case identity
Keep one main record for each maker’s product. Use the market name. Add the facts that show which releases are in scope. These may include version, build, model, package, firmware, or setup.
Map other names to the main record. Do not use an alias in its place. A seller’s label, package name, and code name may all mean the same product. The record should show the proof for that link.
Type external references
For each outside ID, store its type, source, check date, and proof link. A flaw ID does one job. A supplier case, public notice, authority ID, and filing receipt each do another. A flat list can hide reused numbers and false matches.
Use a public flaw ID as a link, not as the maker’s product review. Record if the ID is absent, pending, in dispute, or later fixed. Keep the proof that was checked. Do not make up a value that looks like a real ID.
Reconcile scope before every stage
Before each approved handoff, compare the product list with the last saved copy. Mark each product or version as kept, added, removed, or not yet clear. Give the proof for each change. Use the same case ID in the approval, filed copy, and receipt.
A good ID map answers three questions. Which legal maker owns the case? Which product releases do the facts cover? Which records prove what was known at each report stage?
Continue this workflow with the product-version matrix and the staged evidence trail.