How I build · This site's build log
The one idea. Dated, public, append-only entries: what shipped, what was measured, what was declined. A changelog says what changed. This log also says what the change did and what was left out on purpose, so a reader can hold any claim on the site against the date it was made.
Reading path. Entry from The harness, the case study. The site this log records is This site, whose success floors were published before launch and are filled in from this log. The gates an entry passes through are the general method on How I build · The delivery method, applied here to a content product. The log itself is served as a plain file at /BUILDLOG.md.
1 · The entry form: four fields, one line
date · change · measured effect · decision
| Field | What goes in | What is not allowed |
|---|---|---|
| Date | The day the change was committed into the published folder, ISO 8601. Work on a branch is served when the branch merges; the date stays the commit's | A planned date. The log records what happened, not what is scheduled |
| Change | What a reader can now see, named as it appears on the site | Draft file names, working-branch names, anything that exists only in the private repo |
| Measured effect | A number, the instrument that produced it and when. Or not measured and the reason | A projection, an estimate, an adjective. A forecast written in this field reads as a result |
| Decision | What was left out or declined, and the condition that brings it back | An empty field. Silence reads as "nothing was declined" |
Why one line. A line can be scanned and dated. A change that needs a paragraph is two changes and gets two lines.
Why the third field is never skipped. A log of changes alone is a release note. The measured-effect field forces the question how would anyone know this worked? on the day of the change, while the answer is cheap to set up. It also keeps measured and projected apart, as the rest of the work does (The delivery method §5).
The rule is newer than most lines. Eleven of the first seventeen entries name a draft file, a private folder, a source path or the working branch in the Change field. They stay as written, because the log is append-only. The rule binds every line written after this page.
2 · The first entry, as published
2026-10-18 · Phase 0
index.htmlbuilt from the signed-off home copy, with robots.txt, sitemap.xml and llms.txt · not yet measured (site not live; Pages project to be created) · Resume button, email, OG image and analytics beacon left out until their inputs exist; not live until the GitHub profile lists no uncleared repos.
Read field by field:
- Change. One page and three machine-readable files. The page is built from copy that was signed off first; the HTML adds no words of its own.
- Measured effect. No numbers, and the entry says why: nothing can be measured on a site that is not yet served. The floors it will be measured against (This site §6) were written before this line, and are not edited after it.
- Decision. Four parts of the signed-off design are left out, each because an input does not exist yet: a resume file, a contact address, a preview image, an analytics token. A button with no file behind it, or a privacy claim about analytics that are not running, would be a claim the page cannot back. The entry also sets a launch condition: the site does not go live while the linked code profile still shows projects that are not cleared for publication.
The decision field, closed by later lines. The fourth entry, the same day, adds the resume file and the contact address, each once its input existed. The preview image and the analytics beacon are still out, because their inputs still do not exist. The launch condition was met before the site went live, but the go-live entry did not say so. A late entry records it (§5).
3 · Where an entry comes from: the last step of the publish step
Nothing enters the published folder except through one sequence, and the log line is its last step.
The sweep runs over the whole published folder, and the log lives in that folder, so a log line is held to the same list of forbidden terms as a page. That has happened once: the line for The artefact set used one of the swept terms, and the sweep stopped the commit until it was reworded. The list is fixed, though. It catches the names on it and nothing else. A draft file name or a person's name not on the list passes the sweep, and only reading the line catches it (§6).
4 · Why a file, and not the commit history
The plan (This site §4, pre-registered on 2026-10-17): a public repo whose commit history is the build log, "without extra effort".
As built (2026-10-18): the repo is private and has two zones. Drafts, reviews, open TBDs and session records sit in one; only the published folder is served. The commit history carries the drafts, so it cannot be published, and a public log has to be a file inside the published folder.
The trade-off accepted, and what it cost. The log is a curated record, not an automatic one, so a commit can reach the published folder without a line. It has. Counted from the repo history on 2026-10-18, before this page, 21 commits changed the published folder; three real changes went in with no line (two sets of tile images and one background motif), plus the commit that first moved the folder in, which came before the log existed. Each of the three now has a late entry (§5). In return, the log can say what a commit message cannot (the measured effect and what was declined), and it exposes nothing from the drafting room. The case study planned one thing and the build did another, and this log records that too.
5 · Corrections are new lines
Append-only means a wrong or incomplete entry stays as written. A correction is a new line, dated the day it is made, that names the entry it corrects:
date · correction to <date of the earlier entry> · what was wrong or missing · decision
A change that went in with no line gets a late entry in the same form, naming the date of the change it covers.
Held so far, by hand. Across all 17 commits that touched the log before this page, no line was removed or changed. That is a one-off count, not a check that runs on every commit (§6).
One recorded exception. One entry named a third-party portfolio by its domain, and that domain is a person's name. The site names no person, and that rule outranks append-only. The line is edited once, to "a designer's portfolio gallery", and a new line records the edit and why. It is the only edited line in the log.
Lines appended with this page:
2026-10-18 · correction to 2026-10-18 · the privacy note was cut to its first sentence (no cookies, no forms) because no analytics run yet; not recorded in that entry · the second sentence returns in the same commit as the beacon.
2026-10-18 · late entry for 2026-10-18 · launch condition in the first entry met: the uncleared repositories were made private before the site went live · not measured · recorded late; the go-live entry did not say so.
2026-10-18 · late entry for 2026-10-18 · Home page: quiet grid motif behind the figure panels on tiles without an image · not measured · recorded late; the change went in with no line.
2026-10-18 · late entry for 2026-10-18 · Home page: wordless diagram images for three summary tiles (the sovereign OSINT platform, the enterprise AI platform, the customer-facing LLM assistant) and for the ebook library tile · not measured · recorded late; the two changes went in with no line.
2026-10-18 · edit to the 2026-10-18 entry on gallery tiles · a third-party portfolio's domain, which is a person's name, replaced by "a designer's portfolio gallery" · the no-names rule outranks append-only; this is the log's only edited line.
6 · Stated honestly
- Append-only is a rule, not yet a check. The count in §5 was run once, by hand. A gate that compares the log with its previous version on every commit is planned, not built.
- The sweep checks names on a list, not meaning. It cannot catch a draft file name or a person's name that is not on the list. Two kinds of line broke the entry rule and passed it (§1, §5).
- Figures in the log are local so far. Three entries carry Lighthouse mobile runs on a local static server, on a branch build: Performance 93 to 95, Accessibility 100, SEO 100. The go-live entry carries a status check of the live pages and links. No Lighthouse or accessibility run has yet been made against the served site, so the floors on This site are not yet tested there.
- The content gate is smaller than planned. This site §5 plans six binary checks in CI. As built, there is no CI. The gate is two scripted checks run by hand before each commit (the forbidden-name sweep over the published folder and a no-placeholder check over its pages), plus the figure check and the harness hooks that guard the private evidence.
- The log records the published folder only. Reviews, rejected drafts and sign-off notes appear only as their outcome: a page that shipped, or did not.
- This site is published as the plan. Its lead line says it was written before the build and not updated, and its floors are not edited. A dated note comparing its §4 and §5 with this page is still to be written.
Measured figures on this page
| Figure | Source |
|---|---|
| 21 commits changed the published folder; 3 changes had no line; 1 commit came before the log | this site's evidence record, counted from the repo history on 2026-10-18 |
| 17 commits touched the log; 0 lines removed or changed | this site's evidence record, counted from the repo history on 2026-10-18 |
| Lighthouse mobile, local: Performance 93 to 95, Accessibility 100, SEO 100 | the build log itself, three entries of 2026-10-18 |
Dates (2026-10-17 for the pre-registered plan, 2026-10-18 for the private-repo decision and the entries) are from the log and This site.
What this page does not claim
- No traffic result, and no speed or accessibility result on the live site. The local runs are stated as local.
- No claim that every commit has a line. §4 gives the count of those that did not.
- No private history is shown. Two counts are taken from it; no commit, message or draft is published.