DEV Community: Dikshith Somishetty

From Decision Memory to Decision Learning: The Future of RecallIQ

Dikshith Somishetty — Tue, 29 Sep 2026 15:40:05 +0000

RecallIQ — Part 5 of 5

How RecallIQ can evolve from remembering past decisions to learning from their outcomes.

What RecallIQ Is Today

RecallIQ currently explores a simple but important idea:

Teams should be able to remember why they made decisions, not just what they decided.

The prototype provides a foundation for recording decisions, retaining relevant information through Hindsight Cloud, recalling historical context, and applying predefined checks to identify potential risks.

A decision can contain:

A title
A description
Assumptions
An expected outcome
A status

The status can represent whether a decision is:

Pending
Successful
Failed
Warning

This creates a structured record of the decision rather than storing only its final answer.

But remembering is only the first step.

The larger goal is to build a system that can help teams learn from what happened after their decisions were made.

That is the direction of the future RecallIQ roadmap.

1. A Persistent Database

One of the most immediate gaps in the current prototype is storage.

The current decision records are held in application memory.

This means that restarting the backend can reset the decision list.

That is acceptable for an early prototype, but a production system needs durable storage.

PostgreSQL

A database such as PostgreSQL could provide:

Persistent decision records
Querying
Filtering
Historical tracking
Structured relationships between users, teams, and decisions
A foundation for outcome tracking

The architecture could then make a clear distinction between two kinds of storage:

```text id="4y4bnp"
PostgreSQL
│
└── Authoritative decision records

Hindsight Cloud
│
└── Semantic memory and recall




The database would hold the structured source of truth.

Hindsight would provide the memory layer used to retrieve relevant historical context.

This separation would make the system more robust and easier to scale.

---

## 2. LLM-Generated Contextual Analysis

Today's prototype intentionally keeps the analysis simple and transparent.

A future version could introduce an LLM to generate more contextual analysis.

For example, instead of only matching predefined patterns, an LLM could compare:



```text id="j5v4hf"
Current Decision
       +
Current Assumptions
       +
Expected Outcome
       +
Relevant Historical Memories

and identify relationships that may not have been explicitly encoded as rules.

Imagine a team proposing:

"Move our analytics platform to a lower-cost infrastructure provider."

RecallIQ might retrieve an older decision involving:

"Move our reporting workload to a cheaper infrastructure provider."

An LLM could potentially identify that both decisions share a similar assumption about infrastructure costs and performance.

This could produce more contextual insights.

However, adding an LLM should not mean throwing away the principles of the current design.

Keeping the Good Parts

A future LLM-powered RecallIQ should preserve several important properties.

Ground the Model in Recalled Memories

The model should receive relevant historical information instead of relying only on general knowledge.

Keep Rules as a Baseline

Known risks should continue to be checked deterministically.

Rules can provide a predictable baseline even when an LLM is introduced.

Show Supporting Evidence

If an insight comes from a previous decision, users should be able to identify that decision.

The system should answer:

Why did you tell me this?

with something more useful than:

"Because the AI said so."

Keep a Human in the Loop

The system should support human judgment rather than make decisions autonomously.

3. Tracking Actual Outcomes

This may be the most important step in moving from memory to learning.

Every RecallIQ decision already has an expected outcome.

For example:

Expected outcome: Reduce monthly cloud costs by 20% without reducing performance.

But an expected outcome is only a prediction.

What happens afterward is what creates useful evidence.

A future version of RecallIQ could record:

```text id="6h0d4j"
Expected Outcome
↓
20% cost reduction

Actual Outcome
↓
11% cost reduction

Difference
↓
Expected savings were overestimated




Now the system has something more valuable than a decision record.

It has a **lesson**.

---

## From Expectations to Evidence

Suppose a team makes several infrastructure decisions.

| Decision    | Expected Savings | Actual Savings |
| ----------- | ---------------: | -------------: |
| Migration A |              20% |            12% |
| Migration B |              15% |             9% |
| Migration C |              25% |            14% |

Over time, a pattern may become visible.

The team repeatedly overestimates infrastructure savings.

That pattern could become useful context for future decisions.

The system could surface historical evidence such as:

> "Previous infrastructure migrations consistently achieved lower savings than initially expected."

That is very different from simply remembering that the migrations happened.

It is **learning from outcomes.**

---

## 4. Better Memory Relevance, Filtering and Citations

Persistent memory is only useful when the right memories are retrieved.

Future versions of RecallIQ could improve this in several ways.

### Filter by Status

Users could search specifically for:

* Successful decisions
* Failed decisions
* Warning decisions
* Pending decisions

For example:

> Show previous failed decisions related to database migrations.

### Filter by Topic

Users could narrow memories to areas such as:

* Infrastructure
* Databases
* Development
* Security
* Product
* Operations

### Filter by Time

Users could look at:

* Recent decisions
* Decisions from the last year
* Historical decisions
* Decisions within a specific date range

### Citations

One of the most useful improvements would be citations.

Instead of displaying:

> "Migration costs may reduce savings."

the system could show:

> "A similar decision from March 2026 recorded unexpected migration and transfer costs."

The user could then open the original decision.

This makes recommendations easier to evaluate.

---

## Why Citations Matter

Trust is important in decision-support systems.

If an insight appears without context, users may not know where it came from.

But if the system can show:



```text id="qk3v5s"
Recommendation
     ↓
