Build a risk register for a project

Project: {{project_summary}}
People and roles who could own risks: {{roles}}
Our likelihood and impact scales: {{scales}}

Plan, notes and concerns raised so far:
"""
{{project_notes}}
"""

Task:
Build a risk register for this project, so that the team can agree which risks to act on now and who watches each one. I will review it with the team, and they will change scores and owners where they know better. A good register should be short enough to review in one meeting and specific enough that every action has an owner and a date.

If the scales line says "default", score likelihood and impact from 1 to 5. Likelihood: 1 rare, 2 unlikely, 3 possible, 4 likely, 5 almost certain. Impact: 1 negligible, 2 minor, 3 moderate (a small slip in time or cost), 4 major (a milestone missed or a large overrun), 5 severe (the project fails to deliver its goal).

Format:
1. Register table of 10 to 20 risks, with the columns ID, Risk, Likelihood, Impact, Score (likelihood times impact), Response, Actions, Owner, Review date, Early warning sign. Sort by score, highest first.
2. Top five: the highest-scoring risks, with one sentence each on why they matter now.
3. Issues: anything in the notes that is already happening. These are problems to manage, not risks, so list them separately with an owner.
4. Assumptions: things the plan depends on that nobody has confirmed.

How to write each risk:
- Use cause, event and effect, for example "Because the supplier has not confirmed capacity, delivery may be late, which would delay installation." "Resources" or "communication" on its own is a category, not a risk.
- The response is one of: avoid (change the plan so the risk cannot happen), reduce (lower the likelihood or the impact), share (move it to a party better placed to handle it, such as through a contract or insurance) or accept (watch it and have a fallback ready).
- Actions are specific steps with a date, not "monitor closely".
- Each owner is one role from the list who can actually act on the risk; write "to assign" if none fits.

Do not invent facts about the project, suppliers or people. Where a score is your judgment rather than something the notes support, flag it with "(estimate)" so the team knows to discuss it. Include the risks people tend to leave out, such as a key person leaving, the sponsor changing priorities or users not adopting the result, but only where they plausibly apply here.

Length: the table plus no more than 300 words of text.