A notation standard for
LLM-optimized data.
The Brevit Format Specification (BFS) defines a structured, versioned notation for transmitting data to Large Language Models. Like OpenAPI for REST, BFS is both a library standard and a self-describing interchange format.
[brevit:1.0]Add this header to any Brevit-compressed payload to make it self-describing.
Self-Describing
The [brevit:1.0] header tells the LLM exactly how to parse the payload.
Annotation-Based
@alias=prefix is a first-class syntax. LLMs understand it without training.
Versioned
Spec versions are stable. Update your library without breaking existing prompts.
Format Overview
Brevit Format is a plain-text, line-oriented encoding of structured data. It's designed to be maximally token-efficient while remaining fully parseable by any LLM without special training.
Key-Value (Flat Object)
Nested objects become dot-notation paths. No spaces around the colon.
Input (JSON)
{"user": {"name": "Jane", "role": "admin"}}Brevit Output
user.name:Jane user.role:admin
Primitive Array
Arrays of primitives use comma-separated format with count prefix.
Input (JSON)
{"tags": ["ai", "nlp", "api"]}Brevit Output
tags[3]:ai,nlp,api
Tabular Array (Uniform Objects)
Arrays of same-schema objects use compact tabular format.
Input (JSON)
{"items": [{"sku":"A1","qty":2},{"sku":"B3","qty":1}]}Brevit Output
items[2]{sku,qty}:
A1,2
B3,1Abbreviations
Repeated prefixes get @alias shortcuts when it saves tokens net.
Input (JSON)
{"user": {"name":"J","email":"j@x.com","role":"admin"}}Brevit Output
@u=user @u.name:J @u.email:j@x.com @u.role:admin
Annotation Syntax Reference
Brevit Format uses a small set of annotations. All annotations are valid UTF-8 plain text — no binary encoding, no escaping (except for commas and quotes inside values).
| Syntax | Description | Example |
|---|---|---|
@alias=prefix | Define a prefix abbreviation. alias is 1–3 chars, prefix is the full path. | @u=user.profile.settings |
key.path:value | Flattened key-value pair. Nested structure encoded via dot notation. | user.settings.theme:dark |
key[n]:v1,v2,v3 | Primitive array with element count n. | tags[3]:ai,nlp,api |
key[n]{f1,f2}: | Tabular array header. Row data follows on subsequent lines. | items[2]{sku,price}: |
[brevit:1.0] | Optional format header. Identifies the content as Brevit Format v1.0. | [brevit:1.0] |
Value Escaping Rules
- • Values containing a comma must be quoted:
"value,with,commas" - • Values containing a quote must escape it:
"value with \"quotes\"" - • Values containing newlines must be quoted:
"line1\nline2" - • All other values are unquoted:
key:plain value here
How LLMs Parse Brevit Format
Brevit Format is designed to be immediately comprehensible to any instruction-following LLM without special training. The format mirrors patterns the model already sees in its training data:
Dot notation is universal
Every LLM has seen thousands of examples of dot-notation property access in code. user.name:Jane is trivially parsed.
CSV is in every LLM's training data
Tabular format with column headers is recognizable as CSV-like. LLMs parse it as a table without prompting.
Abbreviations are self-documenting
@u=user at the top of a payload means 'when you see @u, expand to user'. This follows the LLM's understanding of variable declarations.
The [brevit:1.0] header is optional but recommended
Including the header in your system prompt tells the model to parse the content as Brevit Format v1.0 — making responses more consistent.
You will receive data in Brevit Format v1.0 [brevit:1.0].Parsing rules:- key.path:value → nested object path with value- key[n]:v1,v2,v3 → array of n primitive values- key[n]{f1,f2,...}: → tabular array header; n rows follow- @alias=prefix → when you see @alias., expand to prefix.Always interpret Brevit Format accurately. The data is semanticallyequivalent to its original JSON form.Versioning
The Brevit Format Specification follows semantic versioning. Current stable version: 1.0.