Definitions and canonical patterns
This page records formal definitions and compact patterns used to label, qualify, and reference budget entries. The content is an explanatory reference: it describes the shape of notation, the intended meaning of markers, and recommended conventions for preserving clarity across versions and contexts. The guidance is neutral and descriptive, focusing on consistent representation rather than operational guidance.
Overview: purpose and constraints
The definitions herein frame budgeting records as annotated language rather than executable instructions. The purpose is to make explicit how category labels, scope qualifiers, separators, and revision markers should be written so that human readers and simple parsers can interpret records consistently. Definitions favor plain-text friendliness: patterns are short, use common characters, and avoid ambiguous punctuation. Constraints include avoiding excessively domain-specific jargon, limiting symbol sets to a manageable number, and preserving original text when adding interpretive notes. Where metadata is added, it is represented as a compact tag or bracketed note to keep the primary line readable. The orientation is archival and descriptive: entries retain their original wording while the reference layer records how to read and link them to related entries across time and documents.
Key terms
- Category a singular noun phrase that names an item grouping.
- Qualifier a short suffix or bracket that clarifies scope.
- Version tag a compact string showing date and revision ordinal.
Canonical patterns
Canonical patterns define the recommended structure for a single record header. A compact canonical header preserves the label, a minimal set of qualifiers, and an optional reference tag. Pattern examples use stable punctuation and short tokens to reduce parsing ambiguity. A suggested canonical form is: Category [qualifier] • YYYY-MM-DD:v#. In this pattern, the category is a clear noun phrase, the qualifier is optional and bracketed for clarity, the separator dot groups inline qualifiers, and the version tag provides provenance. Canonical patterns emphasize a consistent order: label first, then qualifiers, then version reference. When multiple qualifiers are necessary, use ordered, comma-free tokens such as [act] or [est] to keep entries compact and unambiguous. Patterns are intentionally minimal to avoid over-loading a single line with metadata; extended explanations belong in appended notes or a separate revision log.
Symbol reference and spacing rules
A limited symbol set reduces interpretation errors. Recommended symbols include a mid-dot separator (•) for grouping inline qualifiers, an arrow (→) for explicit references to related lines or prior tags, square brackets [ ] for scoped qualifiers or short editorial notes, and simple glyphs to mark review state. Symbols should always be separated from adjacent words by a single space on each side to ensure readability in plain text and in exportable formats. For nested notes, prefer appended numbered annotations rather than deep inline nesting. When a symbol is used as part of a plain-text export, include a short legend at the top of the export that lists the symbol and its meaning. Avoid using punctuation that can be mistaken for decimal points or list markers; prefer visually distinct symbols that remain legible in monospaced contexts. Spacing rules and consistent placement—category first, then qualifiers, then tag—also support automated extraction without modifying the original textual content.
Symbol table
- • mid-dot — groups inline qualifiers
- → arrow — points to related line or previous version
- [ ] brackets — scoped qualifier or short note
- ‡ glyph — editorial marker for review or annotation
Versioning patterns and revision logs
Version tags are concise provenance markers intended to show when an entry was recorded or revised. A recommended tag format combines an ISO date with a revision ordinal, for example 2026-01-10:v3. Tags may include a short editorial suffix in brackets such as [reviewed] to indicate light editorial context. Revision logs are separate entries that pair the version tag with a one-line summary and an optional longer note stored elsewhere. When rendering active and prior versions together, place the active tag first and show prior tags in a compact list to preserve readability. Revision chains should avoid embedding complete explanations inline; instead use a linked log or appended note with an index token that references the line being explained. This keeps the primary record compact while preserving provenance and explanatory context for readers and simple extraction tools.
Tag example
Office Supplies [act] • 2026-01-10:v3 [reviewed]
Category, qualifier, separator, and version tag shown in canonical order. The bracketed word clarifies scope while the version tag captures provenance.
Examples and recommended practice
Practical examples illustrate how to apply the patterns across a variety of record types. Short, canonical examples should serve as templates: single-line headers for quick references, compact revision logs for provenance, and indexed annotations for contextual explanation. Recommended practice includes keeping qualifiers short, avoiding ambiguous punctuation, favoring bracketed qualifiers for scope, using a single separator symbol to group inline metadata, and writing revision notes in a separate log to preserve the main line. When preparing exports, include a brief legend describing the symbols and tag format so downstream readers or tools can interpret the content without ambiguity. The overall aim is consistent, readable notation that makes the structure and lineage of budgeting records explicit without altering their original wording.