RSM Semantic Model & Taxonomy Architecture v4.0

#1. Purpose and Scope

#1.1 Purpose

The Regenerative Systems Model requires a common semantic language through which independently governed systems can describe entities, relationships, capabilities, observations, evidence, commitments, activities, outcomes, and other meaningful state without sharing one database or one application model. The RSM Semantic Model & Taxonomy Architecture defines that language and establishes the rules through which it may evolve.

The specification sits between the RSM Subject Model and the RSM Canonical Model. The Subject Model establishes what kinds of entities can exist and how Subject, Actor, Participant, foundational kind, domain type, and contextual role differ; this specification establishes how those concepts are named, identified, related, extended, validated, serialized, versioned, and governed.

#1.2 Design Objective

RSM must remain semantically stable at its core while supporting domains whose vocabulary will continuously expand. Agriculture, food, water, ecology, health, finance, carbon, logistics, policy, energy, and future domains cannot be encoded permanently into a closed kernel without making that kernel brittle and forcing unrelated implementations to adopt assumptions they do not need.

The semantic architecture therefore follows a deliberate design principle:

RSM is one governed semantic language with a small stable grammar and an extensible vocabulary for a living ecology.

Core semantics remain strongly governed. Domain meaning expands through Concept references, taxonomies, Domain Packs, relationships, predicates, mappings, and validation rules without creating competing RSM ontologies.

#1.3 Scope

This specification governs:

• the RSM semantic namespace;
• semantic identifiers and Concept references;
• the distinction between core grammar and domain vocabulary;
• semantic categories;
• taxonomy concepts and concept relationships;
• contextual role vocabulary;
• relationship vocabulary;
• predicates and semantic conditions;
• value, quantity, and unit semantics;
• JSON-LD representation;
• Domain Pack composition and lifecycle;
• cross-domain typing;
• external vocabulary mappings;
• semantic versioning;
• deprecation and replacement;
• structural and semantic validation;
• semantic equivalence;
• semantic governance; and
• conformance requirements for semantic artifacts.

The specification does not define persistence topology, database schemas, federation transport, protocol authorization, Outcome Formation algorithms, user experience, or application-specific reasoning. Those concerns belong to the Canonical Model, Runtime, Protocol, intelligence, and implementation specifications.

#2. Architectural Position

#2.1 RSM Semantic Layers

The semantic architecture is organized into five layers:

The Core Grammar provides stable semantic primitives. Governed vocabulary and Domain Packs provide extensible meaning, while canonical and derived objects reference those semantics without embedding every possible domain concept directly into their implementation type systems.

Applications consume the resulting Model through protocol and projection boundaries. They may render specialized terminology or views, but they SHALL NOT redefine the meaning of governed RSM terms.

#2.2 Dependency Direction

Semantic dependencies SHALL flow inward toward RSM Core. Domain Packs may depend upon Core and upon explicitly declared compatible Domain Packs, but Core SHALL NOT depend upon agriculture, food, finance, health, or any other domain vocabulary.

The dependency direction is therefore:

Application Vocabulary
        ↓
Domain Packs
        ↓
Governed RSM Vocabulary
        ↓
RSM Core Grammar

This rule prevents application convenience from altering foundational semantics. It also allows the same RSM Core implementation to operate in domains not anticipated when the kernel was designed.

#2.3 Model and Map

The canonical term is Regenerative Systems Model. A map is a projection of Model state, such as a relationship map, capability map, watershed map, material-provenance map, or Outcome Formation map.

Taxonomy terms SHALL therefore describe the Model rather than a particular visual representation. Projection-specific labels, grouping, ranking, and layout belong to application or projection semantics rather than the canonical semantic vocabulary.

#3. Semantic Separation

#3.1 Identity, Kind, Domain Type, and Role

RSM SHALL preserve the Subject Model distinction among Identity, Foundational Kind, Domain Type, and Contextual Role. These semantic layers answer different questions and SHALL NOT be collapsed into a single type attribute.

An entity may retain one identity while acquiring multiple domain types and playing different roles in different contexts. A regional cooperative, for example, may be simultaneously classified as a producer, aggregator, and processor while serving as supplier in one Formation and buyer in another.

#3.2 Semantic Category

RSM additionally defines Semantic Category, which describes the epistemic or architectural standing of an object rather than what the object is.

The principal categories are:

Semantic Category is orthogonal to foundational kind. A canonical rsm:Organization and a projection containing information about that Organization do not possess equivalent authority merely because they carry semantically similar fields.

#3.3 Category Is Not Agency

Semantic Category SHALL NOT encode agency. Agency is applicable to certain foundational kinds and contextual roles, while category describes the standing of an artifact within the architecture.

RSM therefore preserves:

Semantic Category ≠ Foundational Kind
Semantic Category ≠ Domain Type
Semantic Category ≠ Contextual Role
Semantic Category ≠ Agency

These distinctions prevent a projection from masquerading as canonical state and prevent a derived reasoning artifact from silently gaining the authority of the data from which it was computed.

#4. The RSM Semantic Namespace

#4.1 One Governed Namespace

RSM SHALL use a single governed semantic namespace for its core grammar and RSM-managed domain vocabulary. Implementations SHALL NOT create prefixes such as rsm-agriculture:, rsm-food:, or rsm-water: as independent RSM namespaces merely to introduce domain concepts.

The compact semantic prefix is:

rsm:

The exact public base IRI bound to rsm: SHALL be declared by the governed RSM JSON-LD context. Implementations SHALL consume that declaration rather than privately assigning a different expansion to the rsm: prefix.

#4.2 Core Terms

Core semantic classes and properties use stable names directly within the namespace:

rsm:Person
rsm:Organization
rsm:Community
rsm:LivingSystem
rsm:Place
rsm:Facility
rsm:Material
rsm:Instrument
rsm:DigitalAgent
rsm:Formation

rsm:Capability
rsm:Capacity
rsm:Relationship
rsm:Observation
rsm:Evidence
rsm:Outcome
rsm:domainType
rsm:category

Core classes SHOULD use PascalCase. Core properties SHOULD use lower camel case unless a future governed convention explicitly specifies otherwise.

