RecallIQ — Part 3 of 5
Exploring how persistent memory and transparent rules can provide explainable decision support without depending on an LLM.
Start With the Question, Not the Model
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 Two Inputs
The decision-analysis concept behind RecallIQ has two main inputs:
- Relevant memories from Hindsight Cloud
- Predefined risk rules
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.
Why Separate Memory From Reasoning?
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.
A Worked Example
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:
- Costs will fall by at least 20%.
- Transfer fees will be minimal.
- Performance will remain stable.
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.
Risk 1 — Data Transfer and Migration Costs
The proposal assumes that transfer fees will be minimal.
That assumption may not hold.
Migration can involve:
- Data-transfer charges
- One-time migration work
- Infrastructure changes
- Additional operational effort
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.
Risk 2 — Performance and Reliability
The proposal also assumes that performance will remain stable.
Moving a workload to another environment can change:
- Latency
- Throughput
- Availability
- Reliability
- Network behavior
The potential risk is:
Performance or reliability may change after migration.
A practical recommendation is:
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.
Risk 3 — Incomplete Savings Estimates
The expected outcome is a 20% reduction in monthly cloud costs.
But an estimate can overlook costs that are not immediately visible.
For example:
- Recurring service costs
- Migration costs
- Data-transfer charges
- Monitoring costs
- Operational overhead
The potential risk is:
Savings estimates may omit recurring or one-time costs.
The recommendation is:
Validate the assumptions and include all relevant costs before committing.
What the Rules Are Actually Doing
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?
For example:
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.
Where Memory Changes the Picture
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.
Why Decision Status Matters
Historical context is more useful when we know how the previous decision turned out.
RecallIQ uses decision statuses such as:
- Pending
- Successful
- Failed
- Warning
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.
Why Rules First Is a Useful Engineering Choice
Starting with rules has several practical advantages for an early prototype.
1. Transparency
Anyone can read a rule and understand why a risk was raised.
There is no hidden model reasoning to audit.
2. Predictability
The same input can produce the same rule-based output.
This makes testing easier.
3. Traceability
A developer can identify which rule produced a particular risk.
This makes debugging and improvement more straightforward.
4. Lower Complexity
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.
5. Easier Demonstration
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 Limits We Do Not Hide
The rule-based approach also has clear limitations.
Rules Cover Selected Patterns
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.
It Is Not a Comprehensive Risk Assessment
The output is intended to highlight areas for consideration.
It is not a complete evaluation of every possible consequence of a decision.
It Is Not an LLM-Based Analysis System
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.
Human Review Remains Essential
The system is intended to support human decision-making.
A person should review the information and decide what action, if any, should be taken.
Designing for Trust
A decision-support system should make it easy for users to understand where its output came from.
Several principles help achieve that.
Show the Source of Each Finding
A risk should be traceable to:
- A specific rule
- A recalled memory
- Or another clearly identified source
The output should not simply present an unexplained conclusion.
Use Careful Language
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.
Keep a Human in the Loop
The system informs the decision.
It does not make the decision.
Say What Was Not Checked
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.
Why This Approach Matters
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:
- What information should be remembered?
- How should memories be retrieved?
- What known risks can be checked deterministically?
- How can findings be explained?
- How can users verify the source of an insight?
These questions create a foundation for more advanced AI later.
A Path to Something Richer
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.
Ground the Model in Memory
The model should use relevant recalled memories rather than relying only on general knowledge.
Keep Rules as a Baseline
Known risks should continue to be checked even if an LLM is introduced.
Show Supporting Evidence
Important claims should point back to the relevant decision or memory.
Keep Humans Responsible
The system should remain a decision-support tool rather than an autonomous decision-maker.
The Current RecallIQ Architecture
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.
What Comes Next?
The next stage of RecallIQ can build on this foundation.
Potential improvements include:
- Persistent database storage
- More sophisticated decision analysis
- LLM-generated contextual analysis
- Outcome tracking
- Better memory relevance
- Filtering by status, topic, and time
- Citations linking insights to previous decisions
- Authentication
- Team workspaces
- User feedback and evaluation
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.
Conclusion
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.
Explore RecallIQ
🔗 GitHub Repository: https://github.com/ravikanthbojja44-create/Recall-IQ
RecallIQ is currently a prototype and does not have a public live demo deployed yet.
RecallIQ Series
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.
Top comments (0)