#U.Commitment (Deontic Commitment Object)

A.2.8 · Stable · Definitional ontic pattern · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable Type: Definitional ontic pattern

The word family “bind/binding” is used throughout FPF for technical binding (name/slot binding, parameter binding, etc.). This pattern introduces a narrower lexical constraint: do not use “binding” as the Tech-level term for deontic governance relations. Use commitment and model it as U.Commitment. If source wording uses “binding contract/promise” rhetoric, rewrite it into explicit U.Commitment fields (subject, modality, scope/window, referents, and—when auditable—adjudication).

#Keywords

• commitment
• deontics
• obligation
• recommendation-as-duty
• prohibition
• modality normalization
• scope and validity window
• adjudication hooks
• evidenceRefs
• BCP-14 (RFC 2119/8174).

#Relations

#Content

#Terminology: “binding” is overloaded (normative)

The word family “bind/binding” is used throughout FPF for technical binding (name/slot binding, parameter binding, etc.). This pattern introduces a narrower lexical constraint: do not use “binding” as the Tech-level term for deontic governance relations. Use commitment and model it as U.Commitment. If source wording uses “binding contract/promise” rhetoric, rewrite it into explicit U.Commitment fields (subject, modality, scope/window, referents, and—when auditable—adjudication).

This pattern therefore treats commitment as the canonical Tech-level term and uses U.Commitment as the kernel object.

If source wording uses “binding” rhetoric (e.g., “binding contract”, “legally binding promise”), treat it as Plain-level phrasing that must be recovered into explicit U.Commitment fields (subject, modality, scope/window, referents, and, when auditable, adjudication). Deontic keywords are cues for the modality field after the deontic relation is recovered; they are not the governed object of this pattern.

#Use This When

Use this pattern when a project needs to state who is accountable for what, under which modality, scope, and time window, without pretending that the words in a specification, contract, ticket, API description, or standard are themselves the accountable actor.

What goes wrong if missed. A specification, interface, dashboard, contract text, or ticket is treated as the accountable party; evidence, gate admission, performed work, and commitment content collapse into one deontic-looking sentence.

What this buys. The accountable subject, modality, referent, scope, time window, and adjudication hooks become inspectable without turning publications, evidence, gates, or work occurrences into commitment holders.

Typical moments:

• a promise content, policy clause, requirement, SLA, protocol rule, or standard clause must become an accountable commitment;
• source wording says "MUST", "SHALL", "guarantees", "is responsible for", or "legally binding", and the project must recover the deontic relation rather than normalize keywords by themselves;
• evidence or gates are being attached to a duty and the model must keep commitment content, adjudication evidence, and performed work distinct.

Primary EntityOfConcern. The EntityOfConcern is U.Commitment: a deontic relation linking an accountable subject to referents under explicit modality, scope, validity window, and optional adjudication hooks.

First useful move. Name the accountable subject and the referents first. Then state modality, scope, validity window, and adjudication only if the commitment is meant to be checked or enforced.

Not this pattern when. If the current EntityOfConcern is the promised content, use A.2.3; if it is the communicative act that instituted or revoked the commitment, use A.2.9; if it is a gate or admissibility claim, use the gate or boundary pattern; if it is performed work, use A.15.1.

Type: Definitional (D) Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.2 Roles & Agency Kernel Refines: A.2 (Role Taxonomy) Builds on: E.8 (authoring template), A.2.1 (RoleAssignment), A.2.6 (Scope & Γ_time), A.7 (EntityOfConcern / Description episteme / carrier), A.2.3 (U.PromiseContent as promise), A.15.1 (U.Work) Purpose (one line): Provide a minimal, reusable kernel object for deontic commitments (who is accountable, under what modality, in what scope/window, with respect to which referents, with which adjudication hooks), explicitly separating the commitment object from its utterance descriptions (A.7), so deontics stop “living” in naming patterns and become stable across A.6 and governance patterns.

#Terminology: “binding” is overloaded (normative)

The word family “bind/binding” is used throughout FPF for technical binding (name/slot binding, parameter binding, etc.). This pattern introduces a narrower lexical constraint: do not use “binding” as the Tech-level term for deontic governance relations. Use commitment and model it as U.Commitment. If source wording uses “binding contract/promise” rhetoric, rewrite it into explicit U.Commitment fields (subject, modality, scope/window, referents, and—when auditable—adjudication).

This pattern therefore treats commitment as the canonical Tech-level term and uses U.Commitment as the kernel object.

