Operators

CORRESPONDING PILLAR Operators drive the Operate pillar. They run the implementation in production and produce the .pws/ evidence that auditors will later follow.

Who they are

Operators are the people who run the implementation day-to-day and record what happens. Common operator types:

Operations staff — people performing the processes the implementation describes (roasters, QA testers, line workers, supervisors).
Production teams — teams running the actual workflow, whose activities produce registry records.
Record-keepers — staff responsible for the integrity, retention, and retrievability of workspace evidence.
System integrators — engineers binding the implementation to real production systems: data registries, process engines, compliance trackers that emit records on the org’s behalf.

What they’re trying to accomplish

Use — run the implementation’s processes as the org’s actual operations unfold. Each process execution corresponds to a real-world activity.
Store evidence as required — produce .pws/ workspace records that conform to the data class shapes the implementation declares. Every record is one YAML file in a registry subdirectory.
Maintain a complete evidentiary trail — ensure that for every provision-bound process, the records needed to demonstrate compliance actually exist in the workspace.

Artifacts they consume / produce

Artifact	Role
Implementation `.prl`	Consumed — the digital twin that defines what records to keep
`.pws/` workspace directory	Produced — the actual records, one YAML file per record
`manifest.yaml`	Produced — workspace identity and registry list
Registry record YAML files	Produced — one per record per registry

Tools they use

Production systems — ERPs, MES, QMS, custom operational tools that perform the actual work.
Workspace collectors — integrations that take outputs from production systems and write them as YAML record files in the correct registry subdirectory.
Workspace validators — tools that check every produced record against its declared data class shape.
Workspace browsers — readers for navigating the directory tree, filtering records, following references between them.

A worked example

The implementation package includes a populated sample-workspace.pws/ directory showing what this audience produces:

sample-workspace.pws/
├── manifest.yaml          ← workspace identity + registry list
├── BeanLotRegistry/
│   ├── lot-2026-001.yaml  ← one record per YAML file
│   └── lot-2026-002.yaml
├── RoastBatchRegistry/
│   ├── b-2026-001.yaml
│   └── b-2026-002.yaml
└── SupplierRegistry/
    └── sup-001.yaml

Each YAML file holds one record whose attributes conform to the data class the implementation declares. References between records (lot: lot-2026-001 in a roast batch, pointing at a bean lot) match the reference(BeanLot#data) type declared on the RoastBatch#data class. This is the evidence trail that Auditors will later follow.