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.

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.