If source wording uses “binding” rhetoric (e.g., “binding contract”, “legally binding promise”), treat it as Plain-level phrasing that must be recovered into explicit U.Commitment fields (subject, modality, scope/window, referents, and, when auditable, adjudication). Deontic keywords are cues for the modality field after the deontic relation is recovered; they are not the governed object of this pattern.

#Problem frame

FPF needs to express boundary governance and socio-technical obligations in a way that is:

• grounded in an accountable role, role assignment, or party (someone is accountable),
• scope-and-window explicit (where/when the commitment holds),
• reference-based (no paraphrase drift; refer to claim IDs),
• adjudicable (if intended to be checkable, it has an evidence story).

In practice, texts use “MUST/SHALL/should”, “commits to”, “guarantees”, “SLA”, “contract”, etc. Without a stable kernel object for the deontic commitment relation, authors either:

• assign agency to descriptions (“the API guarantees…”),
• smuggle admissibility gates into deontics (or vice versa),
• treat evidence as semantic truth,
• or create multiple inconsistent “contracts” across faces.

A.6.B provides L/A/D/E claim-classification discipline, and A.6.C provides contract-language unpacking, but both benefit from a kernel-level object that pins down what a U.Commitment is structurally (so “contract/binding” rhetoric does not leak back in as ontology).

#Problem

How can FPF represent a deontic commitment relation so that:

1. The accountable subject is explicit (role or role-enactor; not “the spec/interface/service”),
2. Modality is explicit and lintable (obligation, recommendation-as-duty, prohibition, and strength),
3. Scope and validity window are explicit (bounded context + time + conditions),
4. The content is referenceable via stable referent claim IDs (promise contents, gates, evidence targets, etc.),
5. Adjudication hooks exist when the commitment is meant to be testable/auditable (links to evidence claims and carrier expectations),
6. Conflicts can be represented (without requiring this pattern to solve them).

#Forces

#Solution

U.Commitment is the kernel object representing a deontic commitment relation: it links an accountable subject (role or role-enactor) to one or more referents via an explicit modality within an explicit scope/window, optionally with adjudication hooks.

This pattern defines:

• a normative minimal structure for U.Commitment,
• how U.Commitment relates to U.PromiseContent, U.Work, and evidence,
• how it is used as the canonical payload for D-quadrant obligation, recommendation-as-duty, and prohibition claims (A.6.B), while permission claims route to the exact A.2.8.PER result,
• and what must be stated for a commitment to be considered auditable.

#Normative definition

A U.Commitment is a governance object representing a deontic relation that constrains an accountable subject (role or role-enactor) with respect to one or more referents under an explicit modality and explicit scope/window, optionally with explicit adjudication hooks.

Per A.7, a U.Commitment is not the text that states it: it is an object that is typically instituted by (and recorded via) one or more speech acts and utterance descriptions and may be carried by utterance carriers or publication carriers.

#Minimal structure (normative)

A conforming U.Commitment SHALL be representable by the following minimal record (field names are illustrative; the presence/meaning constraints are normative). Required fields are: id, subject, modality, scope, validityWindow, referents. adjudication and source are optional (but may become required by other patterns when auditability or authority must be made explicit).

U.Commitment ::=
  {
    id: CommitmentId,                  // stable identifier; can align with D-* claim ID
    subject: CommitmentSubject,         // accountable role or role-enactor (not an episteme)
    owedTo: optional<set<CounterpartyRef>>, // who the commitment is owed to / intended beneficiary (optional; governance-facing, not required)
    modality: DeonticModalityToken,     // deontic modality (normalized; lintable)
    scope: U.ClaimScope,               // bounded context for applicability + non-temporal delimiters (same primitive as claim scopes; commitments are not epistemes)
    validityWindow: QualificationWindowPolicy, // Γ_time slice + conditions under which it applies / is in force
    referents: set<ReferentRef>,        // what is being bound (by reference, not paraphrase)
    adjudication: optional<AdjudicationHooks>, // evidence hooks if auditable
    source: optional<CommitmentSource>, // what instituted/authorized it (issuer + instituting act + utterance description), when provenance matters
    notes: optional<InformativeText>    // explicitly informative; not part of the commitment relation
  }

CommitmentSubject ::=
  RoleRef | RoleAssignmentRef | PartyRef
  // At minimum: a RoleRef that denotes an accountable role kind in a bounded context.
  // If a concrete party/holder is known, prefer RoleAssignmentRef or PartyRef.
  // If multiple subjects are independently accountable, authors SHOULD model separate commitments (one per subject),
  // unless a joint obligation is explicitly modeled as a single PartyRef.

CounterpartyRef ::=
  PartyRef | RoleRef | RoleAssignmentRef
  // Optional “to whom”/beneficiary/counterparty handle. Keep minimal: do not treat it as a full legal-party model.

