Part of the WebMEM® Protocol
Fragment Class: ProcedureFragment
Location: /protocol/fragments/procedurefragment/
Status: Current Draft
Last Updated: 2026-08-24
Overview
A ProcedureFragment is a WebMEM fragment class for publishing structured, ordered instructions for completing a defined task, process, application, or workflow.
Each ProcedureFragment establishes the procedure being described, the ordered steps required to complete it, and any conditions, dependencies, prerequisites, or supporting knowledge necessary to interpret those steps correctly.
Unlike an ExplainerFragment, which explains how or why something works, a ProcedureFragment represents what must be done and in what order.
A ProcedureFragment may also express conditional paths when the next step depends on a known state or condition. This allows the publisher to expose procedural logic explicitly rather than requiring machines to reconstruct a workflow from prose.
Semantic Purpose
The semantic purpose of a ProcedureFragment is to state:
To complete this defined task or process, these are the steps, requirements, dependencies, and conditional paths that apply.
A ProcedureFragment may establish:
- the task or process being performed;
- the entity, program, service, or context to which the procedure applies;
- prerequisites that must be satisfied before beginning;
- an ordered sequence of steps;
- documents, information, or resources required by particular steps;
- conditions affecting the sequence or applicability of steps;
- alternative procedural paths;
- completion or outcome conditions;
- defined terms required to interpret the procedure;
- relationships to applicable policies or eligibility requirements;
- and provenance supporting the procedure.
The ProcedureFragment preserves these elements as one coherent procedural knowledge object.
ProcedureFragment Within an SDT
A ProcedureFragment exists as one modular knowledge object within a Semantic Data Template (SDT).
The relationship is:
Web Resource → SDT → ProcedureFragment → Ordered Steps
An SDT may contain one ProcedureFragment or multiple ProcedureFragments when a resource describes different tasks, workflows, application processes, or procedural paths.
A ProcedureFragment may also reference other fragments within the SDT when the procedure depends on eligibility criteria, policies, definitions, factual information, explanations, or other structured knowledge.
This allows procedural knowledge to remain independently identifiable while participating in the broader machine representation of the resource.
ProcedureFragment Requirements
A conforming ProcedureFragment should establish enough information to identify the procedure and interpret the sequence of actions required to complete it.
| Element | Purpose |
|---|---|
| Fragment Class | Identifies the knowledge object as a ProcedureFragment. |
| Fragment ID | Provides a stable identifier for the ProcedureFragment within the published knowledge structure. |
| Task | Identifies the task, process, application, or workflow described by the procedure. |
| Steps | Provides the ordered actions required to complete the procedure. |
| Context | Establishes the entity, program, service, jurisdiction, audience, or other scope required to interpret the procedure when applicable. |
| Provenance | Identifies or references the source and lineage supporting the procedure. |
Prerequisites, conditional logic, required materials, dependencies, alternative paths, and related knowledge references may be included when they are necessary to represent the procedure accurately.
Ordered Steps
The defining structure of a ProcedureFragment is an ordered sequence of steps.
Each step represents an action or procedural stage and should preserve its position within the workflow.
A step may identify:
- its sequence number or position;
- the action to be performed;
- information or documents required for the action;
- the entity or system responsible for the action;
- conditions that must be satisfied before proceeding;
- the expected result of the step;
- and the next applicable step or procedural branch.
The structure should preserve the publisher’s intended sequence rather than requiring a consuming system to infer procedural order from surrounding prose.
Example ProcedureFragment
The following simplified example represents an application procedure using the current WebMEM HTML serialization.
<template
data-webmem-fragment
data-fragment-class="ProcedureFragment"
data-fragment-id="procedure-example-benefit-application">
<section
data-entity-type="PublicBenefit"
data-entity-id="program:example-benefit"
data-provenance-ref="#provenance-example-program">
<h3 data-role="task">
Apply for Example Benefit Program
</h3>
<ol data-role="steps">
<li data-step="1">
<span data-role="action">
Review the program eligibility requirements.
</span>
</li>
<li data-step="2">
<span data-role="action">
Gather the required identification and income documents.
</span>
</li>
<li data-step="3">
<span data-role="action">
Complete the program application.
</span>
</li>
<li data-step="4">
<span data-role="action">
Submit the application and required documentation.
</span>
</li>
<li data-step="5">
<span data-role="action">
Review the application status and respond to requests
for additional information.
</span>
</li>
</ol>
</section>
</template>
The fragment establishes that:
- the knowledge object is a
ProcedureFragment; - the fragment has a stable identity;
- the task being described is explicitly identified;
- the procedure is scoped to a defined program;
- the required actions are represented in their intended order;
- and provenance supporting the procedure can be resolved through the referenced provenance object.
Prerequisites
A ProcedureFragment may identify prerequisites that must be satisfied before the procedure begins or before a particular step can be completed.
Prerequisites may include:
- eligibility requirements;
- required documents;
- required accounts or registrations;
- prior approvals;
- completed earlier procedures;
- applicable dates or enrollment periods;
- or other conditions that precede the procedure.
When prerequisites constitute substantial eligibility or policy knowledge, the ProcedureFragment may reference the applicable EligibilityFragment or PolicyFragment rather than duplicating those rules within the procedure.
Conditional Logic
A ProcedureFragment may contain conditional logic when the applicable next step depends on a known condition or state.
For example:
<div data-role="condition">
<div
data-role="if"
data-condition="missing_documents"
data-operator="equals"
data-value="true">
<p data-role="then">
Obtain the missing required documents before continuing.
</p>
</div>
<div data-role="else">
<p>
Proceed to the next application step.
</p>
</div>
</div>
Conditional logic may express:
- branching steps;
- required checks;
- alternative procedural paths;
- exceptions;
- repeat or correction paths;
- or conditions determining when the procedure is complete.
The purpose of conditional logic is to expose the publisher’s known procedural structure. It does not require a consuming system to execute the procedure or perform actions on behalf of a user.
Alternative Paths
A procedure may contain multiple valid paths when different circumstances require different actions.
Alternative paths should be represented explicitly when the publisher knows the conditions determining which path applies.
For example:
<div data-role="procedure-paths">
<div
data-role="procedure-path"
data-path="online">
<span data-role="condition">
Online application is available.
</span>
<span data-role="action">
Complete and submit the online application.
</span>
</div>
<div
data-role="procedure-path"
data-path="paper">
<span data-role="condition">
Paper application is required or preferred.
</span>
<span data-role="action">
Complete the paper application and submit it using
the accepted delivery method.
</span>
</div>
</div>
Each path should preserve the conditions and actions specific to that path without implying that all procedural steps apply universally.
ProcedureFragment and EligibilityFragment
ProcedureFragment and EligibilityFragment may participate in the same workflow but serve different semantic purposes.
| EligibilityFragment | ProcedureFragment |
|---|---|
| Represents the conditions determining eligibility. | Represents the steps required to complete a task or process. |
| Answers: Under what conditions is this person or entity eligible? | Answers: What must be done, and in what order? |
| Primarily represents qualification logic. | Primarily represents procedural sequence and workflow. |
| May establish a prerequisite for beginning a procedure. | May reference eligibility requirements as prerequisites. |
For example:
Program → EligibilityFragment → Eligible Population → ProcedureFragment → Application Steps
This keeps qualification logic and procedural instructions independently identifiable while allowing them to participate in the same knowledge structure.
ProcedureFragment and PolicyFragment
A procedure may be established or constrained by an authoritative policy.
The PolicyFragment represents the governing rule, requirement, or restriction. The ProcedureFragment represents the actions required under that rule.
For example:
- PolicyFragment: establishes that documentation must be submitted within a defined period.
- ProcedureFragment: describes how and where the documentation must be submitted.
Where the procedure depends on a policy represented elsewhere in the SDT, the relationship should be explicit.
ProcedureFragment and ExplainerFragment
A ProcedureFragment and an ExplainerFragment may address the same process but serve different purposes.
| ExplainerFragment | ProcedureFragment |
|---|---|
| Explains a subject, process, decision, or relationship. | Defines the ordered actions required to complete a process. |
| Answers: How or why does this work? | Answers: What do I do next? |
| May describe tradeoffs, reasoning, or contextual information. | Preserves procedural sequence, prerequisites, and conditional paths. |
An ExplainerFragment may therefore explain a procedure while the ProcedureFragment defines the procedure itself.
ProcedureFragment and Defined Terms
Procedural instructions often contain domain-specific terms whose meaning must remain precise.
A ProcedureFragment may reference DefinedTermFragment objects for terminology used within steps, prerequisites, conditions, or required documents.
This allows procedural instructions to remain concise while preserving explicit semantic relationships to canonical definitions elsewhere in the SDT.
ProcedureFragment and Relationships
A ProcedureFragment may participate in explicit relationships with other WebMEM knowledge objects.
For example, a ProcedureFragment may relate to:
- an EligibilityFragment defining prerequisites for the procedure;
- a PolicyFragment establishing rules governing the process;
- a DefinedTermFragment defining terminology used in the steps;
- a DataFragment containing facts required by the process;
- a DirectoryFragment identifying locations, providers, agencies, or services involved in the procedure;
- an ExplainerFragment explaining the process;
- another ProcedureFragment representing a prerequisite or follow-up workflow;
- or a canonical resource where an action can be completed.
These relationships allow the procedure to remain a focused procedural knowledge object while connecting it to the broader information required to understand or complete the workflow.
Read the Relationships specification →
ProcedureFragment and Resolution
ProcedureFragments can participate in machine resolution by connecting a task or desired outcome to the structured steps, prerequisites, resources, and related knowledge required to complete it.
A resolution path may take the form:
Task → ProcedureFragment → Required Steps → Applicable Resource
or:
Program → EligibilityFragment → ProcedureFragment → Application Resource
or:
Procedure Step → Required Document → Related Procedure or Resource
The ProcedureFragment publishes the procedural knowledge. It does not require a consuming system to execute the steps, submit information, or perform actions.
Where a procedure participates in a broader resolver surface, the resolver may use or reference the ProcedureFragment as part of the path from an information need toward the appropriate process or resource.
Read the WebMEM Resolution Model →
Provenance
A ProcedureFragment should preserve the evidentiary or authoritative basis for the procedure it publishes.
Provenance may identify:
- the official instructions, policy, regulation, program documentation, manual, or other source establishing the procedure;
- the organization or authority responsible for the process;
- the canonical source location;
- publication, effective, or revision dates;
- retrieval or access dates;
- version information;
- jurisdiction or program scope;
- guidelines or interpretive documentation;
- and other lineage information necessary to establish the origin and applicability of the procedure.
When different steps originate from different authorities or source materials, the provenance model should preserve those distinctions rather than implying that the entire procedure originated from a single source.
Read the Provenance specification →
Conformance
A conforming ProcedureFragment must:
- identify itself as a
ProcedureFragment; - have an identifiable fragment scope;
- identify the task, process, application, or workflow being described;
- contain an ordered sequence of procedural steps;
- preserve the intended order of those steps;
- represent prerequisites or conditional paths when they are necessary to interpret the procedure correctly;
- preserve applicable entity, program, geographic, temporal, jurisdictional, or other contextual scope;
- identify or reference provenance supporting the procedure;
- preserve relationships to eligibility requirements, governing policies, defined terms, supporting facts, or related resources when those relationships are necessary to interpret the procedure;
- and conform to the applicable WebMEM serialization requirements.
A ProcedureFragment represents published procedural knowledge. Conformance does not imply that a consuming system is capable of executing the procedure, performing actions, submitting information, or completing the task on behalf of a user.
A ProcedureFragment represents published procedural knowledge. Conformance does not imply that a consuming system is capable of executing the procedure, performing actions, submitting information, or completing the task on behalf of a user.
Relationship to WebMEM 1.x
The ProcedureFragment class originated in the WebMEM 1.x Semantic Data Template specification and remains a defined fragment class in the current WebMEM Protocol.
Earlier specifications described ProcedureFragment as a structured mechanism for agent-navigable workflows and associated it with retrieval hints, memory cues, glossary alignment, semantic digests, and agentic task execution.
The current protocol preserves the semantic purpose of the class while separating that purpose from retired WebMEM 1.x memory, retrieval, digest, and agent-execution mechanisms.
Ordered procedural steps remain central to the class. Conditional logic also remains part of the class when the applicable workflow depends on known conditions, prerequisites, or alternative procedural paths.
The current protocol clarifies that these structures represent the publisher’s explicit procedural knowledge. They do not prescribe how a consuming system must execute the procedure or imply that the system is authorized or capable of performing the represented actions.
The current protocol also makes explicit how ProcedureFragment participates in machine resolution by connecting tasks, programs, prerequisites, procedural steps, and related resources into navigable knowledge paths.
ProcedureFragment continues to represent the structured steps, requirements, dependencies, and conditional paths necessary to complete a defined task, process, application, or workflow.