registration is not deployment

Bringing a new business onto the platform looks like one operation and is really two. There is the record of the business: its identity, its routing key, its configuration, and a starter menu attributed to it. And there is the deployment of the business: the running surface that answers on its name. Conflating them is how an operator console ends up able to reach production by typing.

The seed work drew the line explicitly. One plane supplies the business data, another provisions the deployment half, and the coordination document states which is which, in what order, with verification and rollback for each. The data half was replayed against an empty database: rows fully attributed, a second run producing no duplicates, rollback clean, and a later structural change leaving the new rows untouched.

It was not applied live, and that was the correct end state of the change. The follow-up verification then said something more useful than a pass: the surface still served the generic shell, and a census of the seeded rows still read empty. Deployment-pending, not a data defect.

That distinction is the whole value of the split. A registered business and a served business are different states read from different places, so "registered" cannot be mistaken for "live" by anyone looking at either.

Cost: two systems to reconcile, and a window in which a business exists and nothing answers for it — which is exactly what it looks like.

What it proves: the team separates the act of recording an intention from the act of making it true.