Facts and Assertions Within an SDT

Part of the WebMEM® Protocol
Location: /protocol/sdt/assertions/
Status: Current Draft
Last Updated: 2026-08-24

Overview

A Semantic Data Template (SDT) exists to communicate publisher knowledge in a form that preserves enough meaning for machines to interpret that knowledge correctly.

At the center of many SDTs are assertions: statements the publisher makes about an identified subject within a defined semantic context.

Some assertions are factual. Some are derived. Other WebMEM fragments contain structures that are better understood as definitions, rules, procedures, eligibility criteria, relationships, recommendations, directory membership, or other forms of knowledge.

This distinction is fundamental.

WebMEM does not treat every machine-readable value as a fact, and it does not treat every piece of structured knowledge as the same kind of assertion.

The Fragment Class establishes the semantic role of the knowledge contained within a fragment. The assertion or structure communicates what the publisher actually states within that role.

What Is an Assertion?

An assertion is a statement of knowledge made by the publisher about an identifiable subject, relationship, condition, or context.

A simple factual assertion might be expressed conceptually as:

monthly_premium = 15.26 USD

But the value and predicate alone may not contain enough information to determine what the assertion means.

Correct interpretation may also depend on:

the subject of the assertion;
the meaning of the predicate;
the datatype of the value;
the unit of measurement;
geographic scope;
temporal scope;
population or entity scope;
source provenance;
derivation status;
and other applicability conditions.

Some of this information may be carried directly by the assertion. Other information may be established by its containing fragment, the SDT, related identity objects, provenance structures, or explicit relationships.

The requirement is not that every assertion duplicate all of its context.

The requirement is that the complete knowledge structure preserve enough context for the assertion to retain its intended meaning.

A Value Is Not a Fact

Consider the value:

15.26

It is machine-readable.

It is not yet a meaningful factual assertion.

Add a unit:

15.26 USD

Now the machine knows that the value represents money, but not what the money describes.

Add a predicate:

average_premium = 15.26 USD

Now the machine knows that the value represents an average premium, but the assertion remains underspecified.

Add subject and context:

subject: Medicare Advantage plans
geography: Putnam County, Ohio
plan_year: 2026
average_premium: 15.26
unit: USD

The assertion has become substantially more useful.

Add population, methodology, and provenance:

subject: Medicare Advantage plans
geography: Putnam County, Ohio
plan_year: 2026
population: plans represented in the applicable CMS source data
predicate: average_monthly_premium
value: 15.26
unit: USD
derived: true
method: arithmetic mean of applicable plan premiums
source: CMS Medicare Advantage Landscape data

The number is still 15.26.

What changed is the amount of meaning the publisher preserved around it.

This progression illustrates one of the central principles of WebMEM: machine readability is not the same as machine interpretability.

The Anatomy of a Factual Assertion

A factual assertion can be understood conceptually as a relationship among several components:

Subject
  ↓
Predicate
  ↓
Value
  ↓
Applicable Context
  ↓
Provenance

In practical terms:

Component	Question Answered
Subject	What entity or defined context is this assertion about?
Predicate	What property, characteristic, measurement, or state is being asserted?
Value	What value or state is asserted?
Datatype	How should the value be interpreted structurally?
Unit	What unit applies when the value represents a measurement or quantity?
Context	Where, when, for whom, or under what conditions does the assertion apply?
Provenance	Where did the assertion come from, and what is its evidentiary lineage?
Derivation	Is the assertion source-observed, normalized, calculated, aggregated, or otherwise transformed?

Not every assertion must carry each component directly. The applicable information may be inherited from the containing fragment or SDT when the relationship is explicit and unambiguous.

The Fragment Class Defines the Assertion

An assertion does not exist semantically apart from the Fragment Class in which it is represented.

Consider:

average_premium = 27.42 USD

Inside a DerivedStatsFragment, the Fragment Class establishes that the value represents calculated or aggregated knowledge.

By contrast:

monthly_premium = 27.42 USD

inside a DataFragment may represent a source-observed value associated with a specific entity.

The numerical values could even be identical. Their semantic roles are not.

This is why WebMEM does not define a separate universal Machine Fact Object that overrides or duplicates Fragment Class semantics.

The Fragment Class establishes what kind of knowledge is being asserted. The assertion supplies the specific content of that knowledge.

Source-Observed Assertions

A source-observed assertion represents knowledge obtained from an identified source without changing the substantive meaning of the source value.

These assertions are commonly represented within a DataFragment.

Examples may include:

plan_type = PPO
monthly_premium = 0 USD
primary_care_copay = 0 USD
maximum_out_of_pocket = 4900 USD

