Let's be honest, nobody wants to write quality management documents. And nobody wants to write them in raw Markdown, staring at asterisks and bracket syntax in a monospace editor like it's 2009. But Markdown is the right format for regulated documents. It's plain text, so it diffs cleanly in Git. It's human-readable even without rendering. It's not locked into any vendor's proprietary format. And it plays perfectly with the Git-native compliance workflow that makes Lightworks possible.
The question was never whether to use Markdown. It was how to make writing Markdown feel like writing in Notion. So that's what we did.
The Editor You Already Know How to Use
If you've used Notion, you already know how to use Lightworks.
Type / to open the command menu. Drag blocks to rearrange content. Click to create a new page. Toggle between headings, paragraphs, callouts, lists, and tables with the same inline controls you'd expect from any modern editor. Bold with Cmd+B. Link with Cmd+K. It's the block-based editing paradigm that Notion popularized — but everything you create is stored as clean Markdown with YAML frontmatter in your GitHub repository.
There's no export step. There's no "download as Markdown" button. The Markdown is the document. The editor is just a view into it.
Databases Without the Spreadsheet
One of Notion's most powerful features is its databases — structured collections of pages with typed properties that can be viewed as tables, boards, lists, or galleries. Lightworks brings this to your QMS.
Create a database of Design Inputs. Give each entry properties like Status, Priority, Linked Risk, and Verification Method. View them as a table to get the spreadsheet-like overview. Filter by status to see what's still in draft. Sort by priority to focus your next sprint.
Each database entry is its own Markdown file with structured frontmatter. The properties you define become YAML fields. The content you write becomes the document body. And because it's all just files in a repo, every change is tracked, diffable, and auditable.
Relationship properties connect databases together — link a Design Input to its parent User Need, connect a Test Protocol to the Design Output it verifies, associate a Risk Analysis entry with the requirements it impacts. These relationships are the foundation of your traceability matrix, and they're defined the same way you'd link databases in Notion: pick the related database, select the entry, done.
@Mentions That Actually Mean Something
In Notion, you @mention teammates to loop them into a page or leave a comment. In Lightworks, @mentions pull from your GitHub repository collaborators — the same people who are reviewing your PRs and approving your merges.
@mention a colleague in a Design Review document and they'll be notified. @mention them in a comment on a requirement and it becomes part of the auditable discussion thread. Because these mentions map to real GitHub identities, they carry the same attribution and accountability that the rest of your compliance workflow depends on.
No separate user directory. No syncing accounts between platforms. Your team is your repo collaborators.
Pages and Sub-Pages, Infinitely Nested
Quality documentation has natural hierarchy. A Design History File contains a Design Input document, which contains individual requirements, which link to verification protocols. Notion handles this with nested pages. So does Lightworks.
Create a page, nest a sub-page inside it, nest another level below that. The sidebar shows your document tree just like Notion's. Each page is a Markdown file. Each nesting level maps to a folder in your repository. The structure you see in the editor is the structure that exists on disk — no database magic, no hidden metadata layer. Just files and folders.
Templates for Regulated Documents
Starting from a blank page is intimidating, especially when you need to meet specific regulatory expectations. Lightworks ships with templates for the documents AI SaMD companies typically need: Software Requirements Specifications, Software Design Documents, Risk Management Files, Verification and Validation Protocols, and more.
These templates aren't locked PDFs or read-only references. They're Markdown files with the right structure, the right frontmatter properties, and placeholder content that guides you through what the FDA expects to see. Delete the placeholder text, write your actual content, and you have a compliant document that lives in your repo and stays in sync with everything else.
What We Don't Do (On Purpose)
Notion has real-time collaborative editing with presence indicators — you can see other people's cursors moving around the page. Lightworks doesn't do this, and that's intentional.
In a regulated environment, simultaneous editing of controlled documents creates problems. Who authored which change? When exactly was each edit made? If two people modify the same section at the same time, which version is the record? Real-time collaboration optimizes for speed at the expense of the clear, attributable change history that compliance requires.
Instead, Lightworks follows the Git model: work on your branch, submit your changes via pull request, get them reviewed and approved. It's slightly less fluid than watching cursors dance around a page, but it produces an unambiguous record of who wrote what and who approved it. For regulated documents, that tradeoff isn't even close.
Similarly, we don't support synced blocks (where one block appears in multiple pages and edits propagate everywhere). In a QMS, a controlled document needs to be a stable, reviewable artifact. If content silently changes because someone edited a synced block in a different document, you've broken the integrity of your change control process.
These aren't missing features. They're design decisions that prioritize compliance integrity over collaboration convenience.
The Best of Both Worlds
The pitch for Lightworks has always been that you shouldn't have to choose between a good developer experience and a compliant QMS. The same principle applies to writing.
You shouldn't have to choose between a modern, intuitive editor and a format that works with Git. You shouldn't have to choose between rich document structure and plain-text auditability. You shouldn't have to choose between feeling like you're using a great product and actually meeting FDA requirements.
Markdown that feels like Notion. Documents that live in Git. Compliance that comes from the workflow, not on top of it.
Lightworks is a Git-native Quality Management System for AI medical device companies. Write your quality docs in Markdown. Store them in GitHub. Let Lightworks handle the compliance.