Supporting Memory
     ↓
Previous Decision
     ↓
Observed Outcome

the user can independently evaluate the reasoning.

This creates a much stronger relationship between:

Memory → Evidence → Insight

rather than:

AI → Answer

5. Authentication and Team Workspaces

Real organizational decisions are rarely made by one person.

Different teams have different:

Decisions
Projects
Context
Access requirements
Historical experiences

A future version of RecallIQ could introduce authentication and team workspaces.

For example:

```text id="7z5n0w"
Organization
│
├── Engineering Team
│ ├── Decisions
│ └── Memories
│
├── Product Team
│ ├── Decisions
│ └── Memories
│
└── Operations Team
├── Decisions
└── Memories




This would allow each team to maintain its own decision history.

It would also introduce the need for appropriate access control.

Not every decision should necessarily be visible to every user.

---

## 6. Feedback and Evaluation

A recommendation system should eventually be able to answer a basic question:

> **Is this actually helping?**

Without evaluation, it is easy to assume that a recommendation system is useful simply because its output looks reasonable.

RecallIQ could introduce feedback mechanisms such as:

* Useful
* Not useful
* Relevant memory
* Irrelevant memory
* Helpful recommendation
* Incorrect recommendation

This feedback could become evaluation data.

---

## Measuring Outcomes

Feedback alone is not enough.

RecallIQ could combine feedback with actual decision outcomes.

For example:



```text id="w9p6t2"
Decision
   ↓
RecallIQ Recommendation
   ↓
Human Decision
   ↓
Actual Outcome
   ↓
User Feedback

Over time, this could help evaluate whether the system's recommendations are actually useful.

It would also prevent the project from making unsupported claims about impact.

Instead of saying:

"RecallIQ improves decisions."

the system could eventually collect evidence to determine whether that claim is supported.

A Suggested Development Order

These improvements depend on one another.

A possible sequence is:

1. Persistent Database

Everything else depends on reliable long-term data.

2. Outcome Tracking

Once decisions are stored reliably, actual outcomes can be recorded.

3. Relevance, Filtering and Citations

Better retrieval makes historical information more useful and easier to verify.

4. LLM-Generated Analysis

Once reliable historical data and citations exist, an LLM can be grounded in that information.

5. Authentication and Team Workspaces

This prepares RecallIQ for multi-user and organizational use.

6. Feedback and Evaluation

Evaluation should happen throughout the process rather than being treated as an afterthought.

The roadmap can therefore be represented as:

```text id="j3c5kt"
Persistent Storage
↓
Outcome Tracking
↓
Better Retrieval + Citations
↓
Grounded LLM Analysis
↓
Team Workspaces
↓
Feedback + Evaluation
↓
Decision Learning




---

## Principles That Should Not Change

As RecallIQ becomes more sophisticated, some principles should remain constant.

### 1. Make the Source Clear

Users should know whether information came from:

* A recorded decision
* A recalled memory
* A predefined rule
* An LLM-generated analysis

### 2. Keep Humans Responsible

RecallIQ should inform decisions.

It should not make decisions on behalf of people.

### 3. Protect Credentials and Data

Secrets should remain in environment variables or appropriate secret-management systems.

They should never be placed in public source code or documentation.

### 4. Claim Only What Has Been Verified

Every feature description should match what has actually been implemented and tested.

### 5. Make Recommendations Traceable

Where possible, users should be able to understand why a recommendation appeared and what evidence supports it.

---

## From Decision Memory to Decision Learning

The difference between memory and learning is important.

### Decision Memory

> "We made this decision before."

### Decision Context

> "We made this decision before, and these were our assumptions."

### Decision Outcome

> "We made this decision, and this is what actually happened."

### Decision Learning

> "We made similar decisions several times, and these patterns emerged."

That progression represents the larger vision for RecallIQ.



```text id="9y3p2m"
Remember
   ↓
Understand Context
   ↓
Track Outcomes
   ↓
Identify Patterns
   ↓
Learn

The objective is not simply to build a larger archive of decisions.

It is to create a system where past experience becomes increasingly useful for future decisions.

What the Future Could Look Like

Imagine an engineer preparing a new proposal.

Instead of starting with a blank page, RecallIQ could surface:

Similar decisions from your team

3 previous decisions found.

2 had warning outcomes.

1 shared a similar assumption about cost.

Then it could show:

Historical lesson: Previous infrastructure migrations achieved lower savings than initially estimated because transfer and operational costs were underestimated.

And finally:

Suggested checks: Validate total cost of ownership, benchmark performance, and compare expected savings with previous outcomes.

The important part is not that an AI generated a sophisticated sentence.

The important part is that the system connected:

Current decision → Historical experience → Evidence → Actionable checks

That is the direction RecallIQ is designed to explore.

Conclusion

RecallIQ began with a simple observation:

Teams often forget why they made decisions.

That forgotten context can cause organizations to repeat approaches, overlook previously encountered risks, and lose valuable institutional knowledge.

Persistent memory provides a way to preserve that context.

But memory alone is not the final goal.

The longer-term vision is to move from:

Remembering decisions

to:

Learning from decisions.

A persistent database can preserve the record.

Outcome tracking can show what actually happened.

Better retrieval can surface relevant history.

Citations can make insights traceable.

LLMs can eventually provide contextual analysis.

