Approval tiers

The cost estimate decides who is allowed to approve.

Most tools collect a cost estimate and print it on a record nobody reads. In Cognitivv PM the number has a consumer: it derives the level of sign-off the decision requires, and that gates the approve screen. Set the three values below and watch it move.

Derived, never stored

Three inputs, one verdict

Delivery effort, time to land, and budget. The tier is recomputed from those values wherever it's needed, so it can't drift from the numbers it describes. Change an estimate and the required approval changes with it, on the spot.

Time is normalized to days before anything is compared: days count as one, weeks as seven, months as thirty. Then the conditions are evaluated in order, and the first match wins.

Approval tier, derived live

The interactive version needs JavaScript. The complete rule table is in the next section, and it's the same logic the product runs.

Approval required

Capacity owner

This commits 35% of the team for 6 weeks. That needs sign-off from whoever owns that capacity, not a team lead.

The rules, in evaluation order

First match wins.

TierCondition
Cannot be determined Any of the three fields is blank. Checked first and deliberately, so a blank can never be scored as a zero.
Executive Delivery effort is 40% or more, or time to land is 180 days or more, or the budget band is over $100k.
Team lead Delivery effort under 15%, and time to land under 30 days, and the budget band is under $10k.
Capacity owner Anything else.

Why blanks are checked first

If a partially estimated decision were scored as though its blanks were zeroes, the cheapest possible route to the team-lead tier would be to skip the cost screen entirely. That is precisely the behavior the gate exists to stop, so unknown is evaluated before every other condition. An unestimated decision isn't cheap. It's unapprovable.

Why the estimate had to decide something

An earlier version of this product collected the cost and did nothing with it. The number reached four places: an impact recap, the decision record, a database row, and one sentence of rationale. All four were prose. Nothing branched on it, nothing escalated on it. A PM could commit 80% of the team for six months and approve it alone with every cost field blank.

That made the question of precision unanswerable on its own terms. Precision is only worth its friction if something reads the number. So the fix wasn't a finer input. It was giving the output a consumer. Now the estimate determines the required level of sign-off, Screen 6 states that requirement plainly, and above the team-lead tier the approver has to confirm the named owner can actually commit that capacity.

The approve gate stops asking “did you tick a box” and starts asking “does the right person know.”

The thresholds are a strawman, and we'll say so

40%, 180 days, $100k. These are defensible, not measured. Nobody has run a study establishing that 39% of a team's capacity is a fundamentally different commitment from 40%. They live as constants in a single module precisely so the first team that finds them wrong can tune them without touching the logic, and we expect at least one team to find them wrong.

The friction to watch is the other edge of the same blade: a PM who genuinely can't estimate a cost can't approve the decision. That's intended. It's also the thing most likely to annoy someone in the first month, and we'd rather you hear it from us.

The ask

Think your thresholds are different?

They probably are. That's a conversation we want to have, the tiers are constants waiting on real teams to correct them.