RecallIQ — Part 3 of 5
Exploring how persistent memory and transparent rules can provide explainable decision support without depending on an LLM.
When people hear "AI decision support," they often picture a large language model reading a proposal and producing a confident opinion.
RecallIQ deliberately started somewhere more modest.
The idea is to first understand the decision-support problem itself:
What has the team experienced before, and what should be checked before making a similar decision?
RecallIQ combines persistent memory with predefined, human-written rules to explore this approach.
The system uses Hindsight Cloud as its persistent-memory layer, while the application's own backend handles the decision logic and rule-based checks.
The goal is not to make the system sound intelligent.
The goal is to make its reasoning transparent, testable, and grounded in information the team has actually recorded.
The decision-analysis concept behind RecallIQ has two main inputs:
The memory layer provides historical context.
The rules identify known patterns that deserve additional attention.
This creates a clear separation of responsibility.
New Decision
│
├───────────────┐
▼ ▼
Hindsight Cloud Risk Rules
│ │
▼ ▼
Past Memories Potential Risks
│ │
└───────┬───────┘
▼
Decision Support
Hindsight provides the memories.
The rules provide the preliminary risk checks.
The human remains responsible for evaluating the decision.
One of the important design choices in RecallIQ is keeping the memory layer separate from the analysis logic.
Hindsight's job is to remember and recall information.
It is not responsible for deciding whether a new decision is good or bad.
The application can therefore distinguish between:
What the team remembers
and
What the application checks
This separation makes the system easier to understand and test.
If a memory appears in the output, it came from the memory layer.
If a risk appears because a specific pattern was matched, it came from a predefined rule.
That traceability is important when building a decision-support system.
Consider a team deciding:
Migrate to a cheaper cloud provider
The description is:
Reduce cloud spending by moving to a cheaper provider.
The assumptions are:
The expected outcome is:
A 20% reduction in monthly cloud costs without reducing performance.
At first glance, the proposal appears straightforward.
But the assumptions contain several areas that deserve validation.
The proposal assumes that transfer fees will be minimal.
That assumption may not hold.
Migration can involve:
The potential risk is:
Data-transfer and migration costs may reduce the expected savings.
A practical recommendation is:
Calculate the total cost of ownership before committing to the migration.
The important part is that the system is not claiming that the migration will fail.
It is identifying an assumption that should be checked.
The proposal also assumes that performance will remain stable.
Moving a workload to another environment can change:
Performance or reliability may change after migration.
Benchmark the workload before and after the migration.
Again, the system is not predicting the future.
It is turning an assumption into something that can be tested.
The expected outcome is a 20% reduction in monthly cloud costs.
But an estimate can overlook costs that are not immediately visible.
For example:
Savings estimates may omit recurring or one-time costs.
The recommendation is:
Validate the assumptions and include all relevant costs before committing.
It is important to understand what the rule system is not doing.
It is not predicting the future.
It is not deciding whether the proposal should be accepted.
It is not claiming that a particular outcome is guaranteed.
Instead, it asks:
Which assumptions deserve additional scrutiny?
Assumption:
"Transfer fees will be minimal."
↓
Risk Check:
"Data-transfer costs may reduce savings."
↓
Action:
"Calculate total cost of ownership."
This turns an abstract concern into a concrete task.
Rules alone would behave similarly for every team.
Memory makes the system specific to the team's own history.
Imagine that Hindsight recalls a previous decision:
Decision:
Migrate another service to a cheaper provider
Status:
Warning
Lesson:
Unexpected transfer costs reduced the expected savings.
Now the current decision has additional context.
The generic warning:
"Transfer costs may reduce savings."
is no longer just a general possibility.
The team has its own historical record showing that a similar assumption caused concern before.
This is where persistent memory becomes valuable.
Historical context is more useful when we know how the previous decision turned out.
RecallIQ uses decision statuses such as:
Consider two memories:
Previous Decision A
Status: Successful
and:
Previous Decision B
Status: Failed
Both may be relevant to a new decision.
But they provide different kinds of evidence.
A successful decision may show what worked.
A failed decision may reveal an assumption or risk worth reconsidering.
A warning may indicate that an approach worked but introduced problems.
This is why outcome information should remain attached to the memory rather than being treated as separate metadata.
Starting with rules has several practical advantages for an early prototype.
Anyone can read a rule and understand why a risk was raised.
There is no hidden model reasoning to audit.
The same input can produce the same rule-based output.
This makes testing easier.
A developer can identify which rule produced a particular risk.
This makes debugging and improvement more straightforward.
The prototype does not need additional model calls for its rule-based analysis layer.
This keeps the initial system smaller and easier to reason about.
During a hackathon, being able to explain exactly why the system produced a particular result is useful.
A reviewer can follow the path:
Decision
↓
Pattern detected
↓
Risk rule matched
↓
Recommendation generated
The rule-based approach also has clear limitations.
The system can only identify patterns that have been explicitly defined.
If a decision falls outside those patterns, the system may return few or no risks.
That silence should not be interpreted as proof that the decision is safe.
The output is intended to highlight areas for consideration.
It is not a complete evaluation of every possible consequence of a decision.
The current repository describes RecallIQ as a prototype and explicitly notes that no AI provider is connected yet. The project does integrate Hindsight Cloud for persistent memory, but the current analysis concept should not be described as an LLM-generated analysis system.
An LLM is part of the future roadmap, not something we should claim is already implemented.
The system is intended to support human decision-making.
A person should review the information and decide what action, if any, should be taken.
A decision-support system should make it easy for users to understand where its output came from.
Several principles help achieve that.
A risk should be traceable to:
The output should not simply present an unexplained conclusion.
Instead of saying:
"This migration will fail."
the system should say:
"Migration costs may reduce the expected savings."
Words such as may, could, and potential accurately communicate uncertainty.
The system informs the decision.
It does not make the decision.
If no rule matches a decision, the system should not imply that there are no risks.
The absence of a detected risk is not the same thing as evidence of safety.
A common temptation when building AI applications is to start with the biggest available model.
RecallIQ takes a different approach.
Before asking a model to generate sophisticated analysis, we can first establish:
These questions create a foundation for more advanced AI later.
The rules-plus-memory design can also provide a foundation for future LLM integration.
A future version could allow an LLM to receive:
Current Decision
+
Relevant Historical Memories
+
Known Risk Rules
and then generate contextual analysis.
For example, the model could identify that:
A previous failed decision shared a particular assumption with the current proposal.
But the architecture should preserve the strengths of the current system.
The model should use relevant recalled memories rather than relying only on general knowledge.
Known risks should continue to be checked even if an LLM is introduced.
Important claims should point back to the relevant decision or memory.
The system should remain a decision-support tool rather than an autonomous decision-maker.
The current repository contains a React + TypeScript + Vite frontend and a FastAPI backend, with Hindsight Cloud used for persistent memory. The repository documentation also states that sample dashboard data is used for preview purposes and that no AI provider is currently connected.
The architecture therefore focuses on establishing the foundation first:
React + TypeScript
│
▼
FastAPI Backend
│
├───────────────┐
▼ ▼
Decision Records Hindsight Cloud
│
▼
Memory Recall
This gives the project a clear base for future analysis capabilities.
The next stage of RecallIQ can build on this foundation.
Potential improvements include:
The objective is not simply to add more AI.
The objective is to make the system more useful while keeping its reasoning understandable and its claims verifiable.
Useful decision support does not have to begin with the biggest model available.
RecallIQ explores a simpler starting point:
Persistent memory + transparent rules + human judgment
Persistent memory gives the system access to relevant history.
Rules provide predictable and explainable checks.
Human judgment remains responsible for the final decision.
This approach creates a foundation that can later support more sophisticated AI without throwing away the transparency of the original system.
The larger vision is to move from:
Remembering decisions
to:
Learning from decisions.
And that is where the next stage of RecallIQ begins.
🔗 GitHub Repository: https://github.com/ravikanthbojja44-create/Recall-IQ
RecallIQ is currently a prototype and does not have a public live demo deployed yet.
Part 1 — The Problem of Forgotten Decisions: Why AI Systems Need Persistent Memory
Part 2 — Inside RecallIQ: Building a Decision-Memory System with FastAPI, React and Hindsight Cloud
Part 3 — Memory Plus Rules ← You are here
Part 4 — Building RecallIQ: Development Workflow, Testing and What We Learned
Part 5 — From Decision Memory to Decision Learning: The Future of RecallIQ
This article is Part 3 of the RecallIQ technical series exploring persistent memory, trustworthy decision support, and the evolution from decision memory to decision learning.