3 min read

Compliance

Compliance in Primmel is built on provisions — statements of requirement using the RFC 2119 modality vocabulary — bound to data and traceable to source standard clauses via references.

Primitives

reference — cite a source clause

reference BFS-4-2 {
  document "Bean Freshness Standard (fictional)"
  clause "4.2"
  title "Moisture content"
}

A pointer to a clause in an external document (typically a .prd extract of a source standard). Provisions cite references to justify their existence.

provision — a requirement

provision MoistureRecorded {
  condition "Every roast batch shall have its moisture content recorded"
  modality SHALL
  reference {
    BFS-4-2
  }
}

A provision has:

  • A condition — the human-readable requirement.
  • A modalitySHALL, SHOULD, MAY, CAN, or MUST (RFC 2119 vocabulary).
  • A reference { ... } block — the clauses this provision derives from.

subject#N — data-aware provisions

provision StandardMeetFreshness {
  subject#1 RoastBatchRegistry
  condition "{ Roast batches (Data) } selected meet the freshness requirements"
  modality SHALL
  reference {
    BFS-4-2
  }
}

The subject#1 RoastBatchRegistry line binds this provision’s evaluation to records in RoastBatchRegistry. The { ... (Data) } placeholder in the condition is replaced by the bound registry’s records at evaluation time.

A provision can have multiple subject bindings (subject#1, subject#2, …), each bound to a different registry.

note — an annotation

note MoistureNote {
  type NOTE
  message "The moisture tolerance reflects typical commercial storage conditions."
  reference {
    BFS-4-2-note
  }
}

type is typically NOTE or EXAMPLE, mirroring the annotation vocabulary of formal standards documents. Notes are attached to processes via note { ... }.

table — a lookup table

table FreshnessGradeTable {
  title "Freshness grade lookup"
  columns "3"
  display "[grade]: [threshold_pct]"
  domain { }
  data {
    "grade" "threshold_pct" "description"
    "A" "10" "Premium freshness"
    "B" "11" "Standard freshness"
    "C" "12" "Acceptable freshness"
  }
}

A lookup table. The first row of data is the header; remaining rows are values. Referenced by TABLE_REFERENCE measurements to look up specific cells.

RFC 2119 modality

Modality Meaning
SHALL / SHALL NOT Absolute requirement.
SHOULD / SHOULD NOT Strong recommendation; deviations need justification.
MAY / MAY NOT Optional behaviour.
CAN / CANNOT Statements of possibility or capability.
MUST / MUST NOT Absolute requirement (synonymous with SHALL).

Modality appears in two places: on a provision (the weight of the requirement) and on a process (whether the step itself is mandatory, recommended, or optional).

Binding compliance to processes

process TestMoisture {
  name "Test moisture content of a roast batch"
  actor QA
  modality SHALL
  validate_provision {
    MoistureRecorded
    MoistureWithinRange
    StandardMeetFreshness
  }
  validate_measurement {
    "[MaxMoisture] <= 12"
    "[MinMoisture] >= 8"
    "[MaxMoisture] <= [RequiredMaxMoisture]"
  }
  reference_data_registry {
    RoastBatchRegistry
  }
  note {
    MoistureNote
  }
}
Clause Meaning
modality SHALL This process is mandatory.
validate_provision { ... } The provisions this process must satisfy.
validate_measurement { ... } The measurement expressions that must hold. See measurement.
reference_data_registry { ... } Registries whose records the provisions evaluate against.
note { ... } Notes attached to this process.

Where to see it in action