Build a risk register where every risk has a real owner and a specific early-warning signal, not just a severity rating

You are building a risk register for a real project or initiative. Most risk registers I've seen are just a list with a severity color next to each item, which doesn't actually help anyone act — I want each risk to have a real owner and something specific that would tell us it's starting to happen before it's a crisis.

PROJECT OR INITIATIVE
A 4-month migration of our billing system to a new vendor platform.

KNOWN RISKS (as raw notes, don't worry about formatting)
Vendor could miss the data migration deadline, some customer data might not map cleanly to the new schema, the old system's support contract expires mid-migration.

TEAM MEMBERS WHO COULD OWN A RISK
Dana (engineering lead, close to the technical migration work), Theo (vendor relationship manager), me (project sponsor, less hands-on day to day).

RISK TOLERANCE OR CONTEXT
Low tolerance — this system touches customer billing, so even a minor data error is costly.

For each risk, score likelihood and impact on a simple scale and explain briefly why, grounded in what's specific to this project rather than a generic industry-standard justification. Assign a real owner from the team list — the owner should be whoever is best positioned to notice the risk starting to materialize and act on it, not necessarily the most senior person available; if no one on the list is well-positioned to own a given risk, say so explicitly rather than defaulting it to me. For every risk, name a specific, observable early-warning signal — something concrete that could actually be noticed in the ordinary course of work, not a vague restatement of the risk itself ("budget overrun" is not a signal; "vendor invoice comes in 15% over the last quote" is). Write a mitigation step that's genuinely preventive, distinct from a fallback response that only kicks in after the risk has already occurred — both matter, and they shouldn't be conflated into one vague line. Rank the register by a combination of likelihood and impact, but flag separately any low-likelihood, high-impact risk that could get buried by that ranking even though it deserves specific attention precisely because it's easy to dismiss until it happens.

WHAT NOT TO DO
Do not invent risks I didn't mention, even plausible-sounding ones — ask if I want to add categories instead. Do not write a mitigation step that's actually just a restatement of "monitor the situation."

OUTPUT FORMAT
A table: Risk, Likelihood, Impact, Owner, Early-warning signal, Preventive step, Fallback response. Ranked by severity, with a separate flagged note for any low-likelihood/high-impact risk.