Field notes from the writing room.

The SWU counter-model to seat licensing, opaque pipelines, vendor lock, and retainer treadmills: shared ledger, exit-ready artifacts, partnership clauses, with falsifiers (Class C, E, F).

The six receipts SolutionWright publishes on every engagement — latency, cost-per-task, refusal rate, override rate, falsifier-status, and evidence-class mix — and why a single composite score should make you walk away. (Evidence classes A, B, C, F.)

Five clauses you can paste into any AI engagement contract to convert a vendor relationship into a partnership — exit-ready artifacts, shared ledger, no dark dependencies, published falsifiers, and disclosed evidence classes (Class C, with redlines).

The patterns SolutionWright uses so a client can read exactly what the system did and why — append-only ledger, evidence-classed claims, gate-and-approval loops, and a falsifier attached to every artifact (Class B, Class C, Class F).

The SolutionWright receipts discipline: every claim tagged with an evidence class, every claim paired with a falsifier, and a single ledger you can inspect at week 1, week 4, and week 12 (Class B, C, F).

A plain-language gating doc: who the SWU workshop is for, who it isn't, the four readiness signals we check before we take a fee, and what a 30-minute scoping call actually covers (Class C, Class E, Class F).

Refusing extraction patterns is a strategic stance, not a moralizing one — extraction destroys the compounding trust that drives referrals and renewals (Class C, E).

The SWU rule that every engagement is exit-ready at every point in time — the artifacts you own outright, the runbook test, and how the handover actually works (Class C, E).

Six specific sentences that show up in extractive AI services proposals, with the one-line question that tests each before you sign (Class C, E).

Why SWU refuses to introduce dependencies the client cannot see, name, and replace, with real-world dark-dependency patterns we have refused on engagements (Class C, E).

The economic case against black-box AI pipelines: every undocumented dependency is a future renegotiation in the vendor's favor, with the SWU transparent-pipeline counter-pattern (Class C, E).

Why seat-based AI pricing creates extraction incentives, the arithmetic on a 50-seat 3-year contract, and the outcomes-based alternative we use instead (Class C, E).

A worked 3-year vendor-lock scenario compared against an exit-ready engagement — direct, indirect, and optionality costs, with the numbers shown (Class C, E).

How an AI services retainer quietly becomes an annuity, the pattern signals to watch for, and the exit-condition clauses SWU writes into our own contracts to prevent it (Class C, E).

A vendor who publishes the test that would prove them wrong can be evaluated. A vendor who does not, cannot. That asymmetry should drive procurement.

A plain self-assessment for buyers considering a scoping call: problem named, owner named, data accessible, exit condition exists. (Evidence classes E, C.)

The most common workshop blocker isn't the model or the scope — it's a data set locked behind an internal team. Here's how we surface it and unstick it before the contract is signed (Class E, Class C).

Why SWU writes the exit condition into the scoping doc before any code is written — and the four-line template we use to do it (Class C, E).

The handoff between scoping call and engagement kickoff — what gets signed, what gets shared, what gets stood up — so the buyer knows exactly what to expect.

Why a sharp problem statement decides whether a workshop ships value or burns six weeks on the wrong target — with three real intake rewrites.

Why SWU refuses to start an AI engagement without a named internal owner on the client side — and the specific things we do during the workshop to confirm the owner is the real owner (Class C, Class E).

A buyer-side framework for matching the depth of an engagement to the depth of the actual problem — borrowed from Maren's three-tier AI worker framing and applied to scope. (Evidence classes E, C.)

A minute-by-minute walkthrough of the SolutionWright scoping call — the questions we ask, the signals we listen for, and what you walk away with on the call itself. (Evidence classes E, C.)

An honest disqualifier post: the buyers who should not book the SolutionWright workshop, and what we recommend instead so nobody loses time or money.

How SWU runs a monthly read-only audit of its own infrastructure, publishes what it finds, and what happens when the audit catches us off-side (Class C, E).

SWU bakes the falsifier into the artifact format — if a deliverable has no test that could break its claim, the format itself rejects it before it ships. (Class E, Class C)

A gate-and-approval loop puts a named human in front of every irreversible action, generates a receipt for the approval itself, and refuses to act without one. (Evidence classes E, C.)

Why SWU builds pipelines a client engineer can read end-to-end on a single screen, and what we trade away to make that possible (Class C, E).

The append-only engagement ledger is a single, ordered file that records every commitment and decision — here is how the pattern works, why it is a standard control in serious engineering, and what it costs to maintain (Class C, Class E).