A source-observed assertion may still undergo technical processing before publication.

For example, the publisher may:

rename a source column;
normalize capitalization;
convert a date into ISO 8601 format;
convert a textual number into a numeric datatype;
normalize a currency representation;
map a source identifier to a canonical entity identifier;
or remove presentation-specific formatting.

These transformations do not necessarily make the assertion derived knowledge if they preserve the substantive meaning of the source assertion.

Normalized Assertions

A normalized assertion preserves the substantive meaning of source information while converting it into a consistent representation used by the publisher’s knowledge model.

For example, a source may contain:

"$0.00"

while the SDT represents:

value: 0
datatype: number
unit: USD

Or a source may contain:

"Preferred Provider Organization"

while the publisher represents:

plan_type = PPO

when the mapping is explicitly established and meaning-preserving.

Normalization should not silently introduce a new interpretation, calculation, classification, or conclusion that was not present in or directly supported by the source.

When a transformation changes the substantive assertion, the resulting knowledge should be represented according to its actual semantic role rather than labeled as merely normalized source data.

Derived Assertions

A derived assertion is produced by calculation, aggregation, transformation, classification, comparison, or another reproducible operation applied to underlying knowledge.

Derived assertions are commonly represented within a DerivedStatsFragment.

Examples may include:

plan_count = 42
average_premium = 27.42 USD
zero_premium_plan_count = 26
zero_premium_percentage = 61.9 percent
minimum_moop = 2900 USD
maximum_moop = 8900 USD

The provenance of a derived assertion should preserve both:

the source knowledge from which the assertion was derived; and
the derivation method necessary to understand how the resulting value was produced.

A derived assertion should not be represented as though the underlying source directly published the derived value when the publisher calculated it.

Source provenance and derivation provenance are different parts of the knowledge lineage.

Assertions and Complex Values

An assertion does not need to contain only a primitive scalar value.

A single semantic assertion may sometimes require a structured value.

Examples may include:

premium_range:
  minimum: 0 USD
  maximum: 148.50 USD

or:

enrollment_change:
  previous: 1842
  current: 2136
  change: 294
  percentage_change: 15.96 percent

The important question is not whether the value is technically scalar or complex.

The important question is whether the structure represents one coherent semantic assertion or several assertions that should remain independently distinguishable.

Complex values should be used when their internal elements form one meaningful unit and when preserving that structure improves interpretation.

They should not be used merely to hide unrelated assertions inside an arbitrary object.

Assertions and Shared Context

Multiple assertions often share the same subject, source, time period, geography, or other context.

For example:

DataFragment
  entity: plan:H5521-290-0
  plan_year: 2026
  source: CMS PBP

  monthly_premium = 0 USD
  primary_care_copay = 0 USD
  specialist_copay = 35 USD
  maximum_out_of_pocket = 4900 USD

The fragment establishes context shared by all four assertions.

There is no semantic benefit in repeating the same entity, plan year, and source on every assertion when their applicability is already explicit and unambiguous.

This is one of the reasons WebMEM uses fragments rather than requiring every fact to become a completely independent object.

Assertion-Level Overrides

Inherited context applies only while it remains accurate.

An individual assertion may require more specific context than the containing fragment.

For example:

DataFragment
  entity: plan:H5521-290-0
  plan_year: 2026
  source: CMS PBP

  monthly_premium = 0 USD

  enrollment = 2136
    source: CMS Monthly Enrollment
    enrollment_month: 2026-07

In this example, the enrollment assertion does not share the source provenance of the other plan benefit assertion.

The more specific assertion-level context must override the broader fragment context where the two differ.

The governing principle is:

Context may be inherited downward. More specific context overrides inherited context when explicitly declared.

Subject Scope

A factual assertion must apply to the correct subject.

This becomes especially important when related entities exist at different levels of an identity hierarchy.

For example:

Carrier
└── Contract
    └── Plan
        └── Segment

An assertion about the carrier is not automatically an assertion about every contract.

An assertion about a contract is not automatically an assertion about every plan.

An assertion about a plan is not automatically an assertion about every segment.

And a segment-specific value should not be generalized to the parent plan when the value varies by segment.

The subject of the assertion must therefore be identifiable either directly or through unambiguous inherited context.

Temporal Scope

Facts can change.

A value that is accurate for one time period may be inaccurate for another.

Temporal scope may represent:

a calendar year;
a plan year;
a month;
a quarter;
an effective date;
a validity interval;
a publication date;
or another period necessary to interpret the assertion.

For example:

entity: plan:H5521-290-0
plan_year: 2026
monthly_premium = 0 USD

