2. Conformance

(Normative)

2.1 Conformance Targets

This specification defines three conformance targets. An implementation MAY conform to one or more targets independently.

Conformance Target 1 — Activity Model. A governed activity implementation that carries all 21 typed attributes organized by four attribute families (Role, Data Lineage, Performance, Risk) plus Governance and Documentation attributes, as specified in Clause 8. Each governed activity SHALL carry the full attribute set. Attributes MAY have null values where not applicable, but the attribute structure SHALL be present.

Conformance Target 2 — Process Structure. A process implementation that provides typed gateways with defined semantics (Clause 9.3), structured exception handling through the BPMN 2.0 event taxonomy (Clause 9.4), governed decomposition through subprocesses with their own governance interfaces (Clause 9.5), and explicit execution ordering through sequence and message flows (Clause 9.6). Deterministic routing logic SHALL be separated from LLM-inferred judgment. Gateway conditions that require reproducible, auditable evaluation SHALL use decision models (Clause 10.3), not probabilistic inference.

Conformance Target 3 — Governance Infrastructure. An execution domain that provides controlled vocabulary for semantic consistency across agents (Clause 10.1), policy linkage connecting governance documents to point-of-execution activities (Clause 10.2), DMN-equivalent deterministic decision models for structured decision logic (Clause 10.3), governance scope boundaries defining permission and inheritance containers (Clause 10.4), and version-controlled audit trail with attribution and rollback capability (Clause 10.5).

2.2 Obligation Keywords

The following keywords, when used in normative clauses of this specification, carry the meanings defined here in accordance with RFC 2119:

• SHALL — absolute requirement. An implementation that does not satisfy a SHALL requirement does not conform.
• SHALL NOT — absolute prohibition. An implementation that violates a SHALL NOT requirement does not conform.
• SHOULD — recommended. Departure from a SHOULD requirement is permitted but requires justification.
• SHOULD NOT — not recommended. Departure is permitted but requires justification.
• MAY — optional. Implementations are free to include or omit MAY features.

2.3 Conformance Claims

An implementation claiming conformance SHALL:

a) Identify which conformance target(s) it claims;

b) Reference this specification by its document identifier (bpmstack.org/spec/2026-04-01) and version;

c) Document any deviations from SHOULD requirements and the justification for each deviation.