Why Prism

Look at what an app saves

Open a creative or technical application and look at what it writes to disk. A .psd, a .blend, a .sketch, a bespoke project folder: each is a private format only its own program fully reads. That one choice carries a familiar set of costs:

• Files are opaque. Another tool reads them only through a brittle importer; a script, only through a custom library.
• Agents can't safely edit them. An AI model can regenerate a whole file and hope, but it cannot make a precise, validated change.
• Exports lose structure and imports are lossy: every trip through an interchange format drops something.
• Project folders become messy, and references break when a file moves.
• Visual state and source state diverge: what you see and what's on disk drift apart.
• Collaboration and versioning are hard because the format doesn't diff.
• And ultimately the app-specific format traps the data inside one program.

These are not edge cases. They all follow from one choice: a file only its own app can read.

What Prism is

Prism is a general-purpose structured file format for complex app and project data. A single Prism file can hold documents, diagrams, assets, graphs, metadata, references, and the imported or exported representations of other formats, and it exposes the whole file as a typed object model that tools and agents can safely inspect and mutate.

That last clause is the difference. A Prism file is a live, path-addressed tree of typed Values. "Set /world/ball.radius to 2" is a precise operation that the format validates, whether the caller is your code, the CLI, or an agent. It addresses a named Property, not a byte offset.

The wedge: AI-editable project files

The wedge is narrow and useful, and it sits beside the tools and assistant you already run:

A universal-but-practical file format for AI-editable project files.

Every problem in the list above has the same root (the file is opaque) and the same cure: give programs and agents a real structured file to talk to. Prism is that file. It gives Claude Code and similar tools something they can read in full, change precisely, and write back without losing structure.

What stops being hard

With a typed object model underneath, the chronic problems become ordinary:

• Composition: files reference files; a fix propagates instead of being re-pasted, and references resolve by path.
• Interoperability: conversion is two codecs meeting at a shared model, with defined round-trips instead of lossy guesses.
• Programmability: one library, one query surface, one mutation API for all your data.
• Agent-safety: edits are typed and validated, so an agent operates at the level of intent and the format accepts only the valid.
• Versioning: the ASCII form is sorted and diff-clean, so it reviews and merges like source code.

The honest question: why trust a new file format?

Adoption is the real hurdle, and the answer is that Prism is built to keep your data free:

• You can always get your data back out. Codecs run both directions; a within-format round-trip is the identity, and cross-format degradation is documented. Prism is the neutral middle, open at both ends.
• The model rests on proven ideas. It is small and built from Path-addressed Elements, typed Values, and connections: the same shapes that have worked at scale elsewhere.
• It is pure and portable. Kinogaki Core, for C++ and Python, rests on the C++20 standard library and has a C ABI, so embedding it stays cheap and reversible.
• Adoption is incremental. Wrap an existing project as a bundle, import the formats you already have, and add structure where it pays. You add it piece by piece.

Prism gives the tools and agents you already use a structured file they can work with directly. Start with the Quickstart, or see how the model holds together.