Implementers

CORRESPONDING PILLAR Implementers drive the Implement pillar. They maintain the organisation’s digital twin, adopt references, customize to satisfy them, and declare the mappings that close a Statement of Applicability.

The pitch , for manufacturers and product owners

The world today. You read a 200-page standard, distill it into a compliance spreadsheet, and hope. Your product’s conformity lives in tribal knowledge and a folder of PDFs. Every audit re-derives it from scratch; every new market asks the same questions in a different costume; every certificate is a photograph of how things looked on one day last year.

What changes. You describe your product in the same language the standard is written in , its identity, its holdings, its behavior , and map your model’s nodes directly onto the reference model’s nodes. The mapping is explicit, checkable, versioned data: your Statement of Applicability stops being a document and becomes a computation. And you can go further: ship a SMART twin of your product , a model-native Digital Product Passport that serves the aspects the standard governs, live, to anyone authorized to ask.

What it looks like in practice. A load-cell manufacturer publishes a reference model whose every node maps onto OIML R 60’s requirements. A customer imports that model as an abstract promise , or plugs the instrument’s live twin straight into their own implementation model, where the compliance engine watches it continuously. Reference and implementation compose in any number of layers; one implementation model can satisfy several reference standards at once, with shared processes counted exactly once.

The proof. The ACME LC-500 pilot walks the whole chain , manufacturer reference model, customer import, live twin, certified fidelity , and the twin-certification program exists precisely to certify that a served twin stays faithful to the physical device.

Your next step. Work through the implementation package, then model your own product.

Who they are

Implementers are the people who build and maintain the organisation’s implementation model, take up reference models, and wire the two together with mappings. Common implementer types:

Implementation authors , consultants or internal teams who build the initial digital twin of the org’s operations.
Engineering teams , staff who refine the implementation over time as the org’s actual processes change.
Compliance teams , staff who decide which standards to adopt and shepherd the mapping process per standard.
Quality teams , staff who ensure the implementation continues to satisfy the mapped-to references between audits.
Consultants , external specialists who help an org adopt a specific standard end-to-end.

What they’re trying to accomplish

Maintain , keep the implementation .prl synchronised with how the org actually operates. The model is a standing artifact, not a one-off project.
Adopt / import / customize , when the org decides to take up a reference, import the reference’s elements (via Namespace#ID aliasing), customize the implementation as needed (add processes, change data fields, refine approvals), and bind the org’s processes to the reference’s provisions via validate_provision.
Map , declare mappings from implementation elements to reference elements, in .prm files and/or map_profile blocks.
Close , iterate until the mapping satisfies the Statement of Applicability: every reference element → ≥1 implementation element.

Artifacts they consume / produce

Artifact	Role
Published reference `.prl`	Consumed , the standard being adopted
Optional `.prd` extract	Consumed , for cross-checking provisions against source clauses
Implementation `.prl`	Produced and maintained , the org’s digital twin
`.prm` JSON mapping	Produced per adoption , the alignment between impl and reference
`map_profile` block (inside `.prl`)	Produced , in-model form of the mapping

Tools they use

Primmel editors , authoring tools for the implementation .prl and map_profile blocks.
Mapping editors , tools that help build .prm files side-by-side with the reference and implementation models, with description/justification fields per pair.
Coverage checkers , tooling that reports on Statement of Applicability progress: which reference elements are mapped, which are not, which are excluded with justification.
Diff tools , compare implementation revisions; compare mappings across reference-model version upgrades.

A worked example

The implementation package shows this audience end-to-end. Acme’s implementers:

Maintain acme-coffee-programme.prl , the digital twin of Acme’s coffee operations.
Decide to adopt the fictional Office Coffee Standard (OCS).
Import OCS elements via OCS# aliases (e.g. process OCS#SourceBeans, provision OCS#Provision4-2-1).
Bind Acme processes to OCS provisions via validate_provision.
Declare the mapping in acme-to-ocs.prm with description and justification per pair.
Iterate until the mapping closes , every OCS requirement has at least one Acme process implementing it.