does not assert that the same plan had a $0 premium in 2025 or will have a $0 premium in 2027.

When temporal scope materially affects truth, it is part of the meaning of the assertion.

Geographic Scope

Some assertions apply only within a defined geography.

Geographic scope may identify:

a country;
a state;
a county;
a ZIP Code;
a service area;
a region;
or another geographic entity.

For example, availability of a Medicare plan may be asserted at county scope while a particular plan segment or benefit value may require a more specific geographic resolution.

Geographic context should be represented at the level at which the assertion is actually valid.

Population and Collection Scope

Aggregated and comparative assertions often depend on the population or collection over which they were calculated.

For example:

average_premium = 27.42 USD

is incomplete if the population being averaged is unknown.

The applicable population might be:

all Medicare Advantage plans represented in the
2026 CMS Landscape data for Mohave County, Arizona

or a narrower subset such as:

PPO plans represented in the applicable county dataset

Changing the population changes the meaning of the derived assertion even if the predicate remains the same.

Population scope should therefore be preserved whenever it materially affects the interpretation or reproducibility of the result.

Predicate Meaning

The predicate identifies what property, state, measurement, or characteristic is being asserted about the subject.

A predicate should be sufficiently precise to distinguish it from similar concepts.

For example:

premium

may be ambiguous in a healthcare context.

More precise predicates might distinguish:

monthly_plan_premium
part_b_premium_reduction
drug_premium
average_monthly_plan_premium

When the meaning of a predicate depends on domain terminology, the assertion may reference a DefinedTermFragment or glossary structure that establishes its canonical meaning.

The predicate should identify the semantic property being asserted, not merely reproduce a presentation label whose meaning depends on surrounding prose.

Datatypes and Units

Values should be represented with enough structural information to prevent avoidable ambiguity.

For example:

value = 15.26

may require:

datatype = number
unit = USD

Other assertions may require:

integer;
decimal;
boolean;
date;
datetime;
duration;
percentage;
currency;
identifier;
enumerated value;
structured value;
or another datatype appropriate to the assertion.

Units should be explicit when the same numeric value could otherwise represent different quantities.

For example:

value: 35
unit: USD

is semantically different from:

value: 35
unit: percent

and:

value: 35
unit: days

Human-readable formatting may accompany a value, but presentation should not be the only mechanism through which datatype or unit can be determined.

Assertions and Defined Terms

A predicate or value may depend on terminology whose meaning must be established explicitly.

For example:

plan_type = PPO

may be understandable within a Medicare context, but the publisher may also relate PPO or plan_type to a canonical definition represented by a DefinedTermFragment.

This relationship allows the assertion to remain concise while preserving a path to the meaning of the terminology it uses.

The relationship may be understood as:

Assertion
→ Predicate or Value
→ Defined Term
→ Canonical Definition

Not every familiar value requires a separate definition. Defined-term relationships are most useful when terminology is specialized, ambiguous, publisher-defined, regulatory, or otherwise important to correct interpretation.

Assertions and Provenance

A factual assertion should preserve enough provenance to establish where the knowledge came from.

Provenance may be inherited from the containing fragment when all assertions in that fragment genuinely share the same source and lineage.

For example:

DataFragment
  source: CMS PBP
  entity: plan:H5521-290-0
  plan_year: 2026

  monthly_premium = 0 USD
  primary_care_copay = 0 USD
  specialist_copay = 35 USD

All three assertions may inherit the same provenance when they originate from the same applicable source.

If another assertion originates from a different dataset, that difference must remain explicit.

Derived assertions require additional provenance because their published values were not necessarily stated directly by the underlying source.

For derived knowledge, provenance should preserve:

the source data used;
the publisher responsible for the derivation;
the method or calculation applied;
the applicable population or input set;
and any temporal or other scope necessary to reproduce or interpret the result.

Read the Provenance specification →

Assertions and Relationships

An assertion may participate in relationships with other WebMEM knowledge objects.

For example, an assertion may relate to:

the entity it describes;
a DefinedTermFragment establishing predicate meaning;
a MetaFragment describing its source dataset;
a PolicyFragment whose rule depends on the asserted value;
an EligibilityFragment whose criteria evaluate the asserted value;
a DerivedStatsFragment that uses the assertion as an input;
or another assertion whose meaning depends on the relationship between them.

Relationships should be represented when they materially improve the machine’s ability to interpret how the assertion participates in the broader knowledge structure.

Read the Relationships specification →

Assertions and Resolution

A factual assertion may be accurate only after the correct subject or context has been resolved.

For example, suppose a plan identifier represents a parent plan with multiple geographic segments:

