AI delivery operating model

Problem

Publishing a portfolio from a working homelab and an active career is a disclosure problem wearing a content problem’s clothes. Every page risks leaking something — an internal hostname, a client-identifying combination, a health measurement, an overclaimed metric. And a single operator writing about their own work has a structural conflict: the author is the person least likely to notice what should not ship. The site needed a content pipeline where privacy and claim integrity are enforced by structure, not by hoping the writer stays careful.

Writing publicly about a home network I actually run and a career I am actually in looks like a writing problem, but it is really a problem of what not to say. Every page risks giving away something it shouldn’t — the name of a machine on my network, enough detail to identify a client, a health figure, a claim bigger than the evidence behind it. And one person writing about their own work has a built-in blind spot: the author is the last person likely to spot what should not be published. So the site needed a process where privacy and honesty are enforced by how the work moves, not by me simply remembering to be careful.

Constraints

In plain terms first: whatever writes a page is never what checks it, publishing needs my approval of the actual words rather than a summary of them, automatic checks block private details before any human looks, and the decision to go live is never automated. The precise ground rules:

The builder never reviews its own work. Every public revision gets an independent review from a fresh context that carries no build history.
Nothing publishes on paraphrase: the owner approves exact claim wording and exact copy, through recorded decisions — not summaries of them.
Sanitization is structural: machine gates fail the build on boundary violations before any human reads it, and the reviewer role carries a mandatory sanitization charter on top.
Production consent is deliberately unautomated. Everything else may be scripted or delegated; the decision to publish is not.

Architecture

Content moves through fixed stages:

Everything published here moves through the same fixed steps, in order:

Claims first — compiled from private evidence records, approved by the owner in structured batches.
Sanitized copy — approved claims become public copy carrying no internal identifiers, evidence IDs, or private values.
Deterministic gates — tests, type checks, a public-boundary scanner (internal hostnames, private addresses, filesystem paths, evidence IDs), and a launch-surface allowlist that fails the build if any unexpected route exists.
Byte comparison — the shipped content is compared byte-for-byte against the approved source.

Delivery is staged: a LAN-only environment serves each exact revision for owner review, an independent reviewer then examines the same revision, and production deploys only after the owner approves that specific commit — with a read-back verification of the live site afterwards. Hosted verify-on-push automation is designed and tracked as the next stage; the production gate stays human by design, not by omission.

Publishing happens in stages. A private copy of the site, reachable only from inside my own home network, shows me the exact version under consideration. A separate reviewer then examines that same version. Only after I approve that specific version does it go live, and the live site is read back afterwards to confirm what actually landed. Further automation is planned, but the final approval stays a human step deliberately, not because nobody got round to automating it.

Recreated diagram. This page itself passed through the pipeline it describes.

AI and agent workflow

The pipeline is operated as a small team of AI roles with bounded charters and separation of duties:

The process runs as a small team of AI roles, each with a written job description and none allowed to do another’s job:

Builder — compiles claims, drafts copy, implements, and deploys; may not review its own work.
Independent reviewer — a fresh context with no build history, read-only access, and refused powers: it cannot deploy, cannot push, and cannot rewrite a claim and approve its own rewrite. Its verdict binds to one exact commit; any content change voids it.
Interviewer — captures the owner’s words verbatim for event write-ups and drafts in the owner’s voice, without publishing anything.
Records clerk — keeps the tracker and wiki current so nothing is lost between sessions.
Specialist updaters elsewhere in the estate follow the same pattern: they execute conventions, they do not set them.

The reviewer’s charter includes a mandatory sanitization pass — direct and combinational identification, internal names and paths, credentials, household, health, and financial material — plus a named critical pass per case: employer inferability for one, health-data handling for another, third-party naming for event pages. Reviews re-verify independently rather than trusting the builder: re-reading live system configuration, re-checking named people against primary sources, sweeping every built page for sensitive tokens.

The reviewer’s job description requires a compulsory privacy sweep every time: anything that identifies a person directly, anything that identifies them by combination, internal machine names and file paths, passwords, and household, health or money details. On top of that each page gets its own named worry — whether an employer could be worked out on one, how health data is handled on another, whether other people are named on the events page. The reviewer checks things again from source rather than taking the writer’s word for it: re-reading the real system settings, checking named people against original records, and sweeping every built page for sensitive words.

Human governance

The owner makes three distinct decisions per publication — the claim batch, the exact public wording, and the exact commit that deploys — each one a recorded, answerable question through structured decision batches.

I make three separate decisions before anything is published: which claims are true and may be made, the exact words that will appear, and the exact version that goes live. Each is asked as a recorded question I have to answer, not assumed.

Corrections flow both ways — the pipeline has corrected the owner’s recollections from primary sources, and the owner has corrected the builder’s groupings from the released record; the primary source is the arbiter.
New disclosures get an explicit yes — when review found an unplanned first disclosure inside already-approved copy, it was surfaced rather than allowed to pass silently.
Readers see the epistemic status — claims are labelled as artifact-verified or owner-attested, and limitation statements survive editing.

Evidence

The pipeline documents itself. Each publication leaves a chain, all versioned privately:

The process keeps its own paperwork. Every publication leaves a trail, all kept privately with its full history:

The claim approvals and the sanitized copy.
The gate results, and the independent review report with a YAML verdict bound to the commit.
The deployment record and the read-back log.

The gate scripts are code in the site repository; the review contract and role charters are versioned documents. This page’s own claims trace to that record, and this page passed the same gates and the same independent review as everything else here.

The automatic checks are real code living alongside the site; the review agreement and the job descriptions are documents with a tracked history. What this page claims traces back to that record, and this page went through the same checks and the same independent review as everything else here.

Outcome

Five gated production publications in a single day — three case studies, a new site section, and identity updates — with zero boundary violations.
Five independent review reports, each bound to an exact commit, each finding real improvements the builder missed and catching real errors, including the builder’s own — with this page’s own review making six.
A reusable content discipline: verbatim capture before prose, exact wording approved rather than assumed, visible maturity labels, conscious consent on every new disclosure.
A delivery pipeline where everything is automated or delegated except the one thing that should not be: the decision to publish.

Lessons

What I would carry into the next system of this kind:

A solo operator can have separation of duties: roles with bounded powers give one person a team’s checks without a team’s headcount.
Independence is a property of context, not intent — a reviewer that shares the builder’s context shares its blind spots.
Make privacy structural: a scanner that fails the build beats a checklist that depends on remembering.
Bind approvals to exact revisions; “approved” without a commit hash is a feeling, not a fact.
Automate everything except consent.