RAGret: Giving Team Decisions a Traceable Memory

A team can remember its final decision and still lose the reasoning that produced it. The proposal was in a meeting transcript, a requirement arrived in a PDF, and the reversal happened in a later discussion. Asking a model to summarize everything can produce readable text without preserving that history.

RAGret approaches the problem through decision records tied to source evidence. It turns uploaded conversations and reference material into an inspectable context graph, then uses saved decisions and passages to answer questions with citations.

Our KodoTech team won second place with RAGret-ALMA at Future Forge: The ALMA Hackathon in Cebu on October 22, 2026. The team included Raymund Zyron, John Lorenzo, and Jhon Paul. The project page includes screenshots, the presentation, and demo links. You can also watch the MVP demonstration before exploring the architecture.

Second Place at Future Forge

We presented RAGret-ALMA as a way to make team decisions traceable: connect a decision to the conversation that produced it, retain the reference material behind it, and let someone inspect the evidence supporting an answer. The competition gave that technical work a concrete outcome: a second-place finish for KodoTech.

The result is part of the project's story alongside the implementation below. The hackathon presentation and MVP demonstration show the project we brought to the event.

A Conversation and a Reference Prove Different Things

The first product distinction is between two upload libraries. Conversations contain what people discussed, proposed, approved, rejected, postponed, or changed. Reference documents provide background guidance, requirements, or policies.

A policy explaining authentication does not establish that a particular team approved an authentication feature. A discussion approving the feature does not, on its own, explain the external requirement behind it. RAGret preserves both kinds of source while giving their relationships different meanings.

That distinction is visible in the workflow. References are retained and indexed as supporting material. Conversations go through decision extraction. Messaging content comes from uploaded exports or pasted text; the app does not connect directly to a person's messaging account.

From an Upload to a Decision Record

The backend saves an original file, extracts its text, and divides it into passages with source locations. PyMuPDF supports PDF extraction and rendering so a citation can retain its page context rather than become a disconnected text string.

For a conversation, retrieval gathers relevant reference passages before calling the configured model. The model proposes structured observations: decision subjects, states, participants, constraints, actions, and supporting quotations.

The server then validates that structure and checks the quotations against the supplied passages. Only validated records feed the persistent graph. This does not prove that the model interpreted a statement correctly, but it gives a reviewer a concrete place to examine the interpretation.

Unchanged conversation extractions can be reused without another model call. Re-extraction is explicit when the conversation should be processed again with the current reference collection.

Why a Decision Needs an Identity

The same subject can appear several times: a proposal in one meeting, an approval in another, and a reversal before release. Treating every mention as an unrelated summary makes it difficult to ask what changed.

RAGret keeps stable decision identities and chronological observations, with scopes so decisions for different releases do not collapse into one record. Its backend resolves saved observations into decision states while retaining the source receipts behind them.

The identity helper illustrates one small part of that structure: normalized labels contribute to stable graph IDs. The larger workflow also needs scope and observation rules; a hash alone cannot determine whether two statements represent the same real decision.

The result is a history that can be investigated. A final state should lead back to the observations that support it, including a documented reversal when one exists.

The Graph Is a Route Into Evidence

The React interface uses React Flow to show decisions, people, sources, constraints, actions, facts, topics, and groups. Type filters, connected-path highlighting, and the minimap help users narrow a dense view.

Those controls need semantic discipline. Two decisions sharing a participant are related, but that alone does not make one depend on the other. Dependency impact follows explicit dependency links instead of treating every visible edge as a causal chain.

Evidence previews provide the next step after selecting an interesting node. A conversation preview can show the cited message and surrounding messages. A reference preview can show the supporting quotation and PDF page. Opening the source moves the reader to that message or page, and retained originals remain downloadable.

The graph therefore has a practical job: help a person move from a question, to a decision, to the original material. Its visual complexity is useful only when those steps remain understandable.

Retrieval Without an Embedding Service

The implementation uses weighted word matching, graph connections, and recency to retrieve saved decisions and evidence. It does not require a vector database, Neo4j, PostgreSQL, or an embedding service.

SQLite stores the property graph and decision records. JSON records retain source metadata and text chunks, while original files are kept locally. FastAPI and Pydantic handle the API and structured data boundary; the browser uses React, Vite, and Motion.

The current development provider is DeepSeek. An ALMA adapter exists for the organizer-provided endpoint once its actual schema and credentials are configured, but live ALMA compatibility remains unverified. The project should be evaluated as implemented rather than described as an integration it has not established.

New References Should Not Rewrite History Silently

Suppose a team uploads a revised policy after its first meeting. That policy becomes available to future conversation extractions. It does not automatically attach itself to every earlier decision or change the saved reasoning behind the original meeting.

RAGret exposes Re-extract for that purpose. A person can deliberately analyze an existing conversation with the updated reference collection. This makes a consequential operation visible instead of disguising a new interpretation as an unchanged historical record.

Stored graph and source views also remain useful when the model is unavailable. Saved evidence can be shown with an explicit label instead of presenting it as a freshly generated answer. New conversation extraction still needs a working model connection.

Try Following One Decision Backward

The prepared Northstar demonstration uses curated fictional conversation traces alongside a real public reference document. It is a suitable place to examine a decision, open its quotation, and compare the cited passage with the displayed interpretation without uploading private team material.

Start with the narrated walkthrough, then inspect the project record and presentation. Follow one decision backward through its observations and sources. Next, inspect a connected dependency and ask whether the relationship is explicit in the evidence.

For user evaluation, I would measure citation-finding success, incorrectly merged decisions, missed reversals, and how often a reader can explain why an answer is supported. No retrieval-accuracy benchmark or team-productivity gain is claimed here. The interesting result is a system that makes its reasoning trail available for inspection.