You found the long version.

The Watson Standard, defined

The main page lists six promises. This is the whole standard they come from: every rule I hold my own work to, written down and numbered so you can point at a clause when I miss one.

I named the practice Watson Standard on September 24, 2026, because a standard is something you can check. Every clause below is written so you could tell, from the outside, whether I kept it.

0 How to read it

"I" and "me"

Bryce Watson, the person doing your work.

"You"

Whoever hired me, and the people you bring in.

"The work"

Anything I do for you under a quote: a review, a fix, a build, or time embedded with your team.

A clause number

Each rule has one, like 3.2, so if you think I missed one you can point to it. Every number is also a link you can send: watsonstandardco.com/definition#3.2.

Clauses marked on the main page are the six promises from the front of the site.

1 Who you deal with

1. 1.1

   You talk to the person doing the work.on the main page

   That's me, from the first call to the handover.

2. 1.2

   I tell you up front that I use AI coding tools, and which ones.

   Today that's Claude Code and OpenAI Codex. Before I use them on your code, I check that their model-training controls are switched off, including Codex's separate Include environments setting. Your production database and your users' records never go into them. Using AI doesn't lower the bar: every change I hand over gets the same checks, whoever or whatever typed it.

3. 1.3

   No report or code change reaches you without a separate review.

   A fresh AI review pass, not the one that did the work, checks it first. Then I do my own final read.

2 Price and scope

1. 2.1

   You get a fixed price before any work starts.on the main page

   Anything new gets its own quote first. You never pay for something you didn't agree to.

2. 2.2

   I never quietly shrink the job we agreed on.

   If something has to be cut or put off, I say so plainly, as a cut, with the reason, before it happens. Then we agree on what to do.

3. 2.3

   If I happen to notice a problem outside the job, I mention it.

   I only check what the job covers. But I won't keep quiet about something I've seen, and I won't fix it at your cost without asking.

3 Evidence

This is the part the name is really about. A finding is only as good as how it was checked.

1. 3.1

   Every finding says where it is, why it matters in plain words, and what to do about it.on the main page

2. 3.2

   I say how I know.

   Each claim is something I checked, something I worked out from what I checked, or something I'm assuming. The report says which.

3. 3.3

   A stand-in is called a stand-in.

   If I measured one thing to estimate another, I name both. A scanner that finds nothing is not the same as an app that's safe, and I won't write it as if it were.

4. 3.4

   If I couldn't check something, the report says what and why.on the main page

5. 3.5

   I try to prove my own conclusions wrong before you see them.

   Before a number or a "the biggest risk is" goes in a report, I look for how it could be wrong. If it doesn't hold up, I cut it or say how sure I am.

6. 3.6

   Every figure carries its date.

   Prices, counts and settings change. Each one says when it was true.

7. 3.7

   When I pass on what someone else said, I keep its strength.

   If your host's docs say a setting "should" protect you, I write "should", not "will".

4 Fixes and builds

1. 4.1

   Every fix comes with a plain test you approve first.on the main page

   It spells out what "fixed" means before I start, so we agree on the finish line.

2. 4.2

   I test how it fails, not only how it works.

   Every "this succeeds" check has a "what happens when it doesn't" partner, and the pieces get tested together, the way your users will hit them.

3. 4.3

   The handover is clean.

   In the work I hand over: no leftover debugging code, no secrets written into the code, and no files left behind that nothing uses.

4. 4.4

   The notes change with the code.

   If a change I make alters how something works, I update the notes in the code or README that describe it, in the same piece of work.

5 Your app and your data

1. 5.1

   I never test your live app or touch real user data without your written OK.on the main page

   I work from test accounts and made-up data.

2. 5.2

   For a review, I never need your live keys.

   Test keys do the job. If a build needs a live one, you decide how I get it.

3. 5.3

   Nothing goes out in your name without your yes.

   I don't email your users, publish, deploy to your live app or change your accounts unless you've said yes to that kind of change.

4. 5.4

   I don't publish anything that identifies you or your app without your written OK.

6 How I talk to you

1. 6.1

   The point comes first.

   The first line of anything I send is the answer, or the thing you need to do.

2. 6.2

   Plain words, and every technical term explained the first time.

3. 6.3

   Anything waiting on you gets its own short list.

   One line each: what it is, what it changes, and exactly what to say or click.

4. 6.4

   Where the work stands is written down, not kept in my head.

   It lives somewhere you can read, and we agree where at the start.

7 If I miss one

This page describes how I work. It isn't a contract. What a piece of work includes, and any refund or re-fix, are set by your quote, your terms sheet and the guarantee on the main page.

If you think I missed a clause, tell me the number. I'll answer in writing with what happened and what I'll do about it.

8 Revisions

When the standard changes, the edition number goes up and this list says what changed and when.

• Edition 1, September 30, 2026. First published.