Plan
├── Segment A → premium = 0 USD
├── Segment B → premium = 18.50 USD
└── Segment C → premium = 32.00 USD

The question:

What is the premium for this plan?

cannot be answered safely from the parent plan identity alone when the premium varies by segment.

The correct resolution path may be:

Plan ID
→ Plan Identity
→ Geographic Context
→ Applicable Segment
→ Premium Assertion

The premium assertion itself is not wrong. The problem arises when it is applied outside the context in which it is valid.

This illustrates an important WebMEM principle:

Factual accuracy and factual applicability are different requirements.

An accurate value applied to the wrong entity, geography, time period, segment, population, or condition can produce an incorrect answer.

Read the WebMEM Resolution Model →

Assertions Are Not Presentation Labels

Human-facing pages frequently use abbreviated labels whose meaning depends on surrounding layout.

For example, a table may display:

Premium     $0
PCP         $0
Specialist  $35
MOOP        $4,900

A human reader may infer the intended meaning from the table heading, page topic, neighboring labels, and domain knowledge.

A machine-facing assertion should not depend entirely on those visual relationships.

The SDT may instead represent:

monthly_plan_premium = 0 USD
primary_care_copay = 0 USD
specialist_copay = 35 USD
maximum_out_of_pocket = 4900 USD

This does not require the human-facing page to abandon concise presentation labels.

The human and machine representations serve different communication requirements while describing the same underlying knowledge.

Assertions Are Not Keywords

An assertion is not a keyword, retrieval hint, search phrase, or list of terms intended to influence discovery.

For example:

Medicare Advantage
PPO
zero premium
best plan
Mohave County

is not a collection of factual assertions merely because the terms are machine-readable.

An assertion establishes an explicit semantic relationship:

subject: plan:H5521-290-0
predicate: plan_type
value: PPO

or:

subject: plan:H5521-290-0
predicate: monthly_plan_premium
value: 0
unit: USD
plan_year: 2026

WebMEM assertions are intended to communicate publisher knowledge, not to provide an alternate keyword surface.

Assertions Are Not Necessarily Independent Objects

An assertion must be semantically distinguishable, but it does not necessarily require its own fragment, URI, endpoint, provenance block, or independently addressable object.

For example:

DataFragment
  entity: plan:H5521-290-0
  plan_year: 2026
  source: CMS PBP

  monthly_premium = 0 USD
  primary_care_copay = 0 USD
  specialist_copay = 35 USD
  maximum_out_of_pocket = 4900 USD

contains four distinguishable factual assertions within one coherent fragment.

The fragment preserves the shared context that makes those assertions meaningful.

Making every assertion an independent fragment would duplicate that context without necessarily adding semantic value.

Semantic distinguishability does not require structural isolation.

The Smallest Useful Unit of Knowledge

WebMEM does not define the smallest possible technical unit as the preferred unit of publication.

Instead, publishers should preserve the smallest useful unit of knowledge that remains interpretable within its applicable context.

Consider:

The number is technically separable.

But the useful assertion is closer to:

subject: plan:H5521-290-0
predicate: maximum_out_of_pocket
value: 4900
unit: USD
plan_year: 2026

And even that assertion may appropriately inherit its source and other context from a containing DataFragment.

The goal is therefore not to maximize the number of independently encoded objects.

The goal is to preserve the knowledge boundary at which an assertion can be interpreted correctly without destroying the shared context that gives it meaning.

Avoiding Meaningless Atomization

Excessive atomization occurs when related knowledge is divided into such small independent objects that a consuming system must reconstruct their shared meaning.

For example, publishing each of these as unrelated fragments:

and then separately publishing:

USD
USD
USD
USD

and elsewhere publishing:

monthly premium
primary care copay
specialist copay
maximum out-of-pocket

would technically expose the components while destroying the useful relationships among them.

WebMEM instead preserves the associations necessary to interpret the assertions as coherent knowledge.

The appropriate level of structure lies between:

meaningless atomization, where context is fragmented away from the knowledge it describes; and
indiscriminate aggregation, where too many unrelated assertions are collapsed into one object whose semantic boundaries become unclear.

Fragment Classes provide the modular semantic boundaries through which WebMEM manages that balance.

Factual Assertions and Other Knowledge Structures

Not every WebMEM fragment exists to assert factual values.

The protocol preserves distinctions among different forms of knowledge.

