RFC: Citum API and distributed styles

CSL Development
1

As I’m running out of features to implement on the schemas and processor (which I now need feedback on), I’ve been working on two big companion features.

API

The first is the server API, with this spec outlining expanding its functionality in general, and adding support for a stateful interactive mode optimized for realtime interaction in a word-processor context, that would also be exposed in both the HTTP server and in the WASM binding.

docs/specs/SERVER_INTERACTIVE_API.md

This started with the existing pandoc/citeproc and citeproc-js/citeproc-rs APIs, but then integrated the advanced features in this processor unsupported in the CSL world (annotated bibs, integral/narrative citations, grouping bibliographies by script, etc).

Distributed Styles and Diff-based type-variants

The other, maybe related, feature is distributed style distribution and inheritance.

The latter is described in the style guide.

The CLI TUI now exposes the former:

citum-tui
citum-tui1145×793 214 KB

So what you see is here is from the embedded style registry, which includes a core of “built in” or “embedded” styles included in the processor, and then a list of others that are stored in the repo.

The idea is one could then add additional registries, where a registry is just a simple YAML list of styles and how to access them.

The two together will allow Citum styles to be assembled through distributed pieces, and the processor can handle them as if they were a complete local file.

So think, for example, of a style that references an APA style by URI, and then overrides some its behavior, but is hosted on a journal site with its own dedicated registry.

2

Per my hint above, the core of this project is closing in on feature-complete.

It has a lot of end-user oriented features not supported, or likely even possible, in CSL or CSL-M.

Citum also now has pretty robust inheritance features. But in order to really exploit that, you also need to allow distributed styles. Both are now implemented.

So a journal could set up a “registry” to describe how to access their style(s), which themselves simple extend one of the embedded styles. Here’s a hypothetical (working) example:

It’s explained more fully here, and in the linked documents.

I debated about whether to implement all this, but it didn’t add much to the compiled binary size, and I think will be useful even if this doesn’t develop into the fully-distributed ecosystem it makes possible.

Next big task is implementing this on the server crate.

3

Another thought that slowly dawned on me as I implemented distributed style inheritance is the GUI style wizard is likely not needed, and a waste of resources to fully develop and maintain, given the rapidly evolving state of LLMs. In 2026, frontier models (particularly Codex) are really good at creating these styles, which likely means open models will get there sometime in the next year or so.

The pivot is reflected in this revised spec:

In this idea, the project would instead provide a dedicated agent skill for more technical users, and the website would provide an easy-to-use frontend to that, where the non-technical users could paste example output, author guide text, etc. to create the style.

Here’s Claude Design’s interpretation of the latter idea.

Screenshot 2026-05-10 at 3.30.39 PM
Screenshot 2026-05-10 at 3.30.39 PM1920×1157 201 KB

4

Have not tested this out, but I’ve extracted an internal skill I’ve been using to develop and update styles and processing code into a more general one, which should work fine without the citum-core repo install locally. If the repo isn’t present (in your terminal session), it will read the JSON schema instead to understand the style model.

It necessarily will work better with the full context of the core repo, but hopefully this will still be useful even without that.

npx skills add citum/skills

I will note that my experience the latest frontier models generally rank as follows for this sort of work: Codex 5.5 > Claude Opus 4.7 > Gemini 3.1.