#4.3 Domain Terms

Governed domain vocabulary SHALL be organized through hierarchical paths within the RSM namespace:

rsm:agriculture/soil-system
rsm:agriculture/grain
rsm:food/grain-lot
rsm:food/ingredient
rsm:water/watershed
rsm:health/gut-microbiome
rsm:finance/transition-loan
rsm:carbon/soil-carbon-credit
rsm:logistics/cold-storage
rsm:policy/conservation-easement

Domain vocabulary terms SHOULD use lowercase kebab-case. Path hierarchy provides namespace organization but SHALL NOT by itself be interpreted as taxonomic inheritance; broader, narrower, equivalent, and related meaning must be represented explicitly.

#4.4 Semantic Namespace Is Not Entity Identity

Vocabulary identifiers and entity identifiers SHALL remain conceptually distinct. A vocabulary IRI identifies meaning, while a canonical object IRI identifies an actual thing.

For example:

rsm:LivingSystem

identifies a foundational semantic class, while:

rsm:agriculture/soil-system

identifies a governed taxonomy concept.

A separate identity such as:

https://id.rsm.org/living-system/01KABC

may identify an actual soil system. The specific identity authority may be federated, but semantic concepts SHALL NOT be used as substitutes for instance identity.

#5. Core Grammar and Open Vocabulary

#5.1 Stable Grammar

RSM Core defines the semantic concepts whose stability is necessary for interoperability. These include foundational entity kinds, canonical distinctions, semantic categories, major evidence concepts, relationship structure, Capability and Capacity, Formation semantics, provenance primitives, lifecycle semantics, and other concepts that would cause interoperability failure if different systems interpreted them differently.

Changes to Core therefore require stricter governance than changes to domain vocabulary. A term SHALL enter Core only when its meaning is broadly applicable across RSM domains and cannot be represented adequately as an extensible Concept.

#5.2 Open-World Domain Semantics

RSM SHALL operate with open-world domain semantics. The kernel is not required to know every crop, financing instrument, testing method, ecological condition, processing method, certification, health concept, policy mechanism, or future domain category before it can preserve an entity referring to that concept.

An implementation that encounters a valid external or governed concept it does not understand may preserve the reference without inventing local meaning. Lack of local understanding SHALL NOT be converted automatically into semantic falsity.

#5.3 Governed RSM Terms and External Terms

A distinction SHALL be made between unresolved RSM vocabulary and external extension vocabulary. A compact IRI under the governed rsm: namespace claims participation in RSM vocabulary and therefore must resolve through the applicable RSM vocabulary registry or Domain Pack.

An absolute external IRI may be preserved as an extension even when the local implementation lacks its ontology. The system should distinguish at least:

KNOWN_RSM_CONCEPT
KNOWN_EXTERNAL_CONCEPT
UNRESOLVED_EXTERNAL_CONCEPT
INVALID_OR_UNAUTHORIZED_RSM_TERM

This distinction prevents typographical or unauthorized rsm: terms from being accepted merely because RSM supports an open world.

#6. Concept Architecture

#6.1 Concept

A Concept is a governed semantic term that supplies meaning without necessarily becoming a canonical identity-bearing object in operational RSM state. Concepts may classify entities, roles, relationships, values, predicates, activities, materials, capabilities, measurements, or other domain semantics.

A Concept SHOULD preserve enough metadata to be understandable and governable independently of application code. An illustrative conceptual record includes:

id: rsm:agriculture/soil-system
label: Soil System
definition: >
  A living soil ecology represented as a managed or naturally occurring
  biological system whose state and change may be observed over time.
conceptClass: domain-type
domain:
  - rsm:agriculture
status: ACTIVE
broader:
  - rsm:agriculture/living-system
introducedIn: 1.0.0
provenance:
  authority: rsm-governance

The exact canonical encoding of concept registries may evolve, but the semantic distinctions represented above SHALL remain available.

#6.2 ConceptRef

ConceptRef is the semantic mechanism by which RSM objects refer to governed or external concepts without hard-coding the complete taxonomy into programming-language enums. A ConceptRef identifies the concept; it does not copy or freeze the concept definition into every referencing object.

Implementations SHOULD resolve ConceptRefs through a Taxonomy Resolver or equivalent semantic boundary. Resolution may return definition, status, broader relationships, pack provenance, semantic version, mappings, and other metadata required by the calling context.

#6.3 Stable Concept Identity

A published concept identifier SHALL remain stable across non-breaking revisions to labels, descriptions, examples, translations, and clarifying metadata. Concept identifiers SHALL NOT be recycled after deprecation or retirement.

When meaning changes incompatibly, a new Concept identifier SHALL be introduced. The old concept should be deprecated and linked explicitly to its replacement rather than silently acquiring different semantics.

#6.4 Concept Classes

The taxonomy registry MAY distinguish concept classes such as:

domain
domain-type
role
relationship-type
activity-type
material-type
instrument-type
capability-type
observed-property
predicate-type
unit
quantity-kind
evidence-type
outcome-type
policy-concept

Concept class helps tools understand how a Concept may be used. It does not replace semantic constraints defined by Core, Domain Packs, or validation shapes.

#7. Taxonomy Structure

#7.1 Broader and Narrower Meaning

Taxonomies MAY organize Concepts through explicit broader and narrower relationships. These relationships describe conceptual generalization and specialization rather than object containment.

For example:

rsm:agriculture/grain
    broader → rsm:agriculture/crop-material

rsm:agriculture/wheat
    broader → rsm:agriculture/grain

rsm:food/grain-lot
    broader → rsm:food/material

The path portion of a compact IRI SHALL NOT substitute for these relationships. rsm:food/grain-lot belongs organizationally under the food vocabulary but becomes taxonomically narrower than another Concept only through an explicit semantic relationship.

#7.2 Related Concepts

Concepts MAY be related without implying inheritance. A soil-system concept may be related to soil-carbon, soil-health, or soil-observation concepts even when none is a broader or narrower form of another.

Related links support discovery and semantic navigation. They SHALL NOT be interpreted automatically as equivalence, substitutability, or entailment.

#7.3 Equivalent and Mapping Relationships

