Observation
Something directly seen, heard, measured, or recorded, without adding a conclusion about its cause or meaning to the observation itself. An observation is not necessarily complete or certain and may still require further examination.
Menorad OS moves a problem through one continuous path from understanding to learning.
Menorad OS is not built around filling out a series of forms. Each stage is part of a coherent cycle that follows a problem from its initial definition through decision, action, observed outcomes, and learning.
The cycle answers a connected set of questions:
What problem are we trying to address?
What information do we have about it?
Given that information, how do we understand the problem?
What decision do we make, and why?
How does that decision become action?
What happened after the action?
And what does that experience add to our future understanding?
The user moves through this path in seven clear, step-by-step stages, while Menorad OS preserves the boundaries between information, analysis, formulation, human decision, action, outcome, and learning behind the experience.
The sections below examine each stage separately, showing where AI can support analysis, where human review or adoption is required, and how the connections between stages are preserved for later review.
The user journey moves through seven clear stages.
A Menorad OS user moves from problem to learning through seven main stages:
1. Define the problem
Clarify the central problem and the scope within which it will be addressed.
2. Information
Enter what has been observed, reported, interpreted, or remains a hypothesis in a structured way.
3. Understand the problem
Bring the information together so conflicts, gaps, relationships, and important assumptions become visible and a reviewable formulation of the problem can take shape.
4. Decision
Based on that understanding, a human records the decision and keeps its rationale clear.
5. Action plan
Connect the decision to specific actions, responsibility, and a path for execution.
6. Outcome
After execution, record what actually happened and compare it with earlier expectations and assumptions.
7. Learning
Bring the result back to the earlier understanding, assumptions, and decision to identify what was learned and what may need to be reconsidered in the future.
These seven stages form one continuous path, while each retains its own meaning. Simplifying the user experience does not mean collapsing the underlying concepts or removing the boundaries between information, understanding, decision, action, and post-execution reality.
In the step-by-step experience, users should be able to see what they have completed, where they are now, and what remains ahead.
Cycle Trace keeps the connections across the cycle visible, but it is not an eighth stage and does not require the user to complete a separate activity.
Stage one: clarify the problem and establish the Case around it.
Menorad OS does not begin with a solution. It begins by clarifying the problem that needs to be understood and decided.
The user first records the central problem in clear language. In the current version of the product, each Case is built around exactly one primary Issue so the path of understanding, decision, action, and learning remains focused on a specific subject.
In the product architecture, an Issue and a Case are not the same thing.
The Issue is the subject that needs to be understood, analyzed, and decided.
The Case is the organized space that holds the work around that Issue. The context, scope, and the elements that later connect to the Issue across the lifecycle are organized within this structure.
This distinction matters because the problem itself should not be confused with the container that holds the process for addressing it. At the same time, users should not have to manage this internal architecture in order to use the product. The experience presents problem definition and Case creation as one coherent, understandable path, while Menorad OS preserves the precise distinction between the two behind the scenes.
By the end of this stage, it should be clear: What problem are we addressing, exactly, and what is the scope of that work?
From there, the Information stage begins: gathering and distinguishing what is needed to understand that specific problem.
Stage two: separate the information before analyzing it.
Once the problem and the scope of the Case are clear, Menorad OS does not move directly into analysis or solutions. It first asks what information we actually have about the problem and what kind of information each item represents.
At this stage, four types of information remain distinct:
Narrative
An account provided by a person or group about the situation. A narrative can be highly important for understanding the problem, but it is not the same as a direct observation.
Interpretation
An understanding formed about the meaning, importance, or relationship of the information. Interpretation helps create meaning, but it should not be recorded as fact without examination.
Hypothesis
A plausible explanation of the problem that still needs to be examined against information, evidence, and competing explanations.
The purpose of this distinction is not to discredit narratives, interpretations, or hypotheses. It is to ensure that each piece of information enters the path of understanding according to what it actually is, so an interpretation does not become a fact simply through repetition or confidence.
AI can help organize information, identify conflicts and gaps, and suggest hypotheses worth examining. But it should not rewrite source information or turn a narrative, interpretation, or hypothesis into an official fact.
Before moving into Problem Understanding, a review is performed to assess how far the necessary information has been gathered, whether the information types have remained distinct, and which conflicts or gaps still require attention.
The goal of this stage is not to collect the greatest possible volume of information. It is to build a clear, organized, reviewable basis for understanding the problem.
Stage three: move from scattered information to an explicit, reviewable understanding of the problem.
Having information does not, by itself, mean understanding the problem. At this stage, the recorded information is examined in relation to the rest so relationships, conflicts, gaps, assumptions, and competing explanations become clearer.
The goal is to reach a Formulation: an explicit, challengeable answer to the question:
“Given what we know now, how do we understand the problem?”
A Formulation is not simply a summary of the information already collected. It should show what the current understanding is based on, what assumptions it contains, and where ambiguity or uncertainty still remains.
Human-only
- Information
- Human analysis / formulation work
AI-assisted
- Information
- AI Candidate
- Human Review
- Human Adoption
Authoritative Formulation
This path can be completed entirely by humans. When AI is used, the system can also analyze information, highlight contradictions and competing hypotheses, and create or critique a proposed Formulation as an AI Candidate.
But AI output is not yet the official Formulation of the Case.
First, Human Review is used to examine and evaluate the output. A positive review still does not make it official. Only through Human Adoption can accepted content become part of the Authoritative Formulation.
This boundary keeps AI proposals, human evaluation, and the official meaning of the Case from being conflated.
Before moving into Decision, another review takes place. The Authoritative Formulation, the information it relies on, and the important assumptions and uncertainties are revisited so the human decision-maker has a clear basis for the decision.
At the end of this stage, the organization has not yet made the decision. But it should be able to say clearly how it currently understands the problem and what that understanding is based on.
Stage four: turn the understanding of the problem into a clear human decision.
Once the Authoritative Formulation has been established and its basis reviewed, Menorad OS moves into the Decision stage.
In this system, a decision is not an answer generated by software. A person with the appropriate authority determines what decision is made and why, and that decision is recorded in connection with the understanding developed in the earlier stages.
Before the decision, AI can broaden what is considered by suggesting different options, raising possible consequences and risks, surfacing trade-offs, examining different scenarios, or challenging the logic of an option.
Human Decision
But these analyses do not replace the decision. AI cannot record, approve, or validate the final decision on behalf of a human.
The decision should be recorded clearly enough that it remains possible to see later what was decided, when, on what basis, and with what rationale. This connection turns the decision from an isolated result into a traceable part of the path of the problem.
Responsibility remains with authority. Using AI does not transfer responsibility for the decision away from the human or the organization.
At the end of this stage, there is a clear, traceable human decision that can move into action.
Stage five: turn the decision into clear, trackable action.
A decision enters organizational reality only when it is clear what needs to be done and who is responsible for carrying it out.
At this stage, Menorad OS connects the recorded Human Decision to an Action Plan. The goal is to prevent a break between what was decided and what is later done in practice.
The Action Plan should be clear enough that it remains possible to identify later what action followed from the decision, where responsibility sat, and exactly what was carried out when the outcome is reviewed.
- Human Decision
- Action Plan
- Execution path
Menorad OS is not trying to become a general-purpose project-management tool at this stage. The Action Plan is part of the same problem cycle, and its value lies in preserving the connection between problem understanding → decision → action → outcome.
AI can help draft an Action Plan—for example, by suggesting possible actions or highlighting areas that need greater clarity. But its output remains a proposal.
Activating the Action Plan remains a human action. AI cannot independently turn its own draft into an official, active Action Plan.
At the end of this stage, the decision is no longer only a recorded statement. It has become a path for action that remains connected to the logic and basis of that decision.
Stage six: bring what actually happened back into the cycle.
After the Action Plan is carried out, Menorad OS does not stop at what was expected to happen. What actually happened needs to be recorded.
At this stage, the Outcome is what is observed and recorded after action. It is not the same as the goal, the expectation, or our interpretation of the result.
Expectation
Outcome
Recording the Outcome clearly makes it possible to compare what actually happened with what was expected when the decision and Action Plan were created. That comparison can show where reality diverged from expectations and which questions need further examination.
AI can help analyze that gap by highlighting patterns, examining differences between expectations and results, and proposing different explanations for review.
But AI cannot invent an Outcome that did not occur, replace recorded reality with its own interpretation, or independently declare that a decision was “successful” or “unsuccessful.”
The existence of a connection between decision, action, and Outcome also does not, by itself, prove causality. The connection is preserved so the path can be reviewed systematically and the organization can examine what happened and what still needs further understanding.
At the end of this stage, the organization knows not only what decision was made and what action was taken, but also has a record of what happened after the action.
That reality becomes the basis for the next stage: Learning.
Stage seven: turn the Outcome into learning for future problems.
The Menorad OS cycle does not end when the Outcome is recorded. Its final value emerges when the organization can learn something from what actually happened and carry that learning into future understanding and decisions.
At this stage, the Outcome is examined again in relation to the path that came before it: How did we understand the problem? What assumptions and hypotheses did we hold? What decision did we make? What action was taken? What did we expect, and what actually happened?
The goal is not to find a simple explanation for success or failure. It is to see what was confirmed, what did not align with reality, which assumptions need to be reconsidered, and what new questions have emerged.
- Outcome
- Learning Candidate
- Human review / acceptance
- Learning
AI can help analyze the path for review and propose a Learning Candidate—for example, by highlighting gaps between expectations and outcomes or identifying assumptions that may need reconsideration.
But an AI proposal does not automatically become official organizational learning. What is accepted as the learning from the cycle still requires human review and acceptance.
And the connection between decision, action, and Outcome does not prove causation. Learning must remain grounded in what is actually known and must not hide uncertainty.
At the end of this stage, a final summary makes it possible to review the complete path from problem to learning. This does not create an eighth stage; it shows how the cycle has closed and what remains available for continued understanding.
Menorad OS does not end at the decision. It brings the result of action back into understanding so each cycle can add something to the next.
AI supports the entire cycle—but never holds authority.
The role of AI in Menorad OS is not limited to one stage or to a separate chatbot. The intent is for AI to support human analysis at specific points across the path from problem to learning.
In problem definition
AI can ask clarifying questions to help make the problem more precise and surface early ambiguities.
In Information
It can analyze information, highlight contradictions and gaps, and help keep attention on the basis, evidence, and uncertainty behind what is being considered.
In Problem Understanding
It can suggest hypotheses and competing hypotheses, draft a Formulation, and challenge the Formulation itself for contradictions, weak reasoning, or areas that need further examination.
At this stage, the formal human boundary remains:
- AI Candidate
- Human Review
- Human Adoption
- Authoritative Formulation
In Decision
AI can examine options, scenarios, risks, and trade-offs and challenge the reasoning behind a decision, but the final decision remains directly human.
In Action Plan
It can suggest draft actions, but activating the Action Plan depends on a human.
In Outcome
It can analyze the gap between what was expected and what actually happened and propose different explanations for review, but it does not create or determine the official Outcome.
In Learning
It can extract a proposed Learning Candidate from the path that was taken, but turning that proposal into official learning requires human acceptance.
Across the entire cycle, three principles remain constant: AI output should stay connected, as far as possible, to its context and basis; uncertainty should not be hidden; and progress through the workflow should not depend solely on AI being available.
AI is also not permitted to create access for itself or others, make an official decision, automatically convert its own output into an authoritative record, advance the workflow independently, or execute an external action without the required authority.
AI broadens the field of analysis, while formal structure, authority, and responsibility remain under the control of the system and humans.
Every decision should preserve the path that produced it.
In many organizations, the final decision remains while important parts of the path that led to it fade over time: what information was available, how the problem was understood, which assumptions were in play, and why one path was preferred over other options.
Menorad OS preserves that continuity across the cycle:
- Problem
- Information
- Formulation
- Human Decision
- Action Plan
- Outcome
- Learning
A decision is therefore not an isolated record. It remains possible to return to its path and see:
- — what information contributed to the understanding of the problem;
- — which Formulation became the basis for the decision;
- — what decision was recorded on that basis;
- — how the decision connected to action;
- — what Outcome was observed after action;
- — and what learning emerged from the cycle.
Traceability preserves the connections between these elements. Alongside it, Provenance helps show where a piece of information, analysis, or output came from and in what context it entered the Case.
Neither concept proves truth. Being traceable shows where information came from and how it was used in the path; it does not mean the information is necessarily correct or certain.
The same limitation applies to Outcomes. Connecting a decision to an Action Plan and then to an Outcome does not, by itself, prove causality. The connection makes systematic review possible so the organization can examine the relationship between what it knew, what it decided, what it did, and what happened.
Cycle Trace is not an eighth stage in the user journey. It is a continuous view of these connections that allows the whole Case to be reviewed from problem to learning.
The value of this capability is in preserving decision memory: the organization can know not only what decision was made, but later understand how it took shape and what happened afterward.
If AI is unavailable—or its output is not suitable—the work should not stop.
Menorad OS is built on the principle that AI is a layer that supports analysis, not a requirement for continuing the cycle and not the final authority over the official meaning of a Case.
For that reason, the product path includes two forms of protection:
Human boundaries
Wherever AI output may affect the official meaning of a Case, it cannot pass through directly and automatically.
In Formulation, AI output begins as a proposal; Human Review and Human Adoption remain separate.
At the Decision stage, final authority rests directly with a human.
In Action Plan, AI can provide a draft, but activation remains human.
In Learning, an AI proposal does not become official learning until a human accepts it.
Human-only alternative path
If AI or the Provider is unavailable, an AI execution fails, or the user does not consider the AI output suitable for continuing the work, the core path from problem to learning should not remain dependent on AI.
The workflow must be able to continue through a human path without the system automatically accepting an output to compensate for the absence of AI, advancing a stage without the required authority, or recording a decision on the user’s behalf.
AI-assisted
- AI Candidate
- Human Review
- Human Adoption
Human-only
- Information
- Human analysis / formulation work
- Authoritative Formulation
- Human Decision
- Action Plan
- Outcome
- Learning
This is not only a technical fallback mechanism. It is part of the governance logic of Menorad OS: AI assistance should be usable, but human authority and the ability to continue the process should not depend on the presence of a model or Provider.
As a result, an AI failure or absence should not change the product’s formal boundaries. The distinctions between information, Formulation, decision, action, Outcome, and Learning remain intact, and human responsibility remains preserved.
The human-only alternative path does not mean that Menorad OS has zero technical dependency on providers or guarantees uninterrupted availability. It is designed to preserve a path for continuing the process without making formal decisions or authority dependent on AI output.
See this path inside Menorad OS.
If you want to see how this logic becomes a real product experience in practice, the next step is to request a demo.
Before the demo, we review the general context of the problem and whether Menorad OS fits the organization’s needs. You can then see the product path from problem definition through information, understanding, decision, action, Outcome, and Learning, including where AI can help, where human authority is preserved, and how the connections between stages remain traceable.
The demo is based on the capabilities that are available and accepted in the version that can actually be delivered—not on planned capabilities or parts still under development.
If the evaluation shows a fit, the conversation can move into the next stage of the commercial and purchase path.