Why this matters in Ontic
Ontic treats problem targeting as a first-order constraint. Before a system can collect state, authorize action, or emit a claim, it must locate the generating condition of the observed failure. That stance is not a general "be thoughtful" guideline—it is a hard governance gate enforced in the stack. We call this Mondai Ishiki (problem consciousness). When the generating condition can be removed so the original question becomes irrelevant, we prefer Kadai Barashi (problem dissolution) over perpetual solution refinement.
Both terms are embedded in Doctrine and the RFCs, but the intuition comes from a long-running leadership and management culture: do not optimize the wrong layer, and do not solve a problem that should be dissolved.
Mondai Ishiki: problem consciousness as a leadership discipline
In Japanese leadership and management contexts, mondai ishiki is the cultivated habit of seeing the actual problem, not its most visible symptoms. It is used to counter two common failure modes:
- Symptom fixation: teams improve the surface issue (faster UI, more rules, bigger prompt) while the causal layer remains untouched.
- Mislocalized effort: decisions are made with incomplete causal alignment, leading to local “wins” that don’t change outcomes.
The discipline is not just analytical—it is organizational. It changes how teams:
- Frame objectives (problem statement precedes solution design)
- Allocate authority (who can assert the causal layer)
- Sequence work (causal discovery before execution)
In Ontic terms, that leadership habit becomes a deterministic gate: no intervention may be authorized until the generating condition is identified.
Kadai Barashi: dissolution over refinement
Kadai barashi is not “fix the bug.” It is “remove the conditions that generate the bug.” In management settings, this manifests as:
- Altering the upstream incentive that creates the downstream failure
- Redesigning a process so the issue no longer arises
- Removing ambiguous objectives that force teams into contradictory execution
The standard is strict: if the condition is removed, continuous monitoring becomes unnecessary, and the original question becomes irrelevant. In Ontic, that is a superior outcome to repeated solution refinement, because it collapses the failure mode entirely.
How Ontic applies these concepts
Ontic does not treat these ideas as metaphors. It encodes them into governance mechanics:
1) Causal ascent before state collection
If the problem layer is ambiguous, state collection is premature. The system should return a causal ambiguity status and ask upstream questions—e.g., don't start logging every token or API call when the real ambiguity is whether this is a model-misuse issue or a policy-design issue. This is Mondai Ishiki operationalized.
2) Symptom detection heuristics
When a request shows repeated patching, escalating rule complexity, or persistent failure despite "progress," the system should flag a mislocalized intervention. These are observable signals in tickets, configs, and logs: repeated rule edits, chained exceptions, escalating prompt length. That is a direct translation of leadership warning signs into machine governance.
3) Dissolution-first outcomes
If a generating condition can be removed, the system should prefer that path over optimizing within the broken frame. This is Kadai Barashi as a routing priority.
4) Problem targeting is a gate, not advice
Ontic’s Doctrine I and RFC-0000 make this non-optional. A system that proceeds without causal alignment is, by definition, out of compliance.
Practical translation for AI governance
Here is the applied pattern, stripped of jargon:
- Identify the generating layer before collecting data or authorizing action.
- Refuse optimization when the problem framing is ambiguous.
- Prefer dissolution when removal of the generating condition is possible.
- Track symptom churn as a signal of mislocalized intervention.
This is how Ontic converts leadership discipline into executable governance. The intent is not cultural decoration; it is structural safety. When you make problem consciousness a hard gate, you prevent entire categories of downstream error.
How this shows up in the stack
- Doctrine I defines the law: action at the wrong causal layer fails regardless of local correctness.
- RFC-0000 implements the enforcement mechanics and response modes.
- Glossary entries encode the terms for precision across policy and engineering.
This lets policy, product, and engineering talk about "wrong causal layer" as a first-class failure mode—not a vague critique, but a specific status that triggers specific responses.
In short: Mondai Ishiki keeps the system honest about what it is solving. Kadai Barashi keeps it honest about whether the problem should exist at all.