Team workspaces can make the system useful across organizations.

Feedback and evaluation can determine whether the system is actually helping.

Together, these capabilities could turn decisions from isolated events into a compounding organizational asset.

That is the future direction of RecallIQ.

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: Designing Trustworthy Decision Analysis Without an LLM

⬅️ Part 4 — Building RecallIQ: Development Workflow, Testing and What We Learned

Part 5 — From Decision Memory to Decision Learning: The Future of RecallIQ ← You are here

This article is Part 5 of the RecallIQ technical series exploring persistent memory, trustworthy decision support, and the evolution from decision memory to decision learning.

Building RecallIQ: Development Workflow, Testing and What We Learned

Dikshith Somishetty — Tue, 29 Sep 2026 15:37:35 +0000

RecallIQ — Part 4 of 5

A practical look at how RecallIQ was developed, tested, and refined during the hackathon, including the engineering decisions, security practices, and lessons learned along the way.

Building for a Hackathon

A hackathon rewards a working demo.

But a working demo is not the same as an honest one.

When building RecallIQ, one of the main goals was to move quickly without making claims about features that had not actually been verified.

The project was developed around a simple principle:

Build the smallest useful system, test each layer independently, and clearly separate what works from what is still being developed.

This approach helped keep the project understandable while leaving room for future improvements.

Choosing a Stack for Speed and Clarity

RecallIQ uses a relatively lightweight technology stack:

Layer	Technology
Frontend	React, TypeScript and Vite
Backend	Python and FastAPI
Data Validation	Pydantic
Memory	Hindsight Cloud
Development	Cursor / Code Editor
API Testing	FastAPI Swagger UI
Environment	PowerShell and Browser

Each component was selected for a practical reason.

React + TypeScript + Vite

The frontend provides a responsive dashboard while TypeScript helps catch mistakes in how application data is handled.

Vite also provides a fast development feedback loop, making it easier to see frontend changes quickly.

Python + FastAPI

FastAPI provides a lightweight backend framework with automatic API documentation.

This was particularly useful during development because the API could be tested independently before the complete frontend workflow was connected.

Pydantic

Pydantic handles data validation.

Instead of allowing malformed decision objects to travel deeper into the application, invalid requests can be rejected early.

Hindsight Cloud

Hindsight provides the persistent-memory layer.

This allows RecallIQ to experiment with retaining and recalling decision context beyond a single application interaction.

Backend First, Dashboard Second

One of the most useful development decisions was to prove the backend before building the interface on top of it.

FastAPI's automatically generated Swagger UI made this possible.

Each endpoint could be tested directly from the browser.

The workflow was:

```text id="r1m5y2"
Define Data Model
↓
Build API Endpoint
↓
Test in Swagger UI
↓
Verify Response
↓
Connect Frontend




This reduced debugging complexity.

If something failed in the dashboard, we could first check whether the backend endpoint itself was working.

That made it easier to distinguish between:

* Frontend problems
* Backend problems
* Memory-service problems

---

## The Development Workflow

The development process followed a sequence of small, testable steps.

### Step 1 — Define the Decision Model

The first step was defining what information a decision should contain.

The model includes:

* Title
* Description
* Assumptions
* Expected outcome
* Status

The status can represent:

* Pending
* Successful
* Failed
* Warning

This structure gives each decision enough context to be useful later.

---

### Step 2 — Build Decision Creation

The next step was creating the decision endpoint.



```text id="b9t2gx"
POST /api/decisions

A valid request creates a decision and returns an appropriate success response.

The expected HTTP status for successful creation is:

201 Created

This endpoint became the foundation for the rest of the application.

Step 3 — Retrieve Decisions

The next endpoint was:

```text id="o7d5xj"
GET /api/decisions




This allows recorded decisions to be retrieved from the running backend.

Testing this immediately after creation helped verify that the application was correctly handling the decision data.

---

### Step 4 — Connect Hindsight

Once the basic decision flow worked, Hindsight Cloud was introduced as the memory layer.

When a decision is created, relevant information can be sent to Hindsight for retention.

The important information includes:

* Decision context
* Reasoning
* Assumptions
* Expected outcome

The purpose is to make the decision available for future recall.

---

### Step 5 — Build Memory Recall

The next step was testing memory retrieval.



```text id="ps5z7x"
POST /api/memories/recall

The backend sends a query describing a situation and receives relevant memories.

This was an important stage because persistent memory is only useful if the system can retrieve relevant information when it is needed.

Testing different query descriptions helped build an understanding of how the memory service responds to different situations.

Step 6 — Connect the Dashboard

Only after the backend workflow was tested independently was the React dashboard connected to the API.

This created a clear separation:

```text id="g3kz5r"
Frontend
↓
FastAPI API
↓
Application Logic
↓
Hindsight Cloud




This approach also made debugging easier.

---

## What Has Been Tested

Being precise about testing status matters more than sounding impressive.

At the current stage:

### Tested Successfully

* Decision creation
* Decision retrieval
* Hindsight memory interaction
* Memory recall
* Backend API workflow
* Frontend/backend communication

### Still Being Verified

The analysis functionality and its complete integration with the dashboard require further verification.

Therefore, we avoid claiming that every planned analysis feature is already available as a fully verified user-interface workflow.

This distinction is important.

There is a difference between:

> "The code exists."

and:

> "The complete feature has been tested and is ready for users."

RecallIQ aims to describe the second category only when it has actually been verified.

---

## Working With an External Memory Service

Adding an external memory service introduces a different type of engineering challenge.

Creating a decision is no longer just a local operation.

The application may need to:



```text id="f1nyw8"
Receive Decision
      ↓
