25 · When to Say No: Intake Rules and Red Lines

Companion Templates

The Challenge. A project you know is a trap gets pushed at you, and the person proposing it is the one who trusts you most. How do you refuse without burning the relationship? One layer down, how do you get the organization to take fewer traps, instead of betting every time on your being in the room?

What You Will Be Able to Do. Use an organization-level intake rubric (five dimensions of scoring plus three red lines) to rule on whether a project should be taken, before any demo. Use the three steps to no to translate refusal from a relationship event into a judgment event. Build a kill register, so the judgment behind saying no evolves the way an eval does.

Week 28, the Light in His Eyes

Week 28, Anchor & Helm's quarterly business review, which is also the meeting where Claims Operations accounts to Anchor & Helm for the launch (Chapters 23 and 24). The first one since the auto queue hit target. The run chart is on the wall. Week 26, first-touch handling time for auto exceptions, -31%, North Star met. Grant Whitmore, Kevin Doyle, and Victor Reyes are all in the room. Halfway through the agenda, Grant closes the minutes.

"Next step, full automation of the whole claims process. AI does loss assessment and payout approval directly. I have had Finance set the budget aside, and I will handle the board."

There is light in his eyes. And this is not an outsider's enthusiasm. The framework he cites is the one you taught him. "You said decision rights move up on evidence. The evidence is hanging on the wall now."

This is the hardest kind of situation to say no in. The budget is there, so you cannot hide behind resources. The results are real, so you cannot say the timing is not right. The proposer is your most important sponsor, and every "I will tell you when the time comes" over the past half year, he remembers. And the five-question framework in your head (Chapter 7) is already sounding the alarm. Risk, 1. The payout decision is a regulatory red line, the error is irreversible, and this company's human oversight capacity cannot carry a move of decision rights like that.

He asked about the same direction once in Chapter 8. That one was easy. The project had just started and one ladder drawing was enough. This time he comes with a budget and results in hand, ready to call it. The hardest no is the one you say to the person who trusts you most. This chapter is about how to get it said, and how to keep your organization from needing you personally to say it every time.

Why This Is Hard: Refusal Has Only Two Default Meanings

Refusal inside an organization has only two default meanings. "I do not want to help you," or "I cannot." The first damages the relationship, the second damages your professional standing. So most people facing a project pushed at them take a third road that looks harmless, take it now and sort it out later. Three months on the project dies on the five gaps, and the relationship and the standing go down together.

The deliverer has to build a third meaning. The evidence says not yet. You have used it twice already. In Chapter 7 the elimination table went on the table, you pointed at the scores and read the evidence column, and the service chatbot forwarded by the board was eliminated. That was its first rehearsal. The hold and watch option in the Chapter 19 impact memo is its midpoint form, turning "no expansion yet" into an option with its own expiry conditions, handed to the person who decides. The mechanism is the same sentence both times. Translate refusal from a relationship event into a judgment event. A relationship event is settled by position and rank. A judgment event is settled by evidence, and nobody in the room has evidence harder than yours.

But an individual who can say no solves only half the problem. The other half is at organization scale. The demo inflation of Chapter 1 and the idea inflation of Chapter 7 reappear unchanged at the organization's intake layer, and because your service carries no price, the cost of proposing an idea is zero, so idea inflation floods toward you at triple speed. After this win at Anchor & Helm, your team becomes the mounting point for every AI wish in the company, new projects arrive every week, each with a budget and a light in someone's eyes. A delivery team with no intake discipline has a settled fate. Packed with impossible projects, record L0 output, L3/L4 achievement at zero. Personal scripting cannot hold back structural traffic. Only a mechanism can. This chapter raises "the evidence says not yet" from a personal script to an organizational mechanism.

Prior Art, and What AI Changed

