Blockers and scope changes have always told half a story on a PtahCast board — both are records of something that already happened: a ticket already stuck, a trade-off already on the table. What was missing was the other half: things that haven't happened yet, but could. "What if the client's approval process drags on," "what if our one specialist gets pulled onto another engagement" — the kind of thing every agency tracks in someone's head, or in a spreadsheet nobody opens after the second week. Risk Management is that other half, built into the same board.
What it does
Every board now has a Risks list, sitting in the sidebar next to Blockers and Scope Changes. Logging one takes a title, an optional description, and two quick Low/Medium/High calls: how likely is this, and how bad if it happens. Add a category — Client, Agency, Third-party, or Other, the same categories your blockers already use — and an optional mitigation note. Nothing here demands precision nobody can actually back up; it's a judgment call made in a few seconds, not a number someone has to defend in a meeting.
The part that matters most: when a risk stops being hypothetical, one button — Materialize into blocker — turns it into a real Blocker, pre-filled with the risk's own title, description, and category, and linked back to the risk that predicted it. The risk itself is marked Materialized. Nothing gets re-typed, and nothing sits stranded as two disconnected logs that quietly drift out of sync with each other.
Why it stays private by default
Blockers and scope changes are already fully visible to clients today, on the reasoning that a fact that already happened deserves a plain, honest record. A risk is a different kind of thing — it's a prediction that something might go wrong, and worded carelessly, "transparency" about a risk reads less like honesty and more like an agency covering itself in advance. So Risk Management flips the default: every risk starts agency-private, visible only inside your own team. Sharing one with a client is a deliberate, explicit action — a "Share with client" toggle that only an Owner or Admin can flip, not something any team member can do while logging a risk in passing.
A shared risk shows up on the detailed client report, alongside scope changes, in plain language rather than raw internal labels — "moderate impact if it happens," not a bare probability/impact grid. The simple client report is left alone entirely; a risk, even a shared one, usually isn't something that needs a decision from the client right now, which is the same reasoning that already keeps scope changes off that simpler view.
What it doesn't do
A few deliberate scope decisions for this first version:
It doesn't feed the Monte Carlo forecast. A risk framed as "adds tickets" or "slows the team down" could, in principle, map onto the same scope-override and throughput-multiplier inputs What-If scenarios already use — but turning "high impact, medium probability" into an actual number is a real design decision, and it's only worth making once agencies are actually keeping their risk logs current. Building that translation before there's real usage to learn from would be solving a problem nobody's confirmed exists yet.
It doesn't schedule reviews or reminders. A textbook risk register expects you to revisit each entry on a cadence. This version doesn't nag you to. That's a natural fit for PtahCast's existing notification system later, not something bolted on before there's demand for it.
It doesn't gate creating or materializing a risk. Any agency team member can log a risk or materialize one — the same everyday, no-role-gate access blockers already have. Only the client-visibility toggle is restricted to Owner/Admin, because that's the one decision with real consequences if it's flipped carelessly.
Same access, one more place to be honest
Available on every plan, on every board. Log the thing you're already worrying about before it becomes a blocker you're explaining after the fact — and decide, deliberately, whether a client ever needs to see it.