3.1 · Separate obligations from inherited constraints
Chapter 3: Constraints and Principles
Watch the chapter or work through its reading pages at your own pace.
Chapter 3 follow-along PDF · Development edition. This chapter’s PDF may be updated with future revisions.
Reading pages in this chapter
Chapter 3 · Page 1 of 2
Separate obligations from inherited constraints
Learning objective: Challenge a constraint without discarding its legitimate purpose or exceeding decision authority.
Constraints differ in origin and in who can change them. A physical dependency, an applicable regulation, a current contract, an internal policy, a system configuration and a team habit are not interchangeable. The redesign team should identify the source and the person authorized to interpret or change it.
A constraint can be binding for this project without being universal. If a current agreement requires a particular approval, retain it until an authorized change is made. The team can explore alternative designs conditional on that change, but must label them accordingly. Brainstorming does not grant operating authority.
Use a purpose-to-mechanism ladder. Start with the stated rule, find its intended protection, identify the evidence that the protection works, and ask what other mechanisms might provide equivalent or better protection. For example, a monthly committee might exist to prevent unauthorized commitments. Its meeting cadence is a mechanism; authorized commitment is the control objective. The committee may also provide exception judgment that a simple threshold would miss.
Do not assume the written rule has only one purpose. Ask its owner about accountability, segregation of duties, auditability, customer promises and failure recovery. Then state exactly what can be changed within the team’s remit and what requires a separate decision. Keep unresolved interpretations in the constraint register.
One practical classification is: fixed within this exercise; changeable by a named owner; unverified; or chosen by this team. Every fixed constraint should carry its scope and source. Every unverified constraint should have a resolution action. If a critical constraint cannot be resolved, keep the affected proposal conditional and avoid a live test that depends on removing it.
Regulations are constraints with a defined source and scope
Aerospace, transportation and medical devices have sector-specific regulatory requirements. Identify the jurisdiction, product or service, activity, current requirement and competent interpretation before deciding what applies. A team preference, internal policy and external legal obligation have different authority.
For each requirement, record its source and version, applicability, required outcome or prescribed method, compliance evidence and responsible expertise. First principles thinking helps separate the obligation from the inherited implementation. It does not give a project owner permission to waive an external requirement.
Consider alternatives only within the permitted design space. Where the requirement prescribes a method, changing the method may require a formal route rather than an internal decision. Keep an unresolved interpretation visible and the dependent proposal conditional.
Source examples
- FAA regulations and policies — U.S. aviation source locator.
- U.S. Department of Transportation regulatory information — identify the relevant transport agency.
- FDA overview of device regulation — U.S. medical device overview.
Practice
A manager says all new suppliers must wait for a weekly committee. In W4, separate the committee, its timing, supplier eligibility, authority and retained evidence. Write two questions for the policy owner and one conditional alternative that preserves the underlying control.
Check your reasoning
Can a team remove a control because it has not observed any failures?
Worked response
Not on that basis alone. The control may explain the absence of failures, or failures may be rare or poorly measured. Establish its purpose, applicable authority, risk and an authorized way to test alternatives.
Read-along slides and narration script
3.01 · Constraints and Principles
Welcome to Colabmo.
I'm Diggy Breiling, founder of Colabmo. Welcome to First Principles Thinking for Business Process Redesign. This is chapter three, Constraints and Principles.
In this chapter, we'll examine constraints and develop principles that a redesign must satisfy.
3.02 · Different kinds of constraints
We begin with constraints and authority.
We will examine the basis for a constraint, separate a control’s purpose from its current mechanism, and write principles that guide a redesign.
Constraints differ in origin and in who can change them. A physical dependency, an applicable regulation, a current contract, an internal policy, a system configuration and a team habit are not interchangeable. The redesign team should identify the source and the person authorized to interpret or change it.
Regulations are an important example. Aerospace, transportation and medical devices each have specific regulatory requirements. What applies depends on the product or service, the activity and the jurisdiction. In the United States, useful starting points include the FAA for aviation, the relevant transportation agency, and the FDA for medical devices.
First principles thinking does not make a regulation optional. Identify the actual requirement, its scope and the evidence needed to show it is met. Work with the appropriate regulatory expertise. Then separate what the rule requires from the way your organization has chosen to meet it. Some requirements prescribe a method; others leave design choices open.
3.03 · Control purpose and mechanism
A constraint can be binding for this project without being universal. If a current agreement requires a particular approval, retain it until an authorized change is made. The team can explore alternative designs conditional on that change, but must label them accordingly. Brainstorming does not grant operating authority.
Use a purpose-to-mechanism ladder. Start with the stated rule, find its intended protection, identify the evidence that the protection works, and ask what other mechanisms might provide equivalent or better protection. For example, a monthly committee might exist to prevent unauthorized commitments. Its meeting cadence is a mechanism; authorized commitment is the control objective. The committee may also provide exception judgment that a simple threshold would miss.
3.04 · Authority to change
Do not assume the written rule has only one purpose. Ask its owner about accountability, segregation of duties, auditability, customer promises and failure recovery. Then state exactly what can be changed within the team’s remit and what requires a separate decision. Keep unresolved interpretations in the constraint register.
One practical classification is: fixed within this exercise; changeable by a named owner; unverified; or chosen by this team. Every fixed constraint should carry its scope and source. An internal policy owner cannot simply waive an external legal requirement; resolve its applicability and any permitted alternatives through the appropriate authority. Every unverified constraint should have a resolution action. If a critical constraint cannot be resolved, keep the affected proposal conditional and avoid a live test that depends on removing it.
3.05 · W4: a weekly supplier committee
Now apply the reasoning. A manager says all new suppliers must wait for a weekly committee. In W4, separate the committee, its timing, supplier eligibility, authority and retained evidence. Write two questions for the policy owner and one conditional alternative that preserves the underlying control.
Pause the video while you work. Before resuming, record your answer to this question: Can a team remove a control because it has not observed any failures?
When you return, compare your reasoning with this explanation. Not on that basis alone. The control may explain the absence of failures, or failures may be rare or poorly measured. Establish its purpose, applicable authority, risk and an authorized way to test alternatives.
Chapter 3 · Page 2 of 2
Write principles that can guide a design
Learning objective: Construct bounded principles with explicit premises and avoid turning preferences into universal truths.
A useful working principle states what any acceptable design must accomplish and why. “Use one portal” is a solution. “A decision maker must have the relevant evidence before making the decision” identifies a dependency. Its application still depends on defining relevant evidence and decision scope.
Regulatory connection: Derive a principle from the applicable requirement and its scope. If a regulation prescribes a method, preserve that method unless an authorized alternative applies. If it specifies an outcome, compare permitted mechanisms and the evidence each would require. Record the regulatory source separately from your interpretation and any unresolved assumptions.
Use this structure: Because these supported premises apply, any acceptable design within this boundary must satisfy this condition. Then add the scope, exceptions and unresolved assumptions. Principles should be few enough to use during design reviews and specific enough to rule out an inadequate proposal.
For the fictional onboarding case, the team might reason: the service must know which legal entity it is serving; the current agreement requires authorization before activation; therefore any acceptable activation design must associate the right entity with an authorization record before activation. This does not establish who types the data or whether checks are sequential.
A principle needs a challenge test. Can you give a plausible acceptable design that violates it? If so, revise the principle, narrow its scope or reclassify it as a preference. Also ask whether the principle is circular. “We need approval because approval is required by the process” explains the current process, not its necessity.
Stop decomposition when the team has premises adequate to distinguish the candidate designs, understands material uncertainty, and can specify tests for that uncertainty. You do not need a philosophical proof of every organizational purpose. You do need to prevent an unsupported premise from silently deciding the design.
Adjacent guidance can improve the discipline without replacing FPT. NASA’s requirements checklist asks whether assumptions are correct and whether requirements avoid unnecessary implementation specifics. Here, that distinction helps separate a needed result from a favored mechanism.
Practice
Use W5 to derive three principles from the onboarding functions. For each, provide two premises, the reasoning connecting them to the principle, and one potential counterexample. Have another pair try to falsify the principle without violating the agreed outcome.
Check your reasoning
Is “Customers must never enter information twice” a sound first principle?
Worked response
It is an attractive design preference, but too absolute. Confirmation, correction or independent verification may be necessary. A stronger bounded condition identifies which data must be accurate, available and traceable, then evaluates how to obtain it with justified effort.
BrightPath: what must every design preserve?
The requirement and the current method
BrightPath is a fictional teaching case. Its candidate outcome is relevant guidance whose limits the client understands, with an appropriate next step for the stated workplace-learning need. Validate that outcome with users. The supplied case conditions require applicable guidance to have an identified material basis and uncertainty, appropriate use of client information, and an owner with relevant competence. They allow clarification, a conditional answer or referral. None establishes a universal 45-minute consultation.
| Statement | Status and basis | Design implication |
|---|---|---|
| Every client currently books a 45-minute consultation | Supplied description of the current method | Investigate which functions the meeting performs; its existence does not establish necessity |
| Advice needs explainable fit to the stated situation | Required property derived from the candidate outcome and supplied case conditions | Establish relevant context and identify material uncertainty before claiming applicability |
| A written exchange can clarify an ambiguous need | Hypothesis, with an unknown applicability boundary | Test with intended users and realistic requests; include users unable to use the default channel |
| Only a live meeting can establish trust | Unsupported generalization | Ask which observable behaviors matter: understandable reasoning, candid limits and reliable follow-through |
Trace the principle to a part and its properties
Part: recommendation. Required property: explainable fit. Supporting functions: establish context, apply relevant expertise and expose consequential uncertainty. Bounded principle: before representing guidance as applicable to this need, identify material context and uncertainty; clarify, qualify or refer when the gap could change the advice. Dependency: usable information and a competent owner. Exception: if that basis cannot be established, communicate the limitation and the recovery or referral path rather than marking the request resolved.
Apply the challenge test to the principle itself. A conditional response with explicit limits can be acceptable; demanding complete knowledge of every aspect of the client's situation would be an excessive requirement. A design that quietly treats an unresolved material gap as settled fails the supplied condition. A live conversation and an asynchronous exchange must each show how they preserve the function.
W5 connection · within a five-minute explanation and practice block
Write one principle, identify its supplied basis, state its scope, and test it against two mechanisms. Record one acceptable exception and who owns it. The team may redesign intake, channel, scheduling and clarification. It cannot promise new expertise or a response-time guarantee without the service owner's decision.
Debrief after your attempt
A defensible answer preserves meaningful clarification and ownership while leaving the channel open. A statement such as “everyone must use the new portal” has already chosen a mechanism. A statement such as “collect all possible information” needs a narrower scope and a reason for each requested item.
References and their limits
GOV.UK Service Manual — Learning about users and their needs. Supports investigating needs with users and distinguishing their problem from a proposed solution. Public-service guidance is used as a learning reference, not as an obligation imposed on BrightPath.
BrightPath and its observations are original fictional Colabmo teaching material. Sources support the methods; they do not establish case facts or achieved results. References checked 18 October 2026.
Read-along slides and narration script
3.06 · A working principle
We now begin the section on Principles that guide a redesign.
A—a useful working principle states what any acceptable design must accomplish and why. “Use one portal” is a solution. “A decision maker must have the relevant evidence before making the decision” identifies a dependency. Its application still depends on defining relevant evidence and decision scope.
Use this structure: Because these supported premises apply, any acceptable design within this boundary must satisfy this condition. Then add the scope, exceptions and unresolved assumptions. Principles should be few enough to use during design reviews and specific enough to rule out an inadequate proposal.
3.07 · BrightPath: what must every design preserve?
Let’s bring this back to BrightPath. What do we actually need to preserve if we change the way advice is delivered?
The current process says everyone gets a forty-five-minute meeting. That tells us what happens today. It doesn’t explain why every client needs that meeting.
Look at the recommendation as one of our pieces. A property we need is a fit to the client’s situation that we can explain. To support that, we need enough context and a way to deal with anything important we don’t know.
So—so here’s a working principle: before we present advice as suitable, we need to identify the context and uncertainty that could change it. If something important is missing, we clarify it, qualify the advice, or refer the client to someone who can help.
A conversation might do that. A written exchange might do it too. We haven’t chosen the channel yet.
Now challenge the principle. Could a client receive useful, appropriately qualified guidance without a meeting? If so, the meeting isn’t necessary in every case. But could we knowingly ignore a gap that changes whether the advice fits? That would conflict with our case conditions.
In W5, write your principle, its basis and its limits. Then try it against two different ways of delivering the service.
3.08 · Principles without a favored tool
For the fictional onboarding case, the team might reason: the service must know which legal entity it is serving; the current agreement requires authorization before activation; therefore any acceptable activation design must associate the right entity with an authorization record before activation. This does not establish who types the data or whether checks are sequential.
A principle needs a challenge test. Can you give a plausible acceptable design that violates it? If so, revise the principle, narrow its scope or reclassify it as a preference. Also ask whether the principle is circular. “We need approval because approval is required by the process” explains the current process, not its necessity.
3.09 · The challenge test
Stop decomposition when the team has premises adequate to distinguish the candidate designs, understands material uncertainty, and can specify tests for that uncertainty. You do not need a philosophical proof of every organizational purpose. You... you do need to prevent an unsupported premise from silently deciding the design.
Adjacent guidance can improve the discipline without replacing FPT. NASA’s requirements checklist asks whether assumptions are correct and whether requirements avoid unnecessary implementation specifics. Here, that distinction helps separate a needed result from a favored mechanism.
3.10 · W5: three principles
Now apply the reasoning. Use W5 to derive three principles from the onboarding functions. For each, provide two premises, the reasoning connecting them to the principle, and one potential counterexample. Have another pair try to falsify the principle without violating the agreed outcome.
Pause the video while you work. Before resuming, record your answer to this question: Is “Customers must never enter information twice” a sound first principle?
When you return, compare your reasoning with this explanation. It is an attractive design preference, but too absolute. Confirmation, correction or independent verification may be necessary. A stronger bounded condition identifies which data must be accurate, available and traceable, then evaluates how to obtain it with justified effort.
Keep your constraints and principles visible. The next chapter uses them to develop alternatives with different operating mechanisms.
3.11 · Next: Rebuilding the Process
You’ve completed chapter three, Constraints and Principles, in First Principles Thinking for Business Process Redesign.
Thank you for learning with Colabmo. Bring your expertise, keep your reasoning visible, and put what you’ve learned to work.
Scroll within the reading area. Use the page buttons above to review within this chapter. The course sidebar and Prev / Next buttons open another course page.
There are no comments for now.
to be the first to leave a comment.