Your seed-bank inventory stubs live in a vendor's hosted mock account — how do you keep them reviewable?

## The thing that moved is custody, not hosting A hosted mock service is a stub server somebody else runs. Your suite points at an address the vendor controls, and the rules that decide what comes back — which request shape earns which canned reply — sit in an account on their side rather than in a directory in your checkout. The remoteness is the boring part: a stub server in another team's cluster is remote too. What is different here is **custody of the definitions**. They are no longer an artefact your tooling can read, diff, review, tag, branch or revert. They are the state of an account, and account state has none of those affordances. Nearly every difficulty that follows is a restatement of that fact. ## Who may edit, and how you find out In a repository, the people who can change a stub are the people who can merge, and every change arrives with an author, a message and a reviewer. In a vendor account it is whoever holds a login, and that set drifts wider than the suite's owners: a developer debugging an integration by hand, a support engineer reproducing a customer report, a contractor added during a crunch and never removed. What that costs, concretely: - **A change has no diff.** You can read the current state; you usually cannot read what it replaced. - **A change has no reviewer.** Nothing forces another pair of eyes before the mapping backing your seed-bank inventory suite starts answering differently. - **A change has no message.** The reason lives in somebody's memory, in a chat thread, or nowhere at all. - **A change is not scoped to a branch.** Feature work and the release branch share the same stub, so an edit made for the former silently reaches the latter. - **Attribution is the vendor's, not yours.** Where the account does record edits, the record is in their format, on their retention policy, and it stops being available when the subscription does. The earliest engineering move is therefore bookkeeping rather than taste: get the definitions out. If the account's contents can be exported, export them on a schedule, commit the export, and let the diff be the alarm. A change nobody can explain then appears as a change nobody can explain, in a place the team already reads every day. ## Review and rollback when there is no revert Rollback is where teams are surprised. In a repository, undoing a bad stub is a revert and a deploy: mechanical, fast, available to anyone on the team. In a vendor account it is a person signing in and re-applying a known-good state — which means a known-good state has to exist somewhere other than the account. If your only copy of it *is* the account, you cannot roll back; you can only reconstruct from memory what the replies used to say. So the exported copy is not documentation. It is the restore path, and it deserves the treatment a database backup gets: - written automatically, rather than when somebody remembers; - re-imported on purpose from time to time, so you know the restore actually works; - owned by a named role, rather than by whoever happens to be awake. ## The outage you cannot fix A suite pointing at a hosted mock depends on the network, on the vendor's availability, and on the account being in good standing. None of those are yours. When the service is unreachable or slow, the build goes red for a reason unrelated to the change under test, and the remedy is a support ticket rather than a commit. The subtler cost is what that does to the meaning of red. A team that learns red is sometimes weather starts re-running instead of reading, and the habit does not switch itself off when the next red is a genuine defect. That is why the routing decision matters: - calls in the inner loop, made by every fast test, should stand in locally, where you own both the definitions and the failure modes; - calls that exercise an integration you genuinely cannot reproduce may point at the hosted service, in a small, clearly labelled suite that is allowed to fail differently; - calls that gate a release should lean on as few externally owned moving parts as the risk appetite allows. ## What an exit costs The question to ask before adopting is how you leave. The definitions are expressed in the vendor's model; the addresses the tests hold are theirs; the access rules and the conventions that grew around the account are theirs. Exit cost is roughly proportional to how many suites hardcode that address and how much behaviour was configured by clicking rather than by committing. An exportable, committed copy kept from the start is the cheapest insurance available, because it turns leaving from an archaeology project into a re-import. ## The honest summary Hosted mock services buy real convenience: no process to run, no image to maintain, an address that answers from anywhere. They pay for it in custody. Review, rollback, attribution, availability and exit all move into a system you do not operate. That can be a good trade. It is only a good trade when the team has already decided who may edit, where the reviewable copy lives, and what happens on the morning the address stops answering.