Coroid models a full software lifecycle, not just the build step. Most of it runs automatically; one part is an optional checkpoint you switch on when work is consequential enough to warrant it.
The optional SDLC workflow
On the New Work form, under advanced settings, is a checkbox:
Use the SDLC workflow (optional) — review an intent and specification before planning. Leave this off to start a plan directly from your brief.
It is off by default. Left off, planning starts from your brief once it passes Qualification. Turned on, two artifacts are produced and approved first:
- Intent — what the work is actually for, with the decisions and assumptions behind it recorded.
- Specification — scope, exclusions and acceptance criteria.
Only once those are approved does planning begin.
When to turn it on
Turn it on when the cost of building the wrong thing is high, when the request came from someone who is not going to review the plan themselves, or when the brief contains an assumption you would rather see written down and agreed.
Leave it off when the brief is already unambiguous. An extra approval gate on routine work is friction without benefit — and the plan approval step still applies either way.
The five stations
The full lifecycle runs in five stages, each producing evidence the next one uses.
| Station | What happens | Status |
|---|---|---|
| Define | An ambiguous request becomes approved intent, decisions, assumptions and success measures | Beta |
| Visualize | Optional UI concepts, refined and approved as design guidance | Beta |
| Deliver | The plan is decomposed and agents execute it | Available |
| Prove | Requirements map to tasks, checks, review findings and pull-request changes | Available |
| Improve | Monitors, remediation and evaluations turn regressions into the next cycle's work | Available |
- DefineApproved intent, decisions, assumptions and success measuresBeta
- VisualizeOptional UI concepts, approved as design guidanceBeta
- DeliverThe plan is decomposed and agents execute itAvailable
- ProveRequirements map to tasks, checks, findings and changesAvailable
- ImproveRegressions become the next cycle's workAvailable
OptionalTurn on the SDLC workflow to approve the intent and specification before planning begins.
Improve feeds the next cycle: monitors, remediation and evaluations turn regressions into new work.
Define and Visualize are the two under active development. Deliver, Prove and Improve are what runs on every task today, whether or not you switch the checkpoint on.
Why the artifacts are versioned
Approvals bind to an exact version of an artifact. Editing an approved artifact creates a new draft rather than silently changing what was agreed.
This is what makes an approval mean something. An approval that floats — attached to "the specification" rather than to a specific version of it — approves whatever the document happens to say later, which is not an approval at all.
Approval roles
Product, design, technical, security and release responsibilities can be assigned independently, so the person approving the security implications is not necessarily the person approving the scope.
Evidence lineage
The point of producing evidence at each station is that a finished pull request can be traced backwards: this change implements this task, which came from this requirement, which came from this approved intent.
That chain is what makes autonomous delivery auditable. Without it you have working code and no account of why it is the code you asked for.
From reviewed code to a release
The pull request is the output of the work cycle. After your repository rules allow a merge, a Release pins a full commit SHA and records which changes that commit contains. Its readiness gate evaluates that exact commit for a chosen environment. Approvals bind to the gate snapshot; editing the candidate or policy makes earlier decisions stale.
Requesting deployment starts an attempt in your connected pipeline. A provider callback or a manual attestation records what reached an environment, and a post-deploy canary records health separately. The task, pull request, and Release therefore keep distinct meanings: completed work is not evidence that code reached production.
How this relates to plans
The SDLC workflow and plans are different checkpoints:
- The SDLC workflow approves what should be built, before an approach exists.
- The plan approves how it will be built, before code exists.
You can use either, both, or neither. Both are cheaper than reviewing a finished pull request you disagree with.