< Skip the blank page />

Thinking about an audit or validation engagement? You can give us both a head start. Read the overview, fill in as much of the scope template as you already know — rough is completely fine — and send it over. Our first conversation then begins from a shared picture of your system instead of an empty page.

1. Download the scope template and fill in what you can — the outcome you want, the systems and environments involved, and anything explicitly out of scope.
2. Email the completed template to baxterdoby@gmail.com, with your name in the subject line.
3. I'll review it and reply within a few days with a scoped plan and a quote. Nothing is committed until we've both signed it off.

Prefer to just say hello first? Use the form above — the template can wait until we've talked.

< What to expect />

Before you commit to anything, here's exactly how an engagement runs and what you actually receive at the end — so there are no surprises about the shape of the work or the deliverable.

There are two ways to work with me, and you choose the level of access you're comfortable with.

• Reliability Review — read-only. I analyze your configuration, pipelines, and validation and report where they will fail. Nothing in your system is touched or changed. This is the right starting point if you want to know your weak spots without anyone going near production.
• Validation & Guardrails — hands-on. Everything in the Review, plus the build: I add schema-driven validation and guardrails that reject invalid configuration and data before your system runs. I work in a branch or environment you control, only ever with your written sign-off, and confirm the guardrails catch known-bad inputs before handover. Nothing is attacked, and your production environment is never touched.

How an engagement runs, step by step:

1. 1 · Scope. Using the template above or a few emails back and forth, we agree the tier, the concrete outcome, which systems and environments are in scope, and what's explicitly out. You get a fixed quote before any work starts.
2. 2 · Review. A schema-driven, read-only pass over your config, pipelines, and validation across every environment, surfacing the gap between what the system is meant to do and what it actually does. This is the whole of a Reliability Review, and the foundation of a Validation engagement.
3. 3 · Build (hands-on tier only). In a branch or environment you control, with your written sign-off, I add the validation and guardrails that reject invalid states before they run, and confirm they catch known-bad inputs. This stage never runs without explicit agreement, and never against production.
4. 4 · Findings. A prioritized report — every issue ranked by severity, likelihood, and blast radius — each paired with the specific guardrail that stops it recurring, written so your own engineers can implement it.
5. 5 · Handover. The validation layers, CI checks, and reproduction steps land as a handover pack, with verification that the guardrails hold and an optional retainer to keep them current.

What the report actually looks like. Rather than describe it, here's a complete example you can open and read. It's built on a fictional system, so no real client data appears anywhere in it — it exists purely to show you the structure, depth, and plain-language tone of a real deliverable.

Illustrative example only — a real report is scoped entirely to your system.