kin

What Kin records

Kin is a semantic system of record for AI-written software. The README frames the problem as follows: a diff is not the change. Git records files and line history, but it does not say what a change touches, whether it reverses an earlier fix, or how far its consequences reach. Kin records the software itself as a graph of entities, relations, changes, and provenance, and gives humans and agents one semantic authority to query and review. The project is described as an early alpha, usable today as a local CLI, a daemon, an MCP server, a review surface, and a graph backed filesystem projection, but it is pre-1.0 and expects rough edges and breaking changes. The README shows a one line signature change in ripgrep that looks harmless in the diff, yet the kin impact command names what the edit reaches before any compiler runs: first the callers of the changed signature, then everything those callers pull in. That graph is built beforehand by kin init, and impact questions are answered from graph truth rather than by re-reading the repository. Whether the change is correct stays with the compiler, the tests, and the review. The architecture is one system with clear public surfaces: kin itself, kin-vfs which projects graph owned files through normal filesystem calls, kin-editor which is the VS Code access, Kin MCP which is a typed tool bundle, and KinLab which is the hosted collaboration layer.

How the pieces fit together

Underneath the access surfaces are implementation layers that the README lists as parts of one system rather than separate products. kin-db holds graph storage, snapshots, indexing, text search, and vector search. kin-model holds the canonical types and domain models shared across the stack. kin-blobs holds content addressable blob storage. kin-search holds lexical search primitives and staged retrieval. kin-vector holds the vector and nearest neighbor substrate. kin-infer holds the inference and embedding substrate. kin-lsp is the language server enrichment that feeds the semantic layer. None of these is installed separately. Humans and agents come in through the CLI, the bundled MCP server, or the VS Code extension, and all three ask the same daemon, which answers from graph authority rather than by re-reading the tree. kin-vfs projects that same graph back through ordinary filesystem calls so editors, compilers, and build systems keep seeing files. Git sits beside the graph as an import and export boundary rather than as an answer path. The open core is Apache-2.0 and covers kin, kin-db, kin-vfs, kin-editor, plus the supporting libraries kin-model, kin-blobs, kin-search, kin-vector, kin-infer, kin-lsp, and kin-actions. KinLab is described as a proprietary product built on this open core, providing the hosted collaboration and control plane. The README also states that the benchmark specification and a standalone, dependency free bundle verifier are public so a claim can be checked without access to the system that produced it.

Admitting a repository and asking it

The shortest path starts with an install and a configuration step. On macOS or Linux the installer resolves the latest stable release, verifies its published SHA-256 checksum, installs managed binaries under the home directory, and launches setup. A user can pass an intent such as agent, local, or editor. To admit an existing repository, the command is kin init run inside the repository directory. In a detected Git repository, kin init atomically admits the complete reachable history, refs, raw objects, the exact workspace tree, and an admission policy into repository graph authority. A worktree with uncommitted edits still admits: kin init admits the committed state and discloses what it did not admit. The semantic entity and relation layer is derived for files that one of Kin's language adapters claims. The adapter registry is the whole set, and it covers TypeScript, JavaScript, Python, Go, Java, Rust, C, C++, C#, Ruby, PHP, Swift, Kotlin, and HCL or Terraform. Everything else, including Markdown, HTML, YAML, and shell scripts, is admitted as content and stays queryable as history and text but is not parsed into entities. Once admitted, a user can run kin locate to find relevant entities from an intent, kin refs to show callers and references, and kin trace to return a focal entity with nearby context. Running kin embed adds local vector similarity over the entities. Kin also ships its own agent that drives any OpenAI compatible endpoint, and it works with Claude Code, Codex, Gemini CLI, Cursor, Kiro, and Cline through a standard MCP entry. The project documents platform boundaries in detail: the core runtime ships on macOS and Linux, while the transparent filesystem projection is not yet shipped on native Windows, where WSL2 remains the recommended path.

Editorial conclusion

The repository is published under the Apache 2.0 license and its most recent commit was recorded on 2026-08-26. The source lives at https://github.com/firelock-ai/kin.