Seizn

Seize your memories. Seizn is the memory layer for AI characters, agents, and creative IP systems.

This README is written as the repo-level orientation file for human and AI operators. After reading only this file, another agent should understand what Seizn is, where the product is pivoting, how the codebase is organized, and which commands and guardrails matter.

Current Product Thesis

Seizn is not an LLM, not a vector database, and not a generic chatbot shell. It is a stateful memory operating layer around AI applications.

The core product stores, retrieves, governs, and explains long-lived context:

• memories: facts, preferences, events, instructions, experiences, relationships
• profile/persona state: stable user, character, or agent traits
• graph state: entities, relationships, provenance, external IDs, observations
• retrieval context: hybrid search, RAG, reranking, answer contracts, traceable evidence
• runtime controls: replay, budget controls, policy checks, retention, audit logs, webhooks

The current strategy is a hybrid wedge:

• Seizn Author: authoring memory for serial fiction, VN, TRPG, manga, drama rooms, and IP builders. This is the 2026-05 candidate direction. The KNOT integration is the first dogfood and PMF test.
• Seizn Live: runtime memory middleware for game NPCs and AI characters. This is the 2026-04 NPC memory pivot and remains valid.

The unifying wedge is:

Build IP and character memory in an authoring surface, then export the same memory graph into a game or agent runtime.

The product should not be positioned as "a better memory API" in the abstract. The sharper pitch is:

• memory layer for IP builders
• AI memory layer for serial fiction
• persistent memory for AI NPCs
• replayable, governable, debuggable memory for AI systems

Why This Pivot Exists

The first pivot narrowed Seizn toward game NPC memory middleware. The reasoning was that Inworld, Convai, NVIDIA ACE, and similar stacks are strong at dialogue, voice, and expression, but long-lived memory and relationship persistence remain thin.

The 2026-05 candidate pivot adds an authoring angle. While working on KNOT, the useful stack became clear:

Seizn memory + persona/profile + world/relationship graph

That same stack is valuable before runtime, while writers and IP builders are designing characters, relationships, episodes, and continuity. The market may be broader and faster to test than game studio middleware alone.

Current decision state:

• Do not treat Seizn Author as a completed full pivot yet.
• Use KNOT as the first dogfood loop.
• If the authoring workflow gives strong signal, build a Seizn Author web surface and test with a small beta group.
• If signal is weak, keep Author as an internal KNOT tool and continue Seizn Live for games.
• Core assets survive either path: SDK, MCP, Graph, Profile, memory search, replay, governance.

Differentiation

Do not sell Seizn as "better semantic search." That is commodity in 2026.

The stronger differentiation is:

The roadmap filter for new features is:

Does this make AI memory more reproducible, governable, debuggable, exportable, or useful for creators building persistent characters?

Canonical Domain Model

The active graph/person model is graph_entities, not a separate characters table.

For creative and NPC work:

• person or NPC: graph_entities row with type = "person"
• faction, location, object, incident, scene: graph_entities with the appropriate type
• relationship: graph relationship edge between entities
• memory: timestamped textual or multimodal note tied to user, namespace, agent, scope, and optional graph context
• profile/persona: stable derived state used to shape recall and context
• external ID: stable mapping from game/editor/world-bible object IDs into Seizn graph IDs

Primitive mapping for games and fiction:

Seasonal Architecture

The codebase uses seasonal codenames. They are not marketing fluff; they are the main architecture map.

These four layers are meant to compose:

Application event
  -> Spring extracts/stores memory
  -> Summer retrieves grounded context
  -> Fall records and replays behavior
  -> Winter enforces policy, deletion, residency, and auditability

Product Surfaces

Key APIs

Common production entry points:

• POST /api/v1/memories: create a memory
• GET /api/v1/memories: browse/search memories
• GET /api/v1/memories/{id}: retrieve memory details
• DELETE /api/v1/memories: delete or flush memory scope
• POST /api/v1/graph: create/list memory graphs
• POST /api/v1/graph/{graphId}/entities: create graph entities
• GET /api/v1/graph/{graphId}/entities?type=person: list people/NPCs
• GET /api/v1/graph/{graphId}/entities/by-external-id/{externalId}: map game/editor IDs to Seizn IDs
• GET /api/v1/graph/{graphId}/relationships: list relationships
• POST /api/summer/rag: document/RAG answer pipeline
• GET /api/retrieval/traces/{id}: inspect retrieval trace
• POST /api/webhooks: manage memory webhooks

Auth uses bearer API keys with the szn_ prefix. Cookie-authenticated dashboard mutations use CSRF protection.

Technology Stack

For a deeper stack inventory, see .github/TECH_STACK.md. Treat that file as implementation inventory, and this README as product and architecture orientation.

Repository Map