Krezl

1. Introduction & The Core Thesis

Human ingenuity is infinite. Human bandwidth is not.

Every ambitious person hits the same ceiling: not a lack of ideas, but a structural failure in tracking the expanding graph of commitments those ideas create. A founder building a fintech platform simultaneously manages regulatory filings, engineering sprints, investor relationships, and hiring pipelines. Each domain spawns sub-problems, each sub-problem spawns dependencies, and the cognitive load of holding this lattice in working memory becomes the actual bottleneck — not talent, not resources, not time.

Krezl exists to absorb that cognitive load.

It is not a project management tool. It is not a task tracker. It is a second brain — a living, structured substrate that models the full topology of what you are trying to accomplish, connects it to everything you know, and actively participates in moving it forward.

"I was able to lay digitally what it takes to start a bank. I want others to have it too."

This specification describes the architecture that makes this possible.

2. The Architecture of Ambition

The Ontology

Most productivity systems model work as flat lists or, at best, two-level hierarchies. This fails because real-world ambition is neither flat nor two-level. Building a payment platform involves regulatory strategy (a space), an infrastructure project (a project), a compliance feature (a feature), and the specific task of drafting a licensing application (a task) — and all of these connect to knowledge artifacts, conversations, and decisions made across months.

Krezl models this as a nested compositional graph with five structural primitives:

Organization — The identity boundary. Everything exists within an organization context. Multi-tenant by design: each organization operates in an isolated schema with independent data, search indices, and vector stores.

Spaces — Contexts of existence. Not folders — domains of concern. "Engineering," "Family," "Health," "Investments." Spaces can nest recursively (a space within a space), reflecting the natural hierarchy of how humans partition their attention. Each space carries its own membership and role model.

Projects — Bounded initiatives with shape and end. A project has a track (platform, mobile, backend), a workflow (the state machine governing its tasks), and a defined scope. Projects live within spaces and can nest within other projects.

Features — Coherent clusters of related work within a project. The level at which "a thing that works" is defined. Features group tasks that collectively deliver a capability.

Tasks — Atomic commitments. The indivisible unit of work: a promise made and tracked. Tasks carry state (governed by a configurable workflow DAG), priority, estimation, assignment, due dates, and completion timestamps. They live within features or directly within projects, and can decompose into subtasks.

This five-level ontology is not arbitrary. It maps directly to how ambitious initiatives actually decompose in the real world: identity → context → initiative → capability → commitment.

Resources: The Knowledge Layer

Alongside the structural primitives, Krezl maintains a first-class knowledge system. Resources are typed knowledge artifacts — files, links, notes, documents, decisions, and specifications — that attach polymorphically to any entity in the graph. A decision document can belong to a project. A research link can attach to a task. A specification can live on a feature.

Each resource carries provenance: who created it, whether it was captured by a human or generated by Aria, which conversation spawned it, and the lineage context connecting it to the broader graph.

3. Relational Topology

The Graph

Entities in Krezl are not isolated records in tables. They form a typed, weighted, directed graph through explicit relationships. Every connection between two entities carries semantic meaning:

Relationships are polymorphic — they connect any entity type to any other entity type. A task can depend on a task in a different project. A feature can reference a resource. A project can block another project in a different space.

This topology is what transforms a collection of records into a navigable map of reality. It enables:

• Critical path identification — trace the dependency chain to find what actually gates progress
• Impact analysis — when something changes, understand what else is affected
• Momentum detection — surface the work that is ready to move because its dependencies are resolved
• Blocked work escalation — identify and surface chains of blocked work before they cascade

Search: Dual-Mode Discovery

Every entity in the graph is indexed twice:

1. Full-text search via PostgreSQL tsvector — fast, exact keyword matching across titles, descriptions, and content
2. Semantic search via Qdrant vector embeddings — meaning-based discovery that finds conceptually related work even when the words don't match

This dual-mode indexing means the system can answer both "find the task titled 'SMTP server'" and "what work relates to email infrastructure?"

4. The Active Substrate

Aria

Aria is not an assistant bolted onto a database. She is the system's native intelligence layer — an operator, navigator, and curator who thinks through the user's graph.