Validate Request
      ↓
Record Decision
      ↓
Contact Hindsight
      ↓
Retain Memory

The Hindsight request can fail because of:

Network problems
Service availability
Invalid credentials
Incorrect request data
Other external-service errors

This means the application should not blindly assume that an external call always succeeds.

The word "attempts" is important when describing memory retention.

The backend attempts to retain the decision, but an external service should always be treated as a possible point of failure.

Testing Memory Recall

Testing a memory system is different from testing a normal database query.

A database query might return an exact matching record.

Memory recall instead focuses on relevance.

For example, a query about:

"Reducing cloud infrastructure costs"

may recall a previous decision involving:

"Migrating workloads to a cheaper cloud provider."

The wording does not have to be identical.

This makes semantic relevance important.

During development, different query descriptions were useful for understanding how the memory layer responded.

This also highlighted an important principle:

The quality of memory recall depends on both the information that was retained and how the new situation is described.

Handling Secrets Properly

One of the simplest but most important practices was protecting API credentials.

The Hindsight API key is stored in a backend environment file and loaded through environment variables.

The basic rules are:

Never Commit `.env`

Environment files containing secrets should be excluded from version control.

Never Put API Keys in Source Code

Credentials should not be hardcoded into application files.

Never Share Credentials in Documentation

API keys should not appear in:

Screenshots
README files
Articles
Presentations
Public repositories

Keep Secrets Behind the Backend

The frontend should not need direct access to the Hindsight API key.

Instead:

```text id="kq3o9w"
React Frontend
↓
FastAPI Backend
↓
Hindsight Cloud




This keeps the credential on the server side rather than exposing it to the browser.

---

## Being Honest About the Prototype

The biggest lesson from building RecallIQ was that limitations should be stated early.

Three limitations are particularly important.

### 1. Storage Is Not Yet a Production Database

The current decision records are held in application memory.

This means they may reset when the backend restarts.

A production implementation should use persistent storage such as PostgreSQL.

### 2. Analysis Is Limited

The current approach uses predefined logic rather than relying on an LLM to generate the analysis.

This makes the system transparent, but it also means that it can only identify patterns that have been explicitly defined.

### 3. Humans Stay Responsible

RecallIQ is a decision-support system.

The output should not be treated as an autonomous decision.

A person should review the information before taking action.

---

## Why These Limitations Matter

It may seem strange to emphasize limitations in a hackathon article.

But doing so actually improves the technical credibility of the project.

A prototype does not need to pretend to be production-ready.

Instead, every limitation can become a roadmap item.

For example:



```text id="l3k1w4"
In-Memory Storage
       ↓
PostgreSQL

Rule-Based Analysis
       ↓
Grounded LLM Analysis

Basic Decision Record
       ↓
Outcome Tracking

Single Prototype
       ↓
Team Workspaces

The current system therefore provides a foundation rather than pretending to be the final product.

Lessons for Other Builders

Several lessons from developing RecallIQ are useful beyond this project.

Test the Backend Independently

Swagger UI can act as an API test bench.

Testing the backend separately makes it easier to identify where problems occur.

Separate Memory From Reasoning

Memory retrieval and decision analysis are different responsibilities.

Keeping them separate makes the architecture easier to understand and modify.

Track Claims Against Evidence

For every feature described in documentation, ask:

Has this actually been tested?

If the answer is no, describe it as planned or under development rather than completed.

Protect Secrets From Day One

It is much easier to prevent a credential from being exposed than to clean up a leaked credential later.

Prefer Honest Scope

A smaller system with accurate claims is more useful than a large description filled with features that have not been verified.

What We Would Improve Next

The current development experience points toward several improvements.

Persistent Database

Move decision records from application memory to PostgreSQL or another production database.

Better Analysis

Introduce more sophisticated contextual analysis while keeping the reasoning traceable.

Outcome Tracking

Record what actually happened after a decision and compare it with the expected outcome.

Better Memory Relevance

Improve filtering and retrieval so that users see the most useful historical decisions.

Citations

Connect recommendations to the exact historical decisions that support them.

Authentication

Introduce user accounts and team-level access control.

Evaluation

Measure whether the recommendations are actually useful rather than assuming they are.

The Development Philosophy

The technical choices behind RecallIQ can be summarized in a few principles:

Build incrementally.

Test each layer independently.

Keep responsibilities separated.

Protect credentials.

Track claims against evidence.

Be honest about limitations.

These principles are not specific to RecallIQ.

They are useful when building almost any AI-enabled application.

Conclusion

RecallIQ came together quickly because the technology stack encouraged short development and testing cycles.

FastAPI made it possible to test the backend independently.

React and TypeScript provided the dashboard layer.

Pydantic provided structured validation.

Hindsight Cloud provided the persistent-memory component.

Most importantly, the project stayed grounded by distinguishing between what had been implemented, what had been tested, and what remained on the roadmap.

A hackathon project does not need to be perfect.

It needs to demonstrate a meaningful idea, show a working foundation, and communicate clearly what exists today and what can come next.