RSM MAY declare mappings between Concepts when different vocabularies represent sufficiently corresponding meanings. Mapping strength SHALL be explicit because exact equivalence is much stronger than broad similarity.

An implementation should be able to distinguish at least:

exact-equivalent
close-equivalent
broader-than
narrower-than
related-to

A mapping SHALL NOT cause two canonical entity identities to merge. Concept equivalence concerns vocabulary semantics, while entity resolution concerns actual things.

#7.4 Polyhierarchy

A Concept MAY have more than one broader Concept. Regenerative systems frequently cross conventional domain boundaries, and forcing each Concept into one tree would distort meaning.

For example, a soil-carbon credit may participate in both carbon and finance vocabularies through explicit classification or mappings. Polyhierarchy SHALL remain a taxonomy feature rather than requiring duplicate Concepts with artificial one-to-one boundaries.

#8. Domain Types

#8.1 Purpose

rsm:domainType specializes the meaning of an entity without replacing its foundational kind. A single foundational entity MAY reference several domain types when each describes a legitimate dimension of the entity.

For example:

{
  "@type": "rsm:Organization",
  "rsm:domainType": [
    "rsm:agriculture/producer",
    "rsm:food/aggregator",
    "rsm:food/processor"
  ]
}

The Organization remains one entity. Its domain types provide additional meaning that applications may use for discovery, reasoning, validation, and presentation.

#8.2 Domain Type Is Not Role

Domain Type describes what an entity is understood to be within a domain, while Role describes how it participates within a particular context. These meanings may resemble one another linguistically but SHALL remain distinct.

A processor Organization may act as buyer in one Formation, while a producer may act as evidence provider in a research context. Permanent identity semantics SHALL NOT be rewritten merely because contextual participation changes.

#8.3 Cross-Domain Typing

An entity MAY hold domain types from several governed domains:

{
  "@type": "rsm:Material",
  "rsm:domainType": [
    "rsm:agriculture/grain",
    "rsm:food/ingredient"
  ]
}

Cross-domain typing is expected rather than exceptional. RSM SHALL therefore avoid architectures that require every entity to have exactly one domain owner.

#9. Contextual Role Vocabulary

#9.1 Role Semantics

Role Concepts describe how an entity participates in a bounded context. Illustrative terms include:

rsm:role/actor
rsm:role/participant
rsm:role/steward
rsm:role/observer
rsm:role/evidence-provider
rsm:role/committer
rsm:role/beneficiary
rsm:role/affected-party
rsm:role/custodian
rsm:role/issuer
rsm:role/evaluator
rsm:role/representative
rsm:role/counterparty
rsm:role/resource

Role vocabulary MAY expand through governed Domain Packs. A domain-specific role SHALL not become a foundational kind merely because it is operationally important in one application.

#9.2 Role Context

A role reference SHOULD be accompanied by sufficient context to determine where and when it applies. A Person may be Steward of a Community, representative of an Organization, Participant in a Formation, and Subject of an Evaluation without those roles conflicting.

Role semantics may therefore carry contextual identity, temporal validity, provenance, and authority basis where applicable. Those dimensions belong to canonical relationship or participation state rather than to the taxonomy Concept itself.

#9.3 Role Constraints

Role Concepts MAY declare semantic applicability constraints. For example, a role may indicate which foundational kinds ordinarily can occupy it or which contexts are required for it to be meaningful.

Such constraints SHALL be interpreted as validation rules rather than as inheritance. The Concept rsm:role/observer does not make its holder a subclass of an observer entity.

#10. Relationship Semantics

#10.1 Relationship as Canonical Structure

rsm:Relationship is a canonical structure connecting two or more Subjects, while a relationship-type Concept describes what that relationship means. The canonical Relationship may carry lifecycle, provenance, validity, conditions, authority, and Biography independently of its semantic type.

An illustrative relationship may reference:

type:
    rsm:relationship/operates

subject:
    Organization A

object:
    Facility B

The relationship instance is not interchangeable with the Concept rsm:relationship/operates. One is durable model state; the other is vocabulary.

#10.2 Core Relationship Vocabulary

General relationship vocabulary may include Concepts such as:

rsm:relationship/located-at
rsm:relationship/part-of
rsm:relationship/operates
rsm:relationship/derived-from
rsm:relationship/stewards
rsm:relationship/affects
rsm:relationship/member-of
rsm:relationship/affiliated-with
rsm:relationship/issued-by

These terms SHOULD be defined only when their meaning is sufficiently domain-independent. Domain-specific relationships should remain in appropriate Domain Packs.

#10.3 Domain Relationships

Domain Packs may introduce relationships such as:

rsm:agriculture/grows-on
rsm:food/processed-by
rsm:water/drains-into
rsm:finance/financed-by

A relationship definition MAY specify allowed subject kinds, allowed object kinds, expected direction, inverse Concept, symmetry, transitivity, or other semantic constraints when those properties are truly part of the relationship's meaning.

Implementations SHALL NOT infer properties such as symmetry or transitivity merely from natural-language labels. Such behavior must be declared explicitly.

#11. Predicates and Semantic Conditions

#11.1 Predicate

A Predicate represents a versioned semantic condition that can be evaluated against an identifiable context. Predicates allow requirements and policies to be expressed in a form that is distinguishable from prose and from the Evidence used to evaluate them.

Examples include:

protein-content >= 12.5 percent
distance-to-facility <= 150 kilometers
certification-status = active
soil-organic-carbon > baseline
available-capacity >= required-capacity

The exact execution mechanism belongs to the Canonical Model and Runtime. This specification governs the semantic identity, input meaning, units, versioning, and vocabulary references required for interoperable interpretation.

#11.2 Predicate Is Not Assertion

A Predicate defines a condition. An Evaluation applies that condition in context, while an Assertion records a governed conclusion produced or adopted under identifiable authority.

RSM SHALL preserve:

Predicate ≠ Evaluation
Evaluation ≠ Assertion
Predicate ≠ Claim
Evidence ≠ Assertion

These distinctions prevent a rule from being mistaken for the result of applying the rule.

#11.3 Predicate Versioning

