Lightweight Source
Keep the document structure small and straightforward, without an archive or opaque binary container around the editable text.
ONDC · Open Specification
Open Native
Document.
A lightweight, open rich-text format with readable source. Content and formatting stay exposed so people and AI can work directly with the document.
Specification DocumentsONDC
Experimental Specification
- Version
- 1.0-draft.1
- Source Encoding
- XML
- Filename Extension
- .ondc
The current prototype exports XML.
Objectives
Rich text should be as accessible to software as ordinary text. The source should remain lightweight, understandable, and usable outside any one application or cloud.
Readable Rich Text
Expose text, headings, lists, tables, and formatting in readable source, rather than only in the rendered page.
AI-First Editing
Let AI read and change the document source directly, without first converting it into a different text format.
Open and Independent
Specify the format openly so different editors, local tools, and cloud providers can implement it.
Local-First OperationUser-Controlled EncryptionSystem requirements across the apps and storage layers.
Format Rationale
Why a New
Document Format?
Rich text should remain readable at its source. The words, structure, and formatting should be directly available to the people and AI tools you authorize.
Open Native Document is an experimental format built around that goal: a lightweight text-based representation, rather than a mandatory archive around the editable document.
Reference Document
One Fable. Six Actual Files.
The same public-domain story, “The North Wind and the Sun,” appears in every file. Compare the actual source, inspect the office packages, switch to a readable preview, and download the originals.
Aesop · George Fyler Townsend
The North Wind
and the Sun
Persuasion is better than Force.
Public-Domain TextDOCX, ODT, and PDF exported with LibreOffice 24.2.7.2. ONDC follows the current draft. Preview typography is normalized; the PDF preview is rendered from the actual file.
File Structure and AI Access
A filesystem connection gives an AI access to files; it does not automatically decode every file type. Office packages need an archive-aware path. Readable ONDC source can use ordinary text tools.
AI Access to Local Files
Illustrated tool sequence · No live AI or timing benchmark
Find the moral and change “Force” to “force”.
DOCX · Open
read_file("fables/north-wind.docx")50 4b 03 04 … ZIP package
A plain file reader sees archive bytes. The text is inside the package.
ONDC · Open
read_file("fables/north-wind.ondc")<p id="moral"><span italic="true">Persuasion is better than Force.</span></p>
The document source is already readable text. Content and formatting are visible together.
Both paths can work. ONDC removes the mandatory archive step for readable document text. Tools still need permission, unlocked content, and validation; a short source file alone does not guarantee correct AI edits.
Source Size and Model Context
Source markup uses space alongside the words. These bars show the original character counts of the document body file, before display formatting.
ONDC is shorter than the generated office body files here. Markdown is smaller still, and HTML is similar to ONDC. A format-aware tool can select only the content it needs.
DOCX2,764 characters
ODT4,388 characters
Markdown764 characters
HTML1,205 characters
ONDC1,207 characters
Measured for this sample, not model-token counts or a general size guarantee. Office styles and relationships are excluded from body-source counts. ZIP compression can reduce stored bytes; it does not make an archive directly readable as text.
Benefits and Limitations
The gain is direct access to a document-focused rich-text source. It comes with the work of building a new format and its ecosystem.
Design Benefits
Direct File Access
A text-based tool can open the rich-text source directly. There is no required archive extraction step for the document body.
Content and Formatting Together
AI can inspect the text and its rich-text structure, rather than receiving only a flattened text extraction.
An Independent Document Model
The specification is intended for different editors and providers, with readable files that can remain useful outside a hosted account.
Current Limitations
An Experimental Ecosystem
The draft and editor cover a limited feature set. Full layout, mature conversion, and independent implementations still require work.
Readable Does Not Mean Automatically Correct
AI tools still need to understand the document rules, preserve unsupported content, and validate changes.
Plain Source and Encrypted Storage Are Separate
Only authorized tools should see unlocked content. Images may remain separate binary assets; encrypted files cannot be searched as plaintext.
Format Comparison
Different Formats, Different Tradeoffs
| Format | Source Access | Strengths | Tradeoffs |
|---|---|---|---|
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
|
Specification Documents
ONDC-TN-001 · Technical Note
Lightweight rich-text source, direct AI access, open implementation, and storage boundaries.
ONDC-TN-002 · Technical Note
Reference text, actual sample files, measurements, preview behavior, and evidence limits.
ONDC-RFC-001 · Draft RFC
Proposal requirements, technical review, decision authority, and publication.
ONDC-RFC-002 · Draft RFC
Version identifiers, feature profiles, compatibility, and migration requirements.
The architecture note is non-normative. The RFCs propose project governance and release policies; they have not been adopted.
November 2026
Implementation Roadmap
Milestones distinguish the local prototype from planned cloud and interoperability work. Planned stages have no committed release dates.
Implemented
Readable Document Source
A working XML format with rich-text editing, parsing, validation, and saving. The editor supports a defined subset of the broader draft.
Implemented
Encrypted Local Workspace
A document library, checkpoint autosave, session passphrases, and personal recovery keys. The vault is separate from plaintext XML exports.
In Progress
Editor and Specification
Expand usable formatting, document supported profiles, and align schemas, examples, and preservation rules.
Planned
Recovery and Security Review
Encrypted backup and restore, portability checks, and independent review of the encryption and recovery design.
Planned
Sync and Self-Hosting
Remote persistence, accounts, synchronization, and an independently operable server with a complete migration path.
Planned
Collaboration and Interoperability
Shared editing, full document layout, measured office-format conversion, and independent implementation testing.
RFC Process
A Request for Comments (RFC) defines a proposed technical change and its rationale. Our proposed project process requires documented review, implementation evidence, and an explicit decision.
- 01
Draft RFC
Define the problem, proposal, alternatives, and compatibility impact.
- 02
Technical Review
Evaluate security, interoperability, and implementation evidence.
- 03
Decision
Record acceptance, required revisions, deferral, or rejection with reasons.
- 04
Versioned Release
Publish accepted changes with schemas, profiles, fixtures, and migration notes.
GitHub repositories and contribution terms are being prepared. Project RFCs are separate from the IETF RFC Series. Maintainer authority and decision rules remain subject to adoption.