Skip to content
OWP

11. Compliance Profiles

A Compliance Profile is a separately-authored artefact that constrains a Function. Profiles are the mechanism by which regulatory, contractual, or organisational requirements attach to OWP-conformant work without modifying the core specification.

11.1 Position in the Protocol

Compliance is opt-in. The protocol’s core specifies behaviour that is correct for the broad case of unregulated knowledge work. Profiles attach to Functions whose work is regulated, contracted, or otherwise constrained; Profiles do not constitute the core behaviour and an implementation that supports the core but not Profiles is conformant at the Core conformance class (§13).

This positioning is intentional. The vast majority of organisational knowledge work is not regulated, and a protocol whose core surface is shaped by regulation imposes regulatory complexity on every deployment, including those where it is irrelevant. The protocol’s core is shaped by general organisational practice; regulation shapes Profiles.

11.2 Profile Structure

A Compliance Profile MUST contain:

  • A Profile ID (URI).
  • A human-readable identification of the regime it implements (e.g. “ASIC RG 271 Internal Dispute Resolution”; “GDPR Article 22 Automated Decision-Making”; “ISO 27001 Annex A”).
  • A set of constraints expressed against the Function’s primitives.
  • A signing key identifying the authoring authority.

Constraints expressible in a Profile include, but are not limited to:

  • Restrictions on Intent generation (e.g. “Workers in Role X MUST NOT generate Intent kind Y without prior Escalation”).
  • Restrictions on Capability invocation (e.g. “Capability kind Z MUST NOT be invoked for customers whose jurisdiction is in set J”).
  • Mandatory Escalation conditions (e.g. “All decisions exceeding threshold T MUST be escalated to a Human Role of class Reviewer”).
  • Required Audit Envelope metadata (e.g. “Envelopes for Function F MUST record the regulatory disposition of the matter under field G”).
  • Retention horizons for Worker history and Audit Envelopes (e.g. “Envelopes for Function F MUST be retained for 7 years”).
  • Provider restrictions (e.g. “Capabilities of category Model MUST be invoked only against Providers certified under regime R”).
  • Evaluation cadence requirements (e.g. “Evaluations of scope role for Role X MUST be produced at least every 30 days; absence beyond a 7-day grace period MUST suspend Worker outbox”).
  • Evaluation threshold constraints (e.g. “Workers in Role X whose most recent Evaluation reports outcome-quality below 0.85 over a 30-day window MUST be auto-restricted to escalation-only authority on Capability kind Y until the next Evaluation passes”). Threshold-driven restrictions and their restoration are recorded as ComplianceConstraintApplied events; see §12.6.

11.3 Attachment and Enforcement

A Profile attaches to a Function at deployment time. A Workforce MAY have multiple Profiles attached; constraints are unioned (the most restrictive applies on each dimension).

The runtime MUST evaluate every outbox action against all attached Profiles. A ComplianceConstraintApplied event MUST be emitted to the Audit Envelope each time a Profile’s constraint actively determines the runtime’s authorisation decision (preventing an action that would otherwise be permitted, requiring metadata that would not otherwise be required, etc.).

Profile authoring, distribution, certification, and version-management are the concerns of Profile authorities (regulators, professional bodies, contracting parties); the protocol specifies only the attachment and enforcement mechanism.