> ## Documentation Index > Fetch the complete documentation index at: https://docs.firstresonance.io/llms.txt > Use this file to discover all available pages before exploring further. # Overview > How ION models a procedure: its steps, step types, fields, standard steps, part links, and review lifecycle. A procedure is a versioned sequence of steps used to build, test, or inspect a part. You author and revise it in the procedure editor, release it through a controlled review, then create [runs](/build-hardware/runs-and-execution/overview) against it on the floor. A run is a copy of the procedure at the moment it starts. Later procedure revisions do not flow into runs already in progress, so each run stays an accurate record of what was done. Steps hold the work instructions and capture operator input inline through structured fields. You reuse shared work through [standard steps](/build-hardware/procedures/standard-steps), link a procedure to the [parts](/build-hardware/parts/overview) it produces or inspects, and constrain execution order through [step dependencies](/build-hardware/procedures/procedure-dependency-manager). ## Steps A step is the unit of work in a procedure. Each step is one of two types, chosen when you create it: * **Content**: written instructions in a rich-text box, with attachments and inline fields. * **Datagrid**: a table of typed cells an operator fills in when the procedure runs. Steps nest up to five levels deep to group related actions, such as inspecting each part of an assembly under one parent. ION numbers steps automatically from 0 by order, with dot notation for children (the first child of step 1 is 1.0, then 1.1). You can tag each step with a [location](/build-hardware/locations-and-work-centers) to show where the work is done. To add, copy, reorder, and nest steps, see [Manage procedure steps](/build-hardware/procedures/steps). ## Fields Both step types collect operator input through data-collection fields. A field defined on a procedure step becomes an input the operator fills in during the run. | Field type | Notes | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Datetime** | A date and time for an event, such as when a part entered a thermal oven. | | **Boolean** | A checkbox for a true/false or pass/fail response. | | **String** | Free text. No length limit, all UTF-8 characters. | | **Number** | Enforces a numeric value. Supports validations. | | **Select** | One option from a list. | | **Multiselect** | One or more options from a list. | | **Signoff** | A role-gated digital signature. Enforced by role during the run. Can be set peer-review-only. | | **File attachment** | A required file, such as a machine CSV export. Maximum 5 GB. | | **Tool** | Links use of a [tool](/build-hardware/tools) to the step for traceability. Can be limited by part number, type, and calibration status. | | **ION: User** | Links an ION user to the step. | | **ION: Part** | Links an ION part to the step. | Fields are optional by default. A **Required** field blocks step completion until filled, and a required field can also allow a **Not Applicable** entry for positive confirmation. **Number** fields support validations that check a reading against limits during the run and can trigger issue creation. For the full reference, see [Step field types](/build-hardware/procedures/steps/fields). ## Custom attributes Beyond the built-in fields, your org can add [custom attributes](/administration/custom-attributes) to procedures and steps for data the built-ins don't cover. * **Procedure attributes** appear in the **Configuration** section of the procedure's **Overview** tab and stay editable at any time. When a run is created, a run attribute of the same name inherits the procedure attribute's value. * **Step attributes** appear inline in the step editor while the procedure is a draft. Their values copy to run steps, where you can edit them through a [redline](/build-hardware/runs-and-execution/redlines-and-deviations). ## Standard steps A standard step is a step whose work instructions are shared across procedures and revisioned independently. When you release a new version, every procedure and not-yet-started run that references it picks up the latest released version automatically, so shared work such as a torque sequence or ESD check stays in sync without redlining each procedure. A standard step disconnects from its source once its run status advances (in progress, redline, canceled, failed, or completed), freezing the run's record at the version in use. Standard steps can be nested inside other steps and standard steps but cannot themselves take a standard step as a child. For creation, reuse, and run behavior, see [Manage standard steps](/build-hardware/procedures/standard-steps). For nesting patterns, see [Nested steps and standard steps](/build-hardware/procedures/nested-steps-and-nested-standard-steps). ## Part links A procedure links to one or more parts to declare which work instructions produce or inspect a given part. This is not a parts list of the assembly. With the **Require part-procedure relationship** org setting enabled, ION blocks run creation unless the selected part is linked to the selected procedure. For inspection-type procedures, each part link is **Required** or **Optional**, which controls whether receiving a part auto-creates an inspection run. To set up links, see [Link a part to a procedure](/build-hardware/procedures/part-procedure-relationship). ## Dependencies Step dependencies define the execution order between steps at the same depth in a procedure. You draw the dependency graph in the procedure's **Dependencies** tab, and ION enforces it during the run so operators know which step is available, blocked, or being redlined. See [Manage step dependencies](/build-hardware/procedures/procedure-dependency-manager). ## Installation requirements Build-type procedures can carry installation requirements on their steps, tying [mBOM](/build-hardware/bills-of-materials/manufacturing-bom) items to the steps that install them. A run step cannot close until its required installs are satisfied, which keeps the [aBOM](/build-hardware/bills-of-materials/made-on-assembly) an accurate digital record of the physical build. This feature is in beta. See [Assign installation requirements](/build-hardware/procedures/installation-requirements-beta). ## Review and lifecycle A procedure moves through a controlled change process: you author it as a draft, move it **In Review**, and it reaches **Released** once reviewers sign off. Standard steps use the same review flow and can be revisioned on their own. You configure which reviewer roles are required per org. See [Configure standard step reviewer roles](/administration/production-settings/configure-standard-step-reviewer-roles). Because a run copies the procedure at start, released changes reach only runs that have not started. To hold work until instructions are final, place the run or step on hold. For patterns that combine nesting, standard steps, and holds, see [Procedure best practices](/build-hardware/procedures/procedure-best-practices).