Limnic Co
INDEPENDENT SOFTWARE PROJECT · CONCEIVED, DESIGNED + BUILT BY LINDSAY GRAVES
Turn scattered information into shared knowledge
Reap is an evidence-to-knowledge system I’m building to explore a harder problem than finding information: how AI can help recover useful knowledge from years of accumulated work without losing where that knowledge came from.
Good work creates a lot of information
Over time, decisions, context, and hard-won knowledge scatter across email, documents, project systems, databases, photos, recordings, and SaaS tools.
Search can find a document. I wanted to know whether a system could reconnect what was scattered, understand what changed over time, and recover what was actually worth carrying forward.
the hypothesis
From evidence to understanding
My first model was too simple: ingest information, organize it, then let AI help make sense of it.
Designing the system exposed distinctions that mattered. A preserved file isn’t yet a trustworthy resource. Understanding what something says isn’t the same as interpreting what it means. And an AI interpretation isn’t organizational knowledge just because the model produced it.
working software
The idea became a real system.
Reap is running locally today with an authoritative resource catalog, preservation, provenance, and a browser interface over the same underlying resource truth.
The system is still being built milestone by milestone. This is the current working software—not a product mockup.
Built to preserve the connection between what Reap knows and the evidence it came from.
TRUST BY DESIGN
The boundaries are part of the system
Powerful models made it easy to generate answers. The harder engineering question was deciding what the AI should be allowed to claim.
Reap keeps original evidence, source-connected resources, machine-derived understanding, proposed interpretations, and human-accepted knowledge distinct. AI can investigate, connect, synthesize, and propose. It cannot silently turn its own conclusions into organizational truth.
Capable doesn’t mean authoritative.
Pressure Tests
Will it Reap?
Reap wasn't my first attempt to solve this class of problem. Several earlier projects had independently begun producing similar architectural needs—but they were at different stages of development, and similarity wasn't enough reason to invent a generic platform.
So I did the opposite. I set those projects aside and built Reap from first principles around one concrete problem. Only after its first knowledge loop was working and hardened did I return to the earlier projects and ask a different question:
Could they now be built as capabilities over Reap without forcing them into an abstraction they hadn't earned?
1. COMMUNICATION ANALYSIS
Years of communication → evidence-backed patterns
The most developed earlier system reached V1 for a real user preparing family-court briefs. LLMs identified communication patterns and candidate evidence while keeping interpretations connected to the underlying communications.
2. CAREER INTELLIGENCE
Work evidence → reusable career knowledge
A career system needed to recover durable evidence of experience and accomplishments, then reinterpret it for resumes, case studies, profiles, applications, and other purposes.
3. PERSONAL ARCHIVE
Scattered digital material → durable personal resources
This project explored acquiring vulnerable and single-copy material from devices and cloud systems while preserving identity, provenance, and portability.
4. email organizer
Accumulated messages → knowledge and action
The email problem wasn't simply inbox management. It asked how years of correspondence could become useful knowledge while allowing resulting actions to move into the systems where work actually happens.
5. Photo organizer
Visual evidence → searchable, interpretable resources
Photos pushed beyond text: preserve the original visual evidence while allowing machine-assisted description, search, relationships, and purpose-specific interpretation above it.
6. business closeout
Organizational evidence → knowledge that survives the business
Closing a business connected preservation to a concrete organizational question: what records, history, decisions, relationships, and knowledge need to survive after the operating systems disappear?
WHAT SURVIVED
Different problems kept revealing the same foundation.
The interpretations changed. The durable resource truth underneath them did not.
Across the experiments, the strongest common pattern was surprisingly small: acquire a resource once, preserve it once, establish its identity and provenance once, then allow different purposes to interpret it differently.
Just as important, the experiments showed me what I had not earned: a universal interpretation model. Meaning remained purpose-specific
UNDER THE HOOD
A pragmatic, modular architecture.
Real data has been one of Reap’s best tests. During acceptance, validation hit a 652 MB preserved object referenced by hundreds of logical Resources. The test suite had passed, but real-source validation ran for more than 35 minutes without completing.
Tracing the execution path exposed the problem: Reap was physically re-validating the same large object for every logical reference to it. I changed the validation boundary so each preserved object is checked once, while its logical references are validated independently. Upon re-run the same validation then completed in about 5.5 seconds.
The bug reinforced something more useful than a performance trick: realistic data can expose places where an implementation has violated its own conceptual model.
35 minutes without completing → ~5.5 seconds
my role
Built with AI. Engineered with judgment.
Reap is an independent project I conceived, designed, and am building. I developed the product model, architecture, trust boundaries, visual principles, development workflow, specifications, and acceptance process, while using AI coding agents as active collaborators throughout implementation.
The most useful failures have not been moments when AI simply got something wrong. They’ve been places where an assumption about the system failed under implementation or testing and forced the model, boundary, or specification to become more precise.
The skill I’m developing isn’t getting AI to produce more code. It’s learning how to turn ambiguous problems into systems whose behavior I can explain, test, and trust.