DeonticModalityToken ::=
  MUST | MUST_NOT | SHOULD | SHOULD_NOT
  // FPF deontic-modality values for the `modality` slot.
  // RFC words and their synonyms are source expressions; map them only after the commitment relation is recovered.
  //
  // **Normalization mapping (normative; illustrative table):**
  // - SHALL, REQUIRED        -> MUST
  // - SHALL NOT, PROHIBITED  -> MUST_NOT
  // - RECOMMENDED            -> SHOULD
  // - NOT RECOMMENDED        -> SHOULD_NOT
  // MAY and OPTIONAL do not normalize into U.Commitment. Recover their actual claim: strong or weak permission under A.2.8.PER, an A-* entry predicate, or informative prose.

ReferentRef ::=
  ClaimIdRef | PromiseContentRef | MethodDescriptionRef | WorkRef
  // Prefer ClaimIdRef when an L/A/D/E claim ID exists (L-*, A-*, D-*, E-*).
  // Use PromiseContentRef when the commitment is about satisfying a promise-content clause (`U.PromiseContent`).
  // Use MethodDescriptionRef (preferred) when the commitment is about performing/avoiding a work-kind (work-to-be-done).
  // Use WorkRef only when the commitment is about an already executed/ongoing Work occurrence (rare).

PromiseContentRef ::=
  ObjectIdRef
  // MUST resolve to a `U.PromiseContent` object (A.2.3). (Some chapters may call this a “promise content”.)

AdjudicationHooks ::=
  {
    evidenceRefs: set<ClaimIdRef>,      // typically E-* claim IDs
    carrierRefs: optional<set<CarrierClassRef>>,  // if evidence carriers are part of the hook
    evaluationNotes: optional<InformativeText>    // how adjudication is done; informative unless normed elsewhere
  }

DescriptionRef ::=
  ClaimIdRef | EpistemeRef
  // A pointer to an utterance description that states/records the commitment (e.g., spec clause, policy text).

SpeechActRef ::=
  ObjectIdRef
  // MUST resolve to a `U.SpeechAct` Work occurrence (A.2.9).

CommitmentSource ::=
  {
    issuer: optional<PartyRef>,         // who issued/authorized the commitment (can be distinct from subject)
    speechActRef: optional<SpeechActRef>, // instituting communicative act, when available
    descriptionRef: optional<DescriptionRef>, // where it is stated/recorded (utterance description)
    authorityClass: optional<AuthorityTag>, // e.g., policy, contract, statute, standard (informative tag)
    precedence: optional<PriorityTag>   // used for conflict handling elsewhere; not a truth claim
  }

Normative constraints:

• (C1) Subject must be accountable. subject MUST resolve to an accountable role or party; it MUST NOT be “the interface, spec, service, or system” as an episteme.
• (C2) Modality must be explicit and normalized. modality MUST be present for normative commitments and MUST be normalized to DeonticModalityToken.
• (C3) Scope + validity must be explicit. scope and validityWindow MUST be present. Defaults are allowed only when an explicit context policy is cited as the source of those defaults (do not rely on “implied defaults”). validityWindow expresses in-force conditions; per-action admissibility gates belong in referenced A-* predicates.
• (C4) Referents must be non-empty. referents MUST contain at least one referent (what is being obligated, recommended as a duty, or prohibited).
• (C5) Referents must be by reference when possible. If the bound content already exists as claim IDs, referents SHOULD cite those IDs rather than restating them.
• (C6) Auditable commitments must have adjudication hooks. If a commitment is intended to be audited/adjudicated by observation, adjudication.evidenceRefs SHALL include the evidence claim IDs (typically E-*) that carry the adjudication substrate.
• (C7) Evidence belongs in adjudication by default. If an E-* claim is referenced only to define how to measure/verify a commitment, it SHALL be listed in adjudication.evidenceRefs (not in referents). An E-* claim MAY appear in referents only when the commitment’s content is itself an evidence-producing/retaining duty (e.g., “MUST retain traces”).
• (C8) Default auditability stance is explicit. If adjudication is absent, the commitment SHALL be treated as non-auditable by default (aspirational / governance-only), unless another pattern or Context policy explicitly supplies adjudication hooks by reference.

#Interaction rules (normative)

1. U.PromiseContent is promise content; U.Commitment is the governance relation. A service promise clause (what is promised) is not, by itself, an accountable commitment. A U.Commitment makes an accountable subject responsible for providing/satisfying the service promise (or for satisfying other governance clauses).

