Version Control

Traditional version control processes manage change by saving a new copy of a document, making edits to that copy, and then sharing the updated file. This works to satisfy an audit, but it creates disconnected snapshots with no clear record of how those procedures interact nor what changed between them, and significant overhead to ensure that only the latest version is accessible to an operator.

Threaded uses a different model. Instead of separate files, you have a single instruction set mapped as a process, with a complete history of every change ever made to it. Each improvement builds on the last, creating a linear record of how your process has developed over time. This enables tighter iterative development, ensures only the published version of the process is accessible to operators, and automatically establishes the required audit trail as the process is improved.

#The Core Concept: One Process, Two States

At any given moment, a manufacturing process in Threaded exists in one of two states:

• Production: The approved, active version currently published for operation.
• Development: An environment with a working draft where changes are being developed, reviewed, or tested before they go live.

These states exist for the full Process rather than individual files. That is, Threaded versions the entire instruction set as a system — similar to how software teams version a codebase rather than individual files. Your instructions are organized as a system or value stream, and work together to define not just individual procedures but the order and flow from one procedure to the next. A change to one part of that system is released as a new version of the whole, ensuring a connected record and that Production always runs on a consistent, approved set of instructions.

Additionally, these two states are always connected. The Development environment is not a separate document, it’s the next version of the same set of instructions in progress. Once approved and released, it becomes the new Production version, and the previous version is preserved in the instruction’s history.

This is the key difference from traditional version control. Instead of “save as” for a new document, you’re always working forward from where you left off in the same process.

#The Workflow: Develop → Review → Publish

#1. Update the Draft in Development

When you’re ready to improve an instruction, you work in the development environment. Your changes — updated steps, new images, revised cycle times, tool updates — are made here without affecting the published version. Operators continue to see and follow the current instruction while you work.

You can also collaborate in Development. Multiple contributors can work in the same space, suggest edits, and refine changes before anything is published.

#2. Create a Change Request to Review the Changes

When a change is ready, it gets submitted for review by opening a Change Request. A Change Request is just that: a request to implement changes into Production. Reviewers see a visual diff of only the modified parts of the instruction set, and can comment directly on specific components to request changes or clarity before approving.

Threaded also runs automated Process CI checks at this stage to surface quality and completeness issues with suggested fixes before anything reaches the floor.

#3. Publish

Once approved through the CR, the draft can be published and becomes the new active version in Production. Version names are defined by the user. Semantic versioning (“major.minor.patch”, 1.4.2) is a common convention, but any naming syntax works. Regardless of the name, every previous version is retained in the instruction’s history, and each published version is timestamped and attributed to whoever created and approved the release.

Over time, this creates a complete, linear record of how the instruction has evolved: what changed, who changed it, when, and why. This allows you to leverage the history of your system, and the knowledge captured within it, for continuous improvement.

#Reading the Version History

Every instruction in Threaded has a version history accessible from the Version Control page to clearly see what changed and when and for audit compliance. Each entry shows:

• The version name or number
• A summary of what changed and why
• The conversation that led to approval and release
• Who approved and released it
• The date it was published

You can open any previous version to review it, compare it against the current published version or any other point in the history, and if necessary restore the draft environment to this former point in time.

#Why This Matters

The traditional “save as” model creates a collection of snapshots with no connection between them. Finding out what changed between v3_FINAL.pdf and v4_revised_JT.pdf means opening both and manually comparing them, assuming you can find the right files and when they were effective.

Threaded’s version control keeps your process connected. Every improvement is traceable. Every change is reviewable before it goes live. And if something introduced on the floor isn’t working, operators can submit feedback directly in context, and you can see exactly what changed in the last release and act on it quickly.

The goal isn’t just documentation for compliance — though the audit trail is there when you need it. It’s giving your team a reliable, low-friction way to collaborate and keep improving without losing track of where you’ve been.