May 2026

Keep your reference knowledge in flat Markdown.

A worked example from Victorian construction law.

A few months ago I had a problem familiar to anyone working with AI assistants on a real domain: I wanted Claude (and ChatGPT, Copilot, and any other AI platform or model for that matter) to actually know a piece of legislation I work with, instead of half-remembering it from training data. Not summarise. Not paraphrase. Know — in the sense of citing sections, refusing to invent material, working with it mechanically.

Author Joel Seignior Published 16 May 2026

The piece of legislation in question was the Victorian Security of Payment Act. The shape of the problem generalises. You probably have your own version of it — internal policies, a regulatory regime, deal precedents, a body of standards, a style guide. Stable reference material you'd like every AI tool you touch to be properly grounded against, every time.

You have three options. Paste it in every time. Build a Notion workspace or a Custom GPT around it and live inside that tool. Or keep the reference material as a portable file you bring with you. This article is about the third option — what makes a flat Markdown file genuinely portable, what discipline the format imposes, and why for reference material specifically it tends to beat putting your knowledge into someone else's workflow. The worked example is a personal project of mine — a single Markdown file in which I curated the Vic SOPA regime so it could be pasted into any AI assistant as context. The pack itself isn't linked here; the underlying legislation is Crown copyright and the pack reproduces it, so I'm keeping the artefact private. I'll talk through its structure, not its content. The lesson is the shape, not the law.

The shape of the problem.

01 — two layers

Knowledge work, especially knowledge work that touches AI, has two distinct things in it. Vendors mostly blur them.

Reference material

The stable, reusable layer.

Slow-changing, authoritative, the same across every matter you touch.

Legislation
Internal policies
Standards documents
Deal precedents
Style guide

Working artefacts

The in-flight stuff.

Fast-changing, situational, specific to a single piece of work.

The draft letter
The matter file
The team conversation
The project board
Today's review thread

Tools optimised for working artefacts — Notion, Copilot, Linear, Slack, the inside of a custom GPT — absorb reference material into their own structures the moment you put it in. The page becomes a Notion page, with Notion blocks, Notion linking, Notion permissions. The policy becomes a SharePoint file with SharePoint metadata. The body of standards becomes a vector index inside someone's RAG product. Once it's in there, it's entangled. Moving it out costs effort and loses fidelity — and if the vendor changes pricing, gets acquired, or sunsets the product, the cost compounds.

The argument here is that the two layers should be treated differently. Working artefacts can live wherever the work happens. Reference material should live in a format that can travel. The boundary is at the instance level, not the category level — I'll come back to it.

The Markdown proposition.

02 — five properties that compound

Flat Markdown isn't magic. It's just plain text with a handful of conventions for headings, lists, emphasis, links, and code blocks. What makes it work as a portable reference format is a small set of properties that compound.

Plain text. Any editor opens it — including the one you'll be using in 2035, whatever that turns out to be. There's no proprietary binary format, no schema migration, no vendor read API to call.
Human-readable raw. You don't need a renderer to understand it. The structure is in the text. A headline is # Headline. A list is a list of - lines. If the renderer breaks, the file is still legible.
Diff-able and version-controllable. You can put it in git, but you don't have to — you can also just “Save As” and visually compare two versions and see what changed. The unit of change is a line, which matches how humans read.
Renders cleanly in any modern LLM context window. Claude, ChatGPT, Gemini, the open-source models you might run locally, the legal-AI platforms grounded against your firm's vault — all of them read Markdown natively. You don't have to convert. You don't have to scrape. You don't have to teach the model the format.
Outlasts the tool you authored it in. The editor that produced the file is irrelevant by the time anyone reads it. Whatever vendor you used to write it can disappear and the file is unaffected.

Working artefacts can live wherever the work happens. Reference material should live in a format that can travel.
from the opening — the boundary worth defending

The worked example.

03 — a personal pack

