Wedding CRM Markdown Standard
An open file format for storing wedding industry CRM data as plain text markdown files with YAML frontmatter. Designed to be human-readable, human-editable, and interoperable across any tool that understands text files.
This specification is published by Wedding Computer and is free for anyone to implement. We encourage other wedding software, CRM tools, and planning apps to adopt this format so wedding professionals can move their data freely between tools.
Why an open format?
Wedding professionals build their business on relationships: client details, wedding timelines, consultation notes, and follow-up history. This data is the lifeblood of their business, but it is usually trapped inside a proprietary database owned by a SaaS vendor.
Plain text files solve this. A markdown file created today will be readable on any computer in 2050, 2075, or 2100. YAML frontmatter is a widely adopted standard for structured metadata in text files.
By publishing this as an open standard, we are making a bet that the best way to serve wedding professionals is to ensure their data is never locked in.
Format overview
Each entity, such as a contact or wedding, is stored as a single .md file. Structured data lives in YAML frontmatter between --- fences at the top of the file. Free-form notes are the markdown body below.
---
id: a1b2c3d4e5f6a1b2c3d4e5f6
first_name: Sarah
last_name: Smith
email: sarah@example.com
phone: "0400 123 456"
partner_first_name: James
partner_last_name: Wilson
status: quoted
wedding_date: 2026-12-15
wedding_location: Sydney
tags:
- vip
- referral
created_at: 2025-06-01T00:00:00.000Z
updated_at: 2025-06-01T00:00:00.000Z
---
Met at the Bridal Expo in March 2025.
- Interested in elopement ceremony
- Budget: $3,000 - $5,000
- Preferred dates: Dec 2026 or Jan 2027
## Follow-up notes
Called on March 15, very enthusiastic.
Sending quote this week.Contact file specification
Contact files represent a lead, client, or business relationship. They live in a contacts/ directory.
Required fields
| Field | Type | Description |
|---|---|---|
| id | string | Unique identifier. 24-character hex string recommended. Must be globally unique. |
| first_name | string | Contact's first or given name. |
| last_name | string | Contact's last or family name. |
| status | enum | Pipeline stage. One of: new, contacted, meeting, quoted, booked, completed, lost, archived. |
| created_at | ISO 8601 | When the contact was first created. Example: 2025-06-01T00:00:00.000Z |
| updated_at | ISO 8601 | When the contact was last modified. |
Optional fields
| Field | Type | Description |
|---|---|---|
| string | Primary email address. | |
| phone | string | Phone number. Always quote in YAML to prevent numeric parsing. |
| partner_first_name | string | Partner's first name for couples. |
| partner_last_name | string | Partner's last name. |
| partner_email | string | Partner's email address. |
| partner_phone | string | Partner phone number. Always quote. |
| source | string | Where the lead came from. Examples: website, instagram, referral, bridal-expo. |
| archived_from_status | enum | Pipeline stage to restore when status is archived. Omit unless archived. One of: new, contacted, meeting, quoted, booked, completed, lost. |
| wedding_id | string | ID of a linked wedding entity, if one exists. |
| wedding_date | string | Expected wedding date. Format: YYYY-MM-DD. |
| wedding_location | string | Expected wedding location. Free text. |
| tags | string[] | YAML array of tags. Example: [vip, referral, 2026] |
| form_data | object | Structured data from enquiry or booking forms. YAML object with arbitrary keys. |
| last_contacted_at | ISO 8601 | When you last reached out to this contact. |
| lost_reason | enum | Structured reason for a lost enquiry. One of: price, availability, chose_competitor, no_response, not_a_fit, other. |
| lost_note | string | Optional free-text context recorded when an enquiry is marked lost. |
Body (notes)
Everything below the closing --- fence is free-form markdown. This is where you write notes, follow-up history, meeting summaries, or anything else.
In Wedding Computer, this maps to the notes field in the contact record. If the body is empty, notes are null.
Wedding file specification
Wedding files represent a wedding event. They live in a weddings/ directory.
---
id: f8e7d6c5b4a3f8e7d6c5b4a3
title: Sarah & James
date: 2026-12-15
location: Royal Botanic Garden Sydney
location_lat: -33.8642
location_lng: 151.2166
status: confirmed
ceremony_type: legal
vendor_visibility: private
guest_count: 85
dress_code: Semi-formal
created_by_user_id: u1a2b3c4d5e6
created_at: 2025-06-01T00:00:00.000Z
updated_at: 2025-07-15T10:30:00.000Z
---
Outdoor ceremony in the rose garden, weather permitting.
Backup plan: The Calyx indoor space.
The timed run sheet lives in timeline.md.Required fields
| Field | Type | Description |
|---|---|---|
| id | string | Unique identifier. 24-character hex string recommended. |
| title | string | Wedding title, typically the couple's names. |
| status | enum | One of: planning, confirmed, completed, cancelled. |
| created_by_user_id | string | ID of the user who created this wedding. |
| created_at | ISO 8601 | When the wedding record was created. |
| updated_at | ISO 8601 | When the wedding record was last modified. |
Optional fields
| Field | Type | Description |
|---|---|---|
| date | string | Wedding date. Format: YYYY-MM-DD. |
| location | string | Ceremony venue name and/or address. |
| location_lat | number | Latitude of the ceremony location in decimal degrees. |
| location_lng | number | Longitude of the ceremony location in decimal degrees. |
| ceremony_type | string | Type of ceremony. Examples: legal, commitment, renewal, elopement. |
| vendor_visibility | enum | Whether vendors on this wedding can see each other. One of: private, visible. |
| dress_code | string | Dress code for guests. Free text. |
| guest_count | integer | Expected number of guests. |
| timeline_notes | string | Additional notes about the day's timeline. |
Body (notes)
The markdown body holds free-form notes about the wedding: logistics, backup plans, run sheet details, vendor coordination notes, or anything else. This maps to the notes field on the wedding record.
Per-wedding companion files
Each wedding is a folder. Alongside wedding.md, the folder holds companion files for the parts of a wedding that deserve their own document: the checklist, the day-of timeline, your private notes, the wedding team, and the activity log.
In timeline.md, the "Run sheet" table is yours to edit: each row is one run-sheet item, the trailing id cell ties a row to an existing item, rows without an id are created, removed rows are deleted, and row order is the display order. Sections for other vendors and pending approvals are generated and read-only.
Files in a wedding folder
| Field | Type | Description |
|---|---|---|
| wedding.md | two-way | Wedding details in frontmatter; shared wedding notes in the body. |
| todo.md | two-way | Your checklist for this wedding, as a markdown task list. |
| timeline.md | two-way | The day-of run sheet as a markdown table, plus other vendors' timelines and pending approvals. |
| notes.md | two-way | Your private notes — never visible to the couple or other vendors. |
| vendors.md | read-only | The wedding team: couple, vendor members, and the couple's vendor list (when shared). |
| log.md | read-only | Append-only activity log for the wedding. |
File naming conventions
Filenames should be human-readable slugs. This makes them easy to browse in a file explorer or Obsidian sidebar.
Contacts
sarah-smith.md — Single contact
sarah-james-smith.md — Couple with same surname
sarah-smith-james-wilson.md — Couple with different surnames
john-doe-2.md — Deduplicated second John Doe
Weddings
sarah-james-2026-12-15.md — Wedding with date
smith-jones-wedding.md — Wedding without date
Slugification rules
1. Decompose Unicode (NFKD normalisation) and strip combining marks
2. Lowercase everything
3. Strip apostrophes and quotes, so O'Brien becomes obrien
4. Replace & with a hyphen
5. Replace all non-alphanumeric characters with hyphens
6. Collapse multiple hyphens and trim leading or trailing hyphens
7. If the result is empty, use untitled
Directory structure
Files are organised by vendor, then by entity type:
vendors/
{vendor_id}/
contacts/
sarah-smith.md
john-james-doe.md
jane-wilson-2.md
weddings/
2026-12-15-sarah-james/
wedding.md
todo.md
timeline.md
notes.md
vendors.md
log.md
files/
smith-wilson/
wedding.mdYAML authoring tips
Always quote phone numbers
YAML parses unquoted numbers like 0400123456 as the integer 400123456, losing the leading zero. Always wrap phone numbers in quotes.
Always quote times
YAML may parse HH:MM as a sexagesimal number. Write time: "15:00" not time: 15:00.
Dates can be unquoted
YAML 1.2 handles ISO dates well. wedding_date: 2026-12-15 and created_at: 2025-06-01T00:00:00.000Z both work without quotes.
Use YAML arrays for tags
Write tags as a YAML array, either inline [vip, referral] or block style with - vip on each line. Not a JSON string.
Colons and special characters in values
If a value contains a colon, hash, or other YAML-special character, quote it.
Null vs absent
Omitting a field and setting it to null are equivalent. Wedding Computer treats both as null. If you are hand-editing, just leave optional fields out.
Interoperability
Files conforming to this standard can be read by:
- Any text editor: VS Code, Sublime Text, Notepad, vim
- Obsidian: reads YAML frontmatter natively and renders the markdown body
- Static site generators: Hugo, Jekyll, Eleventy, and Astro all read YAML frontmatter
- Scripting languages: Python, JavaScript, Ruby, and Go all have YAML parsers
- Any YAML-aware tool: the frontmatter is standard YAML 1.2
Wedding Computer uses the yaml npm package, which is YAML 1.2 compliant, for parsing and serialisation. We recommend other implementations use a YAML 1.2 parser for maximum compatibility.
License
This specification is published under CC0 1.0 Universal (Public Domain). You are free to implement, modify, and redistribute it without restriction.
The specification is intentionally independent of Wedding Computer itself. You can implement it in any software, commercial or otherwise, without asking us. The official Obsidian plugin is open source and doubles as a reference implementation.
Build on this standard
If you are building wedding software, adopt this format. Your users will thank you.