Why Prism

Every serious app has the same problem

Open a creative or technical application and look at what it saves. A .psd, a .blend, a .sketch, a bespoke project folder — each is a private format that only its own program fully understands. That one decision quietly creates a long list of problems that every such app shares:

• 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.

This is not a niche complaint. It is the default condition of almost every file your tools produce.

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 not a blob you parse and re-emit; it 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 — not a guess at byte offsets in something only one app understands.

The wedge: AI-editable project files

The interesting position is not "an AI-native editor." Prism does not replace your tools or your assistant. The wedge is narrower and more useful:

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 instead of breaking.
• 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 rejects the impossible.
• 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 not to trap you:

• 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, not silent. Prism is the neutral middle, not a one-way door.
• It is not a moonshot format. The model is small and rests on proven ideas — path-addressed prims, typed values, connections — the same shapes that have worked at scale elsewhere.
• It is pure and portable. Prism Core depends only on the C++20 standard library and has a C ABI, so embedding it commits you to nothing.
• Adoption is incremental. Wrap an existing project as a bundle, import the formats you already have, and add structure where it pays — you don't rewrite everything to start.

Prism isn't trying to win a format war. It is trying to give the tools and agents you already use a structured file they can actually work with. Start with the Quickstart, or see how the model holds together.