Fragment Class	Primary Knowledge Form
`DataFragment`	Source-observed factual assertions
`DerivedStatsFragment`	Derived factual assertions
`IndexFragment`	Collection membership
`DefinedTermFragment`	Canonical definition
`FAQFragment`	Question-and-answer relationship
`MetaFragment`	Information-resource metadata
`ExplainerFragment`	Structured explanation
`DirectoryFragment`	Directory membership and entry structure
`EligibilityFragment`	Eligibility criteria and qualification logic
`ProcedureFragment`	Ordered procedural structure
`GlossaryFragment`	Vocabulary membership and semantic organization
`PersonaFragment`	Contextual human representation
`PolicyFragment`	Governing rules, conditions, and exceptions
`RecommendationFragment`	Publisher-defined recommendation and basis
`IdentityFragment`	Canonical entity identity and structural classification

Some of these structures may themselves contain factual assertions, but their primary semantic role remains defined by their Fragment Class.

This prevents the concept of “fact” from becoming a catch-all abstraction for every form of structured knowledge.

Example: From Source Data to SDT Assertion

Consider a source dataset containing a row such as:

H5521 | 290 | 0 | 2026 | PPO | $0.00 | $4,900

The source representation may depend on column headers, file documentation, codebooks, and surrounding rows for interpretation.

The publisher may normalize that source knowledge into an SDT:

<template
  data-webmem-fragment
  data-fragment-class="DataFragment"
  data-fragment-id="plan-h5521-290-0-benefits">

  <section
    data-entity-type="MedicarePlan"
    data-entity-id="plan:H5521-290-0"
    data-plan-year="2026"
    data-provenance-ref="#provenance-cms-pbp">

    <data
      data-field="plan_type"
      value="PPO">
      PPO
    </data>

    <data
      data-field="monthly_plan_premium"
      value="0"
      data-type="number"
      data-unit="USD">
      $0
    </data>

    <data
      data-field="maximum_out_of_pocket"
      value="4900"
      data-type="number"
      data-unit="USD">
      $4,900
    </data>

  </section>

</template>

The source values have not been converted into isolated Machine Fact Objects.

They have been represented as factual assertions within a DataFragment whose entity, time, provenance, and semantic role provide the context necessary to interpret them.

Example: Derived Assertion

Suppose the publisher calculates the average premium across the applicable plans in a county.

The resulting assertion might be represented within a DerivedStatsFragment:

<template
  data-webmem-fragment
  data-fragment-class="DerivedStatsFragment"
  data-fragment-id="county-ma-derived-stats">

  <section
    data-entity-type="County"
    data-entity-id="04015"
    data-plan-year="2026"
    data-provenance-ref="#provenance-cms-landscape">

    <data
      data-field="average_monthly_plan_premium"
      value="27.42"
      data-type="number"
      data-unit="USD"
      data-derived="true"
      data-method="arithmetic-mean">
      $27.42
    </data>

  </section>

</template>

The Fragment Class establishes that the assertion is derived knowledge.

The assertion identifies the resulting value and applicable method.

The fragment establishes county, plan-year, and source context.

Additional provenance may identify the exact source population and calculation process when necessary for reproducibility.

Conformance

A factual assertion represented within an SDT must:

occur within a Fragment Class whose semantic role is compatible with the assertion;
identify or inherit an identifiable subject or applicable context;
identify the predicate, property, measurement, or state being asserted;
provide a value or state appropriate to that predicate;
identify datatype or unit when necessary to interpret the value correctly;
preserve temporal, geographic, population, jurisdictional, or other applicability context when that context materially affects meaning;
identify or inherit provenance sufficient to establish the source of the assertion;
distinguish source-observed knowledge from derived knowledge when derivation materially affects the assertion’s meaning or lineage;
preserve more specific context when it differs from context inherited from the containing fragment or SDT;
and remain semantically distinguishable from neighboring assertions.

A factual assertion does not need to:

exist as an independent WebMEM fragment;
have its own URI or endpoint;
repeat context already established unambiguously by the containing fragment or SDT;
carry a separate complete provenance block when provenance can be inherited accurately;
or conform to a universal Machine Fact Object abstraction.

The governing requirement is preservation of meaning.

Relationship to WebMEM 1.x

WebMEM 1.x used the term Semantic Data Atom for field-level claims represented within fragments.

That concept captured an important insight: individual factual values must remain distinguishable within a larger semantic structure.

Earlier implementations, however, increasingly associated these atoms with independent trust scoring, glossary references, provenance references, retrieval behavior, semantic digests, and other mechanisms that risked making the individual field carry too much of the knowledge architecture itself.

The current protocol preserves the useful part of the concept while clarifying the abstraction.

An assertion is a semantic component of a fragment. The Fragment Class determines the kind of knowledge being represented, while the surrounding SDT supplies the broader identity