RecallIQ's development process reinforced that principle:

Build fast, test honestly, and make the next improvement obvious.

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: Designing Trustworthy Decision Analysis Without an LLM

Part 4 — Building RecallIQ: Development Workflow, Testing and What We Learned ← You are here

➡️ Part 5 — From Decision Memory to Decision Learning: The Future of RecallIQ

This article is Part 4 of the RecallIQ technical series exploring persistent memory, trustworthy decision support, and the evolution from decision memory to decision learning.

Memory Plus Rules: Designing Trustworthy Decision Analysis Without an LLM

Dikshith Somishetty — Tue, 29 Sep 2026 15:34:39 +0000

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.

Inside RecallIQ: Building a Decision-Memory System with FastAPI, React and Hindsight Cloud

Dikshith Somishetty — Tue, 29 Sep 2026 15:29:03 +0000

RecallIQ — Part 2 of 5

A technical deep dive into the architecture, API design, persistent memory layer, and rule-based decision analysis behind RecallIQ.

A Decision-Memory App in Three Layers

RecallIQ helps teams keep the reasoning behind their decisions so that past experience can inform future choices.

This article looks under the hood:

How the application is structured
How it uses Hindsight Cloud for persistent memory
How recalled memories are combined with preliminary risk checks
What is working today
What is not yet implemented or verified

The goal is to keep the architecture simple, understandable, and honest about the current prototype's capabilities.

The Technology Stack

RecallIQ is built using a lightweight stack designed for rapid development and clear separation of responsibilities.

Layer	Technology
Frontend	React, TypeScript and Vite
Backend	Python with FastAPI
Data Validation	Pydantic
Memory Service	Hindsight Cloud
Development & Testing	Cursor, Browser, PowerShell and FastAPI Swagger UI

Why FastAPI?

FastAPI was a natural fit for the backend because it automatically generates interactive API documentation through Swagger UI.

This allowed us to test individual endpoints directly from the browser before the dashboard was connected.

For example, we could create a decision through the API, inspect the response, and verify the behavior independently of the frontend.

Why Pydantic?

Pydantic provides validated request and response models.

This means that malformed requests can be rejected early with clear validation errors.

For example, a decision without a required title or with incorrectly structured fields can be caught before the request reaches the application logic.

System Architecture

The flow of RecallIQ is deliberately simple.

┌──────────────────────────────┐
│          User                │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ React + TypeScript Dashboard │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       FastAPI Backend        │
└───────┬──────────────┬───────┘
        │              │
        ▼              ▼
┌──────────────┐  ┌────────────────┐
│   Decision   │  │ Hindsight Cloud│
│   Records    │  │ Memory Service │
└──────────────┘  └───────┬────────┘
                          │
                          ▼
                   Relevant Memories
                          │
                          ▼
                   Rule-Based Analysis
                          │
                          ▼
                Risks + Recommendations

A user works through the React and TypeScript dashboard.

The dashboard communicates with the FastAPI backend.

The backend manages decision records and communicates with Hindsight Cloud.

This separation is intentional.

The frontend never communicates directly with the memory service.

Creating a Decision

When a user creates a decision, the backend performs two important operations.

1. Record the decision

The backend receives the decision information and records it.

A decision contains:

Title
Description
Assumptions
Expected outcome
Status

The status can be:

pending
successful
failed
warning

2. Retain the decision in Hindsight

The backend then attempts to retain the decision-related information in Hindsight.

This allows important context to survive beyond a single application session.

The flow can be summarized as:

User creates decision
        ↓
FastAPI receives request
        ↓
Validate with Pydantic
        ↓
Record decision
        ↓
Send relevant information to Hindsight
        ↓
Memory retained

The use of the word "attempts" is deliberate.

Because Hindsight is an external service, a network request can fail. The application should therefore handle external-service failures rather than assuming that every retention request succeeds.

Recalling Memories

The second major operation is memory recall.

Later, when a user is dealing with a new situation, the backend can send a query describing that situation to Hindsight.

Hindsight returns memories that are relevant to the query.

The flow looks like:

New decision or situation
          ↓
FastAPI creates recall query
          ↓
Hindsight Cloud
          ↓
Relevant memories
          ↓
FastAPI returns results
          ↓
User receives historical context

The important point is that recall is not simply a keyword lookup.

The memory service attempts to find information that is relevant to the situation being described.

This means that the quality of recalled memories depends on both:

What information was previously retained
How the new situation is described

The API Surface

RecallIQ currently exposes several backend endpoints.

`POST /api/decisions`

Creates a new decision.

A successful creation returns HTTP 201.

`GET /api/decisions`

Retrieves the recorded decisions.

`POST /api/memories/recall`

Retrieves relevant memories from Hindsight.

`POST /api/decisions/analyze`

Retrieves related memories and applies the predefined risk rules to produce potential risks and recommendations.

`POST /api/memories/retain`

Requests memory retention directly.

The API-first approach made it possible to test the backend independently before connecting everything to the dashboard.

Why Decision Status Matters

A decision is not simply a piece of historical information.

Its outcome matters.

For example:

Decision A
Status: Successful

is a very different signal from:

Decision B
Status: Failed

And:

Decision C
Status: Warning

may indicate that the approach worked but introduced problems worth remembering.

This is why RecallIQ stores decision status alongside the decision context.