Predicate meaning SHALL be versioned whenever a change could alter evaluation results. Changing a threshold, operator, required property, unit interpretation, evidence requirement, or evaluation scope constitutes semantic change rather than editorial clarification.

Historical evaluations SHALL retain enough information to identify which Predicate version was applied. Current Predicate definitions SHALL NOT retroactively rewrite the meaning of historical Evaluations.

#12. Values, Quantities, and Units

#12.1 Typed Values

RSM semantic values SHOULD preserve enough type information to avoid meaning being inferred from display strings. Dates, quantities, monetary values, percentages, geometries, identifiers, confidence values, and categorical values require representations whose semantics survive serialization and federation.

A quantity SHOULD distinguish numeric value, quantity kind, and unit when those distinctions matter. The string "100" is not semantically equivalent to one hundred acres, one hundred tonnes, or one hundred dollars.

#12.2 Units

Units MAY be represented through governed RSM ConceptRefs or explicit mappings to recognized external unit vocabularies. RSM SHALL NOT require every unit in the world to be duplicated into RSM Core.

Domain Packs may constrain which units are valid for particular observed properties, capacities, or predicates. Conversion rules SHALL be explicit and deterministic when consequential evaluation depends upon them.

#12.3 Comparable Values

Two values SHALL NOT be assumed comparable merely because their primitive data types match. Semantic comparability may depend upon unit compatibility, quantity kind, temporal basis, place, measurement procedure, aggregation method, or other domain conditions.

This is especially important for Capacity, environmental measurements, financial amounts, and health or ecological observations. Semantic validation should detect incompatible comparisons before consequential reasoning proceeds.

#13. JSON-LD Representation

#13.1 Governed Context

RSM SHALL publish and govern a canonical JSON-LD context for semantic interchange. Canonical RSM projections SHALL reference that context rather than redefining governed RSM terms independently in each document.

An illustrative instance is:

{
  "@context": "https://schema.rsm.org/context/v4",
  "@id": "https://id.rsm.org/living-system/01KSOIL42",
  "@type": "rsm:LivingSystem",
  "rsm:domainType": [
    "rsm:agriculture/soil-system",
    "rsm:agriculture/managed-agroecosystem"
  ],
  "rsm:name": "Field 42 Soil System"
}

The actual governed context location and version SHALL be controlled as an RSM semantic artifact. Local implementations SHALL NOT silently redefine the meaning of established keys.

#13.2 Context Keys and Concept Values

Core properties and canonical class aliases SHOULD be declared explicitly in the governed context. Domain Concepts used as values may use compact IRIs under the declared rsm: prefix without requiring every possible domain term to become a separately declared context key.

This distinction is important for extensibility. The context governs the language used to state facts, while the taxonomy registry governs the Concepts referenced by those facts.

#13.3 Deterministic Semantic Projection

Canonical objects SHOULD be capable of producing deterministic semantic projections. Semantically identical state SHALL not acquire different meaning because of JSON member ordering, whitespace, or implementation-specific storage fields.

Projection and reconstruction SHOULD preserve semantic equivalence for all governed interchange content. Storage metadata that is intentionally outside the interchange model SHALL remain distinguishable from semantic loss.

#13.4 Expanded and Compact Forms

Implementations MAY use compact JSON-LD, expanded JSON-LD, RDF-compatible representations, or internal typed objects as appropriate. Conformance SHALL depend upon semantic equivalence rather than one particular textual representation.

A conformant round trip must preserve identifiers, types, governed properties, Concept references, values, and other normative semantic content. Serialization convenience SHALL NOT weaken canonical distinctions.

#14. Domain Pack Architecture

#14.1 Purpose

A Domain Pack is a governed, versioned package of semantic extensions for a coherent domain or cross-domain capability. Domain Packs allow RSM to grow without modifying Core whenever a new crop, health concept, instrument, relationship, observed property, predicate, or domain-specific validation rule is required.

Illustrative packs may include:

rsm-agriculture
rsm-food
rsm-water
rsm-health
rsm-finance
rsm-carbon
rsm-logistics
rsm-policy

These are package names, not independent semantic prefixes. Their concepts remain inside the governed rsm: vocabulary unless a pack explicitly references an external namespace.

#14.2 Pack Contents

A Domain Pack MAY contain:

manifest
concept definitions
taxonomy relationships
role vocabulary
relationship-type definitions
predicate definitions
observed-property definitions
quantity and unit constraints
semantic mappings
SHACL or equivalent validation shapes
examples
valid fixtures
invalid fixtures
compatibility metadata
migration metadata

A Domain Pack SHALL declare its own identity, version, governance authority, compatible RSM Core range, dependencies, and lifecycle state.

#14.3 Pack Manifest

An illustrative manifest is:

id: rsm-pack:agriculture
name: RSM Agriculture
version: 1.2.0
status: ACTIVE
requires:
  rsm-core: ">=4.0 <5.0"
dependencies:
  - rsm-pack:measurement
vocabularyRoot: rsm:agriculture
authority: rsm-domain-governance/agriculture

The physical packaging format may evolve, but equivalent metadata SHALL remain available to the Taxonomy Resolver and validation system.

#14.4 Pack Composition

Multiple Domain Packs MAY be active simultaneously. A regional food-system deployment, for example, may compose agriculture, food, water, finance, logistics, and policy packs without merging them into one monolithic domain ontology.

Pack composition SHALL be deterministic. Dependencies, compatibility constraints, and conflicts must be resolved before a vocabulary set is activated for consequential semantic processing.

#14.5 Core Precedence

A Domain Pack SHALL NOT redefine, shadow, or weaken RSM Core semantics. If a pack requires a meaning incompatible with an existing Core term, it must introduce a distinct domain Concept rather than assigning a new meaning to the Core identifier.

Likewise, one Domain Pack SHALL NOT claim ownership of a Concept identifier already governed by another active pack unless governance explicitly transfers ownership through a versioned migration.

#15. Domain Pack Examples

#15.1 Agriculture

An agriculture pack may define:

rsm:agriculture/soil-system
rsm:agriculture/crop-system
rsm:agriculture/agroecosystem
rsm:agriculture/grain
rsm:agriculture/seed-lot
rsm:agriculture/producer
rsm:agriculture/agronomy-provider
rsm:agriculture/grows-on

