Engineering playbook
How the Engineering Team turns definitions into running Interfaces, ships by traffic share, restores service first, and keeps one record of code.
The Engineering Team turns definitions into running Interfaces and keeps them up. Its week is a stream of small Changes, each shipped by traffic share and reverted on any guardrail breach.
From definition to Version
The Engineering Lead receives one Issue a day from Daily ship and implements it as one Change. A Change is a proposed set of writes, previewed on its own branch against test records. Nothing it does in preview touches a live Customer or moves real money.
Change verdict runs every check on the preview and records the verdict. A pass starts Release a change, which merges the Change into a new Version. A fail returns the Change to its author with the failing run attached.
Every Verb ships on the API, CLI, MCP and SDK at once, because all four generate from one definition. A Verb missing from one Interface is a defect, not a backlog item. Agents and Humans reach the same Verbs under the same names.
Ship by traffic share
Each Version deploys to 1% of traffic, then 10%, 50% and all. At each step the deploy watches its guardrail Metrics: error rate, p95 latency and the one Metric that matters now. A breach at any step reverts the deploy without waiting for anyone.
Take a Headless SaaS that sends appointment reminders for clinics. A Change batches sends to cut cost per message. At 1% of traffic the error rate climbs from 0.2% to 3%, and the deploy reverts before the 10% step.
The cause turns out to be one carrier rejecting batches over 50 messages. The fix caps batch size, passes its verdict, and reaches all traffic by noon.
One record for code
Code and definitions live in Repositories, in db.sb: branches, Changes, checks and Versions in the same database as every other record. Builds and generated code run in isolated Sandboxes, leased per job.
A repository is db-first or git-first. In a db-first repository, GitHub holds a regenerable copy; in a git-first one, edits are authored in GitHub and imported into db.sb as Changes. Either way db.sb is the record, and every Change passes the same verdict.
Incidents
An Incident is a failure Customers feel in production. When one opens, Resolve an incident posts it to the status page within 5 minutes. The Reliability Engineer restores service first, reverting the last Change when it is the cause.
The cause gets fixed second, in a new Change. The postmortem links the Change that prevents a repeat, and the Incident closes with the status page updated.
Take an Agent as a Service that drafts lease summaries for property managers. After a Version deploys, latency on its MCP server triples. The Incident is public in 4 minutes, the revert lands in 9, and the fix ships the next morning.
Wiring and access
Each new Startup starts Connect providers. The Integration Engineer lists the Capabilities the Startup’s Products use and wires the default upstream for each. It runs one test call per Integration and records a fallback.
Every night the Access review compares each Role’s Permissions with the Verbs it called in the last 30 days. The Security Engineer removes unused Permissions and rotates secrets older than 90 days. It refuses any widening that carries no Decision.
Handoffs
| From | To | What passes |
|---|---|---|
| Product Lead | Engineering Lead | The day’s top Issue |
| Engineering Lead | Tester | Each Change, for its verdict |
| Engineering Lead | Reliability Engineer | Each Version as it ships |
| Reliability Engineer | Operations Lead | Customer impact during an Incident |
| Security Engineer | Compliance Officer | Access Evidence, every month |
Next
- Engineering Team: Roles, Processes and Metrics.
- Quality playbook: how a Change earns its verdict.
- Rhythm: every Workflow by when it runs.