When a relevant memory is recalled, the person reviewing it can understand not only what was tried, but also how it turned out.

How Hindsight Is Used

Hindsight is the persistent-memory component of RecallIQ.

It plays two primary roles.

Retention

When a decision is created, the backend sends relevant information to Hindsight for retention.

This can include:

The decision
Reasoning
Assumptions
Expected outcome
Other relevant context

This is what allows the information to outlive a single session.

Recall

Later, the backend submits a query describing a new situation.

Hindsight returns memories that are relevant to that situation.

Those memories provide historical context:

What was tried before?

What was assumed?

What happened?

Was the previous decision successful or problematic?

It is important to be precise about the division of responsibility.

Hindsight supplies the memories.

Our backend performs the analysis.

Hindsight does not generate the final risk analysis used by RecallIQ.

From Recalled Memories to Risks and Recommendations

The analysis endpoint combines two inputs:

Memories recalled from Hindsight
Predefined risk rules

The rules look for known patterns in the new decision's text.

When a pattern is matched, the system produces a potential risk and a corresponding recommendation.

A Worked Example

Consider the decision:

Migrate to a cheaper cloud provider

The description is:

Reduce cloud spending by moving to a cheaper provider.

The assumptions are:

Costs will decrease 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.

The rules identify three potential risks.

Risk 1 — Data Transfer and Migration Costs

Data-transfer charges and one-time migration costs may reduce the expected savings.

Recommendation: Calculate the total cost of ownership rather than comparing provider prices alone.

Risk 2 — Performance or Reliability

Moving workloads could affect latency, performance, or reliability.

Recommendation: Benchmark the workload before and after migration.

Risk 3 — Incomplete Savings Estimates

The estimated savings may not include recurring or one-time costs.

Recommendation: Validate the assumptions and include all relevant costs before committing.

If Hindsight also recalls a previous decision involving similar assumptions, that memory appears alongside the rule output.

This makes the warning more specific to the team's own history.

Why Start With Rules?

The rule-based design is limited, but it has several useful characteristics for an early prototype.

Transparency

Anyone can read the rule and understand why a risk was raised.

There is no hidden reasoning to audit.

Predictability

The same input produces the same output.

This makes the system easier to test and demonstrate.

No Fabricated Content

A rule cannot invent a risk that nobody defined.

The purpose is to prompt careful thinking rather than produce an authoritative-sounding answer.

Lower Complexity

The system does not require additional model calls for the current analysis layer.

This keeps the prototype simpler and easier to debug.

Current Status

The current state of the prototype is deliberately described conservatively.

Working

React and TypeScript dashboard
FastAPI backend
Decision creation
Hindsight memory retention/recall workflow
Decision retrieval

Decision creation and Hindsight memory recall have been tested successfully.

Still Being Verified

The analysis endpoint has been added to the backend, but its availability and integration with the dashboard still need verification.

Therefore, we do not claim that users can currently run the complete analysis workflow directly from the dashboard.

This distinction is important.

A feature existing in backend code is not the same as a feature being fully verified and available through the user interface.

Known Limitations

In-Memory Storage

The current decision list is held in a Python list inside the running backend.

This means it may reset when the backend restarts.

It should not be treated as a production database.

Rule-Based Analysis

The analysis is not generated by an LLM.

The rules cover selected patterns only and should not be considered a comprehensive risk assessment.

Human Review

The results are preliminary.

A person should review the output before acting on any recommendation.

Security Practice

The Hindsight API key is stored in a backend environment file and loaded through environment variables.

The basic security practices are:

Never commit the .env file.
Never place API keys directly in source code.
Never include credentials in screenshots or documentation.
Keep the memory service behind the backend.

The final point is particularly important.

Because the frontend communicates only with our backend, the Hindsight credentials do not need to reach the browser.

These practices may seem small, but they are important when moving from a demo toward a deployable system.

What Comes Next?

The current prototype provides the foundation for several future improvements.

1. Persistent Database

Add a database such as PostgreSQL so that decisions survive backend restarts.

2. LLM-Generated Analysis

Integrate an LLM that can analyze a new decision together with the relevant memories.

3. Outcome Tracking

Track what actually happened after a decision and compare it with the expected outcome.

4. Better Memory Relevance

Improve memory filtering, relevance, and citations.

5. Authentication and Team Workspaces

Allow different teams to maintain separate decision histories with appropriate access control.

6. Feedback and Evaluation

Allow users to indicate whether a risk or recommendation was useful.

This would provide data for evaluating whether RecallIQ is actually helping teams make more informed decisions.

Conclusion

RecallIQ demonstrates a simple architectural idea:

Persistent memory should be separated from reasoning.

Hindsight provides the memory.

FastAPI manages the application logic.

Predefined rules provide transparent preliminary analysis.

React and TypeScript provide the user interface.

This separation makes the prototype easier to understand, test, and improve.

The larger goal is to move beyond simply storing decisions.

The goal is to build a system that can remember what a team tried, understand what happened, and eventually help the team learn from that history.

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 ← You are here

Part 3 — Memory Plus Rules: Designing Trustworthy Decision Analysis Without an LLM

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 2 of the RecallIQ technical series exploring persistent memory, trustworthy decision support, and the evolution from decision memory to decision learning.

The Problem of Forgotten Decisions: Why AI Systems Need Persistent Memory