2. U.Commitment is not U.Work. Work is execution; commitment is governance. A commitment may reference evidence targets, but it does not “contain” evidence.

3. Commitments may reference admissibility predicates; they must not become predicates. If compliance requires satisfying a gate predicate, the commitment should reference the gate (A-*) as a referent, rather than rewriting the predicate as prose inside the commitment.

4. A U.Commitment is a governance object, not a law. Commitments are not truth-conditional invariants. If something is intended to be an invariant, it belongs as law/definition (L), and a commitment can reference it.

5. Commitment changes are explicit (no silent mutation). When a commitment is updated, narrowed, broadened, superseded, or revoked, the change SHOULD be represented as a new U.Commitment (new ID) and an instituting U.SpeechAct (A.2.9) that references the affected commitment IDs (e.g., via U.Commitment.source.speechActRef and a status/supersession claim), rather than editing a published commitment in place without an auditable change record.

#Canonical use in boundary claim registers (recommended)

When using the A.6 stack, represent each D-quadrant atomic claim that states an accountable obligation, recommendation-as-duty, or prohibition as a U.Commitment payload with the fields below. A D-* strong/weak permission, exercise, non-violation, or conflict claim instead cites the exact A.2.8.PER result and does not acquire a U.Commitment payload:

• id = D-*,
• subject = accountable role or party,
• modality = DeonticModalityToken (normalized from RFC-keyword family usage),
• referents = {PromiseContentRef, MethodDescriptionRef, L-*, A-* … as needed} (content/targets),
• adjudication.evidenceRefs = {E-* …} when the commitment is meant to be checkable.

#Archetypal Grounding (Tell–Show–Show)

#Tell (universal rule)

A deontic statement becomes stable and reviewable when it is represented as a U.Commitment with an accountable subject, an explicit modality, explicit scope/window, referent claim IDs, and—if auditable—explicit evidence hooks.

#Show #1 (system archetype: incident response SLO discipline, post‑2015 SRE practice)

A production org states: “Severity‑1 incidents must be responded to within 4 hours.”

A commitment with explicit references:

• subject: RoleAssignmentRef(OpsTeam as ProviderRole) (or at least RoleRef(ProviderRole)),
• modality: MUST,
• scope: bounded context IncidentManagement,
• validityWindow: calendarYear2026 (or “while contract edition X is active”),
• referents: {PromiseContentRef(SVC-SLO-RESP-4H), A-SEV1-CLASS-1} where A-SEV1-CLASS-1 is the admissibility predicate for “counts as Sev‑1”.
• adjudication.evidenceRefs: {E-SLO-RESP-1} where E-SLO-RESP-1 defines the measurement substrate and evidence carriers (tickets + timestamps + clock source).

This makes the statement auditable by construction and keeps “classification gate” separate from “duty”.

#Show #2 (episteme archetype: protocol specification with behavioural typing motif)

A protocol spec states: “Participants MUST follow the state machine; violations are rejected; traces are retained for audit.”

Model as:

• A set of L-* claims defining the state machine and safety/progress properties within the model,

• A-* claims defining what runtime checks count as “admissible trace”,

• D-* commitments instantiated as U.Commitment with:

  • subject = RoleRef(ParticipantImplementer)
  • modality = MUST
  • referents = {L-STATE-MACHINE-1, A-TRACE-VALID-1, MethodDescriptionRef(TraceRetentionProcedure_v1)}
  • adjudication.evidenceRefs = {E-TRACE-LOG-1}

This mirrors common post‑2015 “protocols as types” practice: semantics and progress live in the model; compliance is agent governance; evidence is trace-based.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Kernel universal (any place FPF needs deontic commitment relations).

• Gov bias: prioritizes accountable subjects and adjudication hooks; may increase authoring overhead.
• Arch bias: pushes reference-by-ID and explicit scope/window to preserve evolvability and reduce drift.
• Onto/Epist bias: enforces “descriptions don’t promise”; commitments name accountable subjects.
• Prag bias: aligns with common spec-language practice (RFC keywords) but makes the structure explicit.
• Did bias: favors a small record that can be taught and linted.

#Conformance Checklist (normative)

1. CC‑A.2.8‑1 (Accountable subject). A normative U.Commitment MUST name an accountable subject (role assignment, role enactor, or party) and MUST NOT use a specification episteme, interface-description episteme, or document-carried episteme as subject.

2. CC‑A.2.8‑2 (Explicit modality). A normative U.Commitment MUST specify modality as DeonticModalityToken (with any RFC-keyword synonyms normalized to it).

