Find the constraints that can invalidate the pilot before building it

This is lesson 2 of The FDE Engagement. Test the constraints that could invalidate the proposed workflow, before spending on dependent work. Keep multiple risks visible. Access, ownership, security, cost and the success definition can interact, and none of them has to be the single cause of failure.

You have a record of the customer's request, and the commitments made on the call. Now turn the unresolved questions into a short sequence of feasibility checks.

Find the decision before ranking the risk. A missing credential isn't necessarily a blocker. It becomes one when no approved path can provide the required data before the work that depends on it.

A weekly refresh may be enough for a planning report, and useless for a fifteen-minute exception workflow. So describe the required behavior first, then test whether the available path can deliver it.

Some constraints are knowable early. Others emerge when requirements or environments change. The purpose of discovery is to reduce preventable uncertainty, not to promise that week one can reveal every future problem. So record the evidence date, so a later change can be told apart from a question nobody asked.

A premortem is one way to generate candidates. A published project-premortem method asks participants to imagine failure, and identify plausible causes, and you collect those possibilities independently, then turn them into checks. They're hypotheses, not findings. The AHRQ premortem tool similarly moves from imagined failure reasons to mitigation planning.

The five categories that follow are a starting list for this course, not measured shares of failed engagements.

Five constraints to test. First, usable data access. Does the required information exist, and can the intended service read it at the necessary freshness?

Ask for a sample through the proposed route, with timestamps and the fields the workflow actually needs. A manual export in an email doesn't establish recurring service access. And if the data doesn't exist, distinguish collecting it from merely granting a credential.

There's a documented example of how this can consume a pilot: Reflections on Palantir, from 2024, describes pilots whose time was consumed by data-access negotiations, leaving a rushed demonstration at the end. That's one author's account of particular experiences, not a frequency estimate, and the practical response is to make an access check an early dependency, with an explicit decision date.

Second, operating ownership. Identify who uses the result, who can change the process, and who handles an unresolved case. A buyer may own the budget while another team owns the queue. If those responsibilities are split, schedule the joint decision. Don't assume the buyer can commit the other team's working hours.

Third, security and approval constraints. Obtain the relevant policy, and a named reviewer. "Nothing has ever been approved" and "this design is forbidden" are different statements. Confirm the data class, the permitted processing location, and the outbound-call rules.

A VPC, meaning a private network segment inside a cloud provider, isn't a universal answer. An external model call can still move data outside the allowed boundary, even if the application runs in a private subnet.

Fourth, unit economics. Define the value per completed unit, and the allowable total cost, before choosing an expensive path. Include retries, review and allocated infrastructure where they're relevant. Time released for other work isn't automatically cash saved, and a buyer's estimate needs a measurement plan.

Freed hours become money only when a role isn't filled, a hire is avoided, or the time goes to work someone would otherwise pay for. Until then, the saving is capacity, and capacity has to be measured as output.

Fifth, an agreed decision rule. Stakeholders can care about different outcomes, without making the project impossible. Write the primary outcome, and the constraints that must also hold. For example, faster shipment identification can be the outcome, while no unauthorized refunds and an affordable review queue are requirements, and you ask the decision owner how conflicting results will be resolved.

Now calculate the cost ceiling, without hiding the assumptions. This synthetic planning envelope is separate from later course budgets.

Assume 100,000 completed units a day, a value estimate of 2 cents per completed unit, and a buyer-selected maximum tool cost of 20% of that value. Assume all units complete for this first calculation. Failure and retry costs would have to be added to a real ledger.

Estimated daily value is 100,000 times 2 cents, which is 2,000 dollars. The daily cost budget is 20% of that, 400 dollars. Divided over 100,000 units, the per-unit ceiling is 0.4 cents.

Design A makes one model call per unit, at 3 cents. That's 3,000 dollars a day. Design B uses rules at 0.1 cents per unit, and the model on 5%, so it's 100,000 times 0.1 cents, plus 5,000 calls at 3 cents, which is 250 dollars a day. These are invented exercise prices, not current vendor prices.