Solution Selling's qualification discipline, upgraded this time into an organizational process. Chapter 7 quoted the iron rule of the Bosworth line (paraphrased). Chasing the wrong deal costs ten times what losing one costs, so the qualification standard goes up front. The real core of that work is not the script. It is moving the qualification standard out of personal craft and into a process. Resources go in only after a review, the standard is written on paper, and nobody gets an exemption on enthusiasm. What the delivery team copies is exactly this. Make the intake standard explicit, rule on it at a meeting, leave a trail for the retrospective.

And inside a company you need not build a new gate for it. The company is already full of ready-made carriers, the project approval review, the architecture review, the investment committee, the quarterly ask review, each with its own agenda, its own minutes, and a group of people who already have to sign. Hanging the three red lines and the five dimensions on one of them takes a tenth of the effort of opening your own meeting, and it is harder to route around than a new meeting would be.

Maister's economics of practice, which projects not to take. Managing the Professional Service Firm (its ideas paraphrased) carries an account most service organizations ignore. The wrong project destroys more than profit. It burns the team, because your best people spend themselves on a project that was going to fail, and then they leave. It burns the reputation, because other departments and the executive layer define who you are by the projects you have done. So the intake standard is not an operating detail. It is the team's position. Are we a delivery team or a demo crew. What you take is what you are.

The AI era changed two things. First, the moment for saying no was forced earlier. In traditional software, "can be demoed" and "can be delivered" were not far apart, and the demo was itself the filter. AI tore a crack between the two. The five gaps (Chapter 1) are all invisible at the demo stage, so the infeasible projects are often the ones that make the most stunning demos. Wait for the demo and then say no? Too late. The budget is approved, the executive has reported it up, the applause has already sounded, and sunk cost has taken everyone hostage, you included. The gate has to sit before the demo, and that is exactly where intake sits.

Second, red lines acquired an external source of hardness. In traditional projects, "not taking it" was mostly an economic judgment. For AI projects, part of "not taking it" comes from regulation, ethics, and irreversible harm. Those boundaries are not settled by weighing things up inside your organization, so they have no business appearing in any scoring sheet. A red line is a boundary, not a preference. Inside a company, use that hardness to the full. State red lines through regulation, compliance, audit, and the Group's AI governance policy wherever you can, so that "this is not ours to vote on" is literally true, and you do not have to carry an executive's will on your personal judgment.

The Framework: An Organization-Level Intake Rubric, Five Dimensions of Scoring Plus Three Red Lines

Intake rubric, the organization's ruling structure at the door of a project. Clear the three red lines first (any one of them vetoes), then score the five dimensions, and rule on a candidate project, take it, do not take it, or take it with conditions, before any demo. (Intake, the review that decides which asks the team takes on.)

The three verdicts turn on two things, whether the red lines were cleared and whether any dimension is a weak link. All three red lines clear and no weak dimension, take it. Any red line touched, do not take it, and however high the other dimensions score, nobody looks. Red lines all clear with exactly one dimension at the floor, that is take it with conditions. Taking it with conditions means writing three things down on the spot, which dimension is short, who closes it by when, and who re-scores it once it is closed. If those three cannot be written, record it as not taken then and there. Do not leave an ownerless candidate sitting in the sheet.

Its relation to the five-question framework of Chapter 7 fits in one line. The five questions assess "is this use case any good," the deliverer's personal tool in the field. The intake rubric assesses "can this organization carry it, is it worth carrying," the gate at the team's door. These five dimensions are intake's five, and what they grade is a project. They are not the same set as the five-axis capability radar that grades people in Chapters 3 and 26. You can see the five questions' shadow in the five dimensions, but there are two upgrades, taken up after the table.

