EXECUTABLE RELEASES FOR API PROVIDERS

A breaking change ships twice: once in your release, then again in every repo that calls you.

Ship executable releases, not changelogs.

Stitch compiles your release into a signed change contract. Your customers' own agents execute it inside their private repos — scan, patch, test, approve — and a signed result comes back: unaffected, migrated, rejected, or unknown. Their code never leaves home.

Start with one release See how it runs

RELEASE 2.0.0 · CONSUMER RETURNS DEMONSTRATION

ONE SIGNED RESULT PER CONSUMER REPOSITORY

payments-serviceSCANNED · PATCHED · CI GREEN · APPROVED MIGRATED

ml-batch-jobsSCANNED · NO CALL SITES FOUND UNAFFECTED

legacy-gatewayPATCH FAILED ACCEPTANCE · EVIDENCE ATTACHED REJECTED

vendored-sdk-forkSCAN COULD NOT REACH EVERY PATH UNKNOWN

unknown is an answer. A scan that cannot finish is never reported as unaffected.

EACH RETURN IS SIGNED AND BOUND TO THE RELEASE, THE INPUT COMMIT, AND ITS EVIDENCE DIGESTS. THE PROVIDER SEES TYPED STATUS AND EVIDENCE — NEVER SOURCE. FORMAT PROVISIONAL: THESE RETURNS ARE A DEMONSTRATION, NOT A LIVE RUN.

You shipped v2 a year ago. You still operate v1.

Until the last consumer migrates, the old version is yours to run, patch, and answer for. The tail is exactly as long as the slowest repo you cannot see into.

Every consumer still on an old version is a version you still operate.FIG. 01

WHAT STITCH DOES

Three moves.

Compiles the release

Your API diff, migration guide, and acceptance checks become one signed change contract a repository can execute.

Runs it where the code lives

Each consumer's own agent executes the contract inside their private repo, against their own CI. Source never crosses the boundary.

Returns proof, not promises

Every repo answers with a signed, typed result — unaffected, migrated, rejected, or unknown — bound to the exact release it answers.

One line in the notes. A sprint in every repo that reads it.

A real removal, read from both sides: what the release note can say, and what a repository must do about it. Today the whole right column is every consumer's job, by hand.

The release note — Kubernetes 1.25

PodDisruptionBudget: policy/v1beta1 removed
migrate manifests and clients to policy/v1
policy/v1 available since v1.21
PodSecurityPolicy: removed, no replacement
and that is all a note can do

The same release, executable

detect: every manifest, chart, and call site
rewrite: v1beta1 to v1, in the consumer's branch
verify: their CI plus the contract's checks
approve: a maintainer, before any merge
return: a signed, typed answer per repo

The left column is the Kubernetes v1.25 deprecation guide, verbatim in substance. The right column is the contract format, which is provisional.FIG. 02

TODAY

Today the migration reruns in every repo. By hand.

Read Someone finds the release note and works out whether it applies to this repo at all.

IN EVERY CONSUMER REPO

Search grep for call sites, and hope the ones that matter are the greppable ones.

IN EVERY CONSUMER REPO

Patch Rewrite the usage without the context you had when you made the change.

IN EVERY CONSUMER REPO

Test Convince their CI that nothing else moved, on a deadline you set.

IN EVERY CONSUMER REPO

Or give up File the support ticket, pin the old version, and join your deprecation tail.

One consumer's chain, per breaking release you ship. Nobody on your side sees any of it run — or stall.

Today this sequence is your customers' problem, and its failures come back as yours.

THE LOOP

Publish it. They run it. Proof comes back.

Demonstration — the states below advance on a fixed sequence, not against live checks.

Publish it Your diff, migration guide, and acceptance checks compile into one signed change contract. not started

Scan it The consumer's agent maps every call site in their private repo. A scan that cannot finish says so. not started

Patch it Their agent writes the migration in their own branch, in their own conventions. not started

Prove it Their CI runs, the contract's acceptance checks run, and a maintainer approves the merge. not started

Return it A signed, typed result comes back, bound to the release and its evidence — never to their source. not started

Every breaking release runs the loop again — and the tail stops growing.

CYCLE 01

Coding agents write the changes. They never write the evidence that their own next step is safe.

Every claim in the loop is checked outside the agent that made it.

The signature binds to this exact release.

The CI run is real, and green.

The human approval landed.

The source never left its repo.

A repo answers unaffected, migrated, rejected, or unknown. Unknown is never reported as safe.

HOW IT RUNS

Their repo, their agent, their CI. Your contract.

Provisional — the command names are not final. The shape is: the provider compiles and publishes; each consumer runs.

$stitch compile --release v2.0.0

$stitch publish --to subscribers --sign

$# then, inside each consumer's own CI

$stitch run --contract sha256:9f2c…

Nothing of theirs to leak

The contract executes inside the consumer's trust domain. What leaves is a typed status, signatures, and evidence digests. Source stays home, and no provider ever holds an agent token for a consumer repo.

One neutral runner, any agent

Consumers install one least-privilege runtime — not a privileged agent from every provider — and keep their own coding agent, CI, and merge policy. The contract defines what done means.

The orchestration is provable

No unapproved merge, no undisclosed source, no unearned success claim. These are machine-checked properties of the protocol — not hopes about generated code. Envelopes are DSSE over in-toto, not an invented format.

It already runs, end to end

One signed release ran against three consumer repos on synthetic fixtures: a real commit and pull-request draft in the affected repo, a verified unaffected, and an honest unknown. All three signed results verify, a forged one is rejected, and the provider saw digests, typed counts, and test outcomes — never source. The consumer processes shared one machine: this proves the protocol boundary, not a production sandbox.

The current protocol kernel rejects a merge that skips human approval, and a plan that could sign a result before it earns a status-specific outcome — each caught by an exhaustive model check and a Lean proof. Ask us for the run report.

THE PILOT

One real breaking change. That is the pilot.

Bring the next breaking release on your roadmap. Stitch compiles the contract, runs it across consenting consumer repositories, and measures what happened: call sites found, patches accepted, correction time, time to green, and the support load that never arrived. Consumer code never reaches us — or you.

STITCH IS PRE-LAUNCH. THE PILOT RUNS ONE RELEASE ACROSS CONSENTING CONSUMER REPOSITORIES. CONSUMER CODE NEVER LEAVES ITS OWN TRUST DOMAIN, AND UNKNOWN IS NEVER REPORTED AS SAFE.

WHO

Two engineers. Managed cloud, and flight software.

Veer Singh

Cloud engineer, Google Kubernetes Engine.

Will Zhang

Flight software, Amazon Leo satellites.