One file, one conversation, kept whole.

The envelope, and what rides inside.

A .curt file is UTF-8 JSON, tab-indented by convention. The generator field lets a writer sign its work — readers must ignore it: presence, absence, or value never affects parsing. Declared capabilities ride in extensions.

{
	"curt": "curtis-conversation",
	"version": 1,
	"generator": "[email protected]",
	"extensions": ["images-inline", "usage-metadata"],
	"conversation": {
		"id": "conv_001",
		"title": "Thursday's thread",
		"createdAt": 1760000000000,
		"updatedAt": 1760000600000,
		"messages": [
			{ "id": "m1", "role": "user",
			  "content": "hello", "timestamp": 1760000000000 },
			{ "id": "m2", "role": "assistant",
			  "content": "hi back", "model": "…",
			  "timestamp": 1760000001000 }
		]
	}
}

The envelope, field by field:

Writers may attach extra fields anywhere — tokens, images, tool-call linkage — and readers must preserve them on round-trip where possible and never fail on them. Full field tables live in the spec; a non-normative JSON Schema ships for tooling. The reference implementation is TypeScript, zero dependencies:

import { serializeCurt, parseCurt, curtFilename } from 'curt-format';

const body = serializeCurt(conversation, '[email protected]');
const back = parseCurt(body);      // CurtConversation | null — null means invalid
const name = curtFilename(back!);  // 2025-10-09 my-thread 001.curt

Strict by design.

A READER ACCEPTS A FILE WHEN, AND ONLY WHEN

1. 01
   The body parses as JSON — after ignoring at most one leading UTF-8 BOM, because Windows editors prepend one anyway.
2. 02
   curt is exactly "curtis-conversation" and version is exactly the number 1.
3. 03
   The conversation carries id and title as strings, timestamps as numbers, and a messages array in which every entry passes message validation.

Anything else is a rejection — whole-file, not a best-effort parse. Many conversations travel as a zip of .curt files. Version 1 never changes meaning; later revisions only clarify, so version-1 files stay readable forever.

Grows by extension, not by version.

Writers declare named capabilities in a top-level extensions array. A reader that doesn't know one ignores it and never rejects over it. An entry moves draft → stable when two independent implementations round-trip it. The registry is additive by rule: new entries never change how existing v1 files parse.

Full field definitions per entry: EXTENSIONS.md.

Graded, not claimed.

Implementations run executable vectors from conformance/ and claim the levels they pass — self-reported, but reproducible from the vectors. The reference implementation runs them in CI and passes L1–L4.

• L1 · CORE must Magic and version exact-match, whole-file rejection, one leading BOM tolerated, unknown fields preserved on round-trip, any JSON-number timestamp accepted.
• L2 · NAMED should curtFilename implements the <date> <slug> <suffix>.curt algorithm exactly.
• L3 · BULK may The zip-of-.curt convention: entry names from curtFilename, readers never depend on names, corrupted entries reported rather than silently dropped.
• L4+ · EXTENSION may Per-extension vectors — an extension's presence or malformation never causes rejection.

Ecosystem status — who is in, who passes what, where conformance has drifted — is tracked in CAPABILITIES.md, audited 2026-10-14.

Who reads and writes it today.

Every implementation here is the author's own — the first outside consumer is still the open item. The three newest (curt-vcon, curt-convert, curt-openwebui) depend on the curt-format package directly; the five original application readers still vendor or hand-roll the rules, so a spec revision lands in five places by hand. The ladder from ten copies to one dependency is written down in the audit.

Argued at length, and on the record.

Why a conversation format needs to exist at all — the export trap, the portability right that fails without interoperable formats, the landscape of vendor exports, training formats, transport protocols, and containers — is written up as a preprint.

.curt: A Conversations-First, LLM-Native File Format with Executable Conformance for AI Chat Portability. Jordan Newell, 2026. preprint · DOI 10.5281/zenodo.23864677

Full text lives in the preprint. Citability: the DOI is live — 10.5281/zenodo.23864677 (CC-BY); arXiv (cs.CY) pending an endorsement, and the paper mirrors there when it lands. The claim, cross-checked against the 2025–26 literature: scholarship reached generative AI — model internals, generated data, agentic portability — but never the conversation archive, and the one open export spec stops at a generic transcript. The slot is open. The paper is the argument; this format, with its executable conformance vectors, is the answer.