Co-create the QA platform. Make every auto-decision readable and overridable in one place, not just configurable.

It means you own the parts of the platform whose value compounds (the scenarios, the overrides, the result history) and you lease the parts that change quickly and benefit from a vendor's investment (the runtime, the model integration, the browser automation). The litmus test is portability: if the vendor disappears, can you keep the work? Co-creating means yes. Pure buy means no. Pure build means you own everything including the parts that you should not be writing yourself.

Self-heal becomes a leak when it patches a real regression and reports green. Imagine the checkout button was renamed from 'Checkout' to 'Buy now'. A self-heal can flexibly find the new button and click it, the test passes, the deploy lands. Now imagine the checkout button was removed because of a bug in a feature flag and the only visible button is 'Save for later'. The self-heal still finds 'something close enough' and clicks it. The test passes. The deploy lands. The user-facing checkout flow is broken. The leak is the green check that did not need to be green.

No. Configurable means there is a setting you can tweak before the run. Reviewable means there is a record after the run that names every decision the platform made and lets you accept or reject each one. Most platforms offer the first; almost none offer the second. Configurable is necessary, not sufficient. The decision needs to be readable in retrospect by a human who is not the person who set the config.

A JSON record with the scenario name, the step number, the intent, the previous value, the new value, the reason the platform made the change, and a path to override it. Specifically not 'AI healed your test', specifically not a green check with no detail. The point of the record is that anyone on the team can read it next morning and say 'that was a real regression' or 'that was a UI rename, codify it'.

It changes the adoption story. Instead of 'install and your tests heal themselves', you get 'install and your tests heal themselves, with a queue of decisions to review at the cadence of your team'. Most teams find that pace easier to adopt than fully automatic, because it preserves the trust contract: green means green. Pending means the platform did something, here is what, please confirm.

Scenarios live in your repo as Markdown. The agent (an LLM-driven loop with 18 tools, declared in agent.ts lines 16 to 196) executes them against a real Playwright browser. Every retry, every selector swap, every fuzzy match, and every timeout extension is recorded with the step number and the reason. The override file lives next to the scenario in the repo, and the assrt review CLI walks through pending decisions for batch acceptance or rejection. The default model is claude-haiku-4-5-20251001, named on line 9 of agent.ts, and you bring your own API key so the cost lands on your Anthropic invoice rather than a per-seat SaaS line.

In the same directory as the scenario file, committed to git, reviewed in pull requests like any other source. .assrt/overrides/checkout.json or checkout/.overrides.json depending on layout taste. The point is that overrides are part of the codebase, not part of the vendor's database. They survive a vendor migration. They survive a tool change. They survive an LLM upgrade.

There are three reasonable choices. Strict: pending heals fail the build, force daily review. Lenient: pending heals show as yellow on the dashboard, allow merge but block release until reviewed. Batched: pending heals accumulate over a window (a day, a sprint), get reviewed together, are then enforced strictly. Most teams pick lenient for early adoption and migrate to strict once the heal queue is small. The wrong choice is treating pending heals as green, which silently erodes the meaning of a passing test.

Traditional self-heal patches the test file. The selector changes from #checkout-btn to #buy-now-btn and the next run uses the new value. There is rarely a record, almost never a review queue, and usually no override path. The trust model is 'we know better than you'. Co-create platforms invert this: 'we noticed something, we made a tentative call, you decide if it sticks'. The cost is one human moment per heal. The benefit is that green stays meaningful.

Build still wins for teams with extreme platform surface area or extreme privacy constraints; you maintain the runtime because the alternatives do not exist for your workload. Buy still wins for teams with no QA engineering capacity at all and a willingness to trust the vendor's defaults; the platform does what it does, you accept the trade. Co-create wins everywhere in between, which is most teams. The question is not whether to co-create but on which axes to draw the line. Scenarios, overrides, and results stay yours. Runtime, model integration, and tooling stay vendor.

That is a strong signal that you cannot co-create with them, because you cannot reason about what the platform will do tomorrow. A model swap on the vendor side, a new tool added to the agent, a prompt change to the system prompt, all of these change the behavior of every test you run, and you have no audit trail. Pick a vendor whose source you can read or whose disclosures you can pin to specific lines.

Three numbers. First, the heal queue depth: how many pending decisions are waiting for review. Should be small and stable, not growing. Second, the override-to-scenario edit ratio: how often does a rejected heal trigger a scenario update vs a code fix. Tells you whether the platform is catching real regressions. Third, the time from heal to decision: a few hours is healthy, weeks means the queue is being ignored and green is silently degrading.