How SWU runs the public /transparency page — what we publish, what we redact, what we never hide — and the architectural rules that keep it honest (Class C, Class E).

How SWU redacts client-identifying data while still publishing six receipts publicly — the rule, the format, and the consent flow (Class C, E).

How transparency (receipts and accountability) differs from open-source (license and code access), and where SWU draws each line in client engagements (Class C, E).

A standing SolutionWright disclaimer: what we refuse to say about AI, healing, and outcome guarantees — and why those refusals are the whole point (evidence: E, C).

Why per-token pricing hides the real unit economics of an AI engagement, and the cost-per-task framing SolutionWright puts on every quote.

How the proportion of A/B/C/E/F/U claims shifts across the twelve weeks of an engagement, and what to do when the mix stops moving in the right direction. (Evidence classes E, C.)

Publishing raw latency — every request, every tail event — surfaces failure modes that p50/p95 hide. A walk-through with one live SolutionWright incident. (Evidence classes E, C.)

Override rate is the share of system outputs a human rewrites or replaces before use; a non-zero number is a feature, not a bug, and the line we tune the gates against. (Evidence classes E, C.)

Why SolutionWright publishes the running state of every falsifier on every engagement — and why a 'failed' receipt is sometimes the most valuable one we ship.

Refusal rate — how often a system declines to answer when it isn't sure — is the single most predictive number we track on AI work, and almost no vendor publishes it (Class E, Class C).

A field-guide walkthrough of the six numbers SolutionWright publishes on every engagement — what each one is, how it is measured, and the failure mode it catches. (Evidence classes E, C.)

A redacted real-world example of publishing the six receipts on a bad week of a live engagement: what went wrong, what the dashboard caught before the client noticed, and what we changed. (Evidence classes E, C.)

Composite scores hide drift by averaging trade-offs that move in opposite directions; here is why SWU refuses to roll up the six receipts and what twelve weeks of raw series actually look like. (Evidence classes C, E.)

SWU contracts include a clause requiring evidence-class disclosure on every artifact we deliver — and grant the buyer a right to refuse delivery when the class is U. (Class E, Class C)

The contract paragraph SWU writes on day one — what the client owns, what is transferable, what is documented — so 'walk away clean' is a clause, not a promise (Class C, E).

How SolutionWright writes the falsifier-publication promise directly into the contract, including the trigger conditions and what happens when a failure event is recorded.

A partnership engagement is two-sided: this post lists what SWU owes the client — promptness, evidence, hard truths — and the public receipts we publish on ourselves to prove it (Class C, E).

When budgets tighten, opaque engagements get cut first. The SWU argument for why the receipts discipline is a counter-cyclical moat, not a luxury, with evidence (Class E, C).

Three categories of engagement SWU refuses — extraction-shaped briefs, undisclosable goals, and missing internal owner — and how saying no protects the client too (Class C, Class E).

The exact contract clause SolutionWright requires on every engagement: shared, append-only ledger access for both sides, with read rights that survive the contract (Class C, Class E).

In a healthy partnership engagement, the renewal meeting is a one-page review of the six receipts, the falsifier status, and the next exit condition — not a sales pitch (Class E, C).

The three load-bearing clauses SWU writes into every engagement — shared ledger access, exit-ready artifacts, and a published-falsifier commitment — with redline language you can hand to counsel (Class C, Class E).

A claim with no test that could disprove it is marketing, not engineering. Three SolutionWright claims, each with its published falsifier.

Inside the append-only engagement ledger SolutionWright keeps for every client — what it records, what it makes impossible, and a redacted example from a live engagement (Class C, Class E).

A buyer-side reading guide for any AI services proposal — what to look for, what to red-line, what to refuse — grounded in evidence classes and configuration receipts (Class E, C).

A concrete checklist of what a SolutionWright engagement looks like at week four — first measurable change, six receipts in motion, falsifier status updated, and the client running the ledger themselves.

A concrete checklist of the four artifacts a SolutionWright client has in hand by the end of week one — scope memo, evidence baseline, falsifier list, and exit-plan draft.

The closing artifacts of a SolutionWright engagement — handover ledger, exit-ready system, six published receipts, and falsifiers either survived or recorded as failed with reasons.

Three failure patterns we see in AI engagements — silent model swap, scope creep, and refusal-rate drift — and how a receipts standard surfaces them on day one instead of day ninety (Class C, E).

SolutionWright tags some claims as U for unverified rather than dropping them quietly — and that disclosure is what makes the rest of the ledger worth trusting (Class C, E).

A plain-language walkthrough of the six tags we stamp on every claim we publish, with one sentence shown classed three different ways (Class E, Class C).