#U.Commitment: Deontic Commitment Object

Pattern A.2.8 · Stable · Definitional (D) · Normative (unless explicitly marked informative) Part A - Kernel Architecture Cluster

Type: Definitional (D) Status: Stable 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 (Object≠Description≠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 later governance patterns.

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 material uses “binding contract/promise” rhetoric, rewrite it into explicit U.Commitment fields (subject, modality, scope/window, referents, and—when auditable—adjudication).

#Aliases

• U.Commitment

#Keywords

• commitment
• deontics
• obligation/permission/prohibition
• modality normalization
• scope+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 material 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 your source material uses “binding” rhetoric (e.g., “binding contract”, “legally binding promise”), treat it as Plain-level phrasing that MUST be rewritten into explicit U.Commitment fields (subject, modality, scope/window, referents, and—when auditable—adjudication).

#Problem frame

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

• role/agent-grounded (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 binding”, 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 routing discipline (L/A/D/E), 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 / permission / prohibition / 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 binding 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/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 claims (A.6.B),
• 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 artifacts.

#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: U.QualificationWindow, // Γ_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 binding
  }

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 | MAY
  // Interpreted as in RFC 8174 keyword discipline when used normatively.
  // **Normalization rule:** if authors use synonyms (e.g., SHALL, REQUIRED, RECOMMENDED, OPTIONAL),
  // they MUST be mapped to this normalized set for linting and comparison.
  //
  // **Normalization mapping (normative; illustrative table):**
  // - SHALL, REQUIRED        -> MUST
  // - SHALL NOT, PROHIBITED  -> MUST_NOT
  // - RECOMMENDED            -> SHOULD
  // - NOT RECOMMENDED        -> SHOULD_NOT
  // - OPTIONAL               -> MAY

ReferentRef ::=
  ClaimIdRef | PromiseContentRef | MethodDescriptionRef | WorkRef
  // Prefer ClaimIdRef when a routed 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/party; it MUST NOT be “the interface/spec/service/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/permitted/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. Lifecycle 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 as a U.Commitment payload with:

• id = D-*,
• subject = accountable role/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 routable commitment:

• 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 binding).

• 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 bind agents/roles.
• 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/role-enactor/party) and MUST NOT use an episteme (spec/interface/document) 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 (U.QualificationWindow), 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 routing (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 / 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 missing bridge between governance claims and adjudication (via explicit hooks), which is essential for boundary engineering and for later 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/prohibition modeling (W3C ODRL 2.2, 2018). The minimal “subject + modality + constraint/window + target” shape is widely used; U.Commitment adopts the kernel of that idea while keeping FPF’s boundary routing and evidence discipline.
• Trace-based compliance and audit (2018+ supply-chain / reproducibility practice). “Compliance is evidenced by artifacts” 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, U.QualificationWindow).
• A.7 for keeping “binding” distinct from “utterance” and from “carriers”.

Used by

• A.6.B (Quadrant D) as the canonical payload shape for deontic statements.
• A.6.C (Contract Unpacking) as the formal anchor for the “Commitment” component of the bundle.
• Part D governance/ethics patterns (future work) for expressing layered, conflicting, multi-authority commitments.

Coordinates with

• A.2.3 (U.PromiseContent): services are promise clauses; commitments bind 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:End