I spent the last year exploring the concept that context is a new data type that none of our current systems were designed to handle. Context evolves with every interaction, changes shape, is deeply nested and relational, and must be deterministic.
The Problem: We currently treat AI context like a storage problem (vector DBs) or a retrieval problem (RAG). But vectors destroy structure, and graphs are hard to version. When an agent hallucinates, it’s often because we fed it a "soup" of tokens rather than a structured, provenanced reality.
The Solution: Kantext treats Context as a first-class data type. It’s not a wrapper; it’s a composable, layered data structure where meaning is fused into the data at declaration time.
Try it: The website currently has a wasm playground (https://kantext.dev/playground) with the full composition engine available to try out through multiple scenarios. I'm working toward an open source release of the core engine soon along with full documentation.
The Architecture:
- Declared Language: A language of Declarable Shapes with layers for Value, Meaning, Space, Bond, Compose, and Boundary. Boundaries operate like JSON Schema's Definitions, but they are hierarchical and cascade.
- Context-Addressable Storage (CxAS): The parse -> decompose phase separates content and structure. These fragments are blake3 hashed with typed domains and stored in a global append-only DashMap.
- Holograph: The engine composes the decomposed, CxAS-stored content through a 2-stage k-way merge process of up to 62 Frames. We use BpTree, EliasFano, and WaveletMatrix (in pure Rust) to keep memory usage low and lookups mostly in CPU cache.
- Grounded: Every composition is cryptographically sealed to a Git commit. The Holograph's Projector can output multiple styles, including a compressed "Declared" format that is a full round-trip .kant file. Anything done in memory can be re-grounded to git.
Benchmarks (M2 Max):
Full Parse -> Holograph: ~20MB/s (Note: This is NOT just parse speed. This includes parsing, structural decomposition, Blake3 hashing for Context-Addressable Storage, deduplication, BpTree/EliasFano/WaveletMatrix construction, and cryptographic sealing. So, more like a runtime compiler than just a parser)
Query Latency: ~1-75µs
Composition: 880K points/sec, working toward goal of 1M/s
Binary: ~7MB (No external DB required)
The Backstory: Kantext started as a sort of DSL for DSLs. I spent the last decade building tooling around composable, structurally merged YAML with CumulusCI in the Salesforce ecosystem. Looking to build the evolution of that vision beyond my platform silo, I started in Python, my native language for ~20 years. About 200 Pydantic models into building a declarative delivery system DSL, I hit the composability wall.
Kantext is what came from the realization that we lacked a secure, runtime composable type system for deeply nested context that evolves across instances and interactions.
Kantext started as a yaml embedded language. Now, Kantext's language, the .kant format, uses a custom parser built on chumsky and is a super/subset of YAML with two major differences:
1. No quotes, No NO (or similar) problems: The parser is contextual. Every key is fully parsed and identified before its value. That's thanks to proc macro codegen of a nanosecond tuned parse_key fn for each Shape in the core language.
2. We replaced the yaml tag slot with a "shorthand value" slot, enabling a more ergonomic key + value + nested map pattern.
The name started as a philosophy pun that grew into technical architecture after realizing the influence of Descartes in how we think about type systems and Immanuel Kant's critique of Descartes.
I'd love to hear your feedback, and I'll be hanging out to answer any questions about the Rust internals, the data structures, or the language!