The risks I have accepted, the controls around them, and the exits
This register records limitations I am carrying on purpose. Each entry names the exposure, the reason it remains, the control that narrows it, the date of the decision, and an exit when one exists. Structural limits can remain open. Temporary risks have to name what closes them.
The register exists because several controls looked stronger in prose than they were in code. Review found approval hooks that could fail open, monitoring paths that shared a failure domain, and security settings that were committed but not applied. Those findings stay visible until the running system changes.
Maintained from the accepted-risk decisions, postmortems, security reviews, running-state verification, and repository controls cited by each entry.
How to read this
A risk register is a list of the things you know are wrong and have decided to live with, each one written down with the reason and the date. Writing it down is the whole mechanism. An accepted risk nobody re-reads is just a surprise on a schedule, so each row below says when it was accepted and, where there is one, what event ends it.
The rows are grouped by what kind of thing they are. Structural risks come with the shape of a one-person platform and have no fix. Architectural risks are designs I chose knowing the downside. Temporary ones have an exit already decided. Deliberate choices are the trades where I took the riskier-sounding option on purpose.
Structural
These come with the shape of the thing itself. They do not have fixes, only honesty and compensating controls.
One operator
Every claim on this site about review, approval and merge authority reduces in the end to one person paying attention. There is no second reviewer and no on-call rotation. The compensating controls are the ones this site documents: gates that fail closed, dead-man switches that assume nobody is watching, and automation that declines to act when it cannot verify what it is acting on.
Accepted since the first commit · no exit
Consumer hardware
The cluster is five mini PCs, not servers. No redundant power supplies, no out-of-band management, no guarantee of error-correcting memory. The 2026-08-04 outage is what the missing out-of-band management costs, in days, whatever the cause of that outage turns out to have been. The trade is deliberate and the electricity bill is part of the design.
Accepted since the first build · mitigated by the placement review, not removed
Architectural
Chosen designs whose downsides I take with open eyes.
One edge vendor
Cloudflare is the registrar, the DNS, the static host, the tunnel and the access layer, all at once. That concentration is the price of never exposing an inbound port to the internet, and for a platform this size I judge it a good trade. If Cloudflare has a bad day, the public site and every Cloudflare-fronted surface have it too. The VPN paths are separate, so remote reach does not die with it.
Accepted 2026-07 · revisited only if the trade changes
The internal domain does not match the public brand
The internal DNS zone, the certificates and the mail platform all run on the original domain. The public site moved to my name. Migrating the internal estate would be weeks of certificate and mail churn for no operational gain, so the two names coexist indefinitely. You will see the older name in a handful of honest places on this site, mainly the mail page's published DNS records and the public repository links, and this row is the explanation.
Accepted 2026-08-05 · no exit planned
Temporary by plan
Risks I am carrying on purpose, each with its exit already decided.
Merge authority is policy today, not architecture
Start with the fact, because the repository would tell you anyway. The agent fleet has already merged pull requests at scale, hundreds of them, and it merges routine work as a matter of course rather than as a future plan. The agents push with credentials that could technically reach anything in the repository. What separates the routine work they land themselves from the consequential work that waits for me is written policy plus commit hooks, and the reviews during the outage week found that some of those hooks failed open rather than closed.
So the boundary is real, it is written down, and today it is discipline rather than a fence. The fix is in flight and has three parts: a separate machine identity for the agents, a contract file that names exactly which classes of change may land on their own, and branch protection that enforces the boundary instead of trusting good behaviour. The contract file is itself out of contract, so the fleet can never widen its own permissions.
Accepted 2026-08-05 · exits when the machine identity, the contract file and branch protection land
Certificate verification defaults off for two internal API clients
Two internal API clients skip TLS verification when no certificate authority bundle is configured. A review found it and the fix is queued. Until then, a machine already inside the lab network could impersonate those endpoints. The blast radius is bounded by needing to be inside the network already, which is why this is a queued fix rather than an emergency.
Accepted 2026-08-06 · exits with the fix
No out-of-band path to the hardware
Proven expensive on 2026-08-04, in days. The external dead-man switch and the console access that survives a dead network are both designed and neither is built, so neither is claimed anywhere on this site as working.
Accepted with regret · exits in the current programme
How it runs now
| When | What is reviewed | What happens next |
|---|---|---|
| When a limitation is found | The impact, current control, owner, and evidence are written before the item is accepted. | An unbounded or unexplained exposure remains a defect, not an accepted risk. |
| When a control changes | The running configuration and repository are checked together. | The entry records the new boundary or closes against its exit. |
| After an incident | The postmortem is compared with existing entries. | A missed risk becomes a new row; a misleading row is corrected. |
| During a site review | Claims on other pages are compared with the register. | The narrower current state wins over the stronger page claim. |
| When evidence is unavailable | The entry keeps its prior status and names the missing verification. | No date or completion claim is inferred from committed code alone. |
What broke in the first version of the register
An estimate appeared where the page required a measured fact
An earlier merge-authority entry described the scale of automated merges with an estimate and then explained that the count was still owed. That weakened the purpose of the register. A risk record should narrow uncertainty, not publish a number the system has not measured.
The estimate is gone. The entry now describes the capability and the control boundary without a scale claim. If that number becomes useful later, the site build can derive it from repository history.
Deliberate choices
Trades where I picked the riskier-sounding option because it serves the point of the platform.
Outages will be visible here in near real time
When the live status view ships, a real outage renders on this site while it is happening, with no delay and a link to the postmortem that follows. Most operations pages hide this. A portfolio about operating honestly cannot. The compensating control is the one the last outage tested: the site never depends on the lab, so the page reporting the outage stays up through it.
Accepted 2026-08-05 · staging embed built 2026-08-21, live aggregate pending
A curated public Grafana set bypasses sign-in
The dedicated status hostname exposes the dashboards in the committed public manifest and the document, data, health, and static asset routes they need without Cloudflare Access. The rest of Grafana stays behind Access. Public panels query fixed recording rules that remove source identity before Grafana reads the data; free-form queries, variables, annotations, private links, credentials, account identifiers, and raw target labels remain unavailable. The route is rate-limited at the edge and restricted to embedding by this site. The catch-all Access application has one block-all policy and no SSO policy, which closes the login path on the public host.
Accepted 2026-08-21 · public-host login path risk closed 2026-08-25 · active only while the public route is enabled
The live views can die while the site stays healthy
Anything live on this site depends on the lab, even though the pages do not. When the lab is unreachable, a live panel degrades to its last confirmed state with a timestamp on it, and a note says the site does not depend on the lab but this view does. Stale and labelled beats green and wrong. That rule governs monitoring across the whole platform, and this week's reviews found the places where it was not yet true and turned each into a fix, so the word "everywhere" is being earned one closed finding at a time.
Accepted 2026-08-05 · standing rule, enforced finding by finding
Community plugins for the agent tooling are allowlist-only
The default answer to a marketplace extension is no. Demonstrated attacks exist where a malicious extension switches off the very approval gates this platform depends on. The cost is convenience. The benefit is that the control layer's trust surface stays small enough to enumerate.
Accepted 2026-08-05 · no exit planned
The test this page has to pass
A register earns nothing by existing. It earns its place by being checked, so this one is written to be checkable by machine rather than only readable by a person. Every row names the thing it is about, carries the date it was accepted, and where there is one, names the event that ends it. What the rows assert is recorded somewhere concrete: the repository holds the code and the hooks, the append-only run ledger holds what the agent fleet actually did, and NetBox holds what hosts and services exist.
That matters because of who does the checking. It is the same agent fleet that wrote the outage postmortem on this site, reading the same primary sources rather than a summary of them, so a row that has drifted away from reality can be caught by a reading instead of by the incident that would otherwise reveal it. Today that reading happens when I dispatch it, inside the cross-vendor pass that checks every draft claim against the tree. One pass during the outage week caught fourteen wrong claims across three drafts before a word of them published. A standing check that re-reads this whole register against the tree on a schedule is designed and not built, and this page does not claim it runs.
What I would do differently
I would make each entry a generated record with required fields for source, last verification, control, and exit. The current page is structured for review but remains hand-maintained prose.
I would also separate “accepted” from “implemented but unverified” in the source data. Several controls exist in git before they run live, and those states should not depend on careful wording in a paragraph.