Eleven products, one production system, and the order we read evidence in

A studio this size cannot carry eleven products by doing eleven launches. It carries them because the parts of a launch that are identical every time — store assets, release checklists, subscription plumbing, screen captures, privacy documents, the publishing pipeline itself — are done once, in one system, instead of once per product by hand.

That much is the obvious half, and it is not the interesting half. Sharing infrastructure is a well-understood trade. The part that keeps going wrong is knowing what is true about a product you shipped three weeks ago.

Two rules that make automation restartable

Work in the system is identified by a deterministic hash of its own inputs. A duplicate trigger, a retry, or a crash and restart all resolve to the same identity, so the system cannot double-render or double-post. That one property is what makes retrying safe, and retrying safely is the difference between automation you can leave running and automation somebody has to watch.

The second rule is that publishing sits behind a person. Not because the automation is unfinished — because the cost of a wrong publish is asymmetric, and a gate that is never used is cheap while a gate that is missing once is not. Nothing has gone out of this studio without somebody saying so.

The failure that is not a bug

On 30 September two products went live on the App Store. This site said one of them was in beta and not publicly listed on either store. Nothing in this repository was wrong, and no review could have caught it, because a launch is an event that happens outside the repository: no file changes, so there is no diff to read and no test that can fail.

That is the whole argument for a pre-deployment gate rather than a habit. A script asks Apple for every bundle identifier, lists every app on the developer account, and requests each package page from Google Play. It runs before a deploy, not when something looks wrong — because by the time something looks wrong, it has looked fine for three days.

Which document to believe

The same mistake has now been made seven times in this studio, and only one of them was careless. The other six were all the same shape: a claim taken from a project’s narrative document while machine-readable evidence sat in the same folder, newer, saying something else.

Veyra is the worked example. Its page on this site said generation had never run and no model weights had ever been loaded. That came from a status document and a readme, both dated 11 September, and it was repeated here for two weeks. Meanwhile, in the same repository, there was a file pulled off a physical phone recording two real generation runs — four candidates each, every image a different size, tagged with the real model, with timings read out of the device’s own database. The page understated its own product for a fortnight, which is a kinder failure than overstating one and is still a false page.

So the order is written down, and a lower rank never overrides a higher one however recently it was written and however confidently it is phrased:

• Authenticated provider state — what the store itself says, read while signed in.
• Shipped artefacts and machine-readable evidence — a release build’s own metadata, a database pulled off a device, a captured response, a tag.
• Current source and config — the files the build actually loads.
• Dated acceptance documents — prose, but written against a run that happened.
• Status and handoff narrative — a readme, a status file, a handoff.
• Planning documents and briefs — including the brief that introduced a product to this site.

The ranking is not a statement about who writes carefully. It is a statement about what decays. A store listing changes when the product changes; a readme changes when somebody remembers.

What a shared system is actually for

Every rule above started as a specific thing going wrong on one product, and every one of them now lives in the shared system rather than in that product’s copy of it. That is the real compounding: not that the fifth launch is cheaper than the first, though it is, but that the fifth launch cannot repeat the first four’s mistakes, because the mistake is a failing test somewhere neither product owns.