Skip to main content
Normalized for Mintlify from knowledge-base/neurigraph-memory-architecture/hyperthyme-memory-framework/hyperthyme-technical-architecture.mdx.

Hyperthyme Technical Architecture Document (TAD)

Version: 1.0
Author: Oxford Pierpont
Created: January 2026
Status: Draft
Part of the Neurigraph Product Family

What’s Included:

Table of Contents

  1. Document Overview
  2. System Purpose & Scope
  3. Architecture Overview
  4. Component Specifications
  5. Data Models & Schema
  6. APIs & Interfaces
  7. Retrieval Pipeline
  8. Storage Management
  9. Security & Privacy
  10. Performance Requirements
  11. Deployment Architecture
  12. Integration Patterns
  13. Error Handling & Recovery
  14. Monitoring & Observability
  15. Future Considerations

1. Document Overview

1.1 Purpose

This Technical Architecture Document (TAD) defines the complete system design for Hyperthyme, a persistent memory layer for AI systems. It provides the technical foundation required for implementation, serving as the authoritative reference for all development decisions.

1.2 Scope

This document covers:
  • System architecture and component design
  • Data models and storage strategies
  • API specifications and integration patterns
  • Performance, security, and operational requirements
This document does NOT cover:
  • Business requirements (see PRD)
  • User interface design
  • Marketing or go-to-market strategy
  • The broader Neurigraph ecosystem (Cognigraph, etc.)

1.3 Audience

  • Software engineers implementing the system
  • DevOps engineers deploying and operating the system
  • Technical architects reviewing the design
  • Integration partners building on the platform

1.4 Definitions


2. System Purpose & Scope

2.1 Problem Statement

Current AI systems (LLMs) operate statelessly. They have no persistent memory across sessions. Users must re-explain context repeatedly, and valuable conversation history is lost.

2.2 Solution

Hyperthyme provides a persistent memory layer that:
  1. Archives complete conversations verbatim
  2. Organizes content via hierarchical knowledge graph
  3. Indexes content for fast semantic and keyword retrieval
  4. Retrieves relevant context and injects it into AI prompts
  5. Preserves significant moments as Defining Memories

2.3 Design Philosophy

Principle 1: Summaries are indexes, not storage
  • We never discard original content in favor of summaries
  • Summaries enable fast search; transcripts provide full context
Principle 2: Navigate first, search second
  • Knowledge Graph narrows search space before vector search
  • This maintains performance at scale (millions of Recall Files)
Principle 3: Preserve everything, retrieve selectively
  • Storage is cheap; token context is expensive
  • Store complete archives; inject only what’s relevant
Principle 4: Model agnostic
  • Works with any LLM (Claude, GPT, Gemini, open-source)
  • Memory persists even when switching models

2.4 System Boundaries

In Scope:
  • Conversation logging and archival
  • Knowledge graph management
  • Vector and keyword indexing
  • Memory retrieval and context injection
  • Defining Memory detection and indexing
  • Storage lifecycle management
  • API for integration
Out of Scope:
  • The AI model itself (Hyperthyme wraps around it)
  • User interface (provided by integrating applications)
  • Real-time collaboration features
  • Training or fine-tuning AI models

3. Architecture Overview

3.1 High-Level Architecture

3.2 Component Summary

3.3 Data Flow

Write Path (Logging):
Read Path (Retrieval):

4. Component Specifications

4.1 API Gateway

Purpose: Single entry point for all client requests. Responsibilities:
  • Request authentication and authorization
  • Rate limiting per user/tenant
  • Request routing to appropriate handlers
  • SSL/TLS termination
  • Request/response logging
  • API versioning
Endpoints: Configuration:

4.2 Middleware Orchestrator

Purpose: Coordinates all memory operations for a request. Responsibilities:
  • Session management (tracking active conversations)
  • Routing to Logger, Retriever, Injector
  • Token budget management
  • Error handling and fallbacks
  • Metrics collection
State Management: Each user has an active session containing:
Token Budget Logic:

4.3 Logger Component

Purpose: Captures, parses, and stores all conversation content. Responsibilities:
  • Append messages to active Recall File transcript
  • Track token count for threshold detection
  • Extract entities for Knowledge Graph updates
  • Detect Defining Memory triggers
  • Manage Recall File finalization
Message Processing:
Recall File Finalization:

4.4 Retriever Component

Purpose: Finds relevant memories for a given query. Responsibilities:
  • Execute multi-stage retrieval cascade
  • Rank and filter results
  • Load transcript content as needed
  • Manage retrieval caching
Retrieval Cascade:

4.5 Injector Component

Purpose: Builds context-enhanced prompts for AI models. Responsibilities:
  • Format memories for prompt injection
  • Manage token budget
  • Structure context for different models
  • Handle prompt templates
Context Building:

4.6 Knowledge Graph Manager

Purpose: Maintains the hierarchical structure of user knowledge. Responsibilities:
  • Create and update nodes (projects, topics, concepts)
  • Manage edges (relationships between nodes)
  • Link Recall Files to nodes
  • Support graph traversal queries
Node Types:
Edge Types:
Graph Operations:

4.7 Defining Memory Detector

Purpose: Identifies and indexes significant moments in conversations. Detection Triggers:

5. Data Models & Schema

5.1 PostgreSQL Schema

5.2 Recall File Structure

Each Recall File is stored as a folder:
summary.md Format:
keywords.txt Format:
transcript.md Format:

5.3 Object Models


6. APIs & Interfaces

6.1 REST API Specification