Dikshith Somishetty — Tue, 29 Sep 2026 15:17:47 +0000

RecallIQ — Part 1 of 5

A technical series exploring how persistent memory can help teams preserve decision context, learn from past outcomes, and make better-informed decisions.

The Decision Nobody Can Explain

Every team makes dozens of decisions each week.

Which cloud provider should we use? Should we adopt this framework? Is it time to change how we ship releases?

Most of these choices are made in meetings, chat threads, and quick conversations. Weeks or months later, the outcome is visible to everyone, but the reasoning behind it has often vanished.

Why did we choose that vendor?

What did we assume about cost?

What risk did someone raise that we decided to accept?

This is the problem of forgotten decisions, and it is far more expensive than it looks.

When the context of a decision is lost, the organization loses its ability to learn from its own history. Each new decision is treated as if it were the first of its kind.

What Actually Gets Lost

A decision is more than its final answer. A useful record contains several layers of context:

The decision itself: what was chosen and what was rejected.
The assumptions: the beliefs the choice depended on, such as "costs will fall by 20%" or "performance will stay stable."
The expected outcome: what success was supposed to look like.
The lessons learned: what actually happened, and whether the assumptions held.

In most teams, these layers are scattered.

The decision might live in a slide deck, the assumptions in a chat thread, and the lessons in someone's memory.

When that person changes roles or leaves, the lessons leave with them.

Three Illustrative Scenarios

The following scenarios are illustrative examples of a pattern many teams will recognize, not reports of specific incidents.

The Cheaper Cloud Provider

A team moves workloads to a cheaper provider to cut monthly spending.

The plan assumed savings of at least 20% and minimal data-transfer fees.

Months later, transfer charges and one-time migration work have eaten much of the saving, and latency has crept up.

A year on, a new engineer proposes the same kind of migration for a different service.

Nobody remembers that the first attempt disappointed, or why.

The Technology Switch

A startup adopts a new database because it looked faster in benchmarks.

The team later discovers operational gaps in monitoring and backups.

Eighteen months afterwards, a different technical lead is drawn to another new tool for similar reasons, and the same gaps are rediscovered.

The Workflow Change

A project manager removes a review step to speed up delivery.

Defects rise, and the step is quietly reinstated.

Two quarters later, under deadline pressure, someone suggests removing it again.

In each case, the failure is not a lack of intelligence.

It is a lack of memory.

The organization had the experience but could not retrieve it at the moment it mattered.

Why Notes and Documents Are Not Enough

The obvious answer is:

"Write it down."

And many teams try.

Wikis, decision logs, and retrospectives all help, but they share three weaknesses.

1. They depend on someone remembering to write the record

A decision may happen quickly, and the person involved may never document the assumptions or reasoning behind it.

2. Information is organized around where it was stored

A decision might be in a document, a meeting recording, a chat message, or a presentation.

But when someone faces a new decision, they are usually thinking about the problem, not where a similar decision was documented years ago.

3. Nobody searches at the right moment

A person facing a new decision rarely thinks:

"Was there a similar decision two years ago?"

And even if they do, traditional keyword search only works if they already know which words to search for.

What teams need is not simply a bigger archive.

They need a system that can surface relevant past experience when a similar decision comes up.

Why AI Systems Need Persistent Memory

The same weakness appears in AI systems.

A typical AI assistant can reason well within a conversation, but once the session ends, the context may no longer be available in the same way.

Ask it about a decision you discussed last month and, without persistent memory, it may have to start from zero.

Persistent memory changes this.

If an AI-enabled application can retain information across sessions and retrieve the parts that are relevant to a new question, it can provide continuity:

"You considered something like this before. Here is what you assumed, and here is what happened."

For decision support, this continuity is important.

Good advice about a choice depends on the history around it, not only on general knowledge.

Persistent memory also helps with a subtler issue: assumptions.

Most failed decisions rest on assumptions that were never written down or checked.

A memory system that stores assumptions next to expected outcomes makes them visible and testable the next time a similar choice appears.

Introducing RecallIQ

RecallIQ is a decision-memory system built to explore exactly this idea.

It lets a user record a decision with:

A title
A description
Assumptions
An expected outcome
A status

The status can be:

Pending
Successful
Failed
Warning

The information is retained through Hindsight Cloud, a persistent-memory service, so that it can be retrieved later when a related decision arises.

From memory to decision support

When a user is about to make a new decision, RecallIQ can recall relevant memories and pair them with a set of predefined risk checks.

For example, for a cloud-migration decision, the checks can flag that:

Data-transfer and migration costs may reduce savings.
Performance or reliability may change.
Savings estimates may omit recurring or one-time costs.

The recommendations are practical:

Calculate total cost of ownership.
Benchmark performance.
Validate assumptions before committing.

The goal is not to make the decision for the user.

The goal is to make relevant past experience visible before the decision is made.

How RecallIQ Is Built

RecallIQ is a web application with three primary layers:

Frontend

React + TypeScript + Vite

The dashboard provides the interface for creating decisions and interacting with the system.

Backend

Python + FastAPI

The backend handles decision records, API requests, memory operations, and the preliminary risk-analysis logic.

Memory Layer

Hindsight Cloud

Hindsight provides persistent memory so that information can survive beyond a single conversation or application session.

The architecture can be summarized as:

User
  ↓
React + TypeScript Dashboard
  ↓