Dimension	Test Question
Strategic value	Win it, and what does the organization get? One department's thanks, or agenda power and standard-setting power over a class of problem? (the organizational version of Pain + ROI)
Data readiness	How far do the key data exist, how reachable are they, how far can they be trusted? Have they been reconciled? (inherited straight from the Data question)
Owner in place	Is there someone on the business side who signs for the outcome? Who backstops the errors, who maintains it after launch? (the ownership gap at the door)
Production path	From demo to production, do review, oversight, and change discipline get through? Or can only the demo live?
Reuse potential	What can go into the pattern library (Chapter 23)? How much cheaper is the second delivery? (Maister's leverage)

Scoring follows the weakest-link logic of Chapter 7. 1 to 5, any dimension ≤2 does not enter the schedule, and a re-evaluation condition gets written. No weighting, no averaging. The same rule bites harder in Chapter 7, where a question at the floor eliminates the use case. Here it only keeps the project out of the schedule. That notch is deliberately looser. Assessing whether an organization can carry something runs one notch wider than assessing a single use case.

Both verdicts show up in the meeting that follows. Loss assessment and payout approval touches a red line, not taken. "Move decision rights up one more layer" gets its condition and its re-scoring moment nailed down, and that one goes through as take it with conditions.

The first upgrade is the two dimensions of organizational economics added in (strategic value, reuse potential). An individual assesses the use case. An organization also has to assess what this fight does to itself. The second upgrade matters more. The five questions' Risk column has disappeared here. It was promoted into a red line and no longer gets scored. Three red lines, each with one test question.

Automated decisions at an irreversible-harm step. Can the harm from the single worst output be taken back? Anchor & Helm's "never touch payout decisions" (Chapter 8) is this one's instance.
A move of decision rights with no human oversight capacity behind it. After the move, is there still someone with the time to look, the ability to judge, and the authority to stop it (the three oversight questions, Chapter 12)?
Outward-facing output in a regulatory grey zone. When this output causes a dispute, what do you answer the regulator with?

Each of the three has a typical misjudgment. On the first, reading "a person signs at the end" as not automated. If the signer has no time to actually look, nobody is reviewing, and that is automated. On the second, reading a timetable of "assist first, automate later" as oversight capacity already built. On the third, reading "the regulator has not said no" as "the regulator said yes."

The red lines carry exactly one rule of discipline. Any one of them vetoes, and none of them enters the scoring. The meaning of a scoring sheet is trade-off, and everything that enters the sheet is by default compensable by a high score elsewhere. A red line gets its force from outside. A regulator does not fine you one unit less because strategic value scored 5, and irreversible harm does not turn reversible because reuse potential is high. Pulling Risk out of the scoring columns and making it an off-sheet veto is not a wording change. It admits a fact. Some risks are there to be managed. Some risks are there to be avoided.

One step remains after the ruling, saying the no out loud. Three steps.

Affirm the goal. Declare that what you refuse is the path, not the intention. "The direction is right, and we get there sooner or later."
State the evidence. Put the rubric on the table and go through it item by item. Put Risk in the language the other side cares about. Talk the regulatory account and the brand account, not model probabilities.
Offer a path. A step plus a condition. "First get to [measurable threshold]. When the data is there, decision rights move up one layer, each layer decided on its own."

The third step is where it succeeds or fails, and the rule is one sentence. A no must come with the conditions for a yes. An unconditional "no" is a refusal. A conditional "no" is a roadmap.

Saying no inside a company carries a notch more political cost than saying it outside. Refusing a project is not losing a piece of business. Refusing an executive's use case can be read as picking a side, and next quarter's budget for you sits at the desk beside his. This does not change the structure of the three steps. It raises the weight of the last two. The evidence in step two and the alternative path in step three cannot be skipped inside. A no carrying only an attitude gets you routed around, and a team that gets routed around cannot even keep its gate.

At Anchor & Helm: The Page Goes on the Table

Back to the meeting room in week 28. You knew on the day the target was hit in week 26 that this proposal would come back. That line of revival condition in the Chapter 8 scope decision log (the revival list), "once the advise layer's acceptance data hits target, move up one layer at a time, each layer decided on its own," is owed a settlement. So there is a page in your bag.

"Half a sentence before the conclusion. You have not got the direction wrong. Efficiency across the whole process is what this project pointed at on day one, and if claims cost is to come down another notch, that really is the only way to go." Catch the goal first. Only then does a refusal earn the right to begin.

Then you put the page on the table and go through the five dimensions one row at a time. Strategic value, high, no argument. Data readiness, low. What the queue reconciled is process status data. Loss assessment and payout approval feed on a different set, repair hours, parts prices, the reading of survey images, and not one of them has been reconciled. Owner, "AI sets the loss. Who signs the payout approval?" Nobody answers. Then your finger stops on the three rows boxed out separately, outside the scoring area.

"This one does not get a score," you say. "Get one loss assessment wrong, the customer takes the payout approval to the regulator, and the nature of it becomes a payout decision the company made and got wrong. Calling it a system fault will not cover it. The regulatory consequence and the brand consequence, you know better than I do. I do not need another line on this page."

You did not say the model will get things wrong. Model probability is your ledger. Regulation and brand are his. Speak in his ledger and he had it in three seconds. Victor Reyes added half a sentence from the side. "Until the regulator's line on AI payout approval is out, this review does not pass with me."

"So what I recommend is rebuilding the steps, not dropping it." You turn the page over. "Next step is estimate assist. AI produces the loss estimate, the payout approver reviews it, the whole thing leaves a trail, the same skeleton as the exceptions queue. The step condition is nailed down. When estimate assist's override rate drops below 10%, when the approver changes fewer than one suggestion in ten, the data will tell us which classes of claim can have their decision rights moved up a layer. One layer at a time, each decided on its own. That is the concrete form of that revival condition from back then. When the data is there we go, instead of we will see. As for the payout decision itself, until the regulator speaks it is a red line, and it is not ours to vote on."

Grant studies the page for a while. His first sentence is, "The last ladder you drew me, I took to the board. Give me this page too." Then the second one.

"Then we go with your steps."

After the meeting he holds you back at the door for one more line. "We go with the steps you laid out. But the window with the board, I can only hold it two quarters. When the time comes, the estimate assist numbers had better be presentable."

There is no loser in the room, but the steps now carry a clock. This no could be said because of money saved up over half a year, and the script is only the wrapping. The honest report in Chapter 18, "one point short does not count," is why he does not doubt your evidence for a second. Self-orientation in the denominator of the Trust Equation (Chapter 5), how visibly you are working for yourself, is as low as it can go at the moment you push away a fully funded project.

The relationship took no damage, because the way you refused proved you were carrying the judgment on his behalf. What he wants is someone who can hold off a wrong decision for him. Executors who agree to everything, he has plenty of. The moment you say no is both a withdrawal against the trust balance and the next deposit.

From One No to a Gate

From week 30 on, that page stops being your personal tool. You harden it, together with the retrospective on that meeting, into the team's intake process. A new candidate clears the three red lines first, then the five dimensions, then gets ruled on at a meeting. A killed candidate is not allowed to disappear. It goes into the kill register. Project, proposer, kill reason, revival condition, retrospective conclusion a year later, five columns (template at Template 25.4). The first two rows are ready-made. Full automation (loss assessment and payout approval), revival condition as above. Service chatbot (Chapter 7), re-evaluation condition carried over unchanged.

The sheet has an owner and a rhythm. You hold it from week 30, and after you leave it goes to whoever takes over intake. The fifth column gets a pass once a year, two questions per row, did it get built in the end, did the revival condition come true.

Whether this gate stands inside the company turns less on how good the sheet is than on where its force comes from. Three routes. The first is the cheapest, build no new review. Hang the three red lines and the five dimensions on the company's existing project approval review, architecture review, or quarterly ask review, and the gate comes with an agenda, minutes, and signatories. Second, have the CIO or the responsible VP endorse the standard once at a meeting, and after that "this is the company's intake standard" is not something you have to explain each time. The third is the hardest, write the three red lines into the company's AI governance policy. From then on the red lines are not your team's to vote on and not the proposer's to bid on.

Stronger than a gate is putting a price on the service. Where the company has showback (shows the bill only) or chargeback (actually deducts budget), the compute and labor bill is booked straight to the department using it (Chapter 14). Where it does not, use a non-monetary price. Every project supplies one full-time counterpart from the business side, named, written into the project approval resolution. The price need not be money. As long as the person with the idea has to put something up, inflation comes down by itself.

Owner in place is the hardest dimension to get inside a company. No written agreement can force the business side to produce a signer, and most people genuinely believe that "once it launches someone will look after it." Forcing out a named owner uses the same trade. You want our people and our time, so give us the person who signs for the outcome after launch, name into the project approval resolution. No name, and this dimension is a 1, and by weakest-link logic it does not enter the schedule. This is not obstruction. It turns owner from a courtesy into a claim, and what the claim buys is that after launch this system's priority and iteration schedule are set by him (Chapter 4).

There is one more account that holds only inside a company. The projects you turn down do not disappear. The business department can have it built by an outside firm, or buy a SaaS product, and when it goes badly the ops work still routes back to you, because you are the only people in the company who understand this stuff. You are not moving to a different company and starting over, so inside, "not taking it" does not equal "not my problem." This account pushes the internal no toward the take-it-with-conditions notch, keeping the project on a path you can see, which is cheaper than letting it take a worse road and picking it up afterward. That is also why, among the rubric's three verdicts, the middle one gets the most use inside.

The fifth column is empty right now, and it is the soul of the whole sheet. A year later you read back row by row. The kills you got right, someone else built it later and it died of exactly the cause you predicted. The kills you got wrong, the revival condition had long since come true, nobody re-scored it, and the opportunity went to someone else. Both conclusions feed back into the rubric. Whichever dimension keeps misjudging is the dimension whose test question you fix. This is the spirit of Chapter 11 reappearing at the intake layer. The judgment that judges intake also has to be judged. Without this column, saying no is the one decision in the organization that never gets checked, and it will stop at the level you are at today and never evolve again. Inside a company the sheet carries one more benefit. People come and go and it is still there, and you get to see what actually became of the projects you rejected, so the fifth column's evidence is easier to come by than it would be outside. It turns "why we did not do it back then" into organizational memory, and what it defends against is every change of executives stepping into the same hole again.

Failure Modes

1. Taking everything for next year's budget. Half the team's schedule reads "let us build a demo and see." Inside a company there is no sales team, and nobody pushes you to hit a number. The pressure only changed source. A project an executive named is hard to push back. Next year's headcount and compute get requested on the strength of this year's presentable AI highlights, and your department's OKRs have a few "landed scenarios" written on them. What is truly fatal is that the shape of the account changed. Taking the work and delivering it used to be two groups of people, with benefit and cost on two separate ledgers. Inside, those two ledgers merged into one, and the taker and the deliverer are the same person. You take a project at the start of the year for the budget, knowing it is a trap, and a few months later you are the one who pays.

This is no longer misaligned incentives. It is a bet you placed on yourself, and the payoff on the day you bet is certain while the cost on the day you settle is still invisible, which makes it harder to quit than misalignment. With no gate, taking it is the rational choice in the moment. The consequences settle globally. The team turns into a demo factory, record L0 output, while the deliverer's unit of value settles only at L3/L4 (Chapter 1). Achievement goes to zero and the best people leave first. The test. Go down the running projects on the schedule one by one and ask how many can state the release criteria written down at intake. The ones that cannot are the ones that got in on enthusiasm and a budget narrative.

2. Using delay instead of refusal. "Great idea, the schedule is full, let us look next quarter." Delay defers the social cost of refusal and looks free in the moment. But it also cancels the judgment. The other side got no evidence and no step, only a brush-off, and a brush-off reads no differently from contempt. Next quarter the project comes back unchanged and your credibility is thinner than last time. Relationship and judgment both lose. Delay rolls the interest on the no into the principal. The test. Go through the projects you said "let us look next quarter" about in the past six months and count how many were actually re-scored the next quarter. If none were, what you used was delay, not refusal.

3. Negotiable red lines. The scoring sheet shows "compliance risk 2," and then strategic value's 5 averages it away. The meaning of the sheet is trade-off, and everything that enters it is by default compensable, while a red line's force comes precisely from not taking part in the trade-off. Make the first exception for a "specially important project" and the red line turns from a boundary into a price. After that every proposer comes to bid. Once a red line is in the scoring sheet, it is no longer a red line. The test. Look at which column your red lines live in right now. If they carry a score and can be averaged away by another dimension, they already are not red lines.

4. Killing without a retrospective. A rejected project is never mentioned again, and the register either does not exist or has a permanently empty fifth column. Organizations only review what they did. What was done has data, an owner, and meetings. What was not done produces nothing, and nobody schedules an agenda for it. So refusal becomes the one judgment in the organization exempt from inspection, nobody ever learns which kills were right and which were wrong, and intake's accuracy stops where it was on day one. The test. Pick any candidate rejected last year at random. If nobody can state its revival condition back then and nobody can say whether the condition holds today, this column is empty.

5. Saying no with no alternative path. The meeting ends, the other side leaves politely, and next time the project approval routes around you. A no with no conditions carries nothing but attitude. The other side cannot tell "this road is blocked" from "he does not want to do it," and by ordinary human nature only the second is left. From then on he stops bringing you his ideas to look over. The idea skips intake and goes straight to a budget, dies three months later, and the bill still gets charged to "AI does not work." What you lost is more than this project. It is the gate itself. The test. Read back the words you sent the last time you refused. If there is not one sentence in there about what evidence would reopen it, attitude is all the other side received.

Next Monday

Take the three projects your team took on most recently and run them back through the five dimensions plus three red lines after the fact. Which one should not have been taken? Where is it stuck on the outcome ladder (Chapter 1) now? That is your evidence that your organization needs intake.
Write down your three red lines and check where they live now. The ones living in the scoring sheet, move them out, list them separately, and mark them "any one vetoes."
Build the kill register (Template 25.4). Add the candidates you said "no" or "let us look again" to in the past six months, fill in a revival condition for each, and send it back to the proposer.
Think back to the last time you refused. If you gave no condition, add a line now and send it. "What evidence, if it appears, makes this worth reopening."

Want an agent to get you started? In the repo you set up following Start Here, paste this to your coding agent:

In the repo/ directory of the the-last-mile repository, help me with the Chapter 25 Next Monday actions. First run python3 templates/intake/revival_reminder.py
with the built-in sample to show the reminder for a revival condition coming due, then copy intake-scorecard.md into the working directory I name. The three projects the team
took on most recently I score myself on the five dimensions plus three red lines. You only build the sheet and keep the record, and which one should not have been taken is
mine to judge. The three red lines are mine to write, and you check whether they are listed separately and marked "any one vetoes." Build the kill register per 25.4. The
revival condition on each row is mine to fill in, and who it goes back to is mine to decide. If any command errors, stop and show me the output.

Chapter Kit

Judgment frameworks. The organization-level intake rubric (five dimensions, strategic value / data readiness / owner in place / production path / reuse potential; three red lines, automated decisions at an irreversible-harm step / a move of decision rights with no human oversight capacity behind it / outward-facing output in a regulatory grey zone, any one vetoes, none of them scored); the three steps to no (affirm the goal → state the evidence → offer a path)
Templates. Template 25, Intake Rubric, Red Line List, Saying No Scripts, Kill Register
Key judgments
"Translate refusal from a relationship event into a judgment event."
"Wait for the demo to say no and sunk cost has already taken everyone hostage."
"A no must come with the conditions for a yes. An unconditional 'no' is a refusal. A conditional 'no' is a roadmap."
"Once a red line is in the scoring sheet, it is no longer a red line."