The SOPA pack is a single Markdown file, around 190 KB, that takes the Building and Construction Industry Security of Payment Act 2002 (Vic) — including the substantive 2025 amendments — and turns it into a context pack any AI assistant can be grounded against. I built it section by section, working alongside an AI, with every interpretive note reviewed and logged. It's a personal worked example, not a maintained legal resource.

I'm not going to walk through what the Act says. The source legislation is Crown copyright and I take that seriously; reproducing it here would defeat the point of an article about form. From here on, what I want to show you is the shape of the file — five structural moves it makes, and one separate companion file that does the audit work. These moves are reusable. They'll work for any reference body of knowledge you might want to build into a portable pack.

Five structural moves.

04 — the shape of the file

A self-describing metadata block at the top.

The very top of the pack is a small table answering: what is this, what jurisdiction, what version, what currency date, what amendments have been incorporated, where are the source files. The shape:

| Field                          | Value |
|--------------------------------|-------|
| Jurisdiction                   | … |
| Consolidation version          | …, as at <date> |
| Most recent substantive change | … |
| Source files                   | <relative paths to the originals> |
| Pack currency date             | Pinned to the consolidation version above. |

A reader picking up the file — or an AI model ingesting it — knows what it's holding without needing external context. The file describes itself. If you ever have to triage a folder full of Markdown reference packs in three years, this block is what tells you which is current.

AI Operating Rules baked into the file.

The second section is a numbered list of rules telling any AI grounded against the pack how to behave. Cite explicitly. Treat verbatim text as authoritative. Refuse to invent. Flag jurisdictional cross-contamination. End every substantive answer with the not-legal-advice caveat. A set of rules, all visible at the top of the pack.

The point is that the rules travel with the pack. They aren't configured in a vendor's “guardrails” panel. They aren't a Claude project instruction or a ChatGPT custom instruction. They're content. When you paste the file into a new tool tomorrow, the rules paste with it. When a colleague picks up the file, they see what discipline you've asked the model to apply, and they can argue with it if they disagree. There's no hidden configuration layer.

A clarifying-question protocol, encoded as content.

Before the AI is allowed to opine on a fact pattern, the pack tells it to walk a decision tree of triage questions — coverage, claim track, time bars, adjudication, recovery. The tree is just Markdown headings and bullet points. Any model that reads the pack reads the protocol. Any model that ignores the protocol is visibly off-script in a way the user can see.

This is the same idea as the operating rules: behaviour shouldn't depend on a vendor feature. If you bury “ask before you opine” inside a Custom GPT's instructions, you lose it the moment you switch tools. If you bake it into the reference pack as content, it survives the move.

Verbatim source plus curated note, clearly labelled.

Each unit of meaning in the pack — every defined term, every section — follows the same pattern. The authoritative text appears first, block-quoted. Then a clearly-labelled note, in my voice, sits below it:

> [authoritative source text, block-quoted]

**Note (curated):** [my interpretation — usually one to three short bullets,
flagging traps, cross-references, or amendment history]

Two voices, marked explicitly. The operating rules say the verbatim text controls if a note ever conflicts with it. Anyone reading the pack — human or model — can see at a glance which lines are authoritative and which are mine. That separation is what lets the pack be honest about its own status: it's a structured reference, with interpretive aids attached, and the aids are never allowed to masquerade as the source.

That convention is doing a lot of quiet work. It's the move that lets me write notes at all without compromising the pack's role as a grounding artefact.

Per-section verification dates.

Every defined term and every section in the pack carries a small italic line: *verified: 2026-05-16*. Currency is tracked at the unit of meaning, not just at the document level. If I re-review a single section after an amendment, that one date moves. The rest of the file is unaffected, and a future reader can see, line by line, what I've checked and when.

A page-level “last edited” timestamp on a wiki tells you nothing about whether section 23 was actually re-reviewed when section 7 was touched. Per-unit dating is trivial in Markdown — it's just text — and it pays off the first time someone, including me, asks “is this still right?”

The audit-trail layer.

05 — the companion log