FastAPI Backend
  ↓
 ┌───────────────────────┐
 │                       │
 ↓                       ↓
Decision Records     Hindsight Cloud
                         │
                         ↓
                  Relevant Memories
                         │
                         ↓
                  Rule-Based Analysis
                         │
                         ↓
                  Risks + Recommendations

Decision creation and memory recall have been tested successfully.

Being Honest About the Limits

RecallIQ is a prototype, and it is important to be clear about what it is not.

Rule-Based Analysis

The current risk analysis is rule-based rather than generated by a language model.

It covers selected patterns rather than providing a comprehensive risk assessment.

Hindsight Provides Memory

Hindsight provides the memory layer.

It does not generate the final risk analysis.

The analysis is performed by our backend.

In-Memory Decision Storage

The current list of decisions is held in application memory.

Because of this, the data can reset when the backend restarts. It should not be treated as a production database.

Human Review

All output should be reviewed by a human before anyone acts on it.

RecallIQ is designed to support decision-making, not replace human judgment.

These limitations also point directly toward the next stage of development:

A persistent database
LLM-generated analysis grounded in recalled memories
Tracking actual outcomes against expected outcomes
Evaluation of whether recommendations are genuinely useful

The Bigger Idea

Forgotten decisions are a quiet, compounding cost.

Teams can repeat unsuccessful approaches and overlook risks they have already encountered, not because the knowledge never existed, but because it could not be found when needed.

Persistent memory offers a way to treat decisions as part of a continuing story rather than isolated events.

Instead of asking:

"What should we do?"

a decision-support system can also ask:

"What have we tried before?"

"What did we assume?"

"What happened?"

"What should we check this time?"

That shift—from isolated decisions to accumulated organizational memory—is the core idea behind RecallIQ.

Conclusion

RecallIQ is an early exploration of what happens when persistent memory is placed behind a decision-support system.

It combines:

Decision Records + Persistent Memory + Transparent Risk Rules

The current prototype demonstrates the core idea: past decisions can be retained and recalled so that relevant experience is available when a new decision arises.

The longer-term vision is to move from simply remembering decisions to learning from their outcomes.

That journey is the focus of the remaining articles in this series.

Explore RecallIQ

🔗 GitHub Repository: https://github.com/ravikanthbojja44-create/Recall-IQ

RecallIQ Series

Part 1 — The Problem of Forgotten Decisions ← You are here

Part 2 — Inside RecallIQ: Building a Decision-Memory System with FastAPI, React and Hindsight Cloud

Part 3 — Memory Plus Rules: Designing Trustworthy Decision Analysis Without an LLM

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 of the RecallIQ technical series exploring persistent memory, trustworthy decision support, and the evolution from decision memory to decision learning.

DEV Community: Dikshith Somishetty

From Decision Memory to Decision Learning: The Future of RecallIQ

What RecallIQ Is Today

1. A Persistent Database

PostgreSQL

Keeping the Good Parts

Ground the Model in Recalled Memories

Keep Rules as a Baseline

Show Supporting Evidence

Keep a Human in the Loop

3. Tracking Actual Outcomes

5. Authentication and Team Workspaces

A Suggested Development Order

1. Persistent Database

2. Outcome Tracking

3. Relevance, Filtering and Citations

4. LLM-Generated Analysis

5. Authentication and Team Workspaces

6. Feedback and Evaluation

What the Future Could Look Like

Conclusion

Explore RecallIQ

RecallIQ Series

Building RecallIQ: Development Workflow, Testing and What We Learned

Building for a Hackathon

Choosing a Stack for Speed and Clarity

React + TypeScript + Vite

Python + FastAPI

Pydantic

Hindsight Cloud

Backend First, Dashboard Second

Step 3 — Retrieve Decisions

Step 6 — Connect the Dashboard

Testing Memory Recall

Handling Secrets Properly

Never Commit .env

Never Put API Keys in Source Code

Never Share Credentials in Documentation

Keep Secrets Behind the Backend

Lessons for Other Builders

Test the Backend Independently

Separate Memory From Reasoning

Track Claims Against Evidence

Protect Secrets From Day One

Prefer Honest Scope

What We Would Improve Next

Persistent Database

Better Analysis

Outcome Tracking

Better Memory Relevance

Citations

Authentication

Evaluation

The Development Philosophy

Conclusion

Explore RecallIQ

RecallIQ Series

Memory Plus Rules: Designing Trustworthy Decision Analysis Without an LLM

Start With the Question, Not the Model

The Two Inputs

Why Separate Memory From Reasoning?

A Worked Example

Risk 1 — Data Transfer and Migration Costs

Risk 2 — Performance and Reliability

Risk 3 — Incomplete Savings Estimates

What the Rules Are Actually Doing

Where Memory Changes the Picture

Why Decision Status Matters

Why Rules First Is a Useful Engineering Choice

1. Transparency

2. Predictability

3. Traceability

4. Lower Complexity

5. Easier Demonstration

The Limits We Do Not Hide

Rules Cover Selected Patterns

It Is Not a Comprehensive Risk Assessment

It Is Not an LLM-Based Analysis System

Human Review Remains Essential

Designing for Trust

Never Commit `.env`

`POST /api/decisions`

`GET /api/decisions`

`POST /api/memories/recall`

`POST /api/decisions/analyze`

`POST /api/memories/retain`