Most engagements keep one flat list called risks, and quietly bury their assumptions inside it. That is a mistake, because the two behave differently: a risk needs a mitigation owner, while an assumption needs a validation path and a date to prove it true or false. The Stratenity risk and assumption log separates them, tracks each through the engagement, and defines the trigger conditions that turn an unproven assumption into a live risk. Run weekly, it stops the most common failure mode in advisory work, which is discovering too late that a foundational assumption was wrong.
Two categories the flat risk list collapses into one
Nearly every engagement opens a risk register in week one, and nearly every one of them makes the same quiet error. It pours risks and assumptions into a single column and treats them identically. But they are not the same animal. A risk is a thing that might go wrong and needs someone to reduce the odds or soften the impact. An assumption is a thing the team has decided to treat as true without yet proving it, and it needs a path to confirm or kill it. Blur the two and you get a list that looks disciplined but manages nothing, because a mitigation plan is useless for an assumption and a validation date is meaningless for a risk. The register becomes a comfort object rather than an instrument.
The Stratenity log makes the distinction structural. Risks get mitigation owners; assumptions get validation paths and dates. Crucially, it defines the trigger conditions under which an assumption that fails validation converts into a risk, so the transition is caught the moment it happens rather than in the postmortem. This matters because the two categories are connected: today's quiet assumption is tomorrow's live risk, and the whole point of the log is to see that conversion coming. The most expensive failures in advisory work are almost never the risks you named and watched. They are the assumptions you carried unexamined until the ground shifted underneath the engagement, at which point the cost of responding has multiplied and the options have narrowed.
Four components that keep the two categories honest
The log has four working parts. Each is small enough to maintain in a shared sheet and each closes a specific gap that a flat list leaves open. The structure is deliberately plain, because a register that is elaborate to maintain is a register that stops being maintained by the third week.
| Component | What it holds | Why it is separate |
|---|---|---|
| Risks with mitigation owners | Named threats, each with a probability, an impact, and one accountable person driving mitigation | A risk without an owner is a worry, not a managed item |
| Assumptions with validation paths | Statements treated as true, each with the test that will confirm them and a date to run it | An unvalidated assumption is a bet the engagement is making blind |
| Trigger conditions | The specific signal that flips an assumption into an active risk or escalates a risk's severity | Transitions get missed unless the tripwire is written in advance |
| Weekly review cadence | A standing slot to re-score risks, check validation dates, and process any triggers that fired | Registers that are not reviewed decay into stale artifacts within a month |
Worked example. A payments client's engagement assumes the incumbent processor will grant API access by week four. That is an assumption, not a risk, so it goes in the assumptions column with a validation path: a written access confirmation from the processor, due end of week three. The trigger condition is written down at the same time, in plain language: if confirmation is not in hand by the week-three review, the assumption converts to a high-impact risk, and the mitigation owner, the client's head of engineering, activates a fallback integration plan that has already been sketched. When week three arrives with only a verbal "we are working on it" and no written confirmation, the log fires exactly as designed. The assumption becomes a risk, the fallback starts on schedule, and the engagement absorbs a two-week problem instead of the eight-week crisis it would have become had the team simply assumed access would arrive and discovered the truth in week seven.
Running the log across the engagement
- Sort every entry into risk or assumption on entry. If the team is uncertain which it is, ask a single clarifying question: does this thing need mitigating, or does it need proving? That answer places it every time.
- Give every risk one named mitigation owner and every assumption one validation path with a due date. Entries missing either field are incomplete and should not be counted as managed, no matter how confidently they are worded.
- Write the trigger condition when you log the assumption, not later. The tripwire only works if it is defined before the moment of truth arrives, because after the fact everyone has an opinion about what should have counted.
- Re-score risks on likelihood and impact at the weekly review, and move any assumption whose validation date has passed without proof into the risk column immediately, without waiting for permission or a longer meeting.
- Keep the log to the entries that could actually change the engagement's course. A register with sixty items nobody reads is worse than a tight list of twelve that gets acted on, because the false comprehensiveness hides the handful that matter.
Where risk logs stop working
- Mixing risks and assumptions in one list. The two need different treatment and get neither when merged into a single column of worries. Fix: enforce the two-category split and refuse any entry that will not commit to being one or the other.
- Assumptions with no validation date. An assumption you never schedule a test for is a permanent blind spot dressed up as a tracked item. Fix: require a date on every assumption and treat a passed date as an automatic trigger.
- Risks owned by "the team." Shared ownership is no ownership, and everyone assumes someone else has it. Fix: assign one individual per risk, who may delegate the work but keeps the accountability.
- Defining triggers after the fact. Retrofitted tripwires always fire late, because nobody was watching for a signal that was never written down. Fix: write the trigger condition in the same sitting as the assumption it guards.
- Logging once and never reviewing. A register without cadence is a museum piece that reassures without protecting. Fix: put the weekly review on the calendar and re-score every open item in it, every week.
Before you call the log complete
- Every entry is classified as either a risk or an assumption, with none straddling both.
- Each risk has one named mitigation owner; each assumption has a validation path and a date.
- Every assumption carries a written trigger condition for its conversion to a risk.
- The weekly review is scheduled, and it re-scores risks and checks validation dates.
- The log is short enough that the whole team actually reads it each week.