sample Every name, number and id on this page is invented. Nothing here is a real request, person or deploy.
One sample story, deal ACME-0042
The same story runs through each product's site: a deal waits on a promise, the promise waits on a pull request, the pull request causes an incident, a person approves the rollback, the service recovers, and the lesson reaches the next forecast. PromptCompute's step is the approved rollback.
- Forecast (Sales as Code)Deal ACME-0042 is forecast to close this quarter, on one condition: single sign-on by 30 November.
- Promise (CommitOps)The account team promised single sign-on by 30 November. The promise waits on pull request #431 in acme-checkout.
- Pull request (RepoOps)#431 adds the SAML callback. Session s-9c1 wrote it, and it shipped in deploy dpl-4490.
- Incident (RepoOps)Sign-in errors rose 40 minutes after dpl-4490. RepoOps traced them to #431 and to session s-9c1.
- Approved rollback (PromptCompute) you are hereRepoOps asks PromptCompute before it rolls back dpl-4490. The request carries the change risk and the task id. A named person approves it, the rollback runs with the approved arguments only, the decision is signed into the ledger, and the outcome goes back to RepoOps. Through PromptCompute once that link is switched on.
- Recovery (RepoOps)Sign-in errors fell back under the success criterion on the task. The fix shipped again behind a flag in dpl-4497.
- Lesson (RepoOps)A person reviewed the lesson: a sign-in change ships behind a flag. The next forecast for ACME-0042 reads it once Sales as Code has its RepoOps key.
- Context version (ContextFile)The reviewed lesson becomes context version cv-118 in ContextFile, and the next agent that changes sign-in reads it before it starts. Once that link is switched on.
- On the record (AI Source of Truth)The incident, the approved rollback and the lesson are registered on AI Source of Truth, so a later correction reaches every product that used them.
The approved rollback in PromptCompute
What the approver saw and what the ledger kept. sample
| Action | deploy.rollback high risk |
|---|---|
| Asked by | RepoOps, for the acme-checkout repo |
| Arguments | roll back deploy dpl-4490 to dpl-4483 |
| Change risk | Pull request #431, written in session s-9c1. Sign-in errors rose 40 minutes after the deploy. |
| What broke before | A sign-in change rolled back twice in the last 90 days. |
| Rule | deploy.rollback in production needs one approver from on-call |
| Task | T-01JC4S1GN0ACME000000000042 the RepoOps task id, carried on every signed family statement about the request |
History
14:02Created by RepoOps, high risk, routed to on-call14:05Approved by Dana R. (on-call) with no edits14:05Grant issued for the approved arguments, signed into the ledger14:09RepoOps reported the rollback ran; the outcome went back to RepoOps
RepoOps routing this approval to PromptCompute is built and waits on a setting in RepoOps. Until it is switched on, RepoOps asks for the approval itself.
The step before: the incident in RepoOps. The step after: the recovery in RepoOps.