I build, study and test the whole Google Cloud estate at principal altitude: networks, security control planes, reliable platforms, agent infrastructure, knowledge systems and autonomous delivery. Alpha is where I expose that work as interactive architectures—what decides, what enforces, what fails and what proves the system works.
Data, AI, agent infrastructure and autonomous delivery are self-taught: studied, used daily and proven in systems I build and run myself.
cloud projects the reference connectivity pattern is designed to carry
100scloud projects the reference connectivity pattern is designed to carry
representative connectivity domains in the illustrative fabric
6representative connectivity domains in the illustrative fabric
verification gates from truth to production
11verification gates from truth to production
scenarios and failure drills across seven drafted sheets
41scenarios and failure drills across seven drafted sheets
tool domains behind one policy gateway
8tool domains behind one policy gateway
REPRESENTATIVE SCALEFigures describe what the patterns are designed for, not a disclosed inventory.
Prologue · The end, firstHow do I read an exhibition that responds?
Hands on · Thirteen interactive systems
Everything here responds.
These are not pictures of systems. Each one runs in your browser: pick, step, play, drag, break and replay it, and it shows what decides, what enforces, what fails and what proves it. Look for the red marker; it sits above everything you can operate. On a phone, the bar at the bottom walks you through the atlas one section at a time.
I see one unbroken line: cloud infrastructure becomes reliable platforms, platforms become agentic systems, agentic systems acquire memory, memory enables autonomous workflows, and autonomous workflows hand the irreducible work back to the human—creativity, judgment and purpose.
Unleash creation. Govern promotion.
I build governed AI workforces and the factories that produce them, so building becomes repeatable, verifiable and owned by the people it serves. Nothing I ship is finished until something other than its builder says so.
Act I · The structureWhat is the whole, before any part?
00The stack
Seven layers, one discipline.
Each layer exists to make the one above it boring. Pick a layer to see what lives there, then jump to its working diagram.
I work across the whole estate and own the seams between its layers. Each layer exists to make the one above it predictable.
Principal altitude is how I hold the whole estate in view: every layer, every seam, every enforcing mechanism and every proving test.
▶ Interactive · tap to trySelect any layer to see what lives there, then jump to its working diagram.
Agents as bounded workers: a role, a policy, tools exposed over the Model Context Protocol, approval gates for anything consequential, and an audit trail for everything.
The same rules decide a firewall policy, a release and an agent's permissions. The profile gives each one its proof. Read how I work →
01
Shapes before recipes
Draw the system until its shape is obvious: boundaries, planes, paths and decisions. Implementation details come later and remain private.
02
The platform enforces; documents do not
Every rule names the platform mechanism that enforces it. If the platform only observes it, the design says so plainly.
03
Nothing is called done on a feeling
A control closes only when its proving test passes. A release receives traffic only after verification. The evidence lives beside the claim it proves.
04
Policy before anything is real
A change remains intent until its plan passes policy, receives the required approval and is applied through the governed path. After release, the error budget sets the pace.
05
Reversible by construction
Build the new path before closing the old one. Keep the way back open until verification is signed, with rollback designed and tested as part of the change.
Act I · The structureHow does a system decide, one step at a time?
Workflows · Step through
Pick a workflow. Walk it.
Eighteen workflows across the stack and the blueprint's control planes, each walked from intent to evidence: what happens at every step, the mechanism that decides it, what it leaves behind, and what happens when a step fails. Press Play, or step through at your own pace.
I make architecture legible as a sequence of decisions: what decides each step, what evidence it leaves and where it stops when a check fails.
▶ Interactive · tap to tryChoose a workflow, press Play or step with Next and the arrow keys. A step marked ◆ shows what happens when it fails.
Cloud foundations
Security & posture
Reliable platforms
Agentic systems
Knowledge & memory
Autonomous delivery
Reliable platforms
A change is intent until every check has passed.
From pull request to promotion: built once, signed, checked against policy, approved by a person, admitted by signature, released to a canary and judged by the SLO.
8 steps · ◆ marks a step that can fail; select it to see what happens then.
Owners of the paths it touches review it. The pipeline definition is protected, so a change cannot edit the checks that judge it.
Decided by · Code owners
Evidence left behind
Review recordpropose
SANITIZED REFERENCE ARCHITECTUREPATTERN ONLYReal mechanisms · no employer or client configuration
Act II · The groundHow does anything reach anything else, legibly?
01Cloud foundations
A network a new team joins by declaring intent.
An illustrative fabric: six representative connectivity domains around a routing core. Spokes never peer directly; hybrid, service, egress and east-west traffic each take one legible path. Trace a flow.
I design the network before the first spoke exists, so teams join by declaring intent and every flow follows one legible, governed path.
Credential · Professional Cloud Network Engineer
▶ Interactive · tap to tryPick a flow and the fabric redraws its one legible path, hop by hop.
On-premises→
Interconnect→
Hybrid hub→
Routing core→
Prod hub→
Workload A
Private links terminate on cloud routers in the hybrid hub. Prefixes are advertised once and learned only where they should be.
Drafted studies
Sanitized reference sheets, drawn with generic labels in place of inventory, addresses and resource identities. Each one runs: pick a scenario, including the failure drills, and walk it hop by hop. Every hop names the mechanism that decides it. Here: hybrid connectivity, and the edge.
▶ Interactive · tap to tryPick a sheet and a scenario, press Play or step through it, open it full screen, or download the SVG. Red chips are failure drills.
Control plane
Data paths
Failure drills
Swipe sideways to pan the sheet, or open it full screen and turn your phone.
Step 6 of 6
Sanitized reference architecture · no employer or client configuration reproduced
Control plane
Route exchange
How the network learns where things are, before a single packet moves.
Step 6: Advertise back, on purpose. Cloud Routers advertise the spoke ranges and the private API endpoint to on-prem as custom advertisements: an explicit list in code, reviewed like any other diff, not whatever happens to exist. Decided by Custom route advertisement.
What the prod spoke learns
Destination
Next hop
State
On-prem aggregate
Hybrid spoke · 4 VLAN attachments · ECMP
active
On-prem aggregate
HA VPN tunnels · worse MED
standby
Services ranges
Services VPC spoke
active
Data ranges
Data VPC spoke
active
Non-prod ranges
Excluded by export filter
filtered
General notes
Show the general notes ↓Fold ↑
01Diversity is the designFour attachments across two metros and four edge availability domains, on routers in two regions. Any single failure costs capacity, never reachability.
02Control plane is not data planeCloud Routers learn and advertise routes; packets never pass through them. Diagrams that draw traffic through the router are describing a different system.
03Spokes never peerEvery VPC is a spoke on the hub. Isolation between prod and non-prod is an export filter in code, not an absence of peerings someone has to remember.
04Private by constructionGoogle APIs and shared services are reached through Private Service Connect endpoints. Nothing on this sheet needs a public address to work.
Act II · The groundWhat must hold beneath every workload?
02The security blueprint
Six control planes, under every workload.
A reference security architecture for Google Cloud, written so that every rule names the platform mechanism that enforces it. Governance, Identity, Network, Edge, Data and AI; the workload platforms inherit all six. Pick a plane.
I design six control planes beneath every workload. The platform enforces each control, a proving test closes it and every exception expires.
Credential · Professional Cloud Security Engineer
control planes under every workload
6control planes under every workload
design principles the planes follow
12design principles the planes follow
controls in the catalog, each with its mechanism, proving test and owner
70controls in the catalog, each with its mechanism, proving test and owner
steps every control goes through
5steps every control goes through
days: the longest an exception may live
90days: the longest an exception may live
REPRESENTATIVE SCALEPlanes, principles and steps are counted from what this page draws; the catalog size and the exception limit are design figures.
▶ Interactive · tap to tryPick a plane to read what it guarantees, how the platform enforces it and the test that proves it.
Plane 2 · Identity
Every actor is known, short-lived and least-privileged.
How it is enforced
Four paths and no fifth: workforce through the identity provider's pool, build through one per-project provider, deploy through a second, key replacement through federation
Attribute conditions pin each provider to one repository and one stack by numeric identity; production adds a protected ref
One deployer per project: the build identity cannot deploy and the deploy identity cannot build
Service-account keys retired in waves by disable, soak, delete; creation and upload blocked, expiry set once
No standing administrator access: just-in-time elevation, and in the hub-and-spoke estate an emergency-change group that is empty by default
Two sealed break-glass accounts outside the pool that page on any use
The proving test
A token from the wrong project, stack, audience or unprotected ref is refused at the exchange, and the audit log names both the federated principal and the account it became.
Workload platforms Serverless containers and Kubernetes inherit all six planes and add gates of their own: two independent gates on every request (a network setting and an identity check that fail separately), admission by signed digest, private nodes and control planes, workload identity without keys. See A-102 ↓
Twelve principles
The rules the planes follow. Each one is a design decision that the mechanisms above make real, and none of them is a wish.
01
Private unless decided otherwise
Nothing is reachable, callable or readable by default. Exposure is a recorded decision with an owner.
02
The platform enforces; documents do not
Every rule names the organization policy, IAM condition, firewall policy or admission control that enforces it, or says plainly that it is watched and not prevented.
03
No long-lived secrets
Identities are federated and short-lived for people, pipelines and workloads. Service-account keys are retired, not rotated.
04
Two independent gates
Reaching a workload requires passing a network control and an identity control that fail separately.
05
Measure, test, triage, enforce, verify
Every control goes through the same five steps, and closes on its proving test, run from outside.
06
Build the new path before closing the old one
Callers move first; the old door closes second.
07
Exceptions are narrow and expire
Dated, owned, bound by tag, 90 days at most. An exception is never an edit to the policy; a standing need is an approved pattern.
08
Build and deploy are separate powers
The build plane builds and the deploy plane deploys, and neither identity can do the other's job.
09
Two estates, one standard
The established estate and the hub-and-spoke estate are held to the same controls. The one that is leaving is not exempt because it is leaving.
10
Remediate first
A workload meets every control that applies to it, where it runs today, before it migrates. Migration is never the remedy for something that can be fixed in place.
11
Nothing lands by hand
Every hub, spoke and workload in the hub-and-spoke estate is created and changed only through the pipeline.
12
Tags decide, labels describe
Controls read tags, which only the pipeline binds; quarantine in an incident is the one exception. People and reports read labels. Neither is typed by hand.
Every control, five steps
A control closes on its proving test, run from outside, not on the day its policy was written. Where a constraint has a dry run, the test is the dry run; where it has none, an inventory count and a sandbox proof.
01
Measure
Count it from the live inventory, never an export
02
Test
Dry run where the constraint has one; sandbox proof where it has none
03
Triage
What the test found, with an owner and an order
04
Enforce
On a published date, folder by folder
05
Verify
The proving test, run from outside
Tags decide, labels describe
One record per project, written twice by the pipeline. Controls read tags; people and reports read labels; nobody types either. Firewall identity is derived from the same record and bound on each machine.
Six identity tags, on every project
estate
environment
portfolio
team
classification
regulated scope
Six identity tags, bound on the project by the project module in the apply that creates it. A rule that reads a tag gives the stricter result to a project without one.
Firewall tags, derived and bound per machine
portfolio
role
environment
regulated scope
quarantine
Firewall values are derived by the plan policy from the identity tags and bound on each instance, template and node pool; they are not inherited. Quarantine is the one tag the pipeline does not bind: incident tooling binds it, and every binding pages.
Seven labels for ownership, purpose and provenance, stamped on every resource by the stack that builds it. No access or network decision reads a label.
Two estates, one standard
An established shared network and a hub-and-spoke estate, held to the same catalog. Three moves take a portfolio tier from one to the other, a gate sits between the second and third, and the way back stays open until verification is signed.
▶ Interactive · tap to tryStep through the pathway from one estate to the other; every step says what happens if it fails.
Established estate · remediate in placeGateHub-and-spoke estate · reversible until signed
The gate · step 5 of 9
The readiness gate
A readiness record per tier, opened as a merge request with the evidence of the steps before it, approved by security and by network owners, never by the owner alone. It merges, and the gate tag is set to passed.
Decided by · Two approvals
If this step failsThe record does not merge and the tier returns to remediation or normalization. A passed gate lapses after 30 days without a landing, and the evidence is read again.
SANITIZED REFERENCE ARCHITECTUREPATTERN ONLYNO EMPLOYER OR CLIENT CONFIGURATION REPRODUCEDThree moves, one gate, one way back until verification is signed
Drafted sheets: identity, policy, data
The planes drawn as working sheets, with failure drills. Edge is drawn with cloud foundations above; the AI landing zone with agentic systems below.
▶ Interactive · tap to tryPick a sheet and a scenario, press Play or step through it, open it full screen, or download the SVG. Red chips are failure drills.
The four paths
Failure drills
Swipe sideways to pan the sheet, or open it full screen and turn your phone.
Step 5 of 5
Sanitized reference architecture · no employer or client configuration reproduced
The four paths
Workforce sign-in
A person reaches the estate through the identity provider and the workforce pool, and holds read roles.
Step 5: Elevation in the established estate is just in time. An entitlement names the eligible group, the approvers and the maximum duration. In the hub-and-spoke estate elevation is time-boxed group membership instead, because the deny policy wins over any role. Decided by Privileged access entitlement.
Evidence left behind
Sign-in recordrecorded
Policy bindingrecorded
Grant · expiryrecorded
General notes
Show the general notes ↓Fold ↑
01Four paths, no fifthWorkforce, build, deploy and key replacement. Every other way in is refused by the allowed-members rule or the deny policy.
02The condition is the controlEach provider pins issuer, audience and the numeric identity of one repository or one stack. A federated principal is never granted a role directly; it impersonates an account, and the audit log names both.
03Separate powersThe build account writes the registry and nothing else. The deployer applies and cannot build. The planner reads.
04Keys are retired, not rotatedDisable, soak, delete, in waves by evidence of use; then creation and upload are blocked for good.
SANITIZED REFERENCE ARCHITECTUREPATTERN ONLYNO EMPLOYER OR CLIENT CONFIGURATION REPRODUCEDTooling named by role, never by vendor · no internal catalog identifiers · no estate inventory
Act II · The groundHow do I know the ground still holds today?
03Security & posture
Stop triaging findings. Read the graph.
A severity list tells you what is wrong with each thing. A model of the estate tells you which wrong things line up into a path to something that matters, and which security and platform stakeholders own each link.
I read the estate as a graph: which conditions form an exposure path, who owns each link and what daily evidence proves the path is broken.
▶ Interactive · tap to trySwitch from the findings queue to the graph, select any dot, then break a path and watch the findings it retires.
Sixty findings in the order a scanner ranks them: by severity, with nothing connecting them. Select any dot to see what it is, or follow a guided look.
Look at
Select a dot or a guided look to see what a finding is, where the queue put it, and where the graph puts it.
60
findings, sorted by the vendor's severity
10
marked critical, at the top of the queue
0
relationships between them
?
which ones reach anything that matters
SYNTHETIC DATAPATTERN ONLYIllustrative model · invented findings · no vendor output reproduced
Evidence that judges itself
The posture platform as a pipeline: a collector that can only read, a judge that cannot see the estate, a ledger that is the only authority, and a reviewer who is not the judge. Play one daily run.
▶ Interactive · tap to tryPress Play, or step through the run from the read-only collector to the reviewer who signs.
Step 1 of 8 · Collector · read-only identity
01 · Collect
A daily sweep, and only reads
A scheduled job sweeps every active project in scope with list and get calls, nothing else. Each pull lands as a raw file with its checksum, and one envelope row records what the pull was and how it ended.
The independence ruleThe collector can see the estate and cannot touch it: its identity holds read roles only, and the job issues no mutation.
Leaves · Raw files · checksums · envelopes
What a pull can say
okPulled, at least one record
emptyPulled, zero records, and the API answered
api disabledThe service is not enabled here: nothing of that type can exist
permission deniedNot seen. The station emits a gap, never a zero
errorAny other failure, recorded with its cause
What a verdict can be
supportedGate satisfied, sources covered, at least one modelled edge
action requiredThe gate says so, or an escalation is flagged
blockedA decisive rule failed or a governing premise is unmet
unknownTopology absent, or a station's coverage incomplete
A lab implementation of this pattern runs on Google Cloud, provisioned from code: a daily collector, a daily judge half an hour later, a transactional ledger, a warehouse projection and a governed read surface. What is drawn here is its shape. It describes no employer's or client's estate.
SANITIZED REFERENCE ARCHITECTUREPATTERN ONLYA lab implementation runs daily · nothing of any estate is drawn
Act III · The roadHow does change reach production without trusting a feeling?
04Reliable platforms
Policy before anything is real. Budgets set the pace.
Infrastructure changes are intent until a plan has been computed, checked and approved. After release, a service level objective decides whether the next change ships.
I build governed platforms where policy decides what may ship, verification decides what may receive traffic and the error budget sets the pace.
Credential · Professional Cloud Architect
01
Intent
A reviewed diff in code
02
Plan
What would change, computed
03
Policy
Checked against guardrails
04
Review
A person approves the plan
05
Apply
The only path to real
06
Roll out
Progressive, reversible
07
Observe
SLOs judge the result
The error budget, worked
Choose a month and drag through it. The arithmetic is real; the policy on the right is the kind of rule a team agrees on before the incident, not during it.
▶ Interactive · tap to tryChoose a month, then drag the day slider; the policy decides whether the next change ships.
SLO
99.9% / 30 d
Budget
43.2 min
Remaining
23.0 min
Burn rate
0.7x
Policy decides
Ship
Budget in hand. It exists to be spent on change, so keep shipping.
SYNTHETIC DATAReal arithmetic, invented months · thresholds from the standard multi-window burn-rate pattern
Drafted sheet: workload landing pads
Two governed runtimes and the loop that closes the paved road, with the failure drills that prove the gates.
▶ Interactive · tap to tryPick a sheet and a scenario, press Play or step through it, open it full screen, or download the SVG. Red chips are failure drills.
The paved road
Failure drills
Swipe sideways to pan the sheet, or open it full screen and turn your phone.
Step 10 of 10
Sanitized reference architecture · no employer or client configuration reproduced
The paved road
Ship a change
One change from pull request to 100% of traffic on Cloud Run.
Step 10: Budget intact, promote. With error budget remaining, the release promotes to 100%. The next change starts again at the pull request. Decided by Error budget policy.
Evidence left behind
Review recordrecorded
Test report · SBOMrecorded
Scan resultrecorded
Signed attestationrecorded
Plan · policy verdictrecorded
Approver · timerecorded
Release · admission logrecorded
Traffic recordrecorded
Canary analysisrecorded
Promotion recordrecorded
General notes
Show the general notes ↓Fold ↑
01Cloud Run is the defaultRequest-driven services with no nodes to patch and scale to zero. Most workloads belong here, so the paved road makes it the fastest place to land.
02GKE when it needs itLong-running or stateful work, sidecars, daemons, GPUs or custom networking. Same admission rule, same identity model, same SLOs.
03Decide what is impossibleUnsigned images, public ingress on internal services and exported keys are not discouraged. They are refused, and the refusal is evidence.
04The loop closes the designTelemetry comes with the module, and the budget policy decides whether the next change ships. Reliability is a gate, not a report.
Act IV · The workersWhat may a machine do, and who decides?
05Agentic systems
Agents are workers with a job description.
A role, a policy, tools served over the Model Context Protocol behind one gateway, a person on every consequential action and an audit record of all of it. Step through a run.
I treat agents as bounded workers: each has a role, policy and scoped tools; deterministic software owns authority and control flow, and a person decides every consequential action.
▶ Interactive · tap to tryStep through one run from request to audit record; it pauses where a person must approve.
01 · Request · Operator
“Summarise this week’s new exposure paths and open a change for the worst one.”
PATTERN ONLYSYNTHETIC DATARepresentative run · real runtime shape · no production data
Show the tool domains and operating principles ↓Fold ↑
Tool domains
Each domain is its own MCP server with its own scopes. The gateway authenticates, scopes and rate-limits every call.
estate
Cloud inventory and reachability
knowledge
Typed knowledge search
memory
Recall and store, with provenance
approval
Human-in-the-loop gates
workflow
Status of long-running work
documents
Structured extraction
browser
Verification in a real browser
change
Diffs into the delivery pipeline
Operating principles
01
Read-only by default
Every role starts with no write access. Capability is granted per tool, per scope.
02
Tools, not text
Agents act through typed tools behind one gateway, never by emitting commands for someone to paste.
03
A person on every consequential action
Anything that changes money, access or production pauses for an approval.
04
Everything is recorded
Inputs, tool calls, sources, approver and result. A run can be replayed and audited.
05
Evaluated before promoted
A new prompt or model version runs against a fixed evaluation set before it touches real work.
A constitutional control plane
Deterministic software owns permissions, workflow state, approval gates, memory promotion and audit; the model proposes. Choose what an agent is about to do and read the verdict, and the law that decides it.
▶ Interactive · tap to tryChoose what an agent is about to do; deterministic code returns the verdict and the law behind it.
The prime law
No model owns the system's control flow.
A model may interpret, classify, propose, reason, retrieve, synthesise and recommend tool calls. It may not control permanent authority, permission escalation, irreversible execution, canonical memory, workflow state, identity or audit history. Those belong to deterministic software.
01
No model owns workflow state.
02
No agent owns its own permissions.
03
No retrieved content becomes an instruction.
04
No consequential action without deterministic authorization.
A verdict is computed before execution, not inferred after it.
05
No important claim without provenance.
06
No memory becomes canon because an agent generated it.
07
No two write-capable agents share a workspace.
08
No major proposal escapes adversarial review.
09
No domain silently dominates another.
10
No uncertainty is silently converted into certainty.
11
Every action must return a verdict from reality.
12
Only the owner may change the identity canon.
Operating principle
Claims may travel freely. Acts are gated.
Reading, retrieving and proposing are claims: they can be wrong, and nothing changes because of them. Everything that cannot be undone is an act, and an act waits for a verdict.
What is the agent about to do?
For example: Open the change for review, send a message, spend money
REQUIRE APPROVALby law 04Act · gated
Hard to undo, so a person decides first, shown exactly what will happen.
Proven locally: a control plane with a legal-transition state machine and an append-only, idempotent event log; a policy engine with deterministic verdicts; isolated worktrees under leases; a verification gate before completion; memory nomination. A development project is bootstrapped on Google Cloud. Pattern level, no production claim.
PATTERN ONLYA deterministic verdict · the model proposes, the policy engine decides
Drafted sheet: the AI landing zone
Where models may run, what holds them there, how every prompt and response is screened, and what bounds an agent that can call tools.
▶ Interactive · tap to tryPick a sheet and a scenario, press Play or step through it, open it full screen, or download the SVG. Red chips are failure drills.
Data plane
Control plane
Failure drills
Swipe sideways to pan the sheet, or open it full screen and turn your phone.
Step 6 of 6
Sanitized reference architecture · no employer or client configuration reproduced
Data plane
One grounded inference request
What one model call from a landing-zone application passes through, and where it is refused.
Step 6: Evidence: log, counts, audit. Per-call findings exist only in the platform log, which also holds prompts and responses in full, so it is explicitly off until privacy decides and then restricted. Counts go to monitoring: zero screened requests for an active application means coverage failed. Decided by Logging policy.
Evidence left behind
Screening findingrecorded
Denied callrecorded
Block reason · countrecorded
Platform log · countsrecorded
General notes
Show the general notes ↓Fold ↑
01Only in the landing zoneService restriction denies the AI platform everywhere else; the model allow-list and the endpoint deny list decide which models and regions, and the consumer API is held by API-key constraints.
02Floor and templatesThe organization sets a screening floor that one stack writes; each application raises it with templates. Tune the template, never the floor. Production blocks from its first call.
03Three identities per use caseThe model caller, the grounding reader and each tool are separate, keyless and least-privileged, so an injected instruction fails at IAM before it fails anywhere else.
04Four tiersAssist, grounded, customer-facing, agentic. The tier is a privileged tag the intake sets, and it decides the controls, the sign-offs and the review cadence.
Act V · The memoryHow does a decision stay joined to its evidence?
06Knowledge & memory
Knowledge as a living system.
Typed objects joined by typed relationships, so a decision links to its evidence and a runbook to the system it operates. People and agents walk the same graph. Memory is arriving: systems that carry the record forward and improve with experience. Ask it something.
I keep decisions joined to their evidence, sources, owners and operating systems in one typed graph that people and agents can traverse.
▶ Interactive · tap to tryAsk one of the four questions and the graph lights the path that answers it.
The decision arrives with its evidence, its sources and the idea behind it. Nobody has to reconstruct the reasoning from chat history.
PATTERN ONLYGeneric object types · the working schema stays private
Act VI · The factoryCan the method build, and then build itself?
07Autonomous delivery
A factory that builds repositories, including this one.
An architecture becomes a verified repository through dependency-ordered build contracts, worked backward from a terminal condition. Each contract passes a verification gate and leaves evidence. The graph below is this site's own, read from its manifest at build time.
I turn architecture into verified repositories through dependency-ordered contracts. Each contract passes a gate and leaves evidence; this site is one result.
The method builds the artifact.
The method builds itself.
The method submits both to an independent gate.
Terminal condition→
Dependency order→
Isolated creation→
Verification gate→
Production receipt→
Recursion→
Accumulated learning
The method behind it, in four movements: How I build →
▶ Interactive · tap to trySelect any contract to see what it waited for and unblocked, or replay the whole build in dependency order.
How to read the build graph ↓Fold ↑
01
Each card is a build contract
One piece of this site: what it built, and the verification gate it had to pass.
02
Order comes from dependencies
A contract starts only when everything it waits for has passed its gate. Phases group them by purpose.
03
Done means the gate passed
Select any contract to see what it did, what it waited for and what it unblocked. Or replay the build.
Ship it reversibly: a tagged revision with no traffic, verified, then promoted.
Gate G7 · Full assembly
Passes when: every capability connected; nothing is a shell.
Waits for
Unblocks
Nothing yet: this is the latest contract.
Status · complete
Read from this site's own factory manifest when the page was built · structure only
The gate ladder
Nothing is called done on a feeling. A contract is complete when its gate passes and the evidence is written down: implemented, tested, merged and deployed are each short of it.
Show all 11 gates ↓Fold ↑
G0
Repository truth
Baseline, branch state, existing failures recorded
G1
Architecture & contracts
Invariants, APIs, schemas and trust boundaries agree
G2
Static quality
Types, lint, schemas, generated code consistent
G3
Unit & domain
Invariants and state transitions proven
G4
Data & integration
Migrations, adapters, isolation, failure paths
G5
Security
Authorisation, secrets, input boundaries, audit
G6
Vertical slice
One real journey through every layer
G7
Full assembly
Every capability connected; nothing is a shell
G8
Deployment & runtime
Preview deploy, smoke tests, health
G9
End-to-end & resilience
Critical journeys, failure states, accessibility
G10
Production completion
Only external activation remains
The production receipt is issued by the gate, never by the builder.
Epilogue · The returnWhat was the machinery for?
The top of the stack · the return
Back to people and decisions.
Autonomous delivery is not the last layer. Above it sit the people who hold intent and the gate; every layer below exists to give them clearer information and more room for judgment. The machinery exists to return us to purpose. The profile carries the rest: the doctrine, the method, the proof and where the certified ground ends.
Appendix · For referenceWhat is the work made with today?
08Toolbelt · present vocabulary
What the work is made with.
Google Cloud by name, because it is the subject; everything else by the role it plays. Tools change. The disciplines underneath them (legibility, least privilege, verification, reversibility) are the part that carries over.
I choose tools by the discipline they must uphold: least privilege, legibility, verification and reversibility.
Show the toolbelt ↓Fold ↑
Cloud
Google Cloud
Shared VPC
Network Connectivity Center
Hybrid interconnect
Private Service Connect
Cloud Armor
VPC Service Controls
Kubernetes
Serverless containers
Pub/Sub
Cloud SQL
BigQuery
Infrastructure as code
Declarative infrastructure code
Module design
Policy checks on plans
Drift detection
Security
Organization policy
Secure tags
Workload identity federation
Posture management
Exposure-path analysis
Policy as code
Least privilege
Evidence automation
Reliability
SLOs
Error budgets
Burn-rate alerting
Runbooks
Observability
Application platforms & runtime architecture
TypeScript
Python
Server-rendered web applications
Typed API services
PostgreSQL
Row-level security
Applied AI
Frontier language models
Structured outputs
Model Context Protocol
Agent orchestration
AI landing zones
Prompt screening
Evaluation harnesses
Retrieval
Verification
Property-based tests
Golden files
Real-browser end-to-end tests
Accessibility audits
Factory gates
Appendix · For referenceWhy does each design hold?
Long form
Read the exhibits.
In the reference designs, I show why each architecture holds, what it refuses and how its claims are proved.
What is not on this page · Prompts, schemas, rule contents, address plans, identifiers, vendor findings, and anything that belongs to an employer or a client. The shape is the exhibition; the recipe stays private.