A feature of SystemDox
The record of every decision your AI agents make
Your AI agents draft ADRs, specs and plans. SystemDox Pages publishes the docs tree of a git repository as a site: public on your domain, or internal with sign-in at the edge. Every decision record shows its status; every page names the commit that last changed it.
Track
Every decision has a status and a commit
The signals a reader needs are on the page. The status is read from the document's own header, the commit from git, both at build time. Nothing is maintained on the site by hand.
Status badge
The metadata header of a document renders as a list, and its Status renders as a badge: Proposed, Accepted, Superseded. A reader sees at once whether a decision still holds. The authored file is untouched; this is presentation at build.
Provenance footer
Every page names the commit that last changed the document, with its date and subject, and the commit the site was built from. Both are printed for every reader and linked to GitHub for anyone with access to the repository, so you always know which version you are reading.
Rebuilt on every merge
Your repository stays the only source. Each build checks it out at the commit it publishes and records it, so the site is at most one merge behind and is never a second place to edit.
Consume
Published in a form the whole organisation can use
A repository is where engineers work. A site is where everyone else reads. SystemDox Pages keeps the first as the source of truth and builds the second from it.
Search
Full-text search across the whole site, built at publish time and served as static files. A decision is found by the words in it, not by knowing which folder holds it.
Navigation that follows the repository
The site's navigation mirrors the folders of the docs tree. Move a file in the repository and the site follows on the next merge. There is no second structure to maintain.
Diagrams rendered
Mermaid diagrams in your Markdown render in place, so an architecture picture reads as a picture on the page and stays a text file in the repository.
Publish
Public or internal, decided by the stack
A site is one kind for the whole life of its stack. There is no toggle and no mixed stack, so a private decision has no route to a public page.
Public sites
A public repository's docs tree becomes a public site on your domain, served as plain static pages from a stack that only ever holds public content. No gate to configure, because nothing private is within reach.
Internal sites
A private repository's docs tree becomes a site only your people can open. Every request is checked at the edge, before any cache, against a sign-in. A stack is internal from the day it is created and never flips.
The repository stays the source
SystemDox Pages publishes from git and writes nothing back. Authors keep working in pull requests, reviews and merges. Stop using it and your files are exactly where they were, in your repository, in plain markdown. There is no export step.
Running today
docs.puglieseweb.com is a public site published with SystemDox Pages: an engineering documentation tree of over five hundred pages, rebuilt on every merge. puglieseweb's own internal documentation, its decisions, architecture, runbooks and standards, runs on an internal site with sign-in at the edge. The same feature publishes both; the stack decides who can read.
Open docs.puglieseweb.comSold on its own
SystemDox Pages is a feature of SystemDox, and you can buy it without the rest. Bring a git repository with a docs tree and a domain. We publish it as a public or internal site, rebuilt on every merge. Capture, Build and the Knowledge Base can come later, or not at all.
See pricingIs SystemDox Pages a separate product?
No. SystemDox Pages is a feature of SystemDox. It is sold on its own, so you can publish a repository's documentation without using Capture, Build or the Knowledge Base, but it is one feature of one product and is priced on request.
How do I know which version of a page I am reading?
Every page prints a provenance footer: the commit that last changed the document, with its date and subject, and the commit the site was built from, each linked to GitHub for readers with access to the repository. Both are read from the repository at build time, so a page cannot claim to be newer than it is. The site is rebuilt on every merge.
What happens to my documentation if I stop?
Nothing. Your files stay in your repository as plain markdown, exactly as you wrote them, with git as their history. The site is a build of the repository, never a second place to edit, so stopping leaves your documentation exactly where it already was.
Ready to Transform Your Documentation?
Start capturing architecture decisions, meeting notes, and technical designs with your voice.