PolicyFragment

Part of the WebMEM® Protocol
Fragment Class: PolicyFragment
Location: /protocol/fragments/policyfragment/
Status: Current Draft
Last Updated: 2026-08-24

Overview

A PolicyFragment is a WebMEM fragment class for publishing structured policies, rules, requirements, restrictions, exceptions, and conditional logic within a defined authoritative or organizational context.

Each PolicyFragment establishes the policy being represented, the rule or rules imposed by that policy, the scope within which those rules apply, and any exceptions, exemptions, conditions, or alternative outcomes necessary to interpret the policy correctly.

Unlike an EligibilityFragment, which represents the conditions determining qualification for a program, benefit, service, or product, a PolicyFragment represents the governing rule itself.

A PolicyFragment makes policy knowledge explicit so that machines can distinguish the rule, its applicability, its exceptions, its authority, and its relationships to other knowledge objects without reconstructing that structure from policy prose alone.

Semantic Purpose

The semantic purpose of a PolicyFragment is to state:

Within this defined scope, this policy or rule applies, subject to these conditions, exceptions, exemptions, or alternative outcomes.

A PolicyFragment may establish:

the identity and name of the policy or rule;
the authority responsible for the policy;
the entity, program, jurisdiction, product, service, or other context to which the policy applies;
the rule, requirement, restriction, or obligation established by the policy;
conditions governing applicability;
exceptions or exemptions;
alternative outcomes;
effective dates or other temporal scope;
defined terms necessary to interpret the policy;
relationships to eligibility requirements, procedures, or other policies;
and provenance establishing the source and authority of the policy.

The PolicyFragment preserves these elements as one coherent policy knowledge object.

PolicyFragment Within an SDT

A PolicyFragment exists as one modular knowledge object within a Semantic Data Template (SDT).

The relationship is:

Web Resource → SDT → PolicyFragment → Policy Rules

An SDT may contain one PolicyFragment or multiple PolicyFragments when a resource represents different policies, rules, authorities, jurisdictions, effective periods, or regulatory contexts.

A PolicyFragment may also reference other fragments within the SDT when the policy depends on defined terms, factual information, eligibility criteria, procedures, explanations, or other structured knowledge.

This allows policy knowledge to remain independently identifiable while participating in the broader machine representation of the resource.

PolicyFragment Requirements

A conforming PolicyFragment should establish enough information to identify the policy, understand its governing rule, determine its applicable scope, and distinguish any exceptions or conditional outcomes.

Element	Purpose
Fragment Class	Identifies the knowledge object as a `PolicyFragment`.
Fragment ID	Provides a stable identifier for the PolicyFragment within the published knowledge structure.
Policy Identity	Provides a stable identity for the policy, rule, regulation, requirement, or other governing object when applicable.
Policy Name	Provides the canonical or human-readable name of the policy or rule.
Rule	States the requirement, restriction, obligation, condition, or default outcome established by the policy.
Scope	Identifies the entity, program, jurisdiction, population, product, service, time period, or other context within which the policy applies.
Exceptions	Identifies exceptions, exemptions, override conditions, or alternative outcomes when applicable.
Provenance	Identifies or references the authoritative source and lineage supporting the policy.

Conditional logic, effective dates, related terms, related policies, enforcement conditions, and other information may be included when necessary to represent the policy accurately.

Policy Rules

The rule is the central knowledge structure within a PolicyFragment.

A rule may represent:

a requirement;
a prohibition;
an obligation;
a permission;
a restriction;
a deadline;
a penalty;
a protection;
a coverage rule;
an enrollment rule;
an administrative requirement;
or another authoritative policy condition.

The rule should preserve enough context to determine what it governs and under what circumstances it applies.

Policy Scope

A policy should be represented within the scope in which it is actually applicable.

Policy scope may include:

a jurisdiction;
a government program;
an organization;
a product or service;
a population;
a geographic area;
an enrollment period;
an effective date range;
a contractual relationship;
or another defined context.

A rule should not be represented as universally applicable when its authority or effect is limited to a narrower scope.

Where scope is necessary to interpret the policy correctly, it forms part of the policy knowledge rather than merely metadata about the document containing it.

Exceptions and Exemptions

A PolicyFragment may represent exceptions, exemptions, waivers, override conditions, or other circumstances in which the default rule does not apply or applies differently.

An exception should remain explicitly associated with the rule it modifies.

For example:

a penalty may apply unless a defined exemption is satisfied;
a deadline may be extended under specified circumstances;
a restriction may not apply to an exempt population;
a general requirement may have a special-case alternative;
or a policy may establish different outcomes depending on a known condition.

Explicitly representing exceptions helps prevent a default rule from being interpreted without the qualifications established by the policy itself.

Conditional Logic

A PolicyFragment may contain conditional logic when the effect of a policy depends on known facts, circumstances, exceptions, or alternative conditions.

For example:

<div data-role="logic-model">

  <div
    data-role="if"
    data-condition="no_creditable_coverage"
    data-operator="equals"
    data-value="true">

    <div
      data-role="and"
      data-condition="months_delayed"
      data-operator="greater-than"
      data-value="0">

      <span data-role="then">
        Apply penalty
      </span>

    </div>

  </div>

  <div
    data-role="else-if"
    data-condition="has_creditable_coverage"
    data-operator="equals"
    data-value="true">

    <span data-role="then">
      No penalty applied
    </span>

  </div>

  <div data-role="else">
    Evaluate applicable exception rules
  </div>

</div>

The logic model exposes the publisher’s known policy structure. It does not require a consuming system to execute the rule, determine legal rights, impose a penalty, or make an authoritative policy determination.

Example PolicyFragment

The following simplified example represents a coverage-related policy using the current WebMEM HTML serialization.