These Concepts specialize foundational kinds rather than creating new kernel kinds. A soil system remains rsm:LivingSystem, while grain remains rsm:Material.

#15.2 Food

A food pack may define:

rsm:food/processor
rsm:food/aggregator
rsm:food/grain-lot
rsm:food/ingredient
rsm:food/food-product
rsm:food/mill
rsm:food/cold-storage
rsm:food/processed-by

The same Organization may reference agriculture and food Concepts simultaneously. RSM SHALL not force domain boundaries onto entities whose real-world function crosses them.

#15.3 Water

A water pack may define:

rsm:water/watershed
rsm:water/aquifer
rsm:water/wetland
rsm:water/river-ecosystem
rsm:water/riparian-zone
rsm:water/water-right
rsm:water/drains-into

The Subject Model distinction between Place and LivingSystem remains applicable. A watershed used as spatial context and a watershed ecosystem used as a living ecological Subject may be represented separately and explicitly related.

#15.4 Cross-Domain Composition

Consider a regenerative wheat transition. A single Formation may involve Concepts from agriculture, food, water, finance, carbon, logistics, and policy packs while all canonical objects remain interoperable through Core.

Cross-domain composition is a primary design requirement rather than an exceptional integration case.

#16. Semantic Mappings

#16.1 External Vocabulary Alignment

RSM SHOULD reuse or map to mature external vocabularies where those vocabularies already express useful semantics. RSM does not need to duplicate every concept relating to people, organizations, observations, provenance, geography, units, or other established knowledge domains.

External alignment SHALL remain explicit. An RSM term may map to an external term without causing the external ontology to become the authoritative definition of all RSM behavior.

#16.2 Mapping Strength

Mappings SHALL express their semantic strength. Exact equivalence, close correspondence, broader meaning, narrower meaning, and general relatedness cannot safely be collapsed into one sameAs relationship.

Mappings SHOULD therefore preserve enough information for consuming systems to decide whether substitution, query expansion, transformation, or merely human navigation is appropriate.

#16.3 Mapping Provenance

Mappings SHALL carry provenance and governance metadata when they are used in consequential interoperability. A mapping introduced by an application, imported from an external source, or approved by RSM governance may have different authority.

Derived or suggested mappings MAY exist without becoming governed mappings. Promotion from a suggestion into an active semantic mapping requires an explicit governance action.

#17. Semantic Categories in Detail

#17.1 Canonical

CANONICAL objects represent authoritative durable RSM state within a defined authority boundary. Canonical does not mean universally true; it means the object has been admitted into authoritative RSM state according to the applicable identity, validation, provenance, lifecycle, authority, and policy rules.

Examples include an Organization, Relationship, Capability, Capacity, Observation, Evidence record, Commitment, Formation, Activity, Event, or Outcome once accepted canonically.

#17.2 Derived

DERIVED artifacts are computed conclusions, candidates, interpretations, or reasoning products derived from canonical or other authorized inputs. Examples may include candidate relevance, Configuration, Gap, dependency analysis, viability assessment, Pathway, recommendation, or Formation-readiness analysis.

Derived state SHALL remain distinguishable from canonical state. A Derived artifact may inform action, but computation alone SHALL NOT transform possibility into commitment or inference into authoritative fact.

#17.3 Operational

OPERATIONAL objects support runtime or application work without claiming to be independent facts about the external world. Examples may include an Outcome Context, workflow state, session, investigation context, or coordination workspace.

Operational state may persist durably because work can span long periods. Durability SHALL NOT be mistaken for canonical authority.

#17.4 Projection

PROJECTION artifacts are non-authoritative representations produced for discovery, navigation, analytics, maps, search, user experience, or performance. A network map, profile view, discovery index, cached capability view, or biography timeline may all be projections.

A projection may become stale or incomplete without changing canonical state. Consequential decisions SHOULD reconcile relevant projections with authoritative sources according to the Runtime and Federation specifications.

#18. Provenance and Semantic Lineage

#18.1 Provenance Is Required for Meaningful Change

Semantic artifacts require provenance because vocabularies evolve and because mappings, concepts, and validation rules have governance consequences. An implementation must be able to determine where a Concept, mapping, Predicate, shape, or Domain Pack originated and under whose authority it became active.

Provenance SHOULD preserve creation or publication authority, version, source, applicable Domain Pack, and replacement lineage where relevant.

#18.2 Derivation

Derived artifacts SHOULD identify the inputs, rules, models, or semantic versions sufficient to explain their derivation at an appropriate level. This requirement does not imply disclosure of private model internals; it requires enough observable lineage to identify why the artifact exists and which semantics governed its production.

A Derived artifact that depends upon a Domain Pack SHOULD identify the applicable pack version or semantic environment when future changes could alter the result.

#18.3 Semantic Environment

A Semantic Environment is the resolved set of Core version, governed context, active Domain Packs, mappings, shapes, and other semantic artifacts under which an operation is interpreted. Consequential semantic processing SHOULD be reproducible against an identifiable Semantic Environment.

Illustratively:

RSM Core:            4.0.0
JSON-LD Context:     4.0
Agriculture Pack:    1.2.0
Food Pack:           1.1.0
Water Pack:          1.0.0
Finance Pack:        1.3.0

The Semantic Environment provides a stable answer to the question, “Which meanings and rules were active when this object or decision was interpreted?”

#19. Versioning and Evolution

#19.1 Versioned Semantic Artifacts

At minimum, the following SHALL be independently versionable:

• RSM Core grammar;
• JSON-LD context;
• SHACL or equivalent core shapes;
• Domain Packs;
• Predicate definitions;
• governed mappings; and
• other semantic artifacts whose change can alter interpretation.

Versioning boundaries should reflect semantic compatibility rather than repository convenience.

#19.2 Additive Change

Adding a new domain Concept, translation, example, non-breaking mapping, or optional metadata generally constitutes additive change. Existing conformant objects should retain their prior meaning.

Additive change MAY be delivered without a major Core version when it does not alter established interpretation or validation behavior incompatibly.

#19.3 Breaking Change

