REALITY ENGINE is a proposed framework for organizing knowledge and supporting decisions. It connects claims, evidence, models, decisions, and outcomes in a cycle that can be examined and revised.
Author: Roman Shaban
Status: Conceptual proposal and draft practical protocol
Version: 0.1
In complex situations, finding information or receiving a convincing answer is not enough. We need to know what supports a claim, under which conditions it applies, what decision it justifies, and what changes after that decision is tested.
When these connections are not recorded, an assumption can be mistaken for a fact, a forecast for a promise, or a successful outcome for proof that the entire explanation was correct. An organization may accumulate documents while losing track of why it made particular decisions.
REALITY ENGINE proposes a way to preserve this reasoning. Its central object is a traceable chain of justification: from defining a problem and recording sources to choosing an action, measuring its consequences, and reviewing the model.
Models should remain open to correction, and decisions should remain open to examination.
A model describes selected features of a phenomenon under specified conditions. Its usefulness depends on how well it fits the task, the quality of the data, the accuracy of its predictions, and the limits of its application.
A difference between a prediction and an observed outcome should prompt a review of the full chain: observations, measurements, assumptions, the model, implementation, and external influences. That difference does not, by itself, identify the cause of the error.
The proposed working cycle is:
Observation → model → prediction → decision → action → measurement → review
Each cycle should produce a concrete result: a refined claim, a rejected hypothesis, a tested decision, or a clearer account of what remains uncertain.
Ontology provides a consistent set of concepts for describing entities, states, processes, agents, environments, resources, constraints, goals, and outcomes. Here, ontology means a way to organize descriptions. It does not claim to provide a final inventory of everything that exists.
Claim registry records claims, their sources, verification status, and scope. Observations, hypotheses, interpretations, predictions, and value judgments are identified as distinct types.
Model registry connects explanations to their assumptions, alternatives, predictions, and test results. Multiple models may coexist when they describe different aspects or scales of a phenomenon.
Decision protocol records the goal, options considered, reasons for the choice, expected consequences, and conditions that would trigger a review.
Outcome log stores measurements, differences between expectations and results, and changes made to models. Version history helps reconstruct what was known at the time a decision was made.
Together, these components form the proposed Reality Graph: a graph of relationships among concepts, claims, sources, models, actions, and outcomes. Each relationship should have a defined type, such as “supports,” “contradicts,” “assumes,” “tests,” “applies,” or “revises.”
The system’s smallest unit is a claim with a verification context. A basic record includes:
Identifier: a stable ID and record version.
Content: one clearly stated claim.
Type: observation, hypothesis, interpretation, prediction, or value judgment.
Scope: relevant conditions, time, entities, and limits on generalization.
Provenance: who recorded it, its source, date, and how the information was obtained.
Evidence: the data, verification method, and known limitations.
Assumptions and alternatives: what the conclusion depends on and which explanations compete with it.
Uncertainty: what remains unknown and why.
Review condition: what result would weaken, refine, or reject the claim.
Change history: what was updated and on what basis.
A source is not, by itself, proof. A reference should make it possible to check whether the cited material supports the specific claim. A numerical confidence score should be used only when its method of calculation is explained.
The Thinking Protocol is a working procedure for complex tasks.
Define the problem. What is happening, who is affected, and what boundaries apply?
Specify the desired outcome. What should change, how will it be measured, and which consequences are unacceptable?
Separate what is known from what is assumed. What observations, sources, interpretations, and gaps are present?
Develop alternative explanations. What mechanisms could produce the problem, and what evidence could distinguish among them?
Generate options for action. Consider resources, constraints, risks, and whether the problem itself should be reframed.
Define the test in advance. Record the prediction, indicators, evaluation period, and conditions for stopping.
Act and measure. Distinguish the planned intervention from what was actually carried out.
Update the record. Compare expectations with results, review the explanation, and decide what to do next.
The protocol should produce a decision record with reasons and review conditions. The depth of analysis should match the complexity of the task and the cost of being wrong.
Suppose students can reproduce definitions correctly but struggle to apply them in unfamiliar practical situations.
Problem: Recalling information does not lead to the expected transfer of knowledge to practice.
Hypothesis: The course includes too few tasks that require students to choose independently how to apply a concept.
Alternatives: Instructions may be unclear, foundational knowledge may be insufficient, students may be fatigued, or the teaching and assessment methods may not align.
Intervention: Add new case studies that require students to explain their choices and receive feedback.
Evaluation: Compare the intervention with a clearly described baseline approach. Measure performance on unfamiliar tasks, retention of the skill, and time required.
Review condition: If improvement appears only on familiar exercises, transfer to new situations remains unconfirmed.
This is an illustrative scenario, not a report of completed research. It shows how a general idea can be turned into a testable task.
In the proposed architecture, artificial intelligence can help locate sources, compare claims, generate alternatives, identify contradictions, and prepare plans for testing.
An AI-generated explanation is stored as a candidate for review. Its provenance should show what the model proposed, what external sources support, and what has been independently tested.
A person or responsible organization defines the goals, acceptable costs, limits on delegation, and criteria for acceptance. For an agent, permitted actions and conditions for stopping should be specified separately.
Compatibility with future intelligent systems is supported by explicit definitions, typed relationships, data provenance, version history, and accessible verification. The approach does not depend on the capabilities of future superintelligence.
Evaluating a decision requires three separate questions.
Truth: How well is the claim supported by the available evidence?
Value: For whom is the outcome desirable, whose interests are affected, and which consequences are unacceptable?
Effectiveness: How well does the action advance the stated goal? Time and resource costs can be assessed separately as measures of efficiency.
Achieving a goal does not automatically prove that the explanation was correct or that the consequences were acceptable. These assessments should remain distinct so that one overall score does not conceal important disagreements.
An initial prototype could consist of a claim template, a decision log, and one completed case. A document or spreadsheet is sufficient for an initial test.
The next step is to compare work performed with the protocol against a clearly described baseline approach on comparable tasks. The measures should be defined before evaluation begins:
Outcome quality: prediction accuracy or achievement of the stated goal.
Traceability: whether the reasons behind a decision can be reconstructed.
Verifiability: the share of key claims with accessible evidence.
Error correction: how quickly incorrect assumptions are detected and revised.
Cost of use: the time, resources, and effort required from users.
Usefulness hypothesis: The protocol improves the quality and verifiability of decisions at an acceptable cost.
If it increases documentation without providing a corresponding benefit, the architecture should be simplified or revised.
For researchers: organizing hypotheses, sources, contradictions, and tests.
For education: supporting reasoned thinking and assessing the application of knowledge.
For business: preserving the assumptions, experiments, and outcomes behind strategic decisions.
For AI developers: structuring records that people and agents can examine and reuse.
One possible direction for commercialization is software for knowledge management and decision support. Its viability would require separate validation of customer demand, costs, and measurable benefits.
REALITY ENGINE brings together ideas from systems thinking, scientific testing, knowledge engineering, metacognition, and feedback systems. Combining these ideas does not, by itself, establish novelty. The project’s potential contribution should be assessed through its specific record structure, working rules, and results from comparative trials.
This publication describes a concept and a proposed protocol. It does not establish scientific validity, universal applicability, or superiority over existing methods.
The aim of REALITY ENGINE is to make the path from claim to consequence visible, verifiable, and open to correction.
Title: REALITY ENGINE — An Architecture for Knowledge, Thinking, and Decision-Making
Author: Roman Shaban
Type: Conceptual article and proposed practical protocol
Language: English
Version: 0.1
Subject: Knowledge organization and support for reasoned decision-making
Proposed components: Ontology, claim registry, model registry, decision protocol, outcome log
Key concepts: Systems thinking; knowledge engineering; evidence-based reasoning; metacognition; knowledge graph; decision support; human–AI interaction
Verification status: No empirical results are reported in this publication
Development criterion: Measurable improvement in decision quality and verifiability at an acceptable cost