<template
  data-webmem-fragment
  data-fragment-class="PolicyFragment"
  data-fragment-id="policy-example-coverage-penalty">

  <section
    data-entity-type="Policy"
    data-entity-id="policy:example-coverage-penalty"
    data-provenance-ref="#provenance-policy-source">

    <h3 data-role="policy-name">
      Example Coverage Penalty Policy
    </h3>

    <p data-role="rule">
      A penalty applies when the applicable coverage requirement
      is not satisfied for the period defined by the policy.
    </p>

    <div data-role="exceptions">

      <div
        data-role="exception"
        data-exception-id="creditable-coverage">

        <p>
          The penalty does not apply when the applicable
          creditable coverage requirement is satisfied.
        </p>

      </div>

    </div>

    <meta
      data-role="effective-year"
      content="2026">

  </section>

</template>

The fragment establishes that:

the knowledge object is a PolicyFragment;
the fragment has a stable identity;
the policy itself has an identifiable policy identity;
the governing rule is explicitly represented;
an exception to the default rule is explicitly associated with the policy;
the applicable temporal context is represented;
and provenance supporting the policy can be resolved through the referenced provenance object.

PolicyFragment and EligibilityFragment

PolicyFragment and EligibilityFragment may represent closely related knowledge but serve different semantic purposes.

PolicyFragment	EligibilityFragment
Represents an authoritative policy, rule, requirement, restriction, or exception.	Represents the conditions determining qualification or eligibility.
Answers: What rule applies?	Answers: Under what conditions is this person or entity eligible?
May establish the authority underlying an eligibility criterion.	May reference the policy from which its qualification criteria originate.
Primarily represents governing rules.	Primarily represents qualification logic.

For example:

PolicyFragment → Governing Rule → EligibilityFragment → Qualification Criteria

This keeps the authoritative rule distinct from the eligibility logic derived from or governed by that rule.

PolicyFragment and ProcedureFragment

A policy may require, prohibit, or constrain a particular process.

The PolicyFragment represents the governing rule. The ProcedureFragment represents the actions required to complete the applicable process.

For example:

PolicyFragment: establishes that an appeal must be filed within a defined period.
ProcedureFragment: describes the steps required to file the appeal.

The relationship between the policy and procedure should be explicit when the procedure exists because of or is constrained by the policy.

PolicyFragment and Defined Terms

Policies frequently depend on terminology whose meaning is established by statute, regulation, contract, administrative guidance, or another authoritative source.

A PolicyFragment may reference DefinedTermFragment objects for terms whose precise meaning is necessary to interpret the policy.

Examples may include:

creditable coverage;
enrollment period;
qualifying event;
household income;
service area;
covered service;
or another policy-defined concept.

This allows the policy to remain focused on its governing rules while canonical definitions remain independently maintained.

PolicyFragment and DataFragment

A PolicyFragment may depend on factual values represented elsewhere in the SDT.

For example, application of a policy may depend on:

a date;
a duration;
a geographic identifier;
a coverage status;
an enrollment status;
a monetary value;
or another source-observed fact.

Those factual values may be represented by Machine Fact Objects within a DataFragment, while the PolicyFragment represents the rule governing how those facts affect the policy outcome.

This preserves the distinction between the facts to which a policy applies and the policy rule itself.

PolicyFragment and ExplainerFragment

A PolicyFragment represents the policy itself. An ExplainerFragment may provide a structured explanation of what the policy means, why it matters, or how it applies in different circumstances.

For example:

PolicyFragment: represents a late-enrollment penalty rule and its exceptions.
ExplainerFragment: explains how the late-enrollment penalty works in practical terms.

The explanation should not replace the policy object when the underlying authoritative rule is independently represented.

PolicyFragment and Relationships

A PolicyFragment may participate in explicit relationships with other WebMEM knowledge objects.

For example, a PolicyFragment may relate to:

an EligibilityFragment containing qualification rules governed by the policy;
a ProcedureFragment describing a process required by the policy;
a DefinedTermFragment defining policy terminology;
a DataFragment containing facts evaluated under the policy;
an ExplainerFragment explaining the policy;
another PolicyFragment representing a related, superseding, subordinate, or exception policy;
a MetaFragment describing an authoritative policy source;
or a canonical resource containing the authoritative policy text.

These relationships allow the policy to remain a focused governing knowledge object while connecting it to the facts, definitions, processes, and other rules required to interpret its application.

Read the Relationships specification →

PolicyFragment and Resolution

PolicyFragments can participate in machine resolution by connecting a policy question, rule, condition, or known fact to the applicable governing knowledge and related resources.

A resolution path may take the form:

Policy Question → PolicyFragment → Rule → Exception → Applicable Outcome

or:

Known Fact → PolicyFragment → Applicable Rule → ProcedureFragment

or:

Program → PolicyFragment → EligibilityFragment → Qualification Criteria

or:

PolicyFragment → Provenance → Authoritative Policy Source

The PolicyFragment publishes the policy knowledge. It does not require a consuming system to enforce the policy, make a legal determination, or treat a publisher’s representation as a substitute for the authoritative source.

Where policy knowledge participates in a broader resolver surface, the resolver may use or reference the PolicyFragment as part of the resolution path.

Read the WebMEM Resolution Model →

Provenance

A PolicyFragment should preserve the authoritative and evidentiary basis for the policy it publishes.

Provenance may identify:

the statute, regulation, contract, policy document, administrative guidance, manual, or other source establishing the rule;
the organization, agency, legislature, regulator, or other authority responsible for the policy;
the canonical source location;
publication, enactment, effective, revision, or expiration dates;
retrieval or access dates;
version information;
jurisdiction or program scope;
license or usage information when applicable;
interpretive guidance or related documentation;
and other lineage information necessary to establish the origin and applicability of the policy.