Auditors

CORRESPONDING PILLAR Auditors drive the Audit pillar. They verify conformance by navigating the standard like readers, correlating through .prm mappings to find implementation elements, and viewing .pws/ evidence like operators.

The pitch , for auditors, regulators, and authorities

The world today. An audit is a site visit, a sample, and a spreadsheet. You reconstruct what an organization actually does from interviews and hope the sample was representative. Multi-standard audits request the same evidence three times in three costumes. And when the audit ends, your finding begins aging , nothing tells you whether it is still true.

What changes. You view reality through the standard. The auditor’s lens is a projection: the implementation model, mapped onto the reference standard you are auditing against , one standard or an approved set. The evidence is already accrued, timestamped, and non-rewritable. An audit becomes: open the projection, follow the .prm mapping from clause to implementation element, query the evidence stream. Silence never reads as compliance , what cannot be proven shows as indeterminate, and stale served values degrade on a declared freshness window, never fail silently and never pass silently.

What it looks like in practice. An integrated management system modelled once is viewed through ISO 9001 as a QMS, through ISO 27001 as an ISMS , shared processes assessed once, evidence reused with provenance intact. A regulator watching a certified instrument fleet reads the same verdict chain the certification body produced, with the cryptographic provenance to trust it without phoning anyone.

The proof. The discipline is architectural, not promised: silence is not evidence and evidence accrues, never rewrites are two of the platform’s six published invariants, enforced by the verdict engine every judgment runs through.

Your next step. Read the Audit pillar, then the compliance and measurement example.

Who they are

Auditors are the people who verify conformance against a reference model by following the structural chain from requirement to evidence. Common auditor types:

• External auditors , certification-body auditors (BSI auditors for ISO certification, OIML-appointed assessors, etc.).
• Internal auditors , org staff performing first-party audits ahead of external ones.
• Regulators , market-surveillance or sector regulators checking that certified organisations remain compliant.
• Customer auditors , procurement teams auditing suppliers against standards their supply chain requires.
• Second-party assessors , industry bodies or large buyers performing assessments on member organisations.

What they’re trying to accomplish

For each requirement in the reference model, an auditor follows three steps:

1. Navigate the standard , using reader-style spec-browser capability, find the requirement being audited.
2. Correlate through the mapping , the auditor’s distinct skill: follow the .prm from the reference element to its mapped implementation element(s).
3. View the evidence , using operator-style workspace-browser capability, look at the .pws/ records the implementation produces, and evaluate validate_provision / validate_measurement against them.

The output is a compliance verdict , per requirement, passing or failing , with a traceable evidence path from standard clause to workspace record.

The auditor inherits from readers and operators

This is the structural insight. Auditors do not have a wholly new capability set; they combine two existing capability sets and add one distinct skill:

Tools built for Readers and Operators can be reused by Auditors without modification. The Auditor-specific tool is the mapping navigator , a tool that, given a reference element, finds the implementation element(s) it maps to and the workspace records those elements produce.

Artifacts they consume / produce

Tools they use

• Spec browsers , borrowed from Readers; navigate the reference model.
• Workspace browsers , borrowed from Operators; navigate the .pws/ directory, follow record references.
• Mapping navigators , auditor-specific; given a reference element, walk the .prm to find implementation element(s) and their evidence.
• Provision evaluators , run validate_provision and validate_measurement expressions against workspace records to produce pass/fail verdicts.
• Audit report generators , produce the compliance verdict document with traceable evidence paths.

A worked example

An auditor verifying Acme against the OCS standard would:

1. Open the OCS reference model in a spec browser. Navigate to clause 4.2 (Bean sourcing). Find OCS#Provision4-2-1 (“The organization shall source beans only from approved suppliers”).
2. Open Acme’s acme-to-ocs.prm in a mapping navigator. See that OCS#Provision4-2-1 is mapped to Acme’s SourceBeans process (via the validate_provision binding in the implementation .prl).
3. Open Acme’s sample-workspace.pws/ workspace. See that SupplierRegistry/sup-001.yaml shows Highland Beans Co. was approved on 2026-01-05 by operations.manager@acme.example. See that BeanLotRegistry/lot-2026-001.yaml references that supplier.
4. Verdict: the requirement is satisfied , beans were sourced from an approved supplier.

Each step uses a different capability. Step 1 uses reader-style navigation. Step 3 uses operator-style evidence viewing. Step 2 , the auditor’s distinct skill , correlates via the .prm.

See also

• Primmel Studio , the review surfaces: the model-diff view with facet-level before/after, the C23 conflict marker (asserted vs computed coverage), comment threads, and the save preview that makes every change reviewed before it is written.
• Audit pillar , the architectural activity this audience drives.
• Readers , whose capability set Auditors inherit (standard navigation).
• Operators , whose capability set Auditors inherit (evidence viewing).
• Implementers , who built the implementation and mapping Auditors verify.