Sitting beside the pack is a companion file: AUTHORING_LOG.md. Every interpretive note in the main pack traces back to an entry here. The shape of an entry:

## s.X — Heading
Date: YYYY-MM-DD
Verbatim source: <line refs into the source extract>
Verbatim diff vs docx: clean | re-extracted | TODO
Amendment history visible: <what the source margin says about prior amendments>
Interpretive questions asked: <summary of the choice point>
User answer: <which option I picked, or the text I dictated>
Note committed to pack: yes/no — with excerpt
Open follow-ups: none | list

One field in there needs a footnote: the docx is the source extract the verbatim text was pulled from, and the diff line flags whether the pack still matches it — clean when last checked, re-extracted after an amendment, TODO when I haven't yet re-pulled.

Three things matter about this.

Re-derivable

If you wanted to rebuild the pack from the source legislation, every choice I made is visible. You don't have to trust me — or trust the AI I co-authored with — you can audit.

Itself portable

The log is a plain Markdown file. Same git-ability and diff-ability as the pack. Compare that to a Notion comment history or a ChatGPT thread, which die inside the tool that generated them.

Serious co-authorship

The AI was in the loop, but every “Note committed to pack” line records a choice I made. That's a defensible posture in a way that “I asked ChatGPT and it said…” is not.

Why this beats putting your knowledge into someone else's workflow.

06 — three deployment paths

The portability dividend is concrete. From the same source file, I've actually run three deployment paths.

01

Chat context.

Paste the pack as a system prompt or first user message into Claude, ChatGPT, Gemini or another chat assistant. The operating rules activate; the model behaves.
02

Coding / writing-tool project context.

Drop the pack into the working directory of Claude Code, Cursor or a similar tool. Load it eagerly into the session prompt for a SOPA-heavy run, or leave it on disk and let the assistant read it on demand when the work touches the regime.
03

Managed enterprise platform.

Upload the .docx twin of the pack (generated from the same Markdown source via pandoc) as a Copilot Studio knowledge source. Or drop the pack into a Harvey vault. Or into an iManage workspace fronted by Claude over MCP. Whatever your firm has standardised on, the same source file lands as a grounded reference, with a separate hardened-instructions file compensating where the platform's grounding is looser.

Switching tools doesn't destroy your work. You re-deploy. That's the thing. Frame it as risk management — because that's what it is:

Vendor pricing changes. Your reference material doesn't move. You change tools or stay; the file is the same.
Vendor M&A or product deprecation. The file doesn't care.
You change firm, role, jurisdiction, employer. Your reference material comes with you. It's a file. There's nothing to export.
The AI tooling landscape turns over every twelve months. Model generations come and go. Your reference material doesn't care which model is in front of it this quarter.
The internet goes down. The file is on your laptop. You can grep it. You can read it. You can paste a section into a local model.

None of these scenarios are paranoid. Every one of them happens routinely. The question isn't whether tools will churn — they will — it's whether your reference material churns with them.

A wiki page can look organised without being organised. A Markdown file can't pull that trick. Whatever discipline you have ends up legible in the file. Whatever discipline you lack is equally legible.
from section 07 — on the discipline the format imposes

The discipline the format imposes.

07 — what plain text forces

I said earlier that Markdown is a discipline. Worth saying directly what discipline it imposes, because this is the part that surprised me the most when I built the pack. Writing reference material in Markdown forces:

Citing sources. There are no rich-media hover-cards to lean on. If you want to point at a section, you write the section number.
Labelling voice. If you don't mark the difference between authoritative text and your interpretive note, it disappears into the prose. You'll feel the gap; you have to fix it explicitly.
Dating reviews. Currency has to be written down because there's no system-managed “last edited” decoration to hide behind.
Structuring semantically. Headings, lists, tables. Not visual hierarchies. Not coloured callouts. Either your material has structure or it doesn't, and the file reveals which.