3. CC‑A.2.8‑3 (Scope & validity explicit). A normative U.Commitment MUST specify scope (U.ClaimScope) and validityWindow (qualification-window policy), or explicitly cite the context policy that supplies defaults (do not rely on “implied defaults”).

4. CC‑A.2.8‑4 (Referents present and by ID). referents MUST be non‑empty. If the bound content exists as claim IDs, the commitment SHOULD reference those IDs in referents rather than restating their content.

5. CC‑A.2.8‑5 (Auditable commitments have hooks). If the commitment is intended to be auditable, it SHALL include adjudication.evidenceRefs referencing the evidence claims (typically E-*) that make adjudication possible.

6. CC‑A.2.8‑6 (Evidence separation). If an E-* claim is referenced only for measurement/verification, it SHALL appear in adjudication.evidenceRefs (not in referents).

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

• Makes deontic statements first-class and lintable (subject/modality/scope/referents/hooks).
• Enables clean integration with boundary claim classification (A.6.B) and contract unpacking (A.6.C) without embedding ontology in naming patterns.
• Improves auditability by making evidence expectations explicit only when intended.

Trade-offs / mitigations

• Adds structure to authoring; mitigated by allowing conceptual evidence hooks and default scope policies.
• Does not resolve conflicts between commitments; mitigated by capturing source/precedence tags and delegating resolution to governance patterns (Part D) and context policy.

#Rationale

The triad “promise, utterance, and commitment” is useful for language discipline, but deontic ontology should not be anchored in a naming-focused pattern. A kernel object:

• stabilizes what a “commitment” structurally is,
• ensures “MUST/SHALL” talk is representable without category mistakes,
• and provides the bridge between governance claims and adjudication (via explicit hooks), which is essential for boundary engineering and ethics/governance work.

#SoTA-Echoing (informative; post‑2015 alignment)

Informative. Alignment notes; not normative requirements.

• BCP 14 (RFC 2119 + RFC 8174) / modern spec-language discipline (2017+). Treating modality tokens as a controlled family is standard; U.Commitment.modality makes this family explicit and lintable.
• Policy-as-code ecosystems (2016+). Modern governance stacks often encode gates as code (e.g., Kubernetes admission controls, OPA/Rego-style policy evaluation) and obligations as process controls; the U.Commitment structure helps keep “gate predicates” separate from “actor duties”, while still linking them by reference.
• ODRL-style duty, permission, and prohibition modeling (W3C ODRL 2.2, 2018). The minimal subject/assignee, action/target, constraint/window, and policy shape is widely used, and its source separation is useful. FPF adapts that shape without forcing unlike deontic effects into one modality record: U.Commitment keeps accountable duty/recommendation/prohibition, while A.2.8.PER owns strong/weak permission and exercise. Both retain explicit subject or beneficiary, action/referent, constraint/window, policy provenance, FPF boundary-claim classification, and evidence discipline.
• Trace-based compliance and audit (2018+ supply-chain / reproducibility practice). “Compliance is evidenced by evidence carriers and records” is mainstream; adjudication.evidenceRefs captures this without turning evidence into semantics.
• Supply-chain attestations (2021+). Attestation-oriented schemes (e.g., SLSA-style provenance, transparency logs) operationalize “claims + evidence carriers”; adjudication.evidenceRefs is the bridge point without collapsing evidence into truth.

#Relations

Uses / builds on

• A.2.1 for identifying accountable roles vs role-enactors (role assignments).
• A.2.6 for expressing scope and time/window (U.ClaimScope, qualification-window policy).
• A.7 for keeping source “binding” wording distinct from utterance descriptions and carriers.

Used by

• A.6.B (Quadrant D) as the canonical payload shape only for obligation, recommendation-as-duty, and prohibition statements; strong or weak permission, exercise, non-violation, and conflict claims cite the exact A.2.8.PER result instead.
• A.6.C (Contract Unpacking) as the formal governing pattern for the “Commitment” component of the bundle.
• Part D governance/ethics patterns, when current, for expressing layered, conflicting, multi-authority commitments.

Coordinates with

• A.2.3 (U.PromiseContent): services are promise clauses; commitments assign accountable subjects to those clauses.
• A.2.9 (U.SpeechAct): U.Commitment.source.speechActRef points to the instituting communicative work occurrence when provenance matters.
• A.15.1 (U.Work) and evidence patterns: adjudication hooks refer to evidence in work, not to text.
• A.2.8.PER: strong grants, permission exercise, weak non-prohibition/non-violation findings, and permission conflicts remain separate from U.Commitment; a visible MAY or OPTIONAL token does not choose between those objects and an A-* entry predicate.

#A.2.8:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)