A change is breaking when an object that previously had one valid interpretation receives a materially different interpretation or when established valid data becomes invalid without explicit migration. Renaming an identifier, changing a relationship's direction, changing Predicate semantics, weakening a canonical distinction, or altering a required property may therefore require a major version or a new identifier.

Breaking semantic changes SHALL include migration guidance where existing persistent state may be affected.

#19.4 Deprecation

A Concept may be deprecated when its use should cease but historical references must remain interpretable. Deprecation SHALL preserve identity and SHOULD indicate a replacement when one exists.

A deprecated identifier SHALL NOT be reused for another meaning. Historical data should continue to resolve the old Concept and understand its status.

#19.5 Retirement

Retirement indicates that a semantic artifact is no longer active for new work. Retirement SHALL not erase the artifact from historical resolution when canonical history references it.

Long-lived RSM Biography therefore requires a semantic registry capable of resolving historical versions as well as currently active ones.

#20. Semantic Validation

#20.1 Validation Layers

Semantic validation SHOULD occur in layers so that different failures remain explainable. A useful conceptual progression is:

Later layers SHALL not conceal earlier failures. Validation results should identify whether a problem is syntactic, structural, taxonomic, semantic, referential, or domain-specific.

#20.2 SHACL and Executable Shapes

RSM SHOULD maintain executable semantic shapes for constraints suitable for graph-oriented validation. Shapes provide a machine-enforceable bridge between normative prose and conformant implementation.

A shape SHALL implement an existing normative requirement rather than invent new semantics merely because the validation language can express them. Normative prose, governed schema, executable shapes, and conformance fixtures should remain traceable to one another.

#20.3 Positive and Negative Fixtures

Every consequential semantic invariant SHOULD have both valid and invalid reference fixtures where practical. Negative fixtures are especially important because a model that demonstrates only successful examples does not prove that it rejects semantic collapse.

Examples include verifying that:

Capability cannot masquerade as Capacity
Configuration cannot masquerade as Formation
Claim cannot masquerade as Evidence
Evidence cannot masquerade as Assertion
Subject cannot be assumed to be Actor
Projection cannot become Canonical by serialization
Domain Type cannot replace Foundational Kind
unknown rsm: terms cannot silently enter governed vocabulary

Conformance requires preservation of distinctions, not merely the ability to serialize objects with different labels.

#21. Semantic Equivalence and Round Trip

#21.1 Semantic Equivalence

Two representations are semantically equivalent when they preserve the same governed meaning even if textual formatting, JSON ordering, storage metadata, or representation mechanics differ. Semantic equivalence SHALL be evaluated against the interchange contract rather than byte-for-byte serialization unless a particular digest mechanism explicitly requires canonical byte representation.

This distinction permits implementations in different languages and storage systems while preserving interoperable meaning.

#21.2 Projection and Reconstruction

Where canonical objects support semantic projection and reconstruction, the following property SHOULD hold:

Canonical Object
    → Semantic Projection
    → Reconstruction
    → Semantic Projection

= semantically equivalent projection

Failure of semantic round trip indicates that the projection has either lost governed meaning or introduced meaning not present in the canonical object.

#21.3 Storage Metadata

Revision numbers, internal timestamps, physical row identifiers, cache state, and other implementation metadata need not belong to semantic interchange unless the relevant specification makes them normative. Their exclusion SHALL be explicit so that absence is not confused with accidental semantic loss.

#22. Taxonomy Resolution

#22.1 Taxonomy Resolver

Implementations SHOULD access vocabulary through a TaxonomyResolver or equivalent abstraction rather than scattering hard-coded domain tables throughout application code. The Resolver provides a stable boundary for concept lookup, pack activation, version selection, mapping resolution, and status inspection.

A resolver may answer questions such as:

Does this Concept exist?
Which Domain Pack owns it?
Is it ACTIVE or DEPRECATED?
What is its definition?
What Concepts are broader or narrower?
Which foundational kinds may it classify?
What mappings does it have?
Which semantic version introduced it?

The resolver is a semantic service boundary, not necessarily a network service. An implementation may satisfy it from embedded governed artifacts, a local registry, or a federated semantic registry.

#22.2 Resolution Failure

Failure to resolve a governed rsm: Concept SHALL not be interpreted as if the Concept were false or absent in the world. The correct condition is that semantic meaning could not be resolved under the active Semantic Environment.

Consequential processing SHOULD distinguish UNRESOLVED from negative semantic conclusions. This principle mirrors the broader RSM rule that unavailable authoritative state must not be converted into false state.

#23. Governance

#23.1 Core Governance

RSM Core requires centralized semantic stewardship even when operational RSM is federated. Without governed definitions for foundational concepts, federation would produce syntactically compatible messages carrying incompatible meanings.

Core governance therefore owns foundational term definitions, namespace policy, context releases, semantic-category rules, Core shapes, and compatibility guarantees.

#23.2 Domain Governance

Domain Packs SHOULD have identifiable stewardship appropriate to their knowledge domain. Domain governance may include subject-matter experts, implementers, community representatives, standards specialists, or other authorities appropriate to the semantics being governed.

Domain stewards may propose and maintain domain Concepts without receiving authority to redefine Core. This separation allows decentralized expertise without semantic fragmentation.

#23.3 Concept Lifecycle

Governed concepts SHOULD support a lifecycle such as:

PROPOSED
    ↓
ACTIVE
    ↓
DEPRECATED
    ↓
RETIRED

A PROPOSED Concept may be used experimentally but SHALL not be represented as fully governed RSM vocabulary. ACTIVE Concepts are available for conformant use, while DEPRECATED and RETIRED Concepts remain resolvable for history according to governance policy.

#23.4 Promotion

Application-local or AI-proposed vocabulary MAY be promoted into governed vocabulary through explicit review. Usage frequency, model confidence, or widespread duplication SHALL not by themselves constitute semantic authority.

Promotion should establish definition, identifier, concept class, provenance, applicable domain, relationships, mappings, validation implications, lifecycle status, and ownership.

#24. Semantic Extension Boundaries

#24.1 Application Extensions

Applications MAY define local or external concepts when RSM vocabulary does not yet contain the required meaning. Such concepts SHALL use a namespace controlled by the extension authority rather than inventing unauthorized terms under rsm:.

