How the work is done.

1. 1

   Operate first. The practices are the proving ground.

   Dental software built from investor decks misses the messy parts — staff handoffs, provider habits, supply drift, follow-up gaps. Anything that becomes a DrSupport service or a product wedge must first survive inside a practice I own, with my payroll on the line.

   In practice. DrSupport's denial-recovery service was proven on TN Dentistry's sedation and hospital claims before it was offered to anyone, with a written go/no-go gate: thirty appeals submitted, twenty resolved, zero privacy or fabricated-fact errors, recovered dollars at least three times fully loaded labor.

2. 2

   Measure before building — and audit the meter.

   A number nobody has checked is an opinion with a decimal point. Every site, form and workflow reports into one warehouse, and the measurement itself gets tested against reality before a decision rests on it.

   In practice. The portfolio read "zero traffic" for months. Reconciling the analytics sync showed it was a broken meter: real visitors had been there all along. A month later the reverse — most "visitors" on every site turned out to be datacenter scanners. Both times the fix was to the measurement, not the sites.

3. 3

   Test; don't read.

   Records describe what was true when they were written. When a system is suspected broken, a small live probe beats a long investigation of its configuration.

   In practice. A web-extraction outage was diagnosed for six days from logs and config files, with a three-stage replacement designed. A twenty-five-cent probe task then showed the service had already recovered. The replacement was cancelled and the rule was written down.

4. 4

   Use the cheapest tool that fully solves it.

   Paid dependencies must be justified on capability, never convenience. If a machine I already own can do the job, it does the job.

   In practice. Web rendering moved from a metered crawling API to headless Chrome on the fleet's own nodes. Nightly Core Web Vitals run on a desktop in Provo with the Chrome already installed there, instead of a rate-limited external API.

5. 5

   Completion means publication.

   Work that lives in one node's files does not exist for the rest of the system, and the next agent rebuilds it. A task is not finished until its output is registered where every other agent — and I — can find it, with a summary and a note on how to reuse it.

   In practice. The founding failure of the fleet was the same thing built twice by nodes unaware of each other. Now every task is bound to prior art before it starts, and a nightly harvest promotes results into a searchable registry. The first night it ran, hollow completions fell from sixty-four to seven.

6. 6

   Honest failure is a valid outcome. Hollow success is not.

   A "done" that produced nothing carries no information and hides the real state of the work. A task may settle as failed with a stated reason; it may not settle as done without an artifact.

   In practice. The settle gate's first true positive was the daily operations brief itself — it had run, produced nothing, and would have been marked done. It was flagged instead.

7. 7

   Humans hold the irreversible.

   Agents are fast and cheap at reversible work. Money, outbound contact, patient data and production code are not reversible, so they pass through a person — me, or a named team member — every time.

   In practice. Code changes land as a branch and a pull request that I merge; nothing pushes to production directly. A thousand personalized outreach emails sat staged for weeks rather than send before a deliverability review. The full threshold is written on the Logic page.

8. 8

   Value counts only when measured and verified by someone else.

   Systems that reward claimed value get claimed value. Self-reported numbers are recorded and shown, but never summed into what the system says it has earned.

   In practice. The first value-ledger row the fleet ever wrote recorded a publication canary honestly as "no value, $0.00" rather than dressing it up. That entry is worth more than a dozen optimistic ones.

9. 9

   Repair the root cause. Don't delete what you don't understand.

   Removing a broken component makes the error disappear and the value that was built into it disappear with it. Diagnose, fix, and keep the thing.

   In practice. An analytics tag that seemed missing from a product site was not missing — it was reporting to a retired property. The fix was one identifier, found by reading the deployed code rather than re-adding a tag on top of it.

10. 10

    One canonical thing.

    Two of anything — two analytics properties for one domain, two deployment projects, two repositories for one product — guarantees that one of them drifts and someone builds on the wrong one.

    In practice. One measurement ID per domain, selected by hostname. One deployment project per domain, linked to one repository. Duplicates are archived, not left "just in case".

Cadence

Direct, then let it run; harvest nightly.

I am most useful setting direction and answering short questions, often from a phone. So the system is shaped around that: decisions are framed to be answerable in a tap, work continues after I direct it, and every night a harvest turns what the fleet produced into something the next day can build on.