Launch with proof: each launch claim tied to the change that shipped it
How the Launch with proof workflow checks the docs against a release, puts the announcement in front of a person, and records each claim so anyone can check it later.
Launch with proof is a workflow for founders and launch teams shipping a release that AI agents helped build. It checks the docs against the release, traces what shipped, puts the announcement in front of a person before it goes out, and files each claim in a public record. ContextFile, RepoOps, PromptCompute and AI Source of Truth each do one part, and the post itself lives on your blog.
Three of its five parts are merged. This guide names those three and says what the other two will do.
The problem
A launch post says what shipped. Usually nobody has checked that the docs match the release, and a month later nobody can check the claims at all. The post says a feature exists, and the reader has to take the company’s word for it.
That gets harder when agents wrote much of the code. The person writing the announcement may not know which changes made it into the tag, or whether the docs page they link to still describes last month’s behavior. Launch claims also travel. Buyers, press and investors repeat them, and a wrong one is expensive to chase down once it has been quoted.
How the workflow solves it
The workflow starts from the release itself. ContextFile checks the docs before anyone drafts a word. RepoOps will trace the merged changes and the agent sessions behind them. PromptReports will draft the announcement one claim per sentence, so each sentence can point at the change that backs it.
A person will approve the text in PromptCompute before it publishes. Then AI Source of Truth records each claim with its source change, and the post carries a badge that links to the record. A claim with no source change will not slip through. The step will mark it missing, and the approval card will list it before the person decides.
Step by step
Once the workflow runner ships, a run will take these steps. A step written in the present tense works in its product today. A step written with “will” is still to build.
A run will start from a release tag in GitHub, or when a person or an agent starts it.
- ContextFile checks the docs. It checks each docs page against the release’s context version and cites the launch docs and specs by digest, so the record names the exact version it checked.
- RepoOps will trace what shipped. The release trace will list the merged changes, the agent session behind each one, and the outcomes measured since.
- PromptReports will draft the announcement, one claim per sentence, each claim tied to a change from the trace.
- A person will approve it in PromptCompute. The card will show the verified docs and the release trace next to the draft. The run will wait until the person decides. If they edit the text, the edited text is what will publish, never the first draft.
- AI Source of Truth records each claim with its evidence, and serves a badge for it.
- The post shows the badge. Posts on this blog already carry one that links to their record.
Publishing is the step that touches the world, so it is the step that waits for a person. The plan also puts the social post and the record publish behind an approval policy you set.
What the workflow will report
Each run will report three numbers:
- The share of launch claims with a public record. The plan sets the target at 100%.
- The docs pages that were out of date on launch day. The target is 0.
- The hours from the release tag to the approved announcement.
Each run will also record its outcome as met, not met or not measured. A number the run could not measure will read not measured, never a quiet pass.
Why it matters to a founder
A launch is the day the most people read what you claim. When a buyer asks on a sales call whether a feature really shipped, you can send the record instead of an assurance. If a claim later turns out wrong, AI Source of Truth adds a correction beside the original record. It never edits or deletes a record, so the history stays visible.
It also makes the launch quicker to sign off. The person approving will read every claim with its evidence on one card, instead of asking engineering to confirm each line in a chat thread.
How to set it up
Outside the family you connect GitHub, your blog or CMS, and a social account if you want the workflow to post there.
When the runner and the signed-in app ship, setup will take six steps:
- Sign in with PromptReports ID and pick your org.
- Connect ContextFile, RepoOps, PromptCompute and AI Source of Truth. Link GitHub and your blog through the product that uses each.
- Register the agent that will run the workflow, with a version manifest.
- Set the approval policy for publishing the post, the social post and the record. Start every one at Require approval.
- Choose the trigger, such as each release tag, and start a dry run. A dry run will show which steps would record missing evidence.
- Start the run, and approve the announcement when it reaches you.
An agent will start and follow a run through the PromptReports MCP server or API. The proposed tools are start_run and get_run. The names may change before they ship.
Every plan includes every workflow, so Launch with proof is not an add-on. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. One run is one request, and the steps inside it do not count separately.
Today you can call the merged parts yourself. ContextFile serves its docs check on its MCP server, and AI Source of Truth records claims and serves badges. You call each product in turn with its own key, and nothing ties the calls together as one run.
What is built today and what is planned
The workflows page lists Launch with proof as partly built: three of five parts merged, with the RepoOps release trace and the PromptCompute approval to go.
Built:
- ContextFile cites the launch docs and specs by digest (ContextFile #153).
- AI Source of Truth records each launch claim with its evidence and serves the badge (aisourceoftruth #240).
- Blog posts on this site carry the record badge (PromptReports #19).
Planned:
- The release trace in RepoOps.
- The announcement approval in PromptCompute, with the verified docs and the release trace on the card.
- The workflow runner itself. No runner exists today. The plan is a durable runner service in the PromptCompute stack. It will give each run one run id that every product carries, treat each approval as a step in the run, and meter each run as one workflow request.
Until the runner ships, this workflow does not run end to end, and nothing counts a workflow request.
Read more
This post has no record on AI Source of Truth yet. Once it does, its verdict badge shows here and links to the record.