For example:

acme:proprietary-quality-grade

may coexist with RSM vocabulary. It SHALL not be published as rsm:food/proprietary-quality-grade until accepted into governed RSM vocabulary.

#24.2 No Silent Promotion

An application-local concept SHALL not become an RSM Concept merely because multiple applications use it. Promotion is a governance transition, not a popularity threshold.

The same principle applies to AI-generated taxonomy suggestions. Machine intelligence may discover candidate concepts, synonyms, relationships, or mappings, but governed vocabulary changes require an explicit acceptance boundary.

#24.3 Lossless Preservation

A conformant RSM intermediary SHOULD preserve valid extension IRIs it does not understand where policy permits. It SHALL not replace them with invented RSM terms or discard them merely because local application code lacks a corresponding enum.

This property is essential to open-world interoperability.

#25. Semantic Invariants

#25.1 Core Invariants

The semantic architecture SHALL preserve the Subject Model and Core distinctions:

Person ≠ Organization
Organization ≠ Community
Organization ≠ Facility
LivingSystem ≠ Place
Material ≠ Facility
Instrument ≠ Organization
DigitalAgent ≠ Person
Formation ≠ Relationship

Related entities may be connected explicitly. Semantic convenience SHALL not erase their foundational differences.

#25.2 Role and Agency Invariants

RSM SHALL preserve:

Subject ≠ Actor
Subject ≠ Participant
Participant ≠ Organization
Membership ≠ Authority
Affiliation ≠ Authority
Agency ≠ Authority
Capability ≠ Authority
DigitalAgent ≠ Principal by default

Taxonomies or Domain Packs SHALL not weaken these distinctions through alternative labels.

#25.3 Epistemic Invariants

RSM SHALL preserve:

Observation ≠ Claim
Claim ≠ Evidence
Evidence ≠ Assertion
Predicate ≠ Evaluation
Evaluation ≠ Assertion
Intent ≠ Outcome
Activity ≠ Outcome
Biography ≠ Current State

These distinctions allow RSM to represent uncertainty, evidence, reasoning, and consequence without converting one epistemic state into another.

#25.4 Category Invariants

RSM SHALL preserve:

Canonical ≠ Derived
Canonical ≠ Operational
Canonical ≠ Projection
Derived ≠ Commitment
Projection ≠ Authority
Recommendation ≠ Commitment
Configuration ≠ Formation

No serialization format, API response, database table, or user interface SHALL erase these boundaries.

#25.5 Vocabulary Invariants

RSM SHALL preserve:

Domain Type ≠ Foundational Kind
Facet ≠ Identity
Concept ≠ Entity Instance
Vocabulary IRI ≠ Entity IRI
Taxonomy Path ≠ Taxonomic Inheritance
External Mapping ≠ Entity Equivalence
Domain Pack ≠ Second RSM Ontology

These invariants form the minimum semantic discipline required for RSM interoperability.

#26. Illustrative Integrated Example

#26.1 Subjects and Types

Consider a regenerative grain transition involving a farm organization, field ecosystem, soil laboratory, mill, buyer, lender, watershed, and grain lot.

The semantic environment may classify them as:

Green Valley Farm
    @type rsm:Organization
    domainType rsm:agriculture/producer

Field 42 Soil
    @type rsm:LivingSystem
    domainType rsm:agriculture/soil-system

Valley Analytics
    @type rsm:Organization
    domainType rsm:agriculture/soil-testing-provider

Regional Mill
    @type rsm:Facility
    domainType rsm:food/mill

2027 Wheat Lot
    @type rsm:Material
    domainType rsm:agriculture/grain
    domainType rsm:food/ingredient

Transition Loan
    @type rsm:Instrument
    domainType rsm:finance/transition-loan

Foundational kinds remain stable while Domain Packs supply the specific vocabulary required by the scenario.

#26.2 Relationships

The ecology may contain relationships typed as:

Green Valley Farm
    rsm:relationship/operates
        Farm Facility

Field 42 Soil
    rsm:relationship/located-at
        Field 42 Place

2027 Wheat Lot
    rsm:relationship/derived-from
        Harvested Wheat Material

Regional Mill
    rsm:food/processes
        2027 Wheat Lot

Transition Loan
    rsm:finance/finances
        Transition Formation

The relationship instances carry their own identity and lifecycle where required. The relationship-type Concepts provide semantic meaning without becoming the relationship instances themselves.

#26.3 Observation

A laboratory may record:

Actor:
    Valley Analytics

Operation:
    OBSERVE

Subject:
    Field 42 Soil

Observed Property:
    rsm:agriculture/soil-organic-carbon

Value:
    2.7

Unit:
    rsm:unit/percent

The observed-property and unit references derive from the active Semantic Environment. The Observation itself remains a canonical object governed by the Canonical Model.

#26.4 Cross-Domain Outcome

A later Outcome may affect several Subjects:

Outcome:
    Improved transition performance

Affected Subjects:
    Field 42 Soil
    Green Valley Farm
    Mill Creek Watershed

Outcome Types:
    rsm:agriculture/soil-function-improvement
    rsm:finance/farm-economic-viability
    rsm:water/nutrient-loss-reduction

RSM does not collapse these effects into one universal score. Domain vocabulary provides the semantic distinctions needed to reason about each consequence independently.

#27. Executable Semantic Artifacts

#27.1 Required Artifact Family

The normative prose in this specification should be realized through a small governed family of executable artifacts. At minimum, the architecture anticipates:

docs/schema/
    rsm.context-v4.jsonld
    rsm-core-v4.ttl
    rsm.shacl-v4.ttl

docs/vocabulary/
    core/
    agriculture/
    food/
    water/
    health/
    finance/
    carbon/
    logistics/
    policy/

domain-packs/
    <pack>/manifest.yaml
    <pack>/concepts.*
    <pack>/relationships.*
    <pack>/predicates.*
    <pack>/shapes.*
    <pack>/mappings.*
    <pack>/fixtures/

conformance/
    semantic/
        valid/
        invalid/
        roundtrip/
        taxonomy/
        domain-packs/

