> ## Documentation Index > Fetch the complete documentation index at: https://docs.ironoctopus.ai/llms.txt > Use this file to discover all available pages before exploring further. # Built-in rules > Every rule Iron Octopus follows by default, what each one does, and which ones you can change. Iron Octopus follows a set of rules from the moment you sign up. They're the practices good software teams rely on: agree the plan before work starts, define done before building, review every change with more care the riskier it is, check the result against what was agreed, and keep a record of every decision. You don't set anything up. An admin can change any rule for one project or the whole workspace. See [change a rule](https://docs.ironoctopus.ai/rules/change-a-rule.md). Rules are grouped into **runbooks**. A runbook is the whole process for one kind of thing. A **gate** is a point where the process pauses until conditions are met. A **policy** is what a runbook applies at a gate. | Runbook | Governs | Where admins change it | | - | - | - | | Feature runbook | How a feature moves from Planning to Released. | Workspace settings › **Runbooks** › **Feature runbooks** | | Work-item runbook | What happens when a work item's implementation finishes: review, rework and approval. | Workspace settings › **Runbooks** › **Work-item runbooks** | ## Feature rules ### Gates | Gate | Default requirements | Completes | | - | - | - | | Planning → Building | The feature has acceptance criteria and work items, and every feature it depends on is released. | When you click **Start building**. | | Building → Acceptance | 100% of the work items that aren't cancelled are done, and no defect found by an assessment is still open. | Automatically. | | Acceptance → Released | Every required acceptance criterion is met. | When you click **Release feature**. | A gate either completes **automatically** as soon as its requirements pass, or waits for a **human decision**, where a person sees the evaluated requirements and decides. ### Other feature rules | Rule | Default | What it means | | - | - | - | | Dependencies must be | Released | A feature can't start building until the features it depends on are released. The other option is **Acceptance cleared**: the prerequisite reached Acceptance and its required criteria pass. Neither option alone means the prerequisite's code is merged. | | Acceptance assurance | Static review | Criteria are checked by reviewing code and what the work produced. Tests and running-app checks are disclosed as gaps, not passed. See [requirements](https://docs.ironoctopus.ai/building-blocks/requirements.md#limits-of-default-verification). | | Merge on release | On | **Release feature** merges the feature's branch into the project's main branch, and the feature stays in Acceptance until the merge succeeds. | | Open assessment defects block Acceptance | On | A defect found by a configured assessment must be resolved before the feature moves to Acceptance. | | Assessment repair rounds | 3 | If configured assessments keep finding defects, automatic repair pauses after 3 rounds for an admin to decide. | | Audited waivers | Off | When on, Owners and Admins can waive an assessment requirement or defect, with a recorded reason. | | Feature types | All | A runbook can apply to all features, or only to **Build**, **Maintenance** or **Bug fix** features. | ## Work-item rules | Rule | Default | What it means | | - | - | - | | Code review | Autonomous AI Worker review | Every work item's change is reviewed before it's done. The alternative, **No code review**, lets committed work go straight to Done. | | Applies to | All work-item types | A policy can apply to Coding, Bug-fix, DevOps or Planning items only. | | Highest risk Iron Octopus may approve on its own | High | Critical changes always go to a person. | | Minimum confidence to approve | Low 95% · Standard 97% · High 99% | Below this, a person decides. Thresholds can't decrease as risk increases. | | Rework rounds before a person decides | Low 2 · Standard 3 · High 4 · Critical 4 | Stops work looping in review. | | Required criterion is unverifiable | Require human review | A person decides, rather than review approving. | | Required verification is blocked | Require human review | As above. | | Required criterion is not applicable | Require human review | A criterion can't be quietly dropped. | | A required criterion fails | Always rework | This can't be changed. A confirmed failure always sends work back. | How risk levels are classified is set out in [review and rework](https://docs.ironoctopus.ai/build/review-and-rework.md#risk-levels). ## Rules that always apply These aren't configurable: * **Automatic retries.** A work item that stops before it finishes is retried automatically up to 2 times, then comes to you. * **Risk classification.** Every change is classified by the same rules, and an override needs a recorded reason. * **Revalidation before release.** Iron Octopus checks that the feature, its inputs and the rules in force haven't changed since you approved, before it merges. * **A record of every decision.** Every gate decision, approval and rule change is recorded with who made it and why. * **Released means final.** A released feature never changes. Fixes are new work. ## What you can change on your plan On Pioneer, admins can change rules for the workspace and for individual projects, and make workspace rules mandatory for every project. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.