Implementation
Each Interface, System, or Verb runs managed, custom, or external, and the Customer's contract stays the same whichever kind runs it.
An Implementation is how an Interface, System, or Verb of a Product runs: managed, custom, or external. The kind can change at any time, and the Customer's contract never changes with it.
Three kinds
| Kind | What runs | Who maintains it |
|---|---|---|
| Managed | Code SoftwareBuilder compiles from the definition | The platform |
| Custom | The Startup's own code, running on the platform | The Startup |
| External | A server elsewhere, with api.sb routing each call to it | The Startup or a Source |
Managed is the default. Every inherited create, get, list, update, and delete, every declared rule, and every generated Interface runs managed until the Startup says otherwise.
Mixed per Verb
One Product mixes kinds freely. episodely.fm sells podcast production to independent shows, and its Product runs managed. Its Episode.transcribe Verb runs custom code tuned for crosstalk, and Episode.syndicate runs external, on a feed server the Startup keeps elsewhere.
A System can run external too. The Startup keeps the System's Nouns and Verbs and routes them through an Integration. It still owns the records, and the outside product is a Source.
The Function behind the Verb
A Function carries each Verb's execution: code, a generative model, an Agent, or a Human. The caller never sees which. Every call returns the same Action, with the same statuses and the same Events.
That makes a swap free. episodely.fm's show notes start with a human editor; an Agent then runs the same Verb in shadow, its output graded and never shipped. When an Evaluator agrees with the Agent on 95% of a sample, the Agent takes the Verb, and no caller changes a line.
What stays fixed
The Product's identity never moves with its code. Its Domains, Brand, Customers, Tenants, Entitlements, billing, and history stay in place whichever kind runs. Every call still becomes an Action on api.sb.
Moving a Product to external is ejecting, and it changes no address. An ejected Startup keeps its Customers, its revenue, and its books.
Changes, Versions, and deploys
Some edits are data: copy, an Offer, a price, a Dataset fact. Others are behavior: a new Verb or new custom code. Both arrive as a Change, previewed on its own branch, checked, and merged as one unit.
Each merge produces a new Version, an immutable build at a fingerprint. Deploy points the Startup's live address at that Version, and every Interface serves it at once. Revert undoes a merged Change with a new one.
A Change to a Live Startup's Nouns or Verbs also faces the compatibility gate. A restyle or a copy edit never does.
Deploy and publish
A deploy serves code; publish makes an Offer available to accept. A Product is available only when both hold: its Version is live, and an Offer for it is published.
Publishing carries what the Customer relies on, not only code. A Dataset publishes its coverage and terms, and Software publishes its Verbs and how Tenants stay apart. An Agent Product publishes the task types it accepts and its eval results.
Next
Compatibility covers how a Live Startup changes its API without breaking its Customers.