Frames
Semantic units with slots—structured patterns that enable navigation by meaning, not just keywords
When you describe troubleshooting a software bug, certain elements always appear: the problem itself, what triggered it, steps taken to diagnose it, the root cause discovered, and the solution applied. These elements relate to each other in predictable ways—the symptoms point toward diagnostic steps, the diagnosis reveals the cause, the cause determines the solution.
This is what we call a frame: a structured pattern where specific roles (problem, trigger, diagnosis, cause, solution) consistently appear together and relate in meaningful ways.
Recurse extracts these patterns automatically. When processing a bug report, it recognizes the troubleshooting frame. When processing meeting notes, it recognizes decision frames. When processing research papers, it recognizes argument frames. The content determines what frames emerge.
From Text to Structure
Consider troubleshooting documentation. Without frames, you have text chunks: "The application crashed when users clicked submit." "We checked the network logs and found a timeout." "The API server was hitting connection limits." "We increased the connection pool size to 100." These are separate statements with no explicit relationships.
With frames, the same content becomes structured semantic units. A Problem frame captures the symptom (application crashed), the trigger (users clicked submit), and who was affected. A Diagnosis frame records the investigation steps and findings, linking back to what problem prompted this investigation. A RootCause frame identifies the underlying issue, connecting to what diagnosis revealed it. A Solution frame documents the fix and links to what it solves.
Now you can navigate the knowledge graph: from problem to diagnosis, from diagnosis to root cause, from cause to solution. Or backwards—from a solution to what problem it originally addressed. The frames create navigable structure from previously flat text.
Adaptive Frame Discovery
The specific frame types that emerge depend on your content—research papers develop Claim and Evidence frames, bug reports develop Problem and Solution frames, meeting notes develop Decision and ActionItem frames. The system discovers these patterns automatically rather than requiring predefined schemas.
Adaptive Schemas
Learn more about how Recurse discovers frame patterns from your content without requiring predefined ontologies
Slots and Relationships
Each frame type defines slots—named places where specific information lives. A Decision frame might capture the decision itself, who made it, what options were considered, the reasoning used, and crucially, what other frames it connects to. What prior decisions or discussions led here? What technical constraints influenced this? What future work does this enable?
An Argument frame might capture the claim, supporting evidence, methodology, limitations, and related arguments. But rather than storing these as isolated text, the slots hold references to other frames. The evidence slot links to Evidence frames. The methodology slot links to Method frames. The related arguments slot links to other Argument frames. This creates a web of typed relationships—not just "these documents are similar" but "this claim is supported by this evidence, which was gathered using this method, and contradicts this other claim."
Recursive Composition
Frames don't exist in isolation—they nest and reference each other recursively. A Decision frame might reference a Discussion frame that captured what led to this decision. That Discussion frame might reference prior Decision frames that were being reconsidered, each with their own links to TechnicalConstraint frames that shaped those earlier choices. It might also reference Alternative frames that were debated but ultimately rejected, each documented with its own reasoning.
This recursive structure mirrors how concepts actually relate in practice. Not flat keyword similarity, but typed relationships you can navigate: "show me the discussions that led to this decision" or "trace back from this technical constraint to all decisions it influenced" or "find solutions that addressed similar root causes."
Navigating by Meaning
Without frames, retrieval systems match keywords and aggregate similar text. With frames, you navigate semantic structure. Instead of asking "find documents about API timeouts," you can ask "find problems where timeouts were the symptom, show me what diagnoses were performed, and surface solutions that worked." The system follows the typed relationships between frames—symptom to diagnosis to cause to solution—rather than just matching text.
This enables multi-hop reasoning across sources, traceability back to specific origins, and context assembly based on actual relationships rather than statistical similarity. You're not searching documents; you're traversing a knowledge graph where the structure itself carries meaning. As your knowledge base evolves through temporal versioning, the frame relationships preserve the reasoning chains that connect old understanding to new.