> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # Quality documents > Controlled SOPs and work instructions, versioned so a new revision supersedes the old one without deleting it. A **quality document** is a controlled SOP or work instruction. It contains rich-text content and an ordered list of **steps**, including tasks, measurements, checkboxes, and sign-offs. A defined lifecycle controls when the document becomes authoritative. Published procedures are never overwritten. Publishing a revision creates a **new version** and archives the version it replaces, preserving the audit history. ## The lifecycle A quality document has exactly three states, and only one version of a given document is ever **Active** at a time.
**Draft** The starting state. You edit the name, the work-instruction body, and the steps freely. Only a Draft can be changed. Not yet authoritative.
**Active** The published, in-force revision. Publishing it archives any other Active version with the same name automatically.
**Archived** A retired revision. Superseded by a newer Active version, or manually pulled. Still readable; can be reactivated.
You publish from the document header. The button reads **"Publish"** for a Draft, **"Reactivate"** for an Archived version, and **"Submit for approval"** when an [approval rule](/docs/reference/approvals.md) covers quality documents (more on that below). All three drive the status toward **Active**. NOTE Going Active is exclusive by name. Alforse archives every *other* Active document that shares this one's name in the same company in the same transaction that publishes this one, so "the current procedure" is always a single row. You never end up with two live copies. Archiving (from Active or Draft) and reverting an Active or Archived version to Draft are available too, but reverting a version that has a pending approval request is restricted: only the person who requested it or a designated approver can pull it back to Draft. ## Versioning Versions are the heart of the "controlled" part. A document is identified by its **name**, and each revision is a separate row stamped with a **version** number (starting at 0). The name is unique per version, so `"Incoming Inspection Procedure"` can exist at V0, V1, and V2 side by side. To revise a published document, open the **Versions** menu in the header and choose **New Version**. Alforse copies the current document's body, steps, and tags into a fresh Draft at the next version number. Nothing about the old version changes. When you publish the new one, the previous Active version is archived. The prior revision is never deleted, so the version history stays intact for audit. TIP Editing an already-Active document in place is the wrong move for a controlled record. Cut a **New Version** instead. That is what keeps the paper trail honest: an auditor can see exactly what V1 said and when V2 took over. The header's Versions dropdown lists every revision of the document with its version badge and status, so you can jump between them and read a retired revision without reactivating it. ## Approval Whether publishing needs a sign-off depends on your company's [approval rules](/docs/reference/approvals.md). Quality documents are one of the document types the shared approval engine covers. * **No approval rule** — the **Publish** button flips the document straight to **Active**. * **An approval rule applies** — the button reads **Submit for approval** and creating an approval request instead of going Active. A qualified approver then sees **Approve** / **Reject** in the header. On **Approve**, the document transitions to **Active** in one transaction; the approvers are notified when the request is raised. Only one pending approval request exists per document at a time, and submitting an Archived version for approval moves it back to Draft while the request is open. ## Steps Each document holds an ordered set of **steps**, the same step model Alforse uses for a procedure on a job. A step has a name, an optional description, a **sort order**, and a **type** that decides what gets recorded when someone runs the document: FieldType
**Task** A do-this instruction with no data captured beyond done/not-done.
**Value** A free-form recorded value.
**Measurement** A numeric reading against a **unit of measure** (required for this type), with optional min and max bounds.
**Checkbox** A yes/no confirmation.
**Timestamp** A recorded time.
**Person** A recorded person.
**List** A pick from a fixed set of options you define.
**File** A file upload, optionally constrained to given file types.
**Inspection** An inspection step.
A **Measurement** step must name a unit of measure and can set a min/max range (the maximum cannot be below the minimum); other step types cannot carry a unit. A **List** step must supply its options. These constraints are enforced when you save the step. ## What a quality document is not Quality documents are standalone controlled records. They are **not** attached to a specific process, item, or inspection through a link on the document itself, and they are distinct from two neighbors people often conflate: * A procedure is the versioned work instruction that gets copied onto a job's operation to give it steps and run parameters. It shares the step model with a quality document but lives in the production method, not the quality library. * An [inspection document](/docs/reference/inspections.md) is a ballooned drawing used for first-article and in-process dimensional inspection. That is a separate feature with its own tables. For the wider quality module (issues, dispositions, inbound inspection), see [Quality](/docs/reference/quality.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.