Design B fits the supplied machine-cost budget, with 150 dollars a day remaining for other costs, but that isn't proof it fits the total budget, or meets quality requirements. And the claim that rules settle 95% of the work still needs evidence.

Change the escalation share to 20%. Machine cost becomes 100 dollars plus 600, which is 700 dollars a day, over the 400 dollar budget before any review. If every other cost were zero, the break-even escalation share would be 10%, because 0.1 plus the share times 3 must equal 0.4 cents, so the share is 0.3 divided by 3. Any additional costs lower that allowable share.

This is the question to settle before a prototype makes the costly path feel inevitable.

Request evidence that can change the plan. For the freight pilot, the lesson uses a synthetic constraint register to select the next checks.

For fifteen-minute freshness, the evidence is a daily export only, so the decisive check is the platform owner demonstrating an approved fresh read, with record timestamps, and if it stays unresolved, you test historical lookup only, and defer the live latency claim. For refund authority, the operator lead must approve, so get a written action boundary and reviewer workflow, and otherwise, no automated refunds.

For contract identity, the portal and transport identifiers differ, so reconcile a defined sample, keeping the unresolved cases, and if that fails, limit the work to verified mappings, or stop matching work. And for operator availability, two operators are offered with their hours unconfirmed, so get a named schedule and review budget, or reduce the experiment load and move the date.

Prioritize the checks that could invalidate the next expensive step, since a one-hour access test may be worth doing before a week of model tuning. Don't assign invented probabilities to make the register look quantitative. Use observed evidence, a clear impact and a dated check, and record uncertainty where no estimate is defensible.

Inspect previous attempts, without assuming the cause persists. Ask whether someone already tried to solve the workflow, then request the repository, incident review or decision record.

Distinguish an old technical limitation from a still-active restriction. A rejected external service may say little about a locally hosted design. A failed identity mapping with the same source data is more directly relevant.

Interview the operator and the previous implementer where possible. Their accounts can disagree without either being dishonest, because one remembers a working demo, the other remembers the cases it excluded. Reconstruct the claim using an example and an observable failure, not the confidence of the narrator.

Finally, report the unresolved decision. State what constraint matters, what evidence would resolve it, who owns that decision, and what you recommend if it remains unresolved.

A narrower historical pilot may still be worth funding, provided its question has value on its own. Don't label it mitigation if it removes the very capability the buyer needs to decide on.

If no permitted alternative meets the requirement, recommend stopping this scope. Inventing a fallback to soften the message creates another unsupported promise. The decision record should make both the limitation and the cost already incurred visible.

Your turn. Pause the video here. Take the constraint register, and choose the first two checks for a two-week historical lookup demonstration. Explain which planned work each check unlocks. Then change the buyer's condition: no funding unless the pilot proves live fifteen-minute handling. Decide whether the daily-export fallback still answers the funded question. Also recompute Design B for a 20% escalation rate, and name two costs missing from the envelope.

The lesson's worked review verifies usable exports and identifier reconciliation before building the lookup path, and confirms operator time in parallel, because the evaluation depends on it. A historical-only fallback doesn't prove live handling, so obtain an approved fresh path, or renegotiate or stop that scope. At 20% escalation the machine cost is 700 dollars a day, already over budget. Human review, retries and allocated infrastructure are examples of additional costs, and they can't rescue the deficit.

To recap. A constraint is a blocker relative to a specific workflow, date and approval boundary, so use access, ownership, security, cost and success criteria as prompts, and keep interacting risks visible. Treat premortem ideas and previous-project stories as hypotheses to verify. A cheaper route needs measured coverage and total-cost accounting, not just a claimed escalation percentage, and a fallback must answer a worthwhile agreed question, or you recommend changing or stopping the scope.

That's lesson 2. Next in the series, write the pilot proposal around a decision you can actually test. The full lesson, with its exercise and drill, is on fdeinterviews.com.