Vellix

An AI-native editor for DocLang — structured, presentation-grade documents with the ease of markdown and the ceiling of a real document format. Version-controlled, diffable, and edited as much by AI as by you, without ever touching the XML.

Project status: pre-alpha. This README describes where Vellix is headed, not what you can install today. Commands and features below are the design target, not a promise about the current commit.

Why this exists

Markdown won the engineering world because it's plain text: diffable, version-controllable, pleasant to type, and legible to both humans and machines. But it has a ceiling. The moment you need a real table, a figure with a caption and a cross-reference, footnotes that behave, multi-column layout, or anything you'd hand to someone outside your team as a finished document, markdown taps out. That work goes back to Word and Google Docs — formats a language model can't edit surgically, only regenerate.

DocLang is an open, AI-native document standard — an LF AI & Data project backed by IBM, NVIDIA, Red Hat, ABBYY, and HumanSignal. It keeps markdown's virtues — a structured, text-based, version-controllable source of truth — while expressing what markdown can't: rich semantics, layout, tables, figures, and governance metadata, in a form that maps cleanly to how language models read and write.

There's one problem. DocLang is XML, and the reason people love markdown is that it isn't. Nobody is going to hand-author angle brackets the way they type ## Heading. A spec and a validator aren't enough — without an editor, DocLang is dead in the water.

Vellix is that editor.

What it is

Vellix is the human and the AI interface to DocLang. You edit a rendered document — headings, tables, figures — the way you'd expect to. The XML is what the editor and the AI read and write underneath; you never see it unless you go looking. The job of the editor is to give you DocLang's capabilities without making you pay DocLang's syntax tax.

It competes with "regenerate the whole document," not with your word processor's typesetting. The format is the substrate; the editor is the product.

Quickstart (intended)

# Start a new document — edit it as a rendered doc, never touch the XML
npx vellix new ./design-doc.dclg.xml

# Open an existing DocLang file
npx vellix edit ./design-doc.dclg.xml

# Already have markdown? Bring it in and keep going
npx vellix import ./notes.md

# Export something you can send to a human
npx vellix export ./design-doc.dclg.xml --to docx --theme acme-report

Bring your own model. Vellix talks to current AI providers (Anthropic, OpenAI, local models via an OpenAI-compatible endpoint) and exposes an MCP server, so agents running in Claude, Cursor, or Claude Code can edit the same document you're looking at — live, while you watch the rendered view update.

How it works

• One model, two editors. There is a single in-memory DocLang tree. Your edits and the AI's edits are both operations applied to that one tree — not a fragile sync layer between a "human view" and a "machine view." Because edits are operations, undo/redo works across both you and the AI, and you can see, diff, and accept or reject exactly what the AI changed. This is what makes "AI integrated into the process" real instead of "AI regenerates the file."
• Canonical serialization. Vellix always writes DocLang in canonical form, so two people editing the same document produce minimal, reviewable diffs. It's built to live in a repo and survive code review.
• Author from scratch or bring what you have. Start a new document directly in the editor, or import markdown — with more input formats over time. DocLang is the working source of truth; .docx, .pdf, .md, and HTML are export/render targets. Markdown is supported, never required, and you are never locked in.
• Content and presentation are separate layers. DocLang carries content, structure, and semantics — what a document means. A theme carries how it looks. The editor renders your document live under the active theme, and the same theme drives export, so what you see is close to what you ship. Keeping these apart is also what keeps the AI surgical: it edits meaning, never pixels.

Themes and the presentation layer

The boundary is deliberate: DocLang stays pure content, and the theme is a separate artifact. That keeps the source lean, keeps style changes out of content diffs (a content PR and a restyle are different reviews), and lets one theme dress many documents.

How that's stored evolves:

• Now — a separate bundle. A theme is a folder/package alongside your document. The document optionally records which theme it expects; the theme's bytes live on their own.
• Next — referenced and versioned. A document pins a theme by name and version ([email protected]), resolved from a local directory or a registry, so the same document looks the same months later. This is the brand / design-system story for companies.
• For portability — inlined at export. When you need a single self-contained artifact, the exporter bakes the resolved theme into the output. Authoring stays referenced; portability is an export concern — the way fonts live outside your source but get embedded into the PDF.

Faithful rendering to HTML and PDF is straightforward, since both speak the same styling model as the editor. .docx is the lossy target — Word's style model isn't CSS — so expect "close," not "pixel-identical," there.

Roadmap

v0.1 — prove the bet

• Render DocLang to an editable view under a default theme
• Structural editing: headings, paragraphs, lists, links, basic tables
• Markdown import
• One AI integration (bring-your-own-key) performing surgical edits through the operation model
• Canonical save to disk

Later

• Theme packages: referenced + versioned themes, live theme switching, inline-on-export
• MCP server for agentic editing
• Export to .docx / .pdf / HTML
• More import formats
• Collaborative editing (the operation model is built for it)
• Geometry / bounding-box editing for QA of machine-parsed documents

Contributing

This is early and the ground is moving — the DocLang spec itself is still young (v0.x), and shapes here are not settled. That makes it a good time to influence both. Issues, design discussion, and "this is wrong because…" are all welcome. If you work on docs-as-code, technical writing tooling, or document AI, this is your lane.

License

Apache-2.0, to match the DocLang specification.