-
Notifications
You must be signed in to change notification settings - Fork 6
Ariya4
Ariya4 is FPCOS's four-field problem frame. It is derived from the Four Noble Truths structure — a logical framework for identifying suffering, its cause, its cessation, and the path to that cessation — adapted as a universal problem-solving compass.
The core principle: You cannot solve a problem correctly until you can state it correctly. Most failed solutions solve the symptom, not the cause — because the problem was never properly framed before the solution was proposed.
All four fields are required before any solution is proposed. If any field cannot be completed, the problem is not yet understood. Do not proceed — return to L0 and re-anchor.
Problem : [what is actually broken — not the symptom or label]
Cause : [root cause — constraints, incentives, feedback loops at play]
Cessation : [what does true resolution look like — definition of done]
Path : [least-friction route from Problem to Cessation]
What is actually broken — not the symptom or the label given to it.
The problem statement must describe the causal gap, not the observable effect. If the problem statement can be satisfied by addressing the symptom without touching the root cause, it is not yet a problem statement — it is a symptom description.
Wrong (symptom): "Our customer churn is too high" Right (problem): "Customers are not reaching the activation event within the first 7 days, so they leave before experiencing core value"
The correct problem statement points directly at where the solution must intervene.
Root cause — the constraints, incentives, or feedback loops that produce the problem.
Root cause is not the event immediately before the symptom. It is the structural condition that makes the problem recurring. If removing the cause would prevent the problem from reoccurring — it is the root cause. If the problem would return despite the fix — it is a contributing factor, not the root.
Wrong (proximate): "Our onboarding email open rate is low" Right (root cause): "The onboarding sequence triggers before users have completed any action, so the emails arrive before users have context to understand why they matter"
Common cause categories:
- Structural constraints — the system cannot do X because Y is hard-coded
- Incentive misalignment — the people closest to the problem are not rewarded for solving it
- Feedback loop — a reinforcing (R) loop is compounding the problem
- Information gap — decisions are made without the data that would change them
- Capability gap — the solution requires skills or resources that don't exist
What does true resolution look like — definition of done.
Cessation is not "improvement." It is the state in which the cause no longer operates. It must be specific enough to be falsifiable — you must be able to say whether cessation has occurred.
Wrong (vague): "Better onboarding" Right (specific): "≥60% of new users reach activation event within 7 days, measured weekly for 4 consecutive weeks"
Cessation defines the target. Without it, any improvement can be declared success — and the root cause continues to compound below the surface.
Least-friction route from Problem to Cessation.
Path is not a brainstorm of possible interventions. It is the single sequence of actions, given current constraints identified in L2 (System Lens) and current solution options mapped in L3 (Compound Mind), that reaches Cessation with minimum energy expenditure.
"Least-friction" means: fewest dependencies, fewest new resources required, fewest assumptions about future states, most direct causal link between action and Cessation.
The four fields function as a compass because they are directionally ordered:
- You cannot know the Path without knowing the Cessation
- You cannot know the Cessation without knowing the Cause
- You cannot know the Cause without correctly stating the Problem
Working backwards from Path to Problem is how most failed problem-solving operates — the solution comes first, then the problem is reverse-engineered to justify it. Ariya4 forces the correct direction.
| Failure | Detection | Consequence |
|---|---|---|
| Symptom stated as Problem | Problem statement satisfied by symptomatic fix | Solution works short-term, root cause compounds |
| Effect stated as Cause | Removing the "cause" doesn't prevent recurrence | Problem returns, team loses confidence in solutions |
| Vague Cessation | Cannot tell if resolution occurred | Any improvement declared success, root cause persists |
| Path chosen before Cessation defined | Solution optimized for the wrong target | High effort, wrong outcome |
When building a skill on FPCOS, Ariya4 is inherited as the problem-framing protocol. The most common anti-pattern:
"Skip Ariya4 for obvious problems where the solution is already known."
Why this fails: "Obvious" problems are the highest-risk category for symptom-as-cause errors. The solution feels obvious because the problem is familiar — but familiarity with the symptom is not the same as understanding the cause. The Mirror protocol in L4 specifically catches this by surfacing the hidden assumption in the framing.
- L1-Axiom-Gate — Where Ariya4 runs in the pipeline
- Kalama10 — The companion proof standard
- L4-Shadow-Gate — Mirror protocol catches Ariya4 failures that escape L1
# Ariya4 — Problem Frame
[← Back to Home](Home)
Ariya4 is FPCOS's four-field problem frame. It is derived from the Four Noble Truths structure — a logical framework for identifying suffering, its cause, its cessation, and the path to that cessation — adapted as a universal problem-solving compass.
The core principle: You cannot solve a problem correctly until you can state it correctly. Most failed solutions solve the symptom, not the cause — because the problem was never properly framed before the solution was proposed.
All four fields are required before any solution is proposed. If any field cannot be completed, the problem is not yet understood. Do not proceed — return to L0 and re-anchor.
Problem : [what is actually broken — not the symptom or label]
Cause : [root cause — constraints, incentives, feedback loops at play]
Cessation : [what does true resolution look like — definition of done]
Path : [least-friction route from Problem to Cessation]
What is actually broken — not the symptom or the label given to it.
The problem statement must describe the causal gap, not the observable effect. If the problem statement can be satisfied by addressing the symptom without touching the root cause, it is not yet a problem statement — it is a symptom description.
Wrong (symptom): "Our customer churn is too high" Right (problem): "Customers are not reaching the activation event within the first 7 days, so they leave before experiencing core value"
The correct problem statement points directly at where the solution must intervene.
Root cause — the constraints, incentives, or feedback loops that produce the problem.
Root cause is not the event immediately before the symptom. It is the structural condition that makes the problem recurring. If removing the cause would prevent the problem from reoccurring — it is the root cause. If the problem would return despite the fix — it is a contributing factor, not the root.
Wrong (proximate): "Our onboarding email open rate is low" Right (root cause): "The onboarding sequence triggers before users have completed any action, so the emails arrive before users have context to understand why they matter"
Common cause categories:
- Structural constraints — the system cannot do X because Y is hard-coded
- Incentive misalignment — the people closest to the problem are not rewarded for solving it
- Feedback loop — a reinforcing (R) loop is compounding the problem
- Information gap — decisions are made without the data that would change them
- Capability gap — the solution requires skills or resources that don't exist
What does true resolution look like — definition of done.
Cessation is not "improvement." It is the state in which the cause no longer operates. It must be specific enough to be falsifiable — you must be able to say whether cessation has occurred.
Wrong (vague): "Better onboarding" Right (specific): "≥60% of new users reach activation event within 7 days, measured weekly for 4 consecutive weeks"
Cessation defines the target. Without it, any improvement can be declared success — and the root cause continues to compound below the surface.
Least-friction route from Problem to Cessation.
Path is not a brainstorm of possible interventions. It is the single sequence of actions, given current constraints identified in L2 (System Lens) and current solution options mapped in L3 (Compound Mind), that reaches Cessation with minimum energy expenditure.
"Least-friction" means: fewest dependencies, fewest new resources required, fewest assumptions about future states, most direct causal link between action and Cessation.
The four fields function as a compass because they are directionally ordered:
- You cannot know the Path without knowing the Cessation
- You cannot know the Cessation without knowing the Cause
- You cannot know the Cause without correctly stating the Problem
Working backwards from Path to Problem is how most failed problem-solving operates — the solution comes first, then the problem is reverse-engineered to justify it. Ariya4 forces the correct direction.
| Failure | Detection | Consequence |
|---|---|---|
| Symptom stated as Problem | Problem statement satisfied by symptomatic fix | Solution works short-term, root cause compounds |
| Effect stated as Cause | Removing the "cause" doesn't prevent recurrence | Problem returns, team loses confidence in solutions |
| Vague Cessation | Cannot tell if resolution occurred | Any improvement declared success, root cause persists |
| Path chosen before Cessation defined | Solution optimized for the wrong target | High effort, wrong outcome |
When building a skill on FPCOS, Ariya4 is inherited as the problem-framing protocol. The most common anti-pattern:
"Skip Ariya4 for obvious problems where the solution is already known."
Why this fails: "Obvious" problems are the highest-risk category for symptom-as-cause errors. The solution feels obvious because the problem is familiar — but familiarity with the symptom is not the same as understanding the cause. The Mirror protocol in L4 specifically catches this by surfacing the hidden assumption in the framing.
- L1-Axiom-Gate — Where Ariya4 runs in the pipeline
- Kalama10 — The companion proof standard
- L4-Shadow-Gate — Mirror protocol catches Ariya4 failures that escape L1
[← Back to Home](Home)