Constraint Engine
Input a domain, profession, or role to identify the constraints that define it, and understand the solution space framed by these constraints—as well as how this solution space explains its various behaviors.
Workflow Routing
| Trigger | Workflow |
|---|
| Identify essential constraints for a domain, profession, role, or product | Execute the process outlined in this document, write a Chinese prose analysis, and save it as an org file |
| Analyze why a solution debate is unclear | First identify the default constraints of each party, then explain whether they are actually solving the same problem |
| Determine if a boundary is a true hard constraint or an old interpretation | Conduct three-level rigidity and authenticity qualification, do not rush to propose breakthrough solutions |
Gotchas
- Do not confuse constraints with ordinary difficulties, shortcomings, or suggestions. Constraints must alter the solution space; if removed, allowable behaviors will change.
- Do not focus solely on goals. The same goal with different constraints is not the same problem; complete the problem statement first before discussing solutions.
- Do not casually classify consensus, habits, or industry jargon as hard constraints. Hard constraints must pass the test: "Will the system collapse immediately if violated?"
- Do not rush to write "how to break constraints". First accurately describe the true rigidity of current constraints, identity boundaries, and behavioral explanatory power; mention loosening only briefly at the end.
- Do not mix identity constraints with strategic constraints. If removing a constraint does not change the essence of the entity, it is not an identity constraint.
Examples
Example 1: Analyze a Role
User: "What are the constraints of an investment manager?"
-> Identify constraints such as fund tenure, LP trust, information asymmetry, upside/downside distribution, etc.
-> Explain how these constraints drive behaviors like chasing hot trends, prioritizing consensus, fearing missed opportunities, etc.
-> Save to the org file in notes
Example 2: Analyze a Debate
User: "Why do product managers and growth teams always argue?"
-> First break down the default constraints of both parties: no user disruption vs. must improve conversion
-> Explain that while the goal seems to be building a good product, the actual problem statements are different
-> Then explain why each party's solution is rational within their own constraints
Example 3: Judge an Old Interpretation
User: "Must this industry prioritize sales?"
-> First determine if this is a world constraint, rule constraint, or industry interpretation
-> Check if players in other eras, regions have successfully operated beyond this
-> If they can survive beyond it, downgrade it to a soft or self-imposed constraint
What Are Constraints?
In daily language, constraints are negative—restrictions, lack of freedom, things you can't do. This engine does not view them this way.
Something without constraints has no shape. Water is formless without constraints; give it a cup and it takes shape. A problem has no solution without constraints; add constraints, and solutions emerge from infinity. Constraints do not reduce possibilities; they create specificity from infinity. Without constraints, anything is allowed, which means nothing is defined; with constraints, only certain things are allowed, which defines the entity as itself.
The same applies to problems. A problem is not just defined by goals, but also by constraints. When everyone says "build a product", but one person defaults to "no increased complexity" while another defaults to "must pursue growth", they are already solving different problems. The same goal with different constraints leads to different solution spaces; disputes over methods are often just misalignments.
Therefore, the constraints of an entity are its identity. Constraints are the set of equations that collapse infinite possibilities into "this one". Once this set of equations is complete, the framed solution space emerges—what the role can and cannot do, where the optimal choice lies, all determined by these constraints. The true value of finding constraints is not the list itself, but this solution space: it can explain every actual behavior of the role.
This engine is first and foremost descriptive, not transformative. The core questions are "What are the current essential constraints, what solution space do they frame, and what behaviors do they explain?" "How to do better, which can be loosened" is a secondary matter, and must not interfere with the initial diagnosis—if you rush to find an exit, you will fail to see the walls clearly.
A clear distinction from ljg-rank: ljg-rank digs downward to find the generative forces that produce phenomena ("what supports it"); constraint analysis reaches outward to find the boundaries that define it, and see what solution space these boundaries frame ("what shapes it and drives its behaviors"). One finds the foundation, the other finds the boundaries.
Three Levels of Rigidity: Which Layer Does This Constraint Belong To?
Constraints are not homogeneous; they vary in rigidity and weight. Distinguishing rigidity is the first step to accurately describing constraints.
Hard Constraints (World/Physical Layer)—Cannot be violated; attempting to violate them will cause system collapse. Humans die (time), speed of light cannot be exceeded, a company ceases to exist if cash flow is broken. There is no negotiation here. It does not punish you; the system simply stops.
Soft Constraints (Rules Layer)—Can be violated, but at a cost. Laws, licenses, contracts, industry norms. Violating them will not cause physical system collapse, but you will be punished by authorities or the market. This is a matter of cost, not possibility.
Self-imposed Constraints (Interpretation/Cognitive Layer)—Constraints you believe exist, but can be redefined. "I'm not good at this", "This industry has to be done this way", "What will others think". This layer exists in the mind, not in the real world.
Acknowledge those that cannot be violated; calculate the cost for those that can be violated; rewrite those that can be redefined—they should not be called fate. Most dilemmas are not caused by hard constraints, but trapped by self-imposed constraints—treating interpretation-layer things as world-layer facts. The most costly mistake in a domain is when someone treats a chalk line as a stone wall and绕着走了几十年. Determining the true rigidity of constraints is describing their real weight: whether they are truly unbreakable.
How to Find Them: The Process
Criteria can only be verified after the fact; the effort of finding constraints lies entirely in the process. Seven steps, completed mentally, not written into the article.
1. List Constraint Candidates. For the target domain/role, ask multiple questions to fully explore the boundaries:
- What is the goal of this problem? Which constraints, together with the goal, form the problem?
- If a constraint is replaced, will the problem become a different one?
- In this debate, do all parties share the same default constraints?
- Which thing taken for granted as background might just be an old interpretation?
- What cannot be done? What must be done? What cannot be avoided?
- Are rewards and consequences symmetric—who gets the gains, who bears the losses? Asymmetric incentives are one of the easiest-to-miss yet most behavior-explanatory constraints: if someone only gains upside without bearing downside, their optimal choice will lean toward directions others cannot afford.
- Who lacks information—where is information stuck? Information asymmetry is also a hard constraint; it often determines what the role is actually optimizing (visible signals or invisible reality).
- How fast does time move here, how long does it take for a result to materialize? Time scale is a constraint; if the assessment timeline differs from the result timeline, behavior will be pulled by the former.
List all ten-plus answers, just listing without judging. This step will inevitably be messy, mixing real and false boundaries.
2. Categorize by Layer. Assign each candidate to Hard/Soft/Self-imposed. Judgment question: If violated, will the system physically collapse (hard), will you be punished or pay a cost (soft), or will nothing actually happen—no one has tried it yet (self-imposed)? Be intentionally skeptical when categorizing—anything casually labeled "hard constraint" should be questioned first, as this layer is most prone to impostors.
3. Authenticity Qualification. For every constraint labeled as hard, ask: Who set this rule? If violated, will it truly cause physical collapse, or has no one tried it, been punished, or just gotten used to it? Add a historical check: Have players in other regions or eras already crossed this boundary? If they crossed it and survived, it is not a hard constraint, but a soft or self-imposed constraint mistakenly treated as hard. Note that this step is to more accurately describe the true rigidity of the constraint, not to guide "how to break it". It also explains why some players can break the rules—they saw it was just a chalk line. Qualification ends here; how to break it is a secondary matter later.
4. Identify Constraint Mismatches. If the input involves debates, solution comparisons, or route divergences, do not rush to judge who is right. Write down the default constraints of each party separately: one person defaults to "no increased complexity", another to "must pursue growth"; one defaults to "no user disruption", another to "must improve conversion". They think they are arguing over solutions, but they are actually arguing over problem statements. The same goal with different constraints leads to different solution spaces.
5. Find Constraint Conflicts. The real difficult problems are not just having constraints, but constraints that conflict with each other, where the solution space of satisfying all may be squeezed to empty. Pick out mutually exclusive constraint pairs, see where the solution space is squeezed and if it is empty. Empty solution spaces are often the root cause of a role's awkward, twisted, or seemingly irrational behaviors—it's not that they are stupid, but that there is no solution there, so they have to make twisted trade-offs.
6. Find Identity Constraints. Among all constraints, ask: Which one, if removed, would make the entity no longer itself? This is an identity constraint—the defining boundary of the domain. A restaurant becomes something else if it removes "deliver food to people in person"; a doctor is no longer a doctor if they remove "do no harm". Identity constraints are often in the hard constraint layer, but not always; sometimes a soft constraint is the true identity of the domain.
7. Finalize with Two Lenses.
- Function Theory: Constraints are the domain of function f. Which x can this role's f process, and which cannot—this is its constraint. See where it is framed by the domain, which x are out of reach—those unreachable areas are often the blind spots and gaps in its behavior.
- Evolution Theory: Constraints are selection pressure. The environmental constraints a species faces determine its form—without desert drought, camels would not have humps. See which selection pressures have shaped this role into its current form; what phenotypes the environment rewards and eliminates determines the direction of its behavior.
Only after completing these seven steps will the constraints be solid. The process is done mentally, not written into the article—readers won't see how you explored the boundaries, but they will feel that the analysis is grounded.
From Constraints to Solution Space to Behavior
Once constraints are identified, don't stop at the list. The explanatory power of constraints lies entirely in the solution space they frame. This section is the backbone of the engine, implemented in four steps.
Complete the Problem Statement. Combine goals and constraints. Do not only write "what it wants to do", but also "under what conditions it must do it". Once the problem statement is complete, many debates will disappear automatically: it turns out the solutions are different because the problems are different.
List the Constraint Set. Clearly present the constraints, each with its rigidity, which is the identity constraint, and which are conflicting. This is the system of equations.
Frame the Solution Space. When this set of constraints is combined, allowable behaviors are squeezed into a narrow range: what is feasible, what is excluded, where the optimal choice lies. Constraints and solutions are two sides of the same coin—complete the constraints, and the shape of the solution space emerges on its own.
Explain Actual Behaviors. This is the conclusion, and the most valuable part of the engine: the rational optimal behavior in the solution space should exactly match the repeated behaviors of the role in reality. Match them one by one—why it does this, why it doesn't do that, why the entire industry leans in one direction. If constraints are correctly identified, these "strange behaviors" will automatically emerge from the solution space, no need to assume anyone is stupid or malicious.
Readers will walk away with an interpreter: the various behaviors of this role are not due to personality or morality, but the inevitable result of being squeezed into this solution space by these constraints.
Internal Validation Criteria
After completing the process, review these criteria mentally, do not write them for readers.
- Explanatory Power (Primary Criterion)—Does the rational optimal behavior in the solution space match the actual behaviors observed in reality? If yes, the constraints are correctly identified; if not, it means a constraint is missing or misclassified by rigidity, go back to the process and dig deeper. This corresponds to "anti-generation" in ljg-rank—if constraints cannot generate the behaviors one by one, they are not correctly identified.
- Complete Problem Statement—Have you written both "goal + constraints"? If only goals are written, readers won't get the real problem.
- Visible Mismatches—If the original input is a debate, have you explained where the default constraints of each party differ? If not, the article may slip into solution judgment.
- Completeness—Can the combined constraints frame the entire solution space of the role? When a typical scenario is applied, does the outcome match?
- Accurate Layering—Is each constraint correctly categorized into World/Rules/Interpretation? Focus on reviewing the "hard constraint" category, as it is most prone to impostors.
- Courageous Authenticity Judgment—Have you dared to reclassify constraints labeled as hard into soft/self-imposed? (This is describing their true rigidity, not providing solutions)
- Unique Identity—If the identity constraint is removed, will the role truly cease to exist and become something else? If it remains the same, the identified constraint is not an identity constraint.
If any criterion fails, go back to the process. The most critical is the first one: if explanatory power doesn't match, everything else is useless.
Which Constraint to Loosen (Secondary, Not Part of Diagnosis)
The core of finding constraints is describing the current essence—what it is, what solution space it frames, what behaviors it explains. "How to do better" is another matter, secondary, and must not interfere with the initial diagnosis. Rushing to find an exit will make you fail to see the walls clearly—this is the most common mistake of this engine, must be avoided.
After diagnosis, you can add a brief note: which constraint in this set can actually be adjusted. When constraints conflict and the solution space is squeezed to empty, there are only three ways out—loosen one, redefine one, or elevate the perspective to find a solution invisible from the current view. The constraint classified as "soft/self-imposed" during authenticity qualification is the one that can be adjusted. Mention it briefly, do not overshadow the main content.
Innovation often happens here: not working harder within old constraints, but discovering that something everyone treats as a world boundary is actually just an old interpretation. Rewrite "humans cannot fly" to "humans cannot fly with only their bodies", and the problem changes, as does the solution space. If you write about loosening at the end, focus on this kind of redefinition: which is not fate, but a remnant of the old problem statement.
Chinese Nativization · Anti-Collapse Check
Before writing, repeat three times: 「Would a Chinese person who has never read English speak like this?」 Read each paragraph aloud after writing. If the answer is "No"—don't just change words, rewrite the entire paragraph.
Most common Anglicized mistakes (rewrite the entire paragraph if you make one, don't tweak words):
| Anglicized Expression | Native Chinese Expression |
|---|
| It is based on an assumption | It rests on an assumption |
| This constraint defines X | This constraint frames X into its current form |
| This implies... | That is to say... / This is why... |
| In the process of... | When... |
| For... | For... (natural phrasing) |
| Perform + noun | Replace with a verb |
| Nominalized abstractions ("constraintness", "boundarization") | Replace with specific verbs or objects |
Change not just words, but the frame of thinking—switch from English sentence structures to the tone of native Chinese prose writers (like Wang Zengqi, Wang Xiaobo, A Cheng, Li Juan). Read aloud after writing, listen for awkwardness. Rewrite entire paragraphs where it feels awkward, don't patch.
Another rule: This is analytical writing, not aggressive writing. Do not use meta-rhetoric like "this knife", "dig deeper", "sharp", "nail down" to feign strength. The strength of constraint analysis comes from accurate boundary exploration and thorough behavior explanation, not describing how hard you "strike".
How to Write It
A cohesive prose piece that takes readers on a journey—from "this role has many rules, some behaviors are strange" to "it turns out these few constraints squeeze it into such a narrow solution space, those strange behaviors are all inevitable". No chapters, no subheadings, let the reasoning advance on its own.
Three requirements:
- Can be read in one go—Even people unfamiliar with the domain can't stop reading
- Memorable—After reading, readers can explain it to a friend in one sentence: what constraints frame this role, so it can only behave this way
- Has a contrast—The contrast from "walls everywhere, behaviors hard to explain" to "a few constraints laid out, behaviors automatically emerge" is the beauty of constraint analysis
Follow the backbone structure: first complete the problem statement (goal + constraints), then thoroughly explain the constraint set and rigidity (what it is), then frame the solution space (what is feasible, where it is squeezed), and finally focus on explanatory power (how these constraints drive the role's actual behaviors)—this section is the core, write it in detail. If writing about a debate, let readers see that both parties started with different constraints. At most add one brief note on loosening at the end, stop there.
Attach an ASCII Structure Diagram at the End — Form Follows Framework
Just saying "these few constraints" is not enough; visualize the relationship between constraints and behaviors. Before drawing, ask: What shape is the relationship between this set of constraints and the behaviors they drive? Choose the drawing method based on the answer.
Hard Constraint: Use only pure ASCII characters. Disable any Unicode symbols (arrows → ← ↑ ↓, boxes ┌─┐└┘│, dots • ●, etc.). Allowed: letters, numbers, Chinese characters, spaces, and
- = | + * / \\ < > ^ v [ ] ( ) { } . , : ; _ #
. Use
for arrows,
for borders.
Three common forms, choose the one that best matches the relationship explored in the process. The core of the diagram is explanatory power—let readers see at a glance how behaviors are squeezed out by constraints.
1. Explanation Chain Diagram (Default)
Suitable for: Showing how constraints drive behaviors. This is the main diagram of the engine—Constraints -> Solution Space -> Actual Behavior.
Problem Statement/Constraint Set Solution Space Actual Behavior (Observed)
------------------------------ ------------ --------------------------
Goal: ...
[Constraint 1: ...] (Hard) --+
[Constraint 2: ...] (Soft) --+-- Squeezes into -> [Only X is feasible, -> [Role repeatedly does X]
[Constraint 3: ...] (Hard) --+ Optimal is X] Explanatory Power: Matches
Presentation Requirements: List specific constraints on the left, mark each with rigidity; the middle is the solution space squeezed by the constraint set (what is feasible, where the optimal lies); the right is the actual behaviors observed in reality. A single chain lets readers see that behaviors are the inevitable result of constraints. If the right does not match the left, constraints are not correctly identified—go back and dig deeper, do not force a mismatched chain.
2. Rigidity Nesting Diagram
Suitable for: Showing constraints divided into three layers by rigidity, to see which tightly bind the role and which only block it. The core of the diagram is the true distribution of rigidity + authenticity qualification.
+=========================================+
| Self-imposed Constraints (Cognitive Layer, actually soft) |
| - A rule treated as ironclad, but redefinable |
| +-----------------------------------+ |
| | Soft Constraints (Rules Layer, penalty for violation) | |
| | - Regulations / Contracts / Industry Norms | |
| | +---------------------------+ | |
| | | Hard Constraints (Physical Layer, collapse on violation) | |
| | | * Identity Constraint: The non-negotiable one | |
| | | - Time / Cash Flow / Physical Laws | |
| | +---------------------------+ | |
| +-----------------------------------+ |
+=========================================+
Presentation Requirements: Fill in specific constraints for each layer; mark the identity constraint (the one that breaks the role if removed) with
in the hard constraint layer; if a constraint was "mistakenly treated as hard but is actually soft/self-imposed" during authenticity qualification, place it in its true layer and add a note "often mistaken for hard constraint". This describes the true distribution of rigidity, not guides innovation.
3. Constraint Conflict Diagram
Suitable for: Conflicting constraints that squeeze the solution space to empty, used to explain why a role behaves awkwardly or twisted.
Constraint A: ... ----+
+---- Solution Space = Intersection (empty here)
Constraint B: ... ----+ => Role is forced to make twisted trade-offs: [specific awkward behavior]
Constraint C: ... ----+
Presentation Requirements: List mutually exclusive constraints, indicate where the intersection lies and if it is empty; empty solution spaces are exactly where you explain "why the role does seemingly irrational things"—mark that forced behavior. This uses conflicts to explain behaviors, not rush to provide solutions.
No rigid templates. Show the core—mark the names of constraints, their rigidity, where the identity constraint is, and most importantly: which behaviors are squeezed out by these constraints. Readers should understand why the role behaves this way at a glance.
Output
- Get timestamps: and
date "+%Y-%m-%d %a %H:%M"
- Write to
~/Documents/notes/{timestamp}--{domain}_constraints__constraint.org
- Report the file path to the user",