Physical repository organization may differ, but equivalent governance and executable boundaries SHALL remain identifiable.

#27.2 Context

The JSON-LD context governs compact semantic expression and RSM terms. It SHALL be versioned, reviewable, and testable.

Changes to the context that alter meaning or expansion behavior require compatibility analysis because they can affect every semantic projection.

#27.3 Core Vocabulary

The Core vocabulary artifact contains the stable concepts and relationships required by RSM itself. Domain-specific concepts SHALL remain outside Core unless promoted through formal Core governance.

This keeps the kernel small while preserving a coherent semantic backbone.

#27.4 Validation Shapes

Executable shapes provide machine-verifiable constraints corresponding to normative semantic rules. Shapes SHOULD cite or otherwise trace to the normative requirement they implement so that automated validation does not evolve into an undocumented second specification.

#27.5 Conformance Fixtures

Reference fixtures SHALL include both accepted and rejected examples. They should test namespace rules, Concept resolution, domain typing, role constraints, semantic categories, relationship semantics, pack composition, deprecated concepts, extension preservation, and round-trip equivalence.

The fixtures serve as executable examples of the semantic contract.

#28. Conformance

#28.1 Semantic Conformance

An implementation conforms to this specification when it can preserve and interpret RSM Core semantics, resolve applicable governed Concepts, distinguish semantic categories, maintain the separation of foundational kind from domain type and contextual role, and exchange semantic projections without loss of governed meaning.

Conformance does not require every implementation to understand every Domain Pack. It requires implementations to preserve unknown permitted extensions correctly and to reject or mark unresolved unauthorized RSM vocabulary appropriately.

#28.2 Domain Pack Conformance

A system claiming conformance to a Domain Pack SHALL activate a compatible pack version and satisfy the pack's normative semantic constraints. Merely recognizing the pack's vocabulary labels is insufficient if required relationships, values, predicates, or validation rules are ignored.

Systems MAY declare conformance to different pack sets. Federation should expose enough Semantic Environment information to determine whether two systems share the meanings required for a particular interaction.

#28.3 Round-Trip Conformance

A conformant semantic codec SHOULD demonstrate projection and reconstruction without semantic loss. Golden fixtures should verify semantic equivalence across serialization boundaries and ensure that implementation-specific storage fields do not silently become interchange semantics.

Round-trip tests also protect against accidental creation of a second ontology inside application DTOs or persistence schemas.

#28.4 Governance Conformance

A system SHALL NOT publish unauthorized new terms under the governed rsm: namespace and still claim semantic conformance. Local extensions must remain visibly local until governed promotion occurs.

This rule is essential because interoperability depends less upon shared syntax than upon shared meaning.

#29. Architectural Boundaries

#29.1 Relationship to the Subject Model

The Subject Model owns foundational kinds, Subject semantics, agency boundaries, and the distinction among Identity, Kind, Domain Type, and Role. This specification operationalizes those distinctions through identifiers, vocabulary, taxonomies, Domain Packs, role concepts, and validation.

The Semantic Model SHALL not redefine the Subject Model's foundational kinds through taxonomy shortcuts.

#29.2 Relationship to the Canonical Model

The Canonical Model owns durable canonical object semantics, lifecycle, canonical envelopes, Capability, Capacity, relationships, Evidence, Commitment, Formation, Activity, Event, Outcome, Biography, and protocol-visible authoritative state. This specification defines the semantic language referenced by those objects.

Taxonomy Concepts SHALL not become canonical objects merely because implementations store them in the same database.

#29.3 Relationship to Runtime and Federation

The Runtime owns persistence, identity resolution, policy, authority evaluation, events, projections, federation, reconciliation, semantic artifact loading, and operational availability. This specification defines what semantic artifacts mean and what invariants the Runtime must preserve.

A Taxonomy Resolver is therefore a runtime capability implementing a semantic contract defined here.

#29.4 Relationship to Intelligence Systems

Systems such as Wellzai may use RSM vocabulary to discover candidates, classify meaning, construct Configurations, identify gaps, evaluate viability, develop Pathways, or recommend actions. Such systems MAY derive new semantic hypotheses but SHALL not redefine governed RSM vocabulary or promote their conclusions to canonical truth without the appropriate acceptance boundary.

Intelligence consumes semantics; it does not own them.

#30. Final Architecture Principle

#30.1 One Language, Many Domains

RSM must represent a world whose diversity is effectively unbounded while keeping its common grammar stable enough for durable interoperability. It achieves this not by constructing one enormous closed ontology, but by separating foundational semantics from governed, composable domain vocabulary.

The resulting architecture can be summarized as:

RSM Core
    stable grammar

        +

RSM Governed Vocabulary
    common semantic concepts

        +

Domain Packs
    extensible domain meaning

        +

Canonical Identity
    actual things in the world

        +

Contextual Roles and Relationships
    how those things participate

        +

Semantic Categories
    what authority their representations carry

        =

Regenerative Systems Model
    one interoperable semantic ecology

#30.2 Small in Ontology, Rich in Meaning

The RSM kernel should remain small because stability is valuable at the center. The semantic ecology can remain rich because Concepts, Relationships, Predicates, mappings, Domain Packs, and contextual roles allow meaning to grow without destabilizing the foundation.

This architecture preserves the central principle established by the RSM Subject Model: what something is, what it means in a domain, how it participates, and what authority a representation carries are different questions. Maintaining those distinctions is what allows a regenerative system to remain both computationally precise and open to domains, relationships, and forms of knowledge that have not yet been anticipated.

#30.3 Semantic Foundation for the Infrastructure

The RSM Semantic Model & Taxonomy Architecture establishes the language on which the remainder of the infrastructure depends. The Canonical Model can now define authoritative state without embedding domain taxonomies, the Runtime can resolve and validate meaning without owning that meaning, Domain Packs can evolve without fragmenting the Model, and applications can build specialized experiences without inventing private versions of RSM.

The architectural objective is therefore not merely semantic consistency. It is to create a governed semantic substrate through which independent systems can become mutually intelligible, preserve the distinctions necessary for trust, and participate in a living regenerative ecology without surrendering either their autonomy or the richness of their domain.