Notion, Confluence, and docs-style tools let you embed, link, toggle, colour, and visually structure your content. The format doesn't push you towards clarity — it lets you hide weakness inside the UI. A heading reading “Q3 contractual risk” with a soft-coloured callout under it can pass review for months: the colour-blocking, the toggle below, the small icon next to the heading all make the block feel substantive. Convert the same page to Markdown and what you find is one TODO and a half-paraphrased sentence. The “summary table” that turns out, on inspection, to be three rows of formatted prose — two of them rewording the paragraph above — is the same trick at a different scale.

None of this is dishonesty; it's UI scaffolding doing work the content was supposed to do. Markdown removes the scaffolding. If a heading has no content under it, you stare straight at the gap. That's a feature, not a bug. The same properties that make it portable also make it honest.

What you give up — honestly.

08 — the real trade-offs

Markdown is bad at some things, and pretending otherwise would undercut the argument. You give up:

Real-time multi-user collaboration in the document.
Threaded comments and review workflows pinned to specific blocks.
Database views over the content (filter, sort, group by tag).
Rich embeds — videos, live charts, interactive widgets.
Visual polish out of the box.

For working artefacts — drafts, project boards, team conversations, in-flight reviews — these are real capabilities and the tools that offer them are good at offering them. Nothing here is an argument that you shouldn't use Notion, or Confluence, or Linear, or Slack.

For reference material — the stuff you'd want to reuse in three years, in a new tool, in a different role — they're a trap. The right boundary isn't “old vs. new” or “personal vs. team” or “simple vs. complex”. The right boundary is “is this reference or is this a working artefact?” Reference belongs in a format that can travel. Working artefacts belong wherever the work happens.

The boundary applies at the instance level: a canonical precedent is reference; the same precedent marked up on a live deal is a working artefact. The taxonomy sorts uses, not categories.

The pattern, generalised.

09 — the recipe

Pull back from SOPA. The pattern works for almost any body of reference knowledge:

01

Decide what's reference vs. working artefact.

This is the most important step. The rest follows.
02

For reference material, build a flat Markdown file.

Or a small, flat directory of them. At a minimum: a self-describing metadata block at the top, a set of behaviour rules for any AI grounded on the material, structured sections, dated reviews, and a clearly-labelled separation between authoritative source and your interpretive notes.
03

Keep a companion audit log.

Plain Markdown. Per-section entries. Trace every interpretive move to a source reference and a decision you made.
04

Use the file across every tool you touch.

Drop it into Claude as a system prompt. Drop it into your firm's Copilot agent as a knowledge source. Drop it into a project folder for your coding/writing tool. The pack is the constant; the tool is the variable.
05

For working artefacts, use whatever fits the workflow.

Nothing here is about being precious. The boundary is the data-portability boundary, and it's only worth defending for the reference layer.

The recipe is short because Markdown is small. That's the point.

A note on co-authoring with AI.

10 — the obvious objection

Didn't an AI write half the SOPA pack? Yes. Every section was processed with an AI in the loop. The interpretive notes were drafted in conversation. The AUTHORING_LOG records, for each section, which option I picked among the ones the AI surfaced — or the text I dictated when none of them fit.

The point isn't to keep AI out of authoring reference material. The point is to keep the output portable so it outlasts whichever AI is in front of you today. I can rebuild this pack with a different model in five years. I can fork it. I can subset it. I can hand it to a colleague who doesn't use AI at all and they can read it. If the same work had been authored inside a vendor's AI product, the AI would have helped me write it and then the work would have been trapped. AI in the loop with a portable output beats AI in the loop with vendor lock-in.

The close

Plain text endures. Reference material should endure with it. The format is small; the discipline is real; the portability dividend pays out the first time you switch tools and discover your work moves with you.

I'm not linking the pack itself. The underlying legislation is Crown copyright; the pack reproduces it; and even if it didn't, it would be a personal worked example, not a maintained legal resource, not a substitute for the current consolidation or for legal advice, and not to be relied on for any decision. The shape is the lesson, and the shape is what this article is for.