When you interact with Aria, she has full context:

1. Identity — who you are, your role, your organization
2. Structure — the complete ontology of your spaces, projects, features, and tasks
3. Knowledge — resources, comments, and decisions attached to entities in focus
4. History — past conversations, archived sessions, and long-term memory stored as semantic embeddings
5. Topology — the relationship graph, what depends on what, what's blocked, what's ready
6. Capabilities — the full API surface, expressed as an OpenAPI specification, enabling Aria to take action

Aria operates through a single tool: the HTTP API itself. She reads the same endpoints your browser reads, writes through the same endpoints your mobile app writes. There is no separate "AI database" or "AI action layer." When Aria creates a task, it goes through the same validation, event dispatch, and indexing pipeline as a task created by a human.

Long-Term Memory

Aria maintains continuity across conversations through a semantic memory system. When a conversation is archived, it is:

1. Summarized — a concise synthesis of what was discussed and decided
2. Embedded — the summary is vectorized and stored in Qdrant
3. Linked — entities affected during the conversation are recorded as lineage

When a new conversation begins, relevant memories are retrieved via semantic search and injected into Aria's context. This means Aria remembers the decision you made three weeks ago about authentication strategy when you ask about implementing login today.

Living Scaffolds

The system does not use generic templates. When you tell Aria "I want to build a payment platform," she does not retrieve a static template. Instead:

1. Context retrieval — semantic search across your existing graph and knowledge base
2. Knowledge synthesis — relevant past decisions, resources, and patterns are assembled
3. Grounded generation — a structure is created that is tailored to your accumulated knowledge, your existing projects, and your specific context

The result is a scaffold that is alive — connected to your graph from the moment of creation, with relationships to existing work already established.

5. Integration Layer: The Second Brain Protocol

A second brain is only as valuable as its connectivity. Krezl implements a comprehensive integration layer that turns it into the central nervous system for your digital workflow.

Inbound: Capture Everything

• Inbox API — authenticated REST endpoint for direct machine-to-machine input
• Integration Registry — configurable inbound channels (email, generic webhooks) with unique receiver URLs and adapter-based payload normalization
• Email Reception — self-hosted SMTP server that receives emails directly, parses MIME content, and creates inbox items
• iOS Share Extension — universal mobile input from any app (Messages, Safari, Mail, Slack, Photos, Files)

Every inbound channel normalizes to the same primitive: an inbox item. Aria triages each item, connecting it to the existing graph or spawning new structure as needed.

Outbound: Push to Everything

• Outbound Webhooks — entity events (task.created, project.updated, etc.) pushed to external URLs with HMAC-SHA256 signature verification
• SSE Event Stream — real-time entity events via Server-Sent Events over Redis pub/sub

Bidirectional: The MCP Server

Krezl exposes Aria as a single intelligent tool via the Model Context Protocol. External AI tools — Cursor, Claude, ChatGPT, Gemini — connect to a single endpoint and interact with Aria in natural language. They don't call granular CRUD endpoints; they describe intent, and Aria orchestrates.

A developer working in Cursor can say: "The auth middleware needs a rate limiter — track this." Aria creates the task, links it to the relevant project, and files it with the right priority. The developer never leaves their editor. Their second brain absorbed it.

6. What Comes Next: The Diagnostic Terminal

Everything described above creates a foundation for something more: diagnostic intelligence.

When you have the full graph of someone's ambitions — the structure, the dependencies, the decisions, the velocity — you can do more than track it. You can diagnose it.

• Where is momentum concentrated? Where has it stalled?
• Which decisions created cascading blockers three weeks later?
• What commitments were made but never decomposed into action?
• Where is effort being spent that doesn't connect to any stated ambition?

The diagnostic terminal transforms Krezl from a system that tracks ambition into one that actively reasons about it — surfacing not just what needs to happen next, but what pattern in your execution is limiting what's possible.

This is the difference between a tool and an infrastructure. Tools help you do things. Infrastructure changes what things are possible to do.

Krezl is the active infrastructure for human ambition.