Base URL: https://api.hyperthyme.ai/v1

6.1.1 Chat Endpoint

POST /chat Send a message with memory-augmented context. Request:
Response:

6.1.2 Search Endpoint

POST /search Search memories without sending to AI. Request:
Response:

6.1.3 Recall Files Endpoints

GET /recall-files List user’s Recall Files. Query Parameters:
  • status: Filter by status (active, finalized, archived)
  • topic: Filter by topic (fuzzy match)
  • limit: Max results (default 20, max 100)
  • offset: Pagination offset
  • sort: Sort field (created_at, updated_at, last_accessed_at)
  • order: Sort order (asc, desc)
Response:
GET /recall-files/{id} Get specific Recall File with content. Query Parameters:
  • include: Comma-separated list (summary, keywords, transcript, artifacts)
Response:

6.1.4 Defining Memories Endpoints

GET /defining-memories List user’s Defining Memories. Query Parameters:
  • type: Filter by type (decision, milestone, event, turning_point)
  • since: Filter by date (ISO 8601)
  • limit: Max results
  • offset: Pagination offset
Response:

6.1.5 Knowledge Graph Endpoints

GET /graph/nodes Query Knowledge Graph nodes. Query Parameters:
  • type: Filter by node type
  • name: Search by name (fuzzy)
  • related_to: Find nodes related to a specific node ID
  • depth: Traversal depth for related queries
Response:
POST /graph/nodes Create or update a node. Request:

6.2 MCP (Model Context Protocol) Interface

Hyperthyme exposes tools for MCP-compatible AI systems. Tools Exposed:

6.3 SDK Interface


7. Retrieval Pipeline

7.1 Pipeline Overview

The retrieval pipeline executes a multi-stage cascade designed to efficiently find relevant memories while minimizing computational cost.

7.2 Stage Details

Stage 1: Defining Memory Check

Stage 2: Knowledge Graph Navigation

Stage 3: Keyword Filtering

Stage 5: Content Loading

7.3 Performance Optimization

Caching Strategy:
Batch Operations:

8. Storage Management

8.1 Storage Tiers

8.2 State Transitions

8.3 File Storage Layout

8.4 Storage Estimates

Scale Projections:

9. Security & Privacy

9.1 Authentication & Authorization

Authentication:
  • API key authentication for server-to-server
  • OAuth 2.0 / OIDC for user-facing applications
  • JWT tokens for session management
Authorization:
  • All data is scoped by user_id
  • No cross-user data access
  • Role-based access for admin functions

9.2 Data Encryption

At Rest:
  • All stored files encrypted with AES-256-GCM
  • Per-user encryption keys derived from master key
  • Keys stored in separate key management system
In Transit:
  • TLS 1.3 required for all connections
  • Certificate pinning for mobile SDKs

9.3 Data Isolation

Tenant Isolation:
  • Logical isolation via user_id filtering on all queries
  • Consider physical isolation (separate databases) for enterprise tier

9.4 Audit Logging

9.5 Data Retention & Deletion

Retention Policy:
  • Default: Indefinite (user controls)
  • Configurable per-user retention limits
  • GDPR/CCPA compliant deletion on request
Deletion Process:

10. Performance Requirements

10.1 Latency Targets

10.2 Throughput Targets

10.3 Availability Targets

10.4 Scalability Requirements

Horizontal Scaling:
  • API Gateway: Stateless, scale by adding instances
  • Core Engine: Stateless workers behind load balancer
  • PostgreSQL: Read replicas for query scaling
  • Vector DB: Sharding by user_id range
Vertical Scaling:
  • Start with reasonable instance sizes
  • Scale up before scaling out for simplicity
  • Document scaling thresholds

10.5 Resource Budgets

Per Request:
Per User:

11. Deployment Architecture

11.1 Infrastructure Overview

11.2 Container Configuration

Dockerfile:
docker-compose.yml (Development):

11.3 Kubernetes Configuration

Deployment:

11.4 Environment Configuration


12. Integration Patterns

12.1 Direct API Integration

12.2 LangChain Integration

12.3 MCP Server Implementation

12.4 Webhook Integration


13. Error Handling & Recovery

13.1 Error Categories

13.2 Error Response Format

13.3 Retry Logic

13.4 Circuit Breaker

13.5 Data Recovery


14. Monitoring & Observability

14.1 Metrics

14.2 Logging

14.3 Tracing

14.4 Alerting

14.5 Health Checks


15. Future Considerations

15.1 Planned Enhancements

Short-term (3-6 months):
  • Multi-language support for summaries and keywords
  • Custom embedding model fine-tuning
  • Batch import/export functionality
  • Advanced search filters (date ranges, sentiment, etc.)
Medium-term (6-12 months):
  • Team/organization shared memories
  • Memory sharing with privacy controls
  • Real-time collaboration features
  • Mobile SDK
Long-term (12+ months):
  • Federated memory across multiple Hyperthyme instances
  • On-device memory (edge deployment)
  • Integration with Cognigraph training system
  • Memory compression and archival strategies

15.2 Migration Considerations

Database Schema Evolution:
  • Use Alembic for schema migrations
  • Maintain backward compatibility for 2 major versions
  • Document breaking changes
API Versioning:
  • URL-based versioning (/v1/, /v2/)
  • Support previous version for 12 months after deprecation
  • Provide migration guides

15.3 Scalability Roadmap


Appendix A: Glossary



Document Control:
Hyperthyme is part of the Neurigraph product family.
© 2026 Oxford Pierpont. All rights reserved.