Operators

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

The pitch , for scheme owners, certification bodies, and operations teams

The world today. Certification is episodic: an application, an audit event, a report, a framed certificate , then silence until the next cycle. Between audits you are blind. The certificate claims something about the past, and everyone in the chain , scheme owner, body, lab, customer , re-enters the same data into their own systems, with transcription errors as the only thing truly integrated.

What changes. The scheme itself becomes a model, and certification becomes a runtime. The monitor probes the governed aspects on a schedule; the verdict engine re-judges as evidence arrives; every judgment lands in an append-only evidence stream. Continuous compliance replaces point-in-time compliance , and the certificate stops being a photograph: it is a living CNML document whose every claim names its evidence, signed over a threshold-cryptography PKI (Confium) that no single party can forge or lose.

What it looks like in practice. The OIML Certification System is modelled end to end on B 18:2025 , applications, test dispatch, laboratory work, type evaluation, issuance , on top of the ISO/IEC 17000-series chain it normatively references. One verdict engine serves the portal, the lab workbench, the issuing authority, and the twin monitor; evidence is captured once, at the moment of work, and flows everywhere it is needed.

The proof. The platform’s integration gate proves twelve contracts live, including certificate issuance and CNML verification against the real PKI. The twin-cert demo issues a certificate for a simulated instrument you can interrogate yourself.

Your next step. Read the platform volume for the runtime, or the OIML-CS scheme volume for a certification system already modelled this way.

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.