Every control in view. Every control yours to set.
As deep as you need
Every control in view.Every control yours to set.
Iron Octopus runs delivery the way great engineering teams do: plans, risk levels, runbooks and release gates. They come set up with proven defaults, and you can read, tune and audit every one, for one project or your whole workspace.
1 · Planning
Approve the plan.
Done is defined before anything is built. Iron Octopus drafts the acceptance criteria and breaks the feature into work items. A person approves the plan, and nothing starts until the features it depends on are released.
| In the plan | What it gives you |
|---|---|
| Acceptance criteria | A checkable definition of done, agreed up front. |
| Work items | Small pieces, each built and reviewed on its own. |
| Dependencies | Features build in order, on released code. |
| Architecture | Every feature is planned against the project's published, versioned blueprint. |
2 · Review
Define the risk levels.
Every change is classified by what it touches and reviewed before it's done. Iron Octopus approves a change on its own only when it's confident enough for the risk. Otherwise, a person decides.
Set the highest risk Iron Octopus may approve, and the confidence each level needs. Thresholds can't decrease as risk increases.
| Risk level | Approved by Iron Octopus at | Rework rounds |
|---|---|---|
| Low | 95% confidence or more | 2, then a person |
| Standard | 97% confidence or more | 3, then a person |
| High | 99% confidence or more | 4, then a person |
| Critical | Always a person | 4, then a person |
Defaults. Admins can tighten or loosen each one.
3 · Process
Control the runbooks.
A runbook is the whole process a feature or work item follows. Admins change runbooks for one project or the whole workspace, and can make workspace runbooks mandatory. Every change needs a reason and is published as a new version.
| Setting | Default |
|---|---|
| Code review | Every change reviewed by an AI worker |
| Unverifiable or blocked criterion | Goes to a person |
| Acceptance assurance | Static review, with gaps disclosed |
| Dependencies must be | Released |
| Your own assessments | Optional checks against your standards |
| Applies to | All features, or Build, Maintenance or Bug fix only |
4 · Release
Set the release gates.
Gates are where a feature pauses until conditions are met. Each one completes automatically or waits for a person, and you choose which. Before release, every acceptance criterion gets a verdict with its evidence, and anything Iron Octopus can't verify goes to a person.
| Gate | Default requirements | Completes |
|---|---|---|
| Planning → Building | Criteria and work items exist. Every dependency is released. | A person decides |
| Building → Acceptance | All work items done. No open defects from assessments. | Automatically |
| Acceptance → Released | Every required criterion met. Inputs revalidated, then merged into main. | A person decides |
Across the whole process
On the record, and on your terms.
A record of every decision
Every plan, approval, review, release and rule change is recorded with who made it and when. History that's ready to use as evidence for a SOC 2 audit.
Roles for every person
Guest, Member, Admin and Owner. Each action checks the role, so the right people approve, release and change runbooks.
Your code and your AI
Each feature is built on its own branch and merged into main only on release. Export to your own GitHub at any time. Leading AI models are included, or connect your own.
Go as deep as you need.
Every runbook, gate and default is documented. Or keep it simple and start with an idea.