A few ideas explain how everything in Spirefy Studio fits together. Understand these, and the rest of the app and of these docs follows naturally.
The unified model
Spirefy Studio holds every API you import in one model. An OpenAPI description, an AsyncAPI definition, and an Arazzo workflow all become the same kind of entities: operations, channels, components (schemas, parameters, headers, responses), workflows, and the sources that record where each one came from. Because everything lives in one shape, you can see your whole API surface in one place, including where it overlaps. More on the model and workflows.
Mutations are command batches
Nothing edits the model in place. Every change, whether it comes from an importer or a gesture in the UI, is expressed as a small batch of commands in a format called spirefy.cmd.v1. A batch is atomic, it can reference ids it is about to create, and it leaves an ordered history that any plugin can subscribe to. One protocol carries every kind of change, which is what lets imports, manual edits, and collaboration share the same model safely. It is also the protocol the AI authoring speaks.
Everything is a plugin
The app is a thin shell with a plugin engine inside it. Pages, importers, exporters, curation engines, and tools are all plugins, loaded at startup or on demand. They are WebAssembly modules, sandboxed and wired together through typed WIT interfaces rather than calling each other directly. The Technology page is the deep tour; Plugins is how you build one.
Capabilities
A plugin gets only what its manifest asks for: specific HTTP hosts, specific filesystem paths. The host enforces those at the boundary, so a plugin cannot reach the network or the disk in ways it did not declare. That is what makes running someone else’s plugin a reasonable thing to do.