The next feature I plan to add to the mcp server is the ability to initialize it in a git repo, setting up the .kantext/ directory and will likely include.

If you want a really fun dataset, try downloading the Gene Ontology .obo files, ~24MB and the MCP loads the whole ontology into a Holograph in a few seconds.

There's a fixture loader included in the mcp server as a tool that includes that one.

My goal is to get a good selection of fixtures to test with. Thus far, it's been the prometheus helm chart, Gene Ontology, and extracts of git commits with the full git tree nested.

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!

Comments URL: https://news.ycombinator.com/item?id=47075852

Points: 1

# Comments: 2

I've spent the last ~4 months building a new Rust crate, Typesynth, based on that experience and many of the challenges highlighted in this article.

The general idea is a fully declarative, git embedded and addressable, composable context language where all declarations are decomposed, traced, stacked, merged, and stored in in-memory CAS for immutable access to everything in the composed context. Those contexts can then the "projected" into any form, yaml, json, PyO3, petgraph, etc. as needed.

My inspiration came from working on a Python codebase I initially built almost a decade ago that was based on a layered, hierarchically merged yaml "recipe" for delivery. Tasks in the framework originally had a task_options dictionary. We later built infrastructure for using Pydantic for task_options but never rolled it out to most of the tasks.

I felt the pain of that last year, trying to build UX on top of those tasks and really missing the Pydantic models. So, I went the opposite direction, building a FastAPI app with hundreds of Pydantic/SQLModel models (GitHub API, Salesforce API, Infisical API, etc).

Typesynth is my first ever Rust project. I've put a LOT of time into a proc macro framework to make the whole framework fast with the ambitious goal of composing complex yaml/json in <1ms. Rushing through the final features to be able to release the prototype and share here. Registered the placeholder crate last week!

My starting goal was to build Busbar, an evolution of the concepts of CumulusCI I created/led at Salesforce.org, a new model of delivery where the composable delivery recipes or patterns themselves were the product, not the packaged artifact.

We did some amazing things with CumulusCI over the last decade. But it still remained locked in its silo within a silo. And, it was more a prototype of the vision for true Composable Delivery.

I quickly came to realize what was lacking was a truly declarative, truly compositional language for building "config", or really n-D complexity Contexts. And that our current type systems weren't built to handle.

I'll be sharing more in the coming days about the code side proof, now built in Rust, I've been hacking away at for months now. Both Busbar, and its first module Typesynth, will be coming to GitHub as open source soon!

This blog is about the abstract theory discovered and evolved along the way. Hopefully it might spark your own discovery of a flipped bit and allow you to escape its vector gravity.

- Jason

Comments URL: https://news.ycombinator.com/item?id=43956456

Points: 1

# Comments: 1