What an SOP is and how to access one

Status: Draft

Purpose

This lesson gives a user-level overview of standard operating procedures (SOPs) in SOPs.io. It explains what an SOP is, what it can be used for, and the main ways a user can reach published SOP content.

Learning objectives

After reading this lesson, you should be able to:

Describe an SOP in SOPs.io.
Describe common uses for SOPs.
Identify the main ways a user can access a published SOP.
Distinguish access permission from acknowledgement.

Prerequisites

You do not need prior SOPs.io knowledge. You do not need access to a running SOPs.io system for this lesson.

Key terms

SOP: A governed operating procedure with a stable identity, access policy, and versioned content.
Draft: Editable SOP content that is not the published procedure shown to ordinary viewers.
Published version: An immutable version of SOP content made available through the governed publication process.
Access policy: The rules that determine whether a user may open an SOP and how the SOP must be reached.
Acknowledgement: Evidence that a user has confirmed reading a specific published SOP version. Acknowledgement is separate from permission to view the SOP.

Concept explanation

What is an SOP?

An SOP describes how to perform repeatable work. It can contain instructions, important controls, warnings, reference information, and supporting media.

In SOPs.io, the SOP has a stable identity and policy. Its content is stored in versions. Authors edit a draft. Publishing creates an immutable published version and leaves a separate draft available for later changes. A viewer sees published content rather than the author's current draft. [SRC-DOC-OPERATIONS#Versioned Content]

The current content model uses ordered blocks. A block can contain rich text or media. This gives the published SOP a stable, linear reading and execution view. [SRC-DOC-OPERATIONS#Content Payload]

What can an SOP be used for?

An SOP can be used to:

give workers a consistent procedure for routine work
provide warnings and controls before or during a task
provide guidance for a type of machine or a specific machine
make controlled reference information available to public, authenticated, or assigned users
record that a user acknowledged a particular published version when the acknowledgement policy requires it
provide governed content for learning or operational support

SOPs.io keeps SOP content, access policy, machine applicability, and user entitlements as separate concerns. This allows the same published procedure to be governed without treating a machine identifier or acknowledgement as access permission. [SRC-DOC-OPERATIONS#Access And Entitlement Structure] [SRC-DOC-ACCESS#Core Principles]

Published content and versions

A published version is a fixed record of the procedure content available at the time of publication. Later editing does not change that published version. Publishing a later revision creates another published version. This preserves the content that users previously viewed or acknowledged. [SRC-DOC-OPERATIONS#Versioned Content]

When acknowledgement is required, the record points to the exact published version. An acknowledgement of an older version does not automatically satisfy the requirement for a newly published version. [SRC-DOC-VERIFICATION#Authoring Configuration]

Ways to find or access an SOP

The available access route depends on how the SOP is configured.

SOP list, search, or direct link

A generic SOP can be opened through the SOP list or a direct link when its access policy permits this. SOPs can also be discovered through title and goal search, tags, authoring-organisation filters, and linked knowledge resources. [SRC-DOC-OPERATIONS#Discovery And Semantic Structure]

Some SOPs are public. Other SOPs require the user to sign in. Private SOPs may also require a direct user grant, an organisation grant, or another declared audience relationship. [SRC-DOC-ACCESS#Visibility is the outer gate] [SRC-DOC-ACCESS#Audience is separate from subject grants]

QR code

A QR code can identify a SOP, a knowledge resource, or a machine. Resolving the code sends the user to the relevant SOPs.io page. The QR code is an identifier, not proof that the user is allowed to view restricted content. SOPs.io still applies its normal access rules. [SRC-DOC-OPERATIONS#Machine And QR Structure] [SRC-DOC-MACHINE#QR Security]

Machine or serial-number route

A serial number can resolve to a machine. The user can then reach SOPs associated with that machine through its machine portal. A machine-bound SOP must be reached through resolved machine context rather than through a direct SOP link. [SRC-DOC-OPERATIONS#Machine And QR Structure] [SRC-DOC-ACCESS#Binding is separate from machine applicability]

Machine applicability answers which machines an SOP is for. It does not, by itself, give the user permission to view the SOP. A protected SOP may also require a verified relationship to the resolved machine. [SRC-DOC-ACCESS#Machine applicability is separate from audience] [SRC-DOC-ACCESS#Registration requirement is separate from applicability]

Link from another work application

A work application may direct a user to a relevant published SOP for a task or machine. SOPs.io remains responsible for the SOP's publication state, access decision, and acknowledgement record. The work application remains responsible for its own task and operational decisions. [SRC-DOC-VERIFICATION#Integration Responsibilities]

Access and acknowledgement are different

Access determines whether a user may open an SOP. Acknowledgement records that the user confirmed reading a specific published version. A user may be allowed to view an SOP even when acknowledgement is still required. Completing an acknowledgement does not grant access that the user did not already have. [SRC-DOC-ACCESS#Acknowledgement is separate from access]

An SOP may require no acknowledgement, a checkbox confirmation, or a PIN/password-verified confirmation. The configured policy determines which method applies. [SRC-DOC-VERIFICATION#Implemented Scope]

Worked example or demonstration

Consider a machine with a SOPs.io QR code:

A user scans the code.
SOPs.io resolves the code to the machine or linked resource.
If sign-in is required, the user signs in and returns to the resource.
SOPs.io checks the user's relationship to the machine and the SOP's access policy.
The user sees the latest permitted published SOP version.
If that version requires acknowledgement, the user completes the configured acknowledgement after reading it.

The QR code starts the route to the resource. It does not replace sign-in, machine registration, entitlement, or other server-side access checks. [SRC-DOC-MACHINE#QR Scan Flow] [SRC-DOC-ACCESS#Recommended Decision Workflow]

Guided practice

This descriptive lesson has no guided practice.

Independent practice

This descriptive lesson has no independent practice.

Checks for understanding

This descriptive lesson has no knowledge check.

Assessment and evidence

This descriptive lesson has no assessment or evidence requirement.

Troubleshooting guidance

If you cannot find an SOP:

search by its title or goal
check relevant tags or the authoring organisation
use the machine portal when the SOP is machine-bound
ask the SOP owner whether a published version exists

If access is denied:

confirm that you are signed in when login is required
confirm that you have the required user or organisation access
confirm any required machine registration
open a machine-bound SOP through its machine or QR route

If a QR code resolves but the SOP remains restricted, do not treat this as a QR failure. The code identified the resource, but the access policy did not permit the current user to view it. [SRC-DOC-OPERATIONS#Machine And QR Structure]

Summary

An SOP in SOPs.io is governed, versioned operational content. Users normally see an immutable published version, while authors work on a separate draft. SOPs can support routine work, machine guidance, controlled reference content, learning, and acknowledgement requirements.

Users may reach SOPs through lists, search, direct links, QR codes, machine or serial-number portals, or links from work applications. Reaching a resource does not bypass access controls. Access permission, machine applicability, and acknowledgement remain separate decisions.

Source references

[SRC-DOC-OPERATIONS#Operating Procedures Overview]
[SRC-DOC-ACCESS#SOP Access Principles and Policy Matrix]
[SRC-DOC-VERIFICATION#SOP User Verification Specification]
[SRC-DOC-MACHINE#QR-Based Resource Access and Entitlement Control]