A.2.9 — U.SpeechAct (Communicative Work Object)
Preface node
heading:a-2-9-u-speechact-communicative-work-object:5060
Content
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: A.2.1 (RoleAssignment), A.2.6 (
Γ_time/ windows), A.7 (Object≠Description≠Carrier), A.10 (SCR/RSCR carrier discipline), A.15.1 (U.Work) Purpose (one line): Provide a minimal, lintable kernel object for communicative enactments (approvals, authorizations, revocations, notices, declarations, publications) asU.Work, explicitly separating the act from its utterance descriptions and evidence carriers, so governance and gating can citeSpeechActRefwithout “contract soup” or episteme‑as‑agent mistakes.
FPF already treats communicative acts as observable events used in role-state checklists and grounding (“presence of act: AuthorizationSpeechAct exists…”, and
U.SpeechActis listed as an observable basis for state assertions). The spec’s micro-examples and conformance gates distinguish communicative Work (“performed a SpeechAct”) from operational Work (“executed Work”) while keeping both insideU.Work(cf. CC‑A15‑10 GateSplit). F.18 currently framesU.SpeechActas the “utterance” label in the promise/utterance/commitment triad; A.2.9 keeps that as naming intuition while putting the ontology and conformance discipline in Part A where it can be linted and reused.
A.2.9:1 — Problem frame
FPF repeatedly needs to reference “someone said/did the approving/authorizing/declaring thing”:
- Role eligibility and enactability checklists often depend on the presence of an approval/authorization act within a freshness window.
- Governance patterns and boundary writing (A.6 stack) need provenance: “this obligation/commitment/permission was instituted by that act”.
- Operational patterns need auditable notices (“depletion notice”, “override invoked”) whose existence and timing matter.
Without a first‑class kernel object for such communicative events, authors tend to:
- attribute agency to descriptions (“the spec approves…”, “the interface guarantees…”),
- collapse “utterance text” and “speech act event”,
- leave provenance dangling as “if modeled”,
- encode gates as prose obligations, or treat obligations as gates.
This pattern makes “speech act” an explicit, queryable Work‑kind with clear boundaries to U.Commitment and to utterance surfaces.
A.2.9:2 — Problem
How can FPF represent communicative enactments so that:
- Agency is explicit: a concrete accountable subject performs the act (role/role‑enactor), not a document/spec/interface.
- The act is locatable in time: the act has an explicit Window (and thus freshness can be evaluated).
- The act is locatable in meaning: the act is recognized inside a declared bounded context (the
U.Workjudgement context), not viaU.ClaimScope(which expresses applicability of claims/commitments, not the judgement context for Work occurrences). - The act is auditable: it has at least one declared utterance description and/or evidence carrier when used for gating or governance.
- Institutional effects are linkable: the act can institute (or update/revoke) commitments, role assignments, statuses, etc., by reference.
- Ambiguity is handled pragmatically: the model supports multi‑function / multi‑party communication without requiring full linguistic pragmatics.
A.2.9:3 — Forces
A.2.9:4 — Solution
U.SpeechAct is a kernel Work object: a recorded communicative enactment performed by an accountable role‑enactor within a bounded context, optionally addressed to others, that is recognized (in that context) as updating an information and/or governance state. The act is not the utterance text; it points to utterance descriptions and evidence carriers.
A.2.9:4.1 — Normative definition
A U.SpeechAct is a U.Work occurrence whose primary (intended) effect is communicative: it places an utterance into a context in a way that is recognized by that context’s institutional semantics (policies, procedures, protocol rules) as potentially:
- asserting/informing,
- requesting/directing,
- promising/committing (as an instituting act),
- declaring/authorizing/revoking (status-changing acts),
- notifying (event announcement relevant for downstream work).
Per A.7, U.SpeechAct is an object/event; its utterance descriptions are descriptions (epistemes/spec clauses/messages‑as‑content), and its carriers are artifacts/traces that support observation and audit. (Note: “Surface” is reserved for MVPK publication/interoperability surfaces; do not use it here.)
Whether a given actType institutes commitments/permissions/status changes is entirely context‑policy dependent. Absent an explicit policy, treat a U.SpeechAct as a communicative Work occurrence with observable provenance only; do not infer deontic bindings from the act by default.
A.2.9:4.2 — Minimal structure (normative)
A conforming U.SpeechAct SHALL be representable by the following minimal record (field names are illustrative; the constraints are normative):
Normative constraints:
- (SA‑C0) Work conformance applies. Because
U.SpeechAct <: U.Work, a speech‑act record MUST satisfyU.Workconformance (A.15.1), including the required anchors (isExecutionOf,performedBy,executedWithin,window, and state‑plane / judgement‑context anchoring). A speech act MUST have at least oneaffectedreferent (the thing it is about/updates), even if it is purely governance‑state. - (SA‑C1) PerformedBy must be an accountable actor.
performedByMUST resolve to aRoleAssignmentRefwhose holder is an accountable system/party in the named scope. It MUST NOT be a spec/interface/document as an episteme. - (SA‑C2) ActTypes are required and context-local.
actTypesMUST contain at least oneSpeechActTypeRefrecognized in the Work’s judgement context (local meaning). Free‑text verbs are nonconformant unless registered as a context token. - (SA‑C3) Time honesty.
windowMUST be explicit (or inherited from the parentU.Workrecord) so freshness rules can be evaluated. - (SA‑C4) If used for gating/audit, it must be observable. If a speech act is used as a checklist criterion, guard condition, or provenance hook for a
U.Commitment, the model SHALL include at least one observable handle:utteranceRefsand/orcarrierRefs. When the act is used as evidence, at least one carrier reference SHOULD be SCR/RSCR‑resolvable per A.10. - (SA‑C5) Institutional effects are references, not paraphrases. When the act is intended to institute/update commitments, role assignments, or statuses,
institutes.*SHOULD reference the corresponding object IDs/claim IDs rather than restating content. - (SA‑C6) Cross-context use is Bridge-only. If a
SpeechActRefis used for checking/gating/provenance in a different bounded context than the act’s judgement context, the referencing object MUST satisfy the spec’s cross-context discipline by citing an explicit Bridge/policy that licenses the interpretation (and surfacing congruence vs loss where applicable), rather than assuming equivalence by label.
A.2.9:4.3 — SpeechActRef discipline (normative)
A SpeechActRef is a reference to U.SpeechAct.id.
- If another object (e.g.,
U.Commitment.source.speechActRef) cites aSpeechActRef, the referencedU.SpeechActMUST satisfy SA‑C0…SA‑C4 (and SA‑C6 when used cross‑context). - A
SpeechActRefMUST NOT be replaced by anEpistemeRef(“see the document”) when provenance is needed; the episteme is an utterance description, not the act. - If a system cannot record a full
U.SpeechAct, it may record a stub that still satisfies SA‑C0…SA‑C4 (minimalactTypes, performer, judgement context, window,affected, plus at least one observable handle). When a requiredU.Workanchor is unknown, the stub MUST use an explicit placeholder (e.g., an “AdHocCommunication” MethodDescription) rather than omitting the field.
A.2.9:4.4 — Separation rules with U.Commitment and U.PromiseContent (normative)
-
Speech act is not the deontic binding. A speech act may institute a
U.Commitment, but the deontic relation itself is theU.Commitmentobject (A.2.8). Do not encode obligations/permissions insideU.SpeechActas prose; instead, create/point toU.CommitmentIDs ininstitutes.commitments. -
Speech act is not the service promise clause.
U.PromiseContent/ promise contents are promise content; a speech act may be the act of offering/issuing that promise, but the promise content lives in the service/promise content objects and is referenced from the resulting commitments. -
Speech act is not the carrier. A “signed approval PDF”, “ticket record”, “Slack message”, or “API call log” is a carrier (and may carry an episteme as utterance content); the speech act is the Work occurrence that produced/issued it.
-
Publishing a spec is not a commitment by default. Default interpretation rule (normative). A conformant model/interpreter MUST NOT infer
U.Commitmentobjects solely fromPublish/Approvespeech acts. Publication MAY institute publication/status claims (e.g., “Published”, “Approved”, “Deprecated”), but any obligations/permissions on implementers/operators/providers MUST be modeled explicitly asU.Commitmentobjects (A.2.8). If a Context defines a policy that maps publication acts to commitment-instituting effects (e.g., a namedSpecPublicationPolicy@Context), that policy MUST be named and cited where the implication is used.
A.2.9:4.5 — Multi-function and multi-party support (normative)
-
Multi-function:
actTypesis a set. If one utterance performs multiple recognizable acts (e.g., “approve + instruct + warn”), the model may either:- represent one
U.SpeechActwith multipleactTypesentries, or - represent multiple
U.SpeechActrecords that share the samecarrierRefs/utteranceRefs. In either case, institutional effects must remain referenceable (SA‑C5).
- represent one
-
Multi-party:
addressedTois a set and may include roles/parties/assignments. If addressees matter for validity (e.g., “approval by CAB chair to deployment bot”), they should be explicit.
A.2.9:5 — Archetypal Grounding (Tell–Show–Show)
A.2.9:5.1 — Tell (universal rule)
When governance or gating depends on “someone said/did X”, model that saying/doing as a U.SpeechAct (a Work occurrence), and keep the utterance text and carriers separate. If the saying/doing creates obligations, model those obligations as U.Commitment objects instituted by the speech act.
A.2.9:5.2 — Show #1 (system archetype: change-control approval gates a deployment)
Situation (messy prose): “Change is approved, so the pipeline may deploy.”
Conformant modeling sketch:
-
U.SpeechAct SA-Approve-4711actTypes = {SpeechActTypeRef(Approval@ChangeControl)}performedBy = RoleAssignmentRef(CAB_Chair as ApproverRole@ChangeControl)isExecutionOf = MethodDescriptionRef(ChangeApprovalProcedure_v3)executedWithin = ChangeControlBoardSystemwindow = [t,t]affected = {ChangeRequestId(4711), WorkRef(Deploy-4711)}utteranceRefs = {EpistemeRef(ChangeTicket#4711)}carrierRefs = {CarrierRef(TicketSystemRecord#4711)}institutes.commitments = {CommitmentIdRef(D-Deploy-Authorized)}
-
U.Commitment D-Deploy-Authorizedsubject = RoleAssignmentRef(OpsBot#DeployerRole:CD_Pipeline_v7)modality = MAY(permission to enact)referents = {A-Gate-Deploy-4711}source.speechActRef = SA-Approve-4711
-
Gate predicate
A-Gate-Deploy-4711may include:exists SpeechAct(type=Approval, affected includes ChangeRequestId(4711), performedBy role=ApproverRole, within 90d).
This preserves:
- act vs text vs carrier,
- explicit performer,
- time window for freshness,
- explicit provenance from commitment back to the instituting act.
A.2.9:5.3 — Show #2 (episteme archetype: publishing a spec edition without making the spec an agent)
Situation (anti-pattern): “The interface spec declares MUST/SHALL requirements.”
Conformant modeling sketch:
-
U.SpeechAct SA-Publish-API-v12actTypes = {SpeechActTypeRef(Publish@APISpecContext), SpeechActTypeRef(DeclareNorms@APISpecContext)}performedBy = RoleAssignmentRef(StandardsEditor as PublisherRole@APISpecContext)isExecutionOf = MethodDescriptionRef(SpecReleaseProcedure_v12)executedWithin = SpecPublicationSystemwindow = [t,t]affected = {EpistemeRef(APISpec_v12)}utteranceRefs = {EpistemeRef(APISpec_v12)}carrierRefs = {CarrierRef(GitTag:v12), CarrierRef(SignedReleaseArtifact:v12)}institutes.statusClaims = {ClaimIdRef(D-StdStatus-APISpec_v12-Published)}(if modeled)
Norms live in the published utterance surfaces (spec clauses as routed claims), but the act of publication is a speech act performed by an accountable role. This avoids “the spec promises/commits” category errors while preserving auditability.
A.2.9:6 — Bias-Annotation
Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Kernel universal for speech-act usage that matters for governance, eligibility, gating, provenance, and protocol boundaries.
- Gov bias: favors explicit accountable performers and auditable records; increases clarity but adds modeling overhead.
- Arch bias: optimizes evolvability by keeping institutional effects referenceable rather than embedded in prose.
- Onto/Epist bias: enforces act≠utterance≠carrier and prevents episteme-as-agent metaphors.
- Prag bias: models only what is needed for decisions/audit (not full intention/sincerity/perlocutionary psychology).
- Did bias: keeps the record minimal and queryable for state checklists and boundary reviews.
A.2.9:7 — Conformance Checklist (normative)
- CC‑A.2.9‑1 (Accountable performer). A normative
U.SpeechActrecord MUST identifyperformedByas an accountableRoleAssignmentRefand MUST NOT use an episteme (spec/interface/document) as performer. - CC‑A.2.9‑2 (ActTypes declared). A
U.SpeechActrecord MUST include at least oneSpeechActTypeRefrecognized in its judgement context. - CC‑A.2.9‑3 (Window explicit). A
U.SpeechActrecord MUST have an explicitwindow(or inherit a window from its parent work record) so freshness and gating can be evaluated. - CC‑A.2.9‑4 (Observable when used for gating/provenance). If a speech act is cited by a checklist/guard or by
U.Commitment.source.speechActRef, it SHALL have at least oneutteranceReforcarrierRefthat supports observation/audit in the given context; evidence‑critical uses SHOULD anchor at least one carrier via SCR/RSCR per A.10. - CC‑A.2.9‑5 (Effects by reference). If the act is intended to institute/update commitments/roles/statuses, those effects SHOULD be referenced in
institutes.*by stable IDs. - CC‑A.2.9‑6 (Bridge-only cross-context use). If a
SpeechActRefis interpreted for gating/provenance in a different bounded context than the act’s judgement context, the referencing object MUST cite the Bridge/policy that licenses that cross-context interpretation (no “same label implies same force”).
A.2.9:8 — Common Anti-Patterns and How to Avoid Them
A.2.9:9 — Consequences
Benefits
- Makes approvals/authorizations/notices first-class and queryable, enabling clean RSG checklists and guard rules.
- Provides stable provenance: commitments and status transitions can cite the instituting act explicitly.
- Prevents recurring category errors: “documents promise”, “interfaces commit”, “logs prove”.
Trade-offs / mitigations
- Requires recording a small structured object for communicative events; mitigated by allowing minimal stubs that still satisfy CC‑A.2.9‑1…4.
- Requires context-local
SpeechActTypeRefregistration; mitigated by starting with a small set (Approve, Revoke, Publish, Notify, Authorize) and extending as needed.
A.2.9:10 — Rationale
FPF already relies on communicative acts (approvals, notices, overrides) as operationally meaningful events, but without a kernel object they blur into examples, naming choices, or prose. A.2.9 anchors speech acts where they belong: as a Work-kind with explicit performer, scope, and time, and with disciplined links to utterance surfaces, carriers, and deontic bindings (U.Commitment).
This also improves modularity:
- F.18 can remain a lexical anchor for naming (why “SpeechAct/utterance” as a label family is useful),
- while A.2.9 carries the ontology and conformance discipline for how speech acts behave as objects and how they connect to commitments and evidence.
A.2.9:11 — SoTA‑Echoing (informative; post‑2015 alignment)
Informative. Alignment notes; not normative requirements.
- Adopt — ISO 24617‑2:2020 / multi-dimensional communicative functions. Modern dialogue‑act standards treat communicative behavior as potentially multi‑functional. A.2.9 mirrors this by allowing
actTypesto be a set and by supporting shared carriers across multiple acts. - Adapt — commitment-based semantics for communication (multi-agent/protocol practice, 2015+). A pragmatic way to avoid mental-state modeling is to track communication by its social/institutional effects, especially on commitments and protocol states. A.2.9 reflects this via
institutes.commitmentsand explicit links toU.Commitmentwithout modeling sincerity or intention. - Adopt (warning) — illocutionary pluralism in multiparty discourse (2015+). One utterance commonly performs multiple recognizable functions. A.2.9 avoids the “single force” trap by permitting multi‑type acts and/or multiple acts sharing the same utterance and carriers.
A.2.9:12 — Relations
Uses / builds on
- Uses A.15.1 (
U.Work) for the event/work backbone (performedBy + window + stance). - Uses A.7 for the strict act≠description≠carrier split.
- Coordinates with A.2.6 for scope/window discipline.
Used by
- A.2.8 (
U.Commitment) as a concrete target forsource.speechActRefprovenance. - A.2.5 (RSG checklists/guards) when “presence of authorization/approval act” is a criterion.
- A.6.C (Contract unpacking) as the “utterance/instituting act” hook that prevents episteme-as-agent claims and improves provenance.