Skip to main content

GEARM 0.1 - Generic Enterprise Analytics Reference Model

AttributeValue
SpecificationGeneric Enterprise Analytics Reference Model
AcronymGEARM
Version0.1
StatusNormative Draft / Executable Release Candidate
Specification TypeSemantic Reference Model
ScopeEnterprise Analytics and Analytical Information
Primary Companion ArchitectureGeneric Enterprise Analytics Reference Architecture (GEARA)
Data Semantic FoundationGEDRM 0.1
Product Semantic FoundationBPS / PIN and applicable Product-family specifications
AI Product Semantic AuthorityAIPS
Normative Semantic AuthorityThis human-readable GEARM specification

Specification Status​

GEARM 0.1 establishes the initial conceptual and semantic baseline for the Generic Enterprise Analytics Reference Model. It defines the semantic scope of enterprise analytics, ecosystem boundaries and semantic authority, the Core Concept Model, analytical semantic concepts, Analytics and Information Formation, Consumption/Decision/Outcome semantics, Analytical Provenance, the seven-domain Reference Model, normative Semantic Invariants, and extension/conformance philosophy.

The GEARM 0.1 machine-readable artifact programme is now closed through GEARM-A15 as GEARM-0.1-RC1, an Executable Release Candidate. GEARM-A1 through GEARM-A14 provide the canonical semantic registries, invariant catalogue, conservative RDF/OWL and SHACL formalization, JSON-LD and JSON Schema representations, governed Profile schema, examples, positive and negative testcases, automated conformance runner, cross-artifact reconciliation, and governed regression baseline. GEARM-A15 freezes the release subject through a manifest and checksum inventory and requires the live A12-A14 gates to pass before the candidate is considered closed. Promotion from Executable Release Candidate to Released remains a separate governed publication decision.

GEARM provides the semantic foundation for GEARA.

Publication note: GEARM is published within the BPS specification ecosystem but defines an independent semantic reference model for enterprise analytics. BPS remains the semantic authority for generic Product concepts referenced by GEARM.

Machine-Readable Artifact Downloads​

The human-readable GEARM specification remains the normative semantic authority. Machine-readable artifacts implement and index that authority; they do not redefine it.

M1 - Purpose and Scope

1.1 Purpose​

GEARM defines a generic, technology-independent semantic reference model for enterprise analytics and analytical information.

GEARM establishes the canonical concepts, distinctions, relationships, and semantic structures through which Information Needs are expressed; Analytical Intent and Analytical Use Cases are defined; governed analytical semantics and inputs participate in Analytics; Analytical Outputs and Information are formed; Information Propositions are established; analytical Information is consumed; Recommendations, Decisions, Actions, Outcomes, and Feedback may occur; and Analytical Lineage and Analytical Provenance connect these relationships.

Governing principle: GEARM defines what exists in the enterprise analytics domain, what those concepts mean, and how they relate; GEARA defines how architectural responsibility for those concepts is organized.

Diagram

1.2 Analytics​

Analytics is the governed application of analytical capabilities and methods to Data, Information, Intelligence, or other governed inputs in order to derive, evaluate, interpret, synthesize, monitor, explain, compare, predict, simulate, or otherwise form Information.

Analytics is a capability and activity domain. Analytics is not a Product Family and SHALL NOT be treated as synonymous with Information, Data, Artificial Intelligence, reporting, dashboarding, Data Product, Information Product, AI Product, or decisioning.

1.3 Subject and Scope​

GEARM begins conceptually with an Information Need rather than with a technology, dashboard, dataset, or platform.

A representative conceptual progression is:

Information Need
  -> Analytical Intent
  -> Analytical Use Case
  -> Analytical Semantics + Governed Analytical Inputs
  -> Analytics
  -> Analytical Output
  -> Information
  -> Consumption
  -> Recommendation / Decision
  -> Action
  -> Outcome
  -> Feedback

This progression is explanatory, not mandatory. GEARM is graph-shaped and SHALL NOT imply a mandatory workflow.

GEARM covers Information Need, Analytical Intent, Analytical Use Case, Analytical Semantics, Governed Analytical Inputs, Analytics and Information Formation, Consumption, Recommendation/Decision/Action relationships, Outcome/Feedback/Value, and Analytical Provenance/Lineage.

1.4 Product Boundary​

GEARM does not define generic Product semantics. BPS and applicable Product-family specifications remain authoritative for Product, Product Family, Product Kind, Product Identity, Product Intrinsic Nature, Product Promise, Product Owner, Product Lifecycle, Product Port, and Product Version.

GEARM MAY reference Data Product, AI Product, and Information Product. It MAY define relationships such as consume, invoke, depend on, contribute to, or may-be-productized-as, but SHALL NOT infer Product status from analytical processing, persistence, reuse, publication, discoverability, or consumption.

GEARM owns the analytical concepts Information and Information Proposition. Information Product remains governed by applicable BPS/PIN-derived Information Product semantics.

Information Proposition may be productized as Information Product
Information Proposition != Information Product

1.5 Data, AI and Decision Boundaries​

GEARM SHALL reference generic enterprise data semantics owned by GEDRM and SHALL NOT silently redefine them.

AI Products MAY participate in Analytics, but GEARM SHALL NOT redefine AI Product intrinsic semantics governed by AIPS. Use of an AI Product does not make an Analytical Process, Output, or downstream Information Product an AI Product.

GEARM models Recommendation, Decision, Decision Actor, Action, and Outcome only to the depth required to describe analytical use and consequence.

Analytical Output != Recommendation
Recommendation != Decision
Decision != Action
Action != Outcome

1.6 Independence Principles​

GEARM is actor-neutral, technology-independent, organization-independent, execution-mode-independent, and method-independent.

Human and machine actors MAY occupy equivalent semantic roles where governance permits, but semantic role equivalence does not imply equivalent legal, policy, or accountability treatment.

Batch, streaming, event-driven, interactive, scheduled, continuous, exploratory, or simulated execution MAY realize the same semantics. Arithmetic, rules, statistics, optimization, simulation, AI, human judgement, or combinations MAY realize Analytics without changing output identity merely because the method differs.

1.7 Analytics and Productization​

Analytics does not inherently imply Productization. Analytical Information MAY remain transient, contextual, operational, interactive, or embedded in another process for its entire lifecycle.

Analytics != Productization
Analytical Output != Product
Repeated Consumption != Productization

1.8 Provenance and Value​

GEARM defines Analytical Provenance as the governed account of origins, dependencies, semantics, logic, versions, actors, Processes, Products, consumption relationships, Decisions, Actions, Outcomes, and other evidence relevant to analytical Information.

Analytical Lineage is the derivation/dependency subset of Analytical Provenance.

Analytical Lineage subset-of Analytical Provenance

GEARM recognizes Analytical Value but preserves:

Usage != Value
Availability != Value
Analytical Output != Outcome

1.9 Out of Scope​

GEARM does not define universal Product grammar, Product Intrinsic Nature, Data/AI/Information Product intrinsic semantics, enterprise data architecture, enterprise analytics architecture, platform architecture, organization structure, delivery methodology, domain-specific decision policy, UI/visualization standards, project lifecycle, or vendor-specific capability semantics.

1.10 Relationship to GEARA​

GEARM is the primary semantic foundation for GEARA. GEARA SHALL reference GEARM concepts rather than silently redefine them. If GEARA discovers a missing semantic concept, it SHOULD be evaluated for GEARM before being introduced as an architectural semantic invention.

1.11 M1 Locks​

  1. GEARM is a semantic reference model, not an architecture.
  2. Analytics is a capability/activity domain, not a Product Family.
  3. Information Need is the conceptual starting point.
  4. GEARM is graph-shaped, not a mandatory pipeline.
  5. Product semantics remain owned by BPS and Product-family specializations.
  6. GEARM references but does not redefine Data Product, AI Product, or Information Product.
  7. Analytics and Productization are independent concepts.
  8. Decision/Action semantics are bounded to analytical use and consequence.
  9. Analytical Provenance and Lineage are GEARM semantic concepts; provenance continuity is a GEARA architecture concern.
  10. GEARM -> GEARA is the analytics-side semantic-to-architecture relationship analogous to GEDRM -> GEDRA.

M2 - Ecosystem and Semantic Authority

2.1 Semantic Authority​

Semantic Authority is the recognized authority responsible for establishing canonical meaning, identity, distinctions, and relationships of a concept within a defined specification scope.

Semantic Authority does not imply instance ownership, operational ownership, data authority, Product ownership, architecture authority, implementation ownership, or technology ownership.

Semantic Authority != Instance Ownership
Semantic Authority != Authoritative Source
Semantic Authority != Source of Authority
Semantic Authority != System of Record
Semantic Authority != Architecture Authority

2.2 Canonical Ecosystem​

                        BPS
               Generic Product Semantics
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
   Data Product      AI Product    Information Product
    semantics          AIPS          semantics
          |              |              |
          +--------------+--------------+
                         |
             +-----------+-----------+
             |                       |
             v                       v
           GEDRM                   GEARM
     Enterprise Data          Enterprise Analytics
      Semantic Model           Semantic Model
             |                       |
             v                       v
           GEDRA                   GEARA
     Data Architecture       Analytics Architecture
             \                       /
              +----------+----------+
                         |
                        HDIP
                 optional profile /
                   realization

This diagram expresses semantic and architectural relationships, not a strict inheritance hierarchy.

2.3 Authority Boundaries​

BPS is authoritative for generic Product semantics. GEDRM is authoritative for generic enterprise data semantics. Applicable Data Product specifications own Data Product intrinsic semantics. AIPS owns AI Product intrinsic semantics. Applicable BPS/PIN-derived Information Product specialization owns Information Product intrinsic semantics. GEARM owns generic enterprise analytics semantics. GEARA owns downstream analytics architecture semantics. HDIP MAY profile or realize GEARM/GEARA but does not become their generic semantic authority by implementation.

GEARM SHALL preserve BPS composition non-inheritance:

uses Data Product != is Data Product
invokes AI Product != is AI Product
uses Information Product != is Information Product
uses Analytics != creates an Analytics Product family

2.4 Domain and Local Semantics​

Business domains MAY specialize or contextualize GEARM concepts, introduce domain-specific classifications, and introduce additional relationships, but SHALL NOT redefine canonical GEARM concepts incompatibly while claiming equivalence.

Local terminology MAY be mapped using equivalentTo, specializes, broaderThan, narrowerThan, or relatedTo. Label similarity SHALL NOT establish equivalence.

equivalentTo != specializes
specialization != instance

2.5 Definition, Instance and Observation​

GEARM SHALL distinguish type refinement from runtime manifestation.

Credit Risk Indicator -> specialization of Indicator
Client A Deterioration at 09:00 -> observation/occurrence
Metric Definition != Metric Observation
Threshold Definition != Threshold Evaluation
Classification Definition != Classification Result

2.6 Specification Relationship Vocabulary​

GEARM recognizes semanticFoundationOf, references, specializes, profiles, mapsTo, and extends. inheritsFrom SHOULD NOT be used where reference, specialization, or profile is more accurate.

2.7 Semantic Authority Matrix​

Concept / concernCanonical semantic authority
Product / Product Family / PIN / Product PromiseBPS
Data / Data Asset / generic data authority conceptsGEDRM
Data Product intrinsic semanticsApplicable Data Product specification
AI ProductAIPS
Information ProductBPS/PIN-derived Information Product specialization
Information NeedGEARM
Analytical Intent / Analytical Use CaseGEARM
Analytics / Analytics CapabilityGEARM
Analytical Process / Analytical Logic / Analytical OutputGEARM
Information within analytics scope / Information PropositionGEARM
Measure / Metric / Indicator / KRI semanticsGEARM, subject to domain specialization
Analytical Lineage / Analytical ProvenanceGEARM
Provenance Continuity architectureGEARA
Analytical Self-Service architectureGEARA
HDIP-specific realization conceptsHDIP
Domain-specific analytical semanticsApplicable domain semantic authority

2.8 Boundary Concepts and Conflict Resolution​

Information, Consumer, Decision, Action, Outcome, and Feedback are boundary concepts whose meaning extends beyond Analytics. GEARM defines only the meaning required for consistent use within its scope.

Where specifications appear to conflict, the conflict SHALL NOT be silently resolved. The implementation SHOULD identify scopes and authorities, determine whether concepts are equivalent, specializations, contextual variants, or genuinely different, and record explicit mappings.

2.9 Implementation, Storage and Registry Do Not Establish Meaning​

Implementation prevalence, vendor terminology, storage location, or registry storage SHALL NOT independently establish Semantic Authority. A registry MAY store, expose, version, or resolve definitions while preserving reference to the authority that governs meaning.

2.10 Semantic Change, Version and Provenance​

Changes to canonical semantics SHOULD be governed by their Semantic Authority. Downstream consumers MAY request changes but SHALL NOT silently redefine upstream concepts while claiming equivalence.

Analytical Provenance SHOULD preserve semantic identity, semantic version, governing authority, and effective period where relevant.

Downstream experience MAY reveal semantic gaps and feed explicit evolution, but downstream implementation SHALL NOT silently redefine upstream semantics.

2.11 M2 Principles​

  • M2-PR01 A concept SHOULD have identifiable canonical Semantic Authority within scope.
  • M2-PR02 Specifications SHOULD reference rather than redefine concepts governed elsewhere.
  • M2-PR03 Semantic Authority SHALL remain distinct from ownership and implementation authority.
  • M2-PR04 Composition/use SHALL NOT transfer ontology.
  • M2-PR05 Local/external concepts SHOULD use explicit mappings.
  • M2-PR06 Similar labels SHALL NOT establish equivalence.
  • M2-PR07 Specialization MAY narrow but SHALL NOT contradict upstream meaning.
  • M2-PR08 Technology, storage location, prevalence, or platform ownership SHALL NOT establish meaning.
  • M2-PR09 Analytical use SHOULD reference the applicable governed semantic version.
  • M2-PR10 Semantic evolution SHALL occur through explicit governance.

M3 - Core Concept Model

3.1 Purpose​

The Core Concept Model defines the principal semantic entities in enterprise analytics and their relationships. It distinguishes need from intent, definition from occurrence, capability from process, Process from Execution, Output type from Output Occurrence, Information from Product, Consumer from Decision Actor, Decision from Action, Outcome from Feedback, and Lineage from broader Provenance.

Governing principle: GEARM models both what analytical concepts mean and the governed instances or occurrences through which those concepts are observed, executed, produced, consumed, and evolved.

3.2 Core Categories​

GEARM groups concepts into:

  1. Need and Intent - Information Need, Analytical Intent, Analytical Use Case.
  2. Analytical Semantics - Analytical Semantic Definition, Measure, Metric, Indicator, Threshold, Population, Classification, and related definitions.
  3. Governed Inputs and Dependencies - Governed Analytical Input and referenced Products/assets/resources.
  4. Analytics and Execution - Analytics Capability, Analytical Method, Analytical Process, Analytical Logic, Analytical Execution.
  5. Output and Information - Analytical Output Definition, Analytical Output Occurrence, Information, Information Proposition.
  6. Consumption and Consequence - Consumer, Recommendation, Decision, Action, Outcome, Feedback.
  7. Value and Evaluation - Analytical Value and fitness/effectiveness evidence.
  8. Provenance and Lineage - Analytical Lineage and Analytical Provenance.

These are semantic groupings, not architecture planes, applications, platform modules, teams, or processing stages.

3.3 Definition and Occurrence​

GEARM SHALL distinguish governed definitions from runtime manifestations.

Measure Definition != Measure Observation
Metric Definition != Metric Observation
Indicator Definition != Indicator Observation
Threshold Definition != Threshold Evaluation
Classification Definition != Classification Result
Analytical Process != Analytical Execution
Analytical Output Definition != Analytical Output Occurrence

A reusable governed Definition SHOULD possess stable identity and version where required for reuse or provenance. Runtime occurrences SHOULD reference the applicable Definition version rather than merely current state.

3.4 Information Need, Analytical Intent and Analytical Use Case​

An Information Need is a legitimate requirement for Information that enables understanding, monitoring, evaluation, comparison, prediction, explanation, decision, or action.

Analytical Intent expresses the analytical outcome intended to address one or more Information Needs without determining technology, Product status, UI, or topology.

An Analytical Use Case is a governed application of analytical semantics, capabilities, inputs, Logic, and Outputs intended to address one or more Information Needs. It MAY identify intent, semantics, inputs, Processes, expected Outputs, Consumers, and provenance obligations. It is not inherently a Product.

3.5 Analytical Semantic Definition​

An Analytical Semantic Definition is a governed definition establishing meaning required to perform, interpret, or consume Analytics consistently. It includes Measure, Metric, Indicator, KPI/KRI designation, Threshold, Population, Cohort, Dimension, Classification, temporal, and other analytical definitions.

A Semantic Definition establishes meaning; executable or Analytical Logic realizes or evaluates that meaning.

Semantic Definition != Executable Logic

3.6 Governed Analytical Input and Dependency​

A Governed Analytical Input is a contextual role played by an existing governed resource intentionally used by an Analytical Process or Use Case. It MAY be a Data Product, Information Product, AI Product, Data Asset, external Information, reference Information, Semantic Definition, rule, or upstream Analytical Output.

Being used as an input does not change intrinsic identity.

An Analytical Dependency is a governed relationship in which an analytical element relies on another entity. Dependency MAY be Product, semantic, Logic, rule, model, temporal, reference-information, or upstream analytical dependency.

dependsOn != IS-A

3.7 Analytics Capability, Analytical Method, Process, Logic and Execution​

An Analytics Capability is an ability to perform a defined class of analytical work.

An Analytical Method is a governed approach or technique used to realize analytical work.

An Analytical Process is a governed definition describing how capabilities, methods, inputs, Semantic Definitions, Logic, and dependencies are composed to produce Outputs.

Analytical Logic is governed logic applied within a Process.

An Analytical Execution is a concrete runtime execution of an Analytical Process and MAY record Process version, input versions, semantic versions, rules, thresholds, AI Product versions, parameters, time, and Outputs.

Analytics Capability != Analytical Method
Analytical Process != Analytical Logic
Analytical Process != Analytical Execution

3.8 Analytical Output Definition and Occurrence​

An Analytical Output Definition describes a type or class of result an Analytical Process may produce.

An Analytical Output Occurrence is a concrete result produced by an Analytical Execution and SHOULD reference its Output Definition where one exists.

Analytical Output is the umbrella semantic category and MAY be used where Definition/Occurrence distinction is immaterial.

3.9 Information and Information Proposition​

Within GEARM, Information is meaningful content formed by placing Data, observations, evidence, or other inputs into a context enabling interpretation or use. Information MAY be formed through Analytics, observation, curation, human interpretation, governed rules, AI capability, synthesis, or combinations thereof.

An Information Proposition is a defined proposition describing informational value intended for a Consumer. It MAY arise from Outputs, combine Information, remain contextual/non-productized, or be intentionally productized.

Analytical Output != Information Proposition
Information Proposition != Information Product

3.10 Consumer, Recommendation, Decision, Action, Outcome and Feedback​

A Consumer is an actor, Product, service, application, or other entity that intentionally uses Information, an Output, or a Product exposing informational value. Consumer is a semantic role.

A Consumption Event is a concrete occurrence of consumption.

A Recommendation is Information proposing or suggesting a possible course of action.

A Decision is a governed selection or determination concerning a state, treatment, response, or course of action. A Decision Actor is authorized to make or materially participate in a Decision. A Decision Event is a concrete occurrence.

An Action is an intervention, execution, workflow initiation, communication, or other response. An Action Actor performs or initiates an Action. An Action Event is a concrete occurrence.

An Outcome is a result or consequence associated with analytical or downstream activity. An Outcome Observation is concrete evidence concerning an Outcome.

Feedback is Information derived from use, observations, Decisions, Actions, Outcomes, or other evidence and used to assess or evolve analytical elements.

3.11 Analytical Value​

Analytical Value is beneficial effect associated with formation or use of analytical Information. It MAY include understanding, awareness, earlier detection, decision support, improved action, avoided loss, risk reduction, efficiency, financial benefit, customer benefit, or regulatory effectiveness.

Usage alone SHALL NOT establish Value.

3.12 Analytical Subject, Population, Context and Time​

An Analytical Subject is the entity, population, event, Process, Product, relationship, or phenomenon about which analytical Information is formed. Domain ontologies MAY define subject types.

A Population is a governed set or class of Analytical Subjects to which an analytical definition, Use Case, Process, or Output applies.

Analytical Context is Information relevant to interpretation, such as subject, Population, time, jurisdiction, domain, purpose, Consumer, or environment.

GEARM recognizes multiple time dimensions including Observation Time, Processing Time, Effective Time, Publication Time, Consumption Time, Decision Time, Action Time, and Outcome Observation Time.

3.13 Core Relationship Families​

GEARM recognizes relationship families including:

  • Motivation: motivates, addresses, satisfies;
  • Semantic: definedBy, usesSemantics, specializes, classifiedAs, appliesTo;
  • Dependency: dependsOn, consumes, invokes, references, composedFrom;
  • Analytical: realizesCapability, usesLogic, executes, produces, evaluates, derivedFrom, forms;
  • Product Boundary: expresses, mayBeProductizedAs, exposedBy, consumedThrough;
  • Consumption: consumedBy, usedBy, receivedBy;
  • Decision: informs, recommends, decidedBy, authorizes, resultsIn;
  • Outcome/Feedback: producesOutcome, observedBy, generatesFeedback, evolves;
  • Provenance: tracesTo, derivedFrom, generatedBy, associatedWith, versionOf.

GEARM-A2 formalizes the canonical machine-readable predicate names for the relationship vocabulary recognized here and for specification, mapping, Definition/Occurrence, provenance, and evolution relationships defined elsewhere in GEARM 0.1. The human-readable GEARM specification remains the normative semantic authority.

3.14 Definition Graph and Execution Graph​

The Definition Graph describes governed design-time relationships among Information Needs, Use Cases, Semantic Definitions, Product dependencies, Processes, Logic, Output Definitions, and Information Propositions.

The Execution Graph describes runtime relationships among concrete input versions, Executions, Output Occurrences, Consumption Events, Decision Events, Action Events, Outcome Observations, and Feedback occurrences.

The Execution Graph SHOULD reference applicable Definition Graph elements.

3.15 State, Event, Observation and Inference​

GEARM distinguishes State - a condition regarded as holding over an interval - from Event - an occurrence at a point or interval in time.

GEARM SHOULD distinguish direct Observation from analytically formed Inference where materially relevant.

State != Event
Observation != Inference

3.16 Graph Semantics and Cardinality​

The Core Concept Model is graph-shaped. Relationships MAY branch, converge, recurse, be reused, and be many-to-many. One Process MAY have many Executions; one Execution MAY produce many Outputs; an Output MAY become an input to downstream Analytics.

Contextual role SHALL NOT redefine intrinsic identity. Productization MAY occur at the Information Proposition boundary, but its lifecycle remains governed by Product semantics.

3.17 M3 Principles​

  • M3-PR01 Definition and occurrence SHALL remain distinguishable where material.
  • M3-PR02 Reusable governed definitions SHOULD have stable identity and version.
  • M3-PR03 Contextual role SHALL NOT change intrinsic semantic nature.
  • M3-PR04 Analytical Process and Analytical Execution SHALL remain distinct.
  • M3-PR05 Output semantics SHALL remain distinguishable from individual occurrences.
  • M3-PR06 GEARM SHALL permit graph-shaped many-to-many semantics.
  • M3-PR07 Context MAY affect interpretation without necessarily changing intrinsic identity.
  • M3-PR08 Product status SHALL NOT be inferred from Analytical Output.
  • M3-PR09 Observation and Inference SHOULD remain distinguishable where material.
  • M3-PR10 Provenance SHOULD connect runtime occurrences to governed definitions and versions.

M4 - Analytical Semantics Model

4.1 Purpose​

The Analytical Semantics Model defines governed analytical meaning independently of implementation.

Governing principle: Analytical meaning SHALL be governed independently of the technology or executable logic used to realize it.

4.2 Analytical Semantic Definition and Signature​

An Analytical Semantic Definition is a governed definition establishing meaning required to perform or interpret Analytics consistently. It SHOULD have stable identity where reused, governed, versioned, or used in provenance.

An Analytical Semantic Signature is the set of characteristics required to preserve intended meaning. Depending on the concept, this MAY include subject, property, Population, Dimension, unit, value domain, aggregation, grain, temporal window, observation semantics, evaluation condition, classification semantics, and context.

A technical implementation may change without changing semantic signature. A material signature change MAY be a semantic-definition change even where implementation remains technically compatible.

4.3 Measure​

A Measure represents governed quantification of a property or phenomenon.

A Measure Definition specifies what is quantified and, where applicable, subject, property, unit, scale, aggregation semantics, and temporal context.

A Measure Observation is a concrete value corresponding to a Measure Definition.

4.4 Metric​

A Metric is a governed quantitative analytical construct defined for a particular analytical purpose. It MAY derive from Measures, other Metrics, events, states, governed Data, or other inputs.

A Metric Definition establishes meaning. A Metric Observation is a concrete value for a subject, Population, and temporal context.

Measure != Metric
Metric Observation != numeric value alone

4.5 Indicator​

An Indicator is a governed analytical construct intended to indicate a condition, state, change, tendency, or other analytically relevant characteristic. It MAY be quantitative, ordinal, categorical, Boolean, state-based, or composite and MAY be informed by Measures, Metrics, Scores, Classifications, events, other Indicators, or combined evidence.

Metric != Indicator

A Metric MAY provide evidence for an Indicator and MAY also be intentionally governed as an Indicator where that interpretation is explicit.

4.6 Performance Indicator, Risk Indicator, KPI and KRI​

A Performance Indicator indicates performance relative to an objective, expectation, or operational condition. A Risk Indicator indicates risk exposure, emerging risk, risk condition, or material risk-related change.

A KPI is a Performance Indicator explicitly designated as Key within a governance context. A KRI is a Risk Indicator explicitly designated as Key within a governance context.

KPI IS-A Indicator
KRI IS-A Indicator
Indicator != KPI/KRI designation

"Key" status is contextual governance designation and SHOULD identify its applicable objective, risk taxonomy, domain, portfolio, Product, jurisdiction, regulatory framework, organizational scope, or effective period as relevant.

4.7 Analytical Condition and Threshold​

An Analytical Condition is a governed predicate or evaluative condition applied to analytical evidence. A Condition Evaluation records a concrete result.

A Threshold is an Analytical Condition based on governed boundaries, ranges, bands, or comparative conditions. It MAY be scalar, range-based, multi-band, relative, dynamic, temporal, multi-dimensional, or context-dependent.

A Threshold Set is a governed collection of related Threshold Definitions and SHOULD have independent identity/version where changes materially affect behaviour.

Threshold IS-A Analytical Condition
Threshold Definition != Threshold Evaluation
Threshold != Alert
Threshold != Decision Policy

4.8 Analytical Rule​

An Analytical Rule describes how analytical evidence, conditions, or states relate to an analytical result. It MAY combine conditions, derive state, classify evidence, promote a condition to Signal, combine Indicators, or determine severity.

Analytical Rule Definition != Executable Analytical Logic
Analytical Rule != Business Decision Rule

4.9 Population and Cohort​

A Population is a governed set/class of Analytical Subjects to which a definition, Use Case, Process, or interpretation applies. A Population Definition specifies membership criteria. A concrete set at a point or interval MAY be represented as a Population Snapshot.

A Cohort is a Population whose members share qualifying characteristics relevant to an analytical purpose.

Population Definition != Population Snapshot
Cohort IS-A Population

4.10 Dimension and Classification​

A Dimension is a governed analytical axis used to characterize, group, partition, compare, filter, or aggregate subjects/observations. A Dimension Member is a governed value/category belonging to a Dimension.

A Classification is governed assignment of an entity or result to one or more defined Classes. A Classification Result is a concrete assignment.

Population != Dimension
Dimension != Classification
Classification Definition != Classification Result
Classification != Indicator

4.11 Score​

A Score is a quantitative or ordinal analytical assessment expressed on a defined scale. A Score Definition SHOULD establish subject, scale, value domain, directionality, meaning, Population, and interpretation constraints.

Score != Probability
Score != Classification
Score != Metric

A value between 0 and 1 SHALL NOT be treated as probability unless its governed definition establishes probabilistic meaning.

4.12 Signal and Alert​

A Signal is analytical Information indicating a potentially relevant condition, state, event, change, or tendency that may warrant attention, further evaluation, or downstream processing.

An Alert is governed Information or notification indicating that a condition warrants awareness, review, escalation, or response by an intended Consumer.

A Signal MAY arise from Threshold Evaluation, Indicator Observation, Classification Result, Score, anomaly detection, AI Product output, event correlation, Analytical Rule, or combined evidence. Several Signals MAY contribute to one Alert, and an Alert MAY also be generated directly from another condition.

Indicator != Signal
Source Event != Signal
Signal != Alert
Alert != Decision
Alert != Action

Delivery mechanism SHALL NOT determine Alert identity.

4.13 Severity and Analytical State​

Severity is a governed characterization of materiality, urgency, or significance associated with an analytical condition, Signal, Alert, or Assessment.

An Analytical State is a governed characterization regarded as holding for an Analytical Subject over an interval or until superseded.

State != Signal

4.14 Grain, Temporal Window, Baseline, Unit and Scale​

Analytical Grain identifies the semantic level at which an observation applies.

A Temporal Window defines the interval/selection semantics over which evidence is observed, aggregated, compared, or evaluated.

A Baseline is governed reference Information used for comparison and MAY be historical, peer-based, target-based, model-based, policy-defined, or dynamically calculated.

Unit is the quantity standard in which a value is expressed; Scale is the governed value space or ordering used for interpretation.

4.15 Normalization and Composite Indicator​

Normalization places values onto a governed comparable scale or basis and SHOULD preserve provenance to source values and normalization definition.

A Composite Indicator is an Indicator formed from multiple governed inputs, potentially including Measures, Metrics, Indicators, Scores, Classifications, Signals, and AI Product outputs. Composite status does not make it an Information Product.

4.16 Semantic Composition, Reuse, Versioning and Effective Time​

GEARM does not require a fixed Measure -> Metric -> Indicator -> Threshold -> Signal -> Alert sequence. Direct and alternative compositions are valid.

Authoritative definitions SHOULD be reused or explicitly specialized rather than silently duplicated.

Definitions SHOULD be versioned where change affects meaning, interpretation, calculation, Population, temporal semantics, thresholds, classes, scale, compatibility, or historical reproducibility. Implementation versions MAY evolve independently where semantics remain unchanged.

Definitions or designations MAY have Effective Time. Historical results SHOULD be interpreted using applicable historical semantics rather than current-state definitions.

4.17 Analytical Semantics Anti-Patterns​

GEARM SHOULD avoid semantically equivalent Metric proliferation without mapping, dashboard/report implementations becoming semantic authority through storage location, treating Threshold as Risk Appetite or Risk Policy, treating presentation colour as semantic state, and assuming KPI/KRI designation is universally Key across every context.

4.18 M4 Principles​

  • M4-PR01 Governed meaning SHOULD be explicit and technology-independent.
  • M4-PR02 Definitions SHALL remain distinguishable from runtime observations/evaluations.
  • M4-PR03 Measure and Metric SHALL remain distinct.
  • M4-PR04 Indicator SHALL remain distinct from Metric.
  • M4-PR05 KPI/KRI Key status SHALL be contextual governance designation.
  • M4-PR06 Threshold/Condition SHALL remain distinct from evaluation result.
  • M4-PR07 Analytical Rules, Thresholds, Signals, and Alerts SHALL NOT be treated as Business Decisions or Decision Policies merely because they contribute to them.
  • M4-PR08 Population, Cohort, Dimension, and Classification SHALL remain distinguishable.
  • M4-PR09 Historical results SHOULD remain traceable to applicable semantic versions.
  • M4-PR10 Presentation, delivery, storage, and tooling SHALL NOT determine canonical analytical meaning.
  • M4-PR11 Analytical semantic concepts MAY be composed in multiple valid graph patterns.
  • M4-PR12 Existing governed definitions SHOULD be reused or explicitly specialized.

M5 - Analytics and Information Formation Model

5.1 Purpose​

M5 defines how governed inputs, Semantic Definitions, Analytics Capabilities, Analytical Methods, Analytical Logic, and Execution combine to form Analytical Outputs and Information.

Governing principle: Analytics applies governed capabilities and methods to governed inputs in order to derive, evaluate, interpret, synthesize, predict, detect, simulate, explain, or otherwise form Information.

5.2 Analytics Capability and Analytical Method​

An Analytics Capability is an ability to perform a defined class of analytical work independently of particular implementation or Execution.

An Analytical Method is a governed approach or technique used to realize analytical work, including arithmetic, deterministic calculation, statistics, regression, clustering, optimization, rule evaluation, probabilistic reasoning, machine learning, simulation, human expert assessment, or combinations.

Analytics Capability != Analytical Method
Analytics != AI
Analytical Method != AI Product
uses AI Product != becomes AI Product

5.3 Analytical Process, Logic and Execution​

An Analytical Process is a governed definition describing how capabilities, methods, inputs, semantics, Logic, and dependencies are composed to produce Outputs.

Analytical Logic is governed executable/interpretable logic used within a Process and MAY include formulas, aggregations, filters, joins, scoring, feature derivation, temporal logic, rule composition, threshold logic, statistical procedures, or model invocation.

An Analytical Execution is a concrete runtime execution of a Process.

Analytical Process != Analytical Logic
Analytical Process != Analytical Execution
Analytical Logic != Analytical Semantic Definition

GEARM recognizes deterministic and non-deterministic Processes. Provenance SHOULD capture material execution context needed to interpret or reproduce non-deterministic results.

5.4 Analytical Output and Result Groupings​

An Analytical Output is a result produced through Analytics. Persistence or reuse does not make it a Product.

GEARM recognizes semantic result groupings:

  • Observational/Derived: Measure, Metric, Derived Value;
  • Evaluative: Indicator, Score, Classification, Assessment, Analytical State;
  • Detection: Anomaly, Signal, Alert;
  • Predictive/Prospective: Prediction, Forecast, Scenario;
  • Interpretive: Insight, Explanation;
  • Action-Oriented Information: Recommendation.

These groupings need not become strict ontology subclass trees.

5.5 Observation, Derivation, Inference and Evaluation​

An Observation is Information recorded or determined concerning a subject or phenomenon.

A Derivation forms an Output from governed inputs through defined Logic/Process and does not automatically imply inference.

An Inference is Information formed through analytical reasoning from evidence rather than direct observation.

Evaluation assesses evidence against governed criteria, semantics, rules, conditions, thresholds, objectives, or reference states and MAY produce Condition Evaluation, Indicator Observation, Classification Result, Score, Assessment, or Analytical State.

Observation != Inference
Derivation != Inference
Evaluation != Decision

5.6 Assessment, Classification and Scoring​

An Assessment is analytical interpretation of evidence against defined context, criteria, or objective and MAY combine observations, Metrics, Indicators, Scores, Classifications, Signals, AI Outputs, rules, and expert judgement.

Assessment != Decision

Classification and scoring MAY be performed through rules, statistical methods, AI Products, or human judgement. Method SHALL NOT alter semantic result identity.

5.7 Detection and Anomaly​

Detection identifies analytically relevant conditions, patterns, events, states, anomalies, or changes.

An Anomaly is an Output indicating material inconsistency with an expected, normal, reference, or learned condition. Anomaly does not automatically imply risk, error, fraud, Alert, or adverse Outcome.

Anomaly != Signal

5.8 Prediction, Forecast, Probability and Uncertainty​

A Prediction estimates an unknown or future condition from evidence. It is not an observed fact.

A Forecast is a Prediction whose primary purpose is estimating a future state, quantity, trajectory, or series over a future horizon.

Forecast IS-A Prediction
Not every Prediction is a Forecast
Prediction != Observation

A Probability is a quantitative representation of uncertainty under a governed probabilistic interpretation. Confidence scores and other uncertainty qualifiers SHALL have governed semantics and SHALL NOT be assumed equivalent to Probability.

5.9 Simulation and Scenario​

Simulation generates possible states, behaviours, or Outcomes under defined assumptions/conditions.

A Scenario is a governed representation of a possible, hypothetical, assumed, or stressed situation used for analytical exploration/evaluation.

Scenario != Forecast
Simulation Result != Observed Outcome

5.10 Trend, Comparison, Aggregation, Association and Causal Inference​

A Trend describes directional or patterned change over time or another ordered domain.

Comparison evaluates one governed value/state/subject/Population relative to another or a baseline/target/peer/benchmark.

Aggregation combines observations under governed grouping/aggregation semantics.

An Association describes a relationship or statistical dependency. Correlation MAY characterize Association but:

Correlation != Causation

Causal Inference is analytical reasoning intended to estimate or establish causal relationships under explicit assumptions and methodology. GEARM recognizes it but does not define a complete causal-inference ontology.

5.11 Synthesis, Interpretation, Insight and Explanation​

Synthesis forms higher-order Information by combining governed evidence or Information, including Metrics, Indicators, Scores, Classifications, Predictions, Signals, Information Products, AI Product outputs, domain context, and expert judgement.

Interpretation assigns governed contextual meaning to evidence or analytical results.

An Insight is interpreted Information intended to improve understanding.

An Explanation describes relevant reasons, evidence, factors, relationships, or derivation concerning a result. Explanation MAY be derivational, evidential, comparative, model-based, semantic, or contextual.

Insight != Recommendation
Explanation != Provenance
Reason Code != Explanation

5.12 Recommendation and Prescriptive Analytics​

A Recommendation proposes or suggests a possible course of action.

Prescriptive Analytics is Analytics whose intended outcome includes Information concerning possible, preferred, constrained, or recommended actions.

Prescriptive Analytics != Decision Authority
Recommendation != Decision

5.13 Analytical Archetypes​

GEARM recognizes multi-valued archetypes including Descriptive, Diagnostic, Monitoring, Comparative, Predictive, Detection, Exploratory, and Prescriptive Analytics. One Use Case MAY combine several archetypes.

Analytical Archetype != Product Family

5.14 Information Formation​

Information Formation is the semantic process through which governed evidence, Outputs, context, interpretation, or synthesis become meaningful Information.

Formation MAY involve Contextualization, Derivation, Evaluation, Inference, Interpretation, Synthesis, or human curation.

GEARM recognizes formation characteristics:

  • Contextualized Information - formed through context;
  • Derived Information - formed through transformation/calculation/aggregation/comparison;
  • Evaluated Information - formed by assessment against governed criteria/conditions/thresholds/rules;
  • Synthesized Information - higher-order Information combining multiple governed inputs/results/interpretations.

These MAY inform future Information Product intrinsic classification but:

Information Formation Type != Product Family

5.15 Information Proposition and Direct Consumption​

An Information Proposition is a defined statement of informational value intended for a Consumer. It MAY combine one or many Outputs, existing Information, curated knowledge, and external Information.

An Output MAY also be consumed directly without becoming an Information Proposition or Product where context does not require those abstractions.

Analytical Output != Information Proposition
Information Proposition != Information Product

5.16 Intermediate and Terminal Outputs​

An Intermediate Analytical Output is primarily intended for downstream analytical processing. A Terminal Analytical Output is intended for consumption without further analytical transformation within the current Use Case.

These are contextual statuses and do not establish Product identity.

5.17 Human Judgement, AI Outputs and Analytical Evidence​

Human analytical judgement MAY interpret evidence, classify ambiguous conditions, synthesize Outputs, assess context, or provide explanation. It remains distinct from Decision.

Where AI materially produces an Output, the Output SHOULD be classified by what it represents, such as Prediction, Classification, Explanation, or Recommendation, rather than by a generic "AI Output" label.

Analytical Evidence is governed Data, Information, Output, observation, or other material used to support Inference, Evaluation, Interpretation, Assessment, Recommendation, or Decision. Evidence is a contextual role.

Analytical Judgement != Decision
Evidence != Provenance

5.18 Epistemic Character and Analytical Quality​

Analytical Information SHOULD preserve epistemic character where material, including Observed, Derived, Inferred, Predicted, Simulated, Assessed, or Recommended.

Analytical Quality concerns fitness of analytical Information for intended use and MAY include semantic correctness, methodological fitness, reproducibility, timeliness, completeness, consistency, uncertainty, stability, and explainability.

Data Quality != Analytical Quality

5.19 Lifecycle Separation​

An Output MAY be transient, persisted, distributed, reused, consumed, archived, or superseded. These lifecycle characteristics do not establish Product status.

Persistence != Productization
Reuse != Productization
Distribution != Productization

5.20 M5 Principles​

  • M5-PR01 Capability and Method SHALL remain distinct.
  • M5-PR02 Process and Execution SHALL remain distinct.
  • M5-PR03 Outputs SHOULD be classified by what they mean, not by the technology/method that produced them.
  • M5-PR04 Observation and Inference SHOULD remain distinguishable where material.
  • M5-PR05 Predicted or simulated Information SHALL NOT be represented as direct observation.
  • M5-PR06 Assessments, Insights, Signals, Alerts, Predictions, and Recommendations SHALL NOT automatically be Decisions.
  • M5-PR07 Method changes SHALL NOT alone change output semantic identity.
  • M5-PR08 Analytics MAY form Information, but not all Information requires Analytics.
  • M5-PR09 Information Formation SHALL remain distinct from Productization.
  • M5-PR10 Consequential Outputs SHOULD retain formation provenance.
  • M5-PR11 Analytical Quality is broader than upstream Data Quality.
  • M5-PR12 GEARM SHALL permit compositional, chained, branching, and reused Analytics without a mandatory pipeline.

M6 - Consumption, Decision and Outcome Model

6.1 Purpose​

M6 defines downstream use and consequence of analytical Information and preserves explicit separation among Consumption, Recommendation, Decision, Action, Outcome, Feedback, and Value.

Governing principle: Analytical Information may inform a Decision, but Information, Recommendation, Decision, Action, and Outcome remain distinct semantic concepts.

6.2 Consumer, Consumption and Consumption Event​

A Consumer is an actor, Product, application, service, or other governed entity that intentionally uses Information, an Analytical Output, or a Product exposing informational value.

Consumption is governed use, receipt, access, interpretation, or processing of Information by a Consumer and MAY occur through direct access, query, subscription, notification, event stream, API, interactive experience, agent interface, or embedded machine processing.

A Consumption Event is a concrete occurrence of Consumption.

Consumer != Decision Actor
Consumer != Consumption Event
Consumption != Decision
Consumption != Action
Consumption != Value

Consumption does not by itself establish that Information was understood, influenced a Decision, caused Action, or created Value.

6.3 Recommendation and Recommendation Actor​

A Recommendation is Information proposing or suggesting one or more possible courses of action.

A Recommendation Actor is an actor or capability that produces, endorses, or presents a Recommendation. It MAY be human, Analytical Process, AI Product, agent, service, or hybrid arrangement.

A Recommendation Occurrence is a concrete Recommendation generated for a subject and context and MAY subsequently be accepted, rejected, modified, deferred, superseded, or ignored.

Recommendation Actor != Decision Actor
Recommendation != Decision

6.4 Decision and Decision Actor​

A Decision is a governed selection, determination, or commitment concerning a state, treatment, response, or course of action.

A Decision Actor is an actor authorized to make, approve, or materially participate in a Decision.

A Decision Event is a concrete occurrence of a Decision. Where reusable decision semantics are modeled, GEARM MAY distinguish Decision Definition from Decision Event.

Technical capability to execute a decision SHALL NOT itself establish Decision Actor authority.

6.5 Decision Policy, Rationale and Confidence​

A Decision Policy is a governed policy constraining, guiding, or authorizing Decisions. GEARM recognizes Decision Policy only to the depth needed to model analytical use.

A Decision Rationale is Information describing why a Decision was made and MAY reference evidence, Recommendations, policy, human judgement, exceptions, or context.

Decision confidence/uncertainty may qualify a Decision or its evidence but does not establish authority.

Decision Policy != Analytical Rule
Decision Policy != Threshold
Decision Rationale != Analytical Provenance
Decision Confidence != Decision Authority

6.6 Action and Action Actor​

An Action is an intervention, execution, workflow initiation, communication, escalation, state change, or other response associated with a Decision, Recommendation, analytical condition, or authorized automation.

An Action Actor performs, initiates, or carries out an Action. An Action Event is a concrete occurrence.

Decision != Action
Decision Actor != Action Actor

A Decision does not necessarily result in an Action. An Action MAY occur under pre-authorized authority without a new Decision Event for every execution.

6.7 Automation, Autonomy and Delegation​

Automated Action does not necessarily imply autonomous Decision authority.

Automation != Autonomy
Technical Capability != Governed Authority

An actor MAY receive delegated authority to perform Decision or Action roles. Delegation SHOULD identify granting authority, role, scope, constraints, effective period, and escalation conditions where applicable. Delegated execution SHALL NOT automatically imply transfer of ultimate accountability.

6.8 Outcome and Outcome Observation​

An Outcome is a result, consequence, or observed effect associated with an Analytical Use Case, Recommendation, Decision, Action, Product, or related activity.

An Outcome Observation is concrete evidence concerning an Outcome and MAY identify subject, Observation Time, observer, source, state/value, and related analytical/downstream events.

Outcome Observation does not itself prove causal attribution.

6.9 Outcome Attribution and Causality​

Outcome Attribution is a governed relationship associating an Outcome with one or more preceding Decisions, Actions, Products, or analytical interventions. Attribution MAY be direct, contributory, probabilistic, inferred, or unknown.

GEARM SHALL distinguish traceability, association, attribution, and causality.

Traceability != Causality
Association != Causality
Temporal Order != Causality
Attribution != Proven Causality

6.10 Feedback​

Feedback is Information derived from consumption, Decisions, Actions, Outcomes, observations, or other evidence and used to assess or evolve an analytical element.

Feedback MAY concern effectiveness, failure, false positive, false negative, usefulness, semantic mismatch, threshold miscalibration, model drift, operational friction, or unexpected consequence.

Outcome != Feedback
Feedback != Change Authority

Feedback MAY motivate evolution but does not itself authorize change.

6.11 Analytical Value​

Analytical Value is beneficial effect associated with formation, consumption, or use of analytical Information and MAY include improved understanding, earlier detection, better decision support, avoided loss, reduced risk, customer outcome, efficiency, regulatory effectiveness, or financial benefit.

Value MAY arise without formal Decision or Action.

Usage != Value
Consumption != Value
Outcome != Value
Decision != Value
Action != Value

Value SHOULD be supported by appropriate evidence where formally assessed.

6.12 Counterfactual Value and Outcome Horizon​

Some Value can only be estimated by comparing observed Outcomes with an alternative state in which the analytical intervention did not occur. Counterfactual analysis, control groups, historical baselines, causal inference, or simulation MAY be required.

Estimated counterfactual Value SHALL remain distinguishable from directly observed Outcomes.

GEARM distinguishes Output Time, Consumption Time, Decision Time, Action Time, and Outcome Observation Time. Outcome assessment SHOULD respect the relevant Outcome Horizon.

6.13 False Positive / False Negative Feedback​

Where appropriate, analytical feedback MAY classify results as True Positive, False Positive, True Negative, or False Negative relative to a governed predicted/detected condition, reference truth or observed Outcome, and observation window.

6.14 Human/Machine Participation and Decision Intelligence Boundary​

The same semantic roles MAY be performed by human or machine actors where governance permits; equivalent role capability does not imply equivalent legal, policy, ethical, or accountability treatment.

GEARM distinguishes:

  1. Analytics - forms governed analytical Information;
  2. Decision Intelligence - combines analytical Information with context, policy, constraints, reasoning, and other evidence to support or structure Decisions;
  3. Action - executes or initiates response.

GEARM models the interface among these areas but does not define a complete universal Decision Intelligence ontology in 0.1.

6.15 Decision Support, Decision Automation, Option Set and Optimization​

Decision Support aids an authorized Decision Actor. Decision Automation makes Decisions automatically within delegated authority. Both MAY use the same Information and remain different operating patterns.

An Option Set identifies possible courses of action. A Recommendation MAY select, rank, or prefer options.

An Optimization Result identifies solutions according to governed objectives/constraints and MAY be an Option Set, ranked set, Recommendation, or optimized plan. Optimization Result SHALL NOT automatically be treated as a Decision.

6.16 Decision Override and Quality Boundaries​

A Decision Override occurs where an authorized Decision Actor intentionally departs from an automated, recommended, or default result. Overrides MAY provide Feedback.

Recommendation acceptance does not prove analytical correctness.

Recommendation Acceptance != Analytical Accuracy
Analytical Quality != Decision Quality
Decision Quality != Action Quality

6.17 Recursive Learning​

Outcome evaluation MAY itself create a new Analytical Use Case.

Analytical Use Case
  -> Information
  -> Decision
  -> Action
  -> Outcome
  -> Outcome Observation
  -> Feedback / new Information Need / evolved Use Case

6.18 Downstream Provenance​

Where relevant, Analytical Provenance MAY record what Information was consumed, by whom, when, through which Product/Port, and for what governed purpose; Recommendations and their disposition; Decision Events and evidence; Action Events and authority; and Outcome Observations and attribution claims.

Capture SHOULD remain proportionate to privacy, security, policy, and materiality.

6.19 M6 Principles​

  • M6-PR01 Consumption SHALL remain distinct from Decision, Action, Outcome, and Value.
  • M6-PR02 Recommendation SHALL remain distinct from Decision and SHALL NOT imply Decision authority.
  • M6-PR03 Decision Actor status SHALL depend on governed authority rather than technical capability.
  • M6-PR04 Decision and Action SHALL remain distinct even where implemented in one system.
  • M6-PR05 Consumer, Recommendation Actor, Decision Actor, and Action Actor MAY be fulfilled by one entity but remain distinct roles.
  • M6-PR06 Outcome SHALL remain distinct from Action, Outcome Observation, Feedback, and Value.
  • M6-PR07 Traceability, association, temporal order, and attribution SHALL NOT automatically be treated as causal proof.
  • M6-PR08 Feedback is learning Information, not change authority.
  • M6-PR09 Value SHOULD be supported by evidence and SHALL NOT be inferred solely from usage or deployment.
  • M6-PR10 Human and machine actors MAY perform equivalent semantic roles where governance permits.
  • M6-PR11 Automation SHALL remain distinguishable from autonomous Decision authority.
  • M6-PR12 Outcomes and Feedback MAY create new Information Needs and Use Cases.

M7 - Analytical Provenance Model

7.1 Purpose​

M7 defines Analytical Provenance and Analytical Lineage and how analytical Information may remain traceable across definitions, inputs, Products, Processes, Logic, Methods, Executions, Outputs, Information Formation, consumption, Recommendations, Decisions, Actions, Outcomes, Feedback, and evolution.

Governing principle: Analytical Provenance provides governed traceability across the formation, use, and consequence of analytical Information; Analytical Lineage represents the derivation-oriented subset of that Provenance.

7.2 Analytical Lineage​

Analytical Lineage is the traceable set of derivation and dependency relationships through which an Analytical Output is formed. It MAY identify governed inputs and versions, Semantic Definitions and versions, Logic, Process/version, Execution, AI Product dependencies, rules, thresholds, intermediate Outputs, and final Outputs.

Analytical Lineage primarily answers: From what, and through what governed analytical derivation, was this result formed?

7.3 Analytical Provenance​

Analytical Provenance is the broader governed account of origin, identity, semantics, dependencies, Logic, Methods, versions, Executions, actors, Products, consumption relationships, Decisions, Actions, Outcomes, Feedback, and other evidence relevant to analytical Information.

Analytical Lineage subset-of Analytical Provenance
Analytical Lineage != Analytical Provenance

7.4 Provenance Scope​

GEARM recognizes Local Analytical Lineage, Product Provenance, Consumption Provenance, Decision Provenance, Action Provenance, Outcome Provenance, and End-to-End Analytical Provenance.

These are scopes, not maturity rankings.

Complete local Lineage does not automatically establish End-to-End Provenance.

A system SHALL NOT claim end-to-end analytical provenance merely because its local analytical lineage is complete.

7.5 Provenance Continuity and Boundary Preservation​

GEARM defines semantic relationships required to connect upstream Data/Product Provenance, GEARM Analytical Provenance, and downstream Decision/Action/Outcome Provenance. GEARA later defines architectural responsibility for preserving this continuity.

GEARM SHALL NOT redefine upstream Data, Data Product, AI Product, or Information Product provenance merely because it participates in Analytics.

Provenance Continuity != Provenance Re-Ownership

7.6 Provenance Graph, Definition Provenance and Runtime Provenance​

Analytical Provenance is graph-shaped and MAY branch, converge, fan out, recurse, and span multiple Products, Consumers, Decisions, Actions, and delayed Outcomes.

Definition Provenance preserves relationships to governed definitions such as Metric, Indicator, KPI/KRI designation, Threshold, Population, Dimension, Classification, Score, Signal, Alert, Process, Logic, and Information Proposition.

Runtime Provenance describes concrete input versions, Executions, Output Occurrences, Consumption Events, Decision Events, Action Events, and Outcome Observations. Runtime Provenance SHOULD reference applicable Definition Provenance.

7.7 Design and Execution Provenance​

GEARM distinguishes:

  • Design Provenance - how governed definitions, Processes, semantics, rules, Products, and Logic are related;
  • Execution Provenance - what actually happened during runtime.

Both MAY be required for historical reconstruction or reproducibility.

7.8 Semantic, Logic and Method Provenance​

Semantic Provenance identifies definitions/versions that supplied meaning to an Output.

Logic Provenance identifies Analytical Logic materially involved in forming a result.

Method Provenance identifies Analytical Method used to realize a capability.

Semantic Provenance != Logic Provenance
Method Provenance != Logic Provenance

7.9 AI, Product, Input and Intermediate Provenance​

Where AI materially contributes, GEARM SHOULD reference applicable AI Product identity/version and relevant AIPS evidence rather than redefine AI provenance.

Product Provenance MAY identify Data Product, AI Product, Information Product, Product Version, and Output Port identities/versions.

Product Version != Output Port Version

Input Provenance identifies governed inputs materially consumed by an Execution. Intermediate Outputs MAY be included where omission would prevent meaningful reconstruction or explanation; GEARM does not require every trivial intermediate value to be persisted.

7.10 Granularity, Completeness and Scope Labels​

Provenance depth/granularity SHOULD be proportionate to analytical materiality, regulation, Decision consequence, Product obligations, reproducibility needs, risk, privacy, and cost.

More provenance is not automatically better provenance.

Completeness MAY be assessed across identity, version, semantic, dependency, Logic, Method, temporal, Consumer, Decision, Action, and Outcome dimensions relative to a declared scope.

GEARM MAY use shorthand scope labels:

  • P0 - No Governed Analytical Provenance;
  • P1 - Local Analytical Lineage;
  • P2 - Product and Semantic Provenance;
  • P3 - Consumption and Decision Provenance;
  • P4 - End-to-End Analytical Provenance.

These labels describe scope, not maturity.

7.11 Version Awareness, Stable Identity and Time​

Material provenance SHOULD be version-aware and identify semantic, Process, Logic, Product, AI Product, Threshold, Rule, and Output Port versions where applicable.

Current-state metadata SHALL NOT substitute for historical version evidence where reconstruction is required.

Stable Identity != Version Identity

GEARM recognizes Observation Time, Source Event Time, Ingestion Time, Processing Time, Publication Time, Consumption Time, Decision Time, Action Time, Outcome Observation Time, and Effective Time. These SHALL NOT be assumed identical.

Temporal ordering does not establish causality.

7.12 Consumption, Recommendation, Decision, Action, Outcome and Feedback Provenance​

GEARM MAY preserve material traceability concerning:

  • Information consumed, Consumer, time, purpose, Product/Port;
  • Recommendation Occurrence, Actor, evidence, and disposition;
  • Decision Event, Actor, evidence, policy, override, and result;
  • Action Event, Actor, authority, target, time, and status;
  • Outcome Observation, source, observer, time, related Decisions/Actions, and attribution;
  • Feedback and what it subsequently influenced.

7.13 Evolution Provenance​

Evolution Provenance records relationships among successive governed definitions, Processes, Products, or analytical constructs, including supersedes, supersededBy, derivedFromVersion, replaces, and deprecatedBy.

Semantic and implementation versions SHOULD be permitted to evolve independently where meaning and implementation change independently.

7.14 Reproducibility and Non-Determinism​

Provenance MAY support exact reproduction, equivalent reproduction, explanatory reconstruction, or trace-only reconstruction depending on method and governance need.

Where Analytics is non-deterministic, provenance SHOULD preserve material execution context such as AI Product/model version, prompt/instruction reference, runtime parameters, random seed where available, external context, or tool references.

Complete provenance does not guarantee exact reproducibility.

7.15 Human Analytical Provenance​

Where human analytical judgement materially contributes, provenance MAY identify human analytical role, judgement occurrence, evidence considered, time, Process, and resulting Assessment/Interpretation, subject to privacy and governance.

7.16 Provenance as Governed Information​

Analytical Provenance MAY itself be subject to privacy, confidentiality, security, purpose limitation, data minimization, access control, retention, and integrity requirements.

A requirement for provenance SHALL NOT automatically justify unrestricted collection or exposure of Consumer or Decision Actor Information.

Provenance access MAY be governed independently from access to the analytical result. Provenance retention MAY differ from Output retention.

7.17 Federated Provenance​

No single physical system is required to own or store all provenance. Different provenance dimensions MAY remain governed by different authoritative stores such as Data Catalog, Product Registry, Semantic Registry, AI Registry, analytics metadata store, Decision system, workflow platform, and Outcome system.

Federated Provenance is provenance assembled through stable identities and governed relationships across multiple authoritative stores.

Stable identity and relationship continuity are more important than physical centralization.

7.18 Provenance Relationships and Boundaries​

GEARM recognizes provenance-oriented relationships including wasDerivedFrom, wasGeneratedBy, used, usedSemantic, usedLogic, usedMethod, invoked, consumed, wasConsumedBy, informed, recommended, wasDecidedBy, authorized, resultedIn, wasPerformedBy, producedOutcome, wasObservedAs, generatedFeedback, supersededBy, versionOf, and specializes. GEARM-A2 formalizes their machine-readable predicate identities and their relationship to the broader GEARM relationship vocabulary.

GEARM preserves:

Explanation != Provenance
Provenance != Audit
Observability != Provenance
Evidence != Provenance
Provenance != Causal Proof
Provenance Completeness != Analytical Quality
Traceable != Correct
appearsInProvenance != isAccountableOwner

7.19 Information Product Provenance​

Productization SHALL NOT reset required upstream analytical provenance. Productized Composition SHOULD preserve material upstream Product identities and analytical formation relationships.

Federated Consumption alone does not establish a new Product.

7.20 M7 Principles​

  • M7-PR01 Analytical Lineage SHALL be treated as the derivation-oriented subset of Analytical Provenance.
  • M7-PR02 Provenance SHOULD preserve material continuity across upstream Products, analytical formation, consumption, Decisions, Actions, Outcomes, and Feedback where applicable.
  • M7-PR03 Runtime occurrences SHOULD remain traceable to governed definitions and versions.
  • M7-PR04 Consequential Outputs SHOULD preserve material Semantic Provenance.
  • M7-PR05 Historical evidence SHOULD reference actual versions involved.
  • M7-PR06 Productization SHALL NOT erase required upstream provenance.
  • M7-PR07 Traceability, association, or temporal sequence SHALL NOT be treated as causal proof.
  • M7-PR08 Federated provenance is permitted where identities and governed relationships preserve traceability.
  • M7-PR09 Provenance SHOULD be risk- and purpose-proportionate.
  • M7-PR10 Provenance itself is governed Information.
  • M7-PR11 Complete traceability SHALL NOT imply correctness.
  • M7-PR12 Provenance SHOULD support historical interpretability after semantics, Logic, Products, and Processes evolve.

M8 - GEARM Reference Model

8.1 Purpose​

The GEARM Reference Model organizes enterprise analytics semantics into logical domains describing why analytical Information is needed, which governed semantics give Analytics meaning, which governed resources participate as inputs, how Analytics forms Information, how Information may become a reusable proposition, how Information is consumed and may participate in Decisions/Actions, and how Outcomes, Value, Feedback, and Evolution close the loop.

The Reference Model is semantic. It SHALL NOT be interpreted as enterprise architecture, platform architecture, mandatory workflow, system topology, processing pipeline, organizational model, or delivery lifecycle.

Governing principle: GEARM organizes the meaning of enterprise analytics; GEARA organizes architectural responsibility for realizing that meaning.

8.2 Seven Canonical Logical Domains​

GEARM 0.1 defines:

  1. RM1 - Information Need and Analytical Intent
  2. RM2 - Analytical Semantics
  3. RM3 - Governed Inputs and Analytical Dependencies
  4. RM4 - Analytics and Information Formation
  5. RM5 - Information Proposition and Product Boundary
  6. RM6 - Consumption, Decision and Action
  7. RM7 - Outcome, Value, Feedback and Evolution

Across all domains, Analytical Provenance/Lineage, Identity/Version/Time/Context, Semantic Authority, and Quality/Fitness operate as cross-cutting concerns rather than process stages.

8.3 Reference Model Overview​

RM1 Information Need & Analytical Intent
       |
       v
RM2 Analytical Semantics
       +
RM3 Governed Inputs & Dependencies
       |
       v
RM4 Analytics & Information Formation
       |
       v
RM5 Information Proposition & Product Boundary
       |
       v
RM6 Consumption, Decision & Action
       |
       v
RM7 Outcome, Value, Feedback & Evolution
       |
       +------> may generate new Information Need / evolution

Analytical Provenance and Lineage span the full graph.

8.4 RM1 - Information Need and Analytical Intent​

RM1 contains Information Need, Analytical Intent, and Analytical Use Case.

Information Need -> motivates -> Analytical Intent
Analytical Intent -> realizedThrough -> Analytical Use Case
Analytical Use Case -> addresses -> Information Need

RM1 begins with Information Need rather than Dashboard Requirement, Dataset Requirement, AI Requirement, or Technology Requirement. Relationships are many-to-many.

8.5 RM2 - Analytical Semantics​

RM2 contains governed semantic definitions enabling consistent Analytics, including Measure, Metric, Indicator, KPI/KRI designation, Analytical Condition, Threshold, Analytical Rule, Population, Cohort, Dimension, Classification, Score, Signal Definition, Alert Definition, and Analytical State Definition.

RM2 primarily answers: What does the analytical concept mean?

Runtime observations/evaluations remain distinct from these definitions and primarily participate in RM4.

8.6 RM3 - Governed Inputs and Analytical Dependencies​

RM3 represents governed entities on which analytical activity depends. Governed Analytical Input is a contextual role.

Potential participants include Data Product, AI Product, Information Product, Data Asset, external governed Information, reference Information, Semantic Definition, Analytical Rule, and previous Analytical Output.

Participation in Analytics does not change intrinsic ontology.

8.7 RM4 - Analytics and Information Formation​

RM4 represents the semantic machinery through which governed inputs and semantics become Outputs and Information.

Primary concepts include Analytics, Analytics Capability, Analytical Method, Analytical Process, Analytical Logic, Analytical Execution, Analytical Output Definition/Occurrence, Analytical Evidence, and Information Formation.

Formation includes Contextualization, Derivation, Evaluation, Inference, Interpretation, and Synthesis.

Result forms MAY include Measure Observation, Metric Observation, Indicator Observation, Score, Classification Result, Trend, Anomaly, Signal, Alert, Prediction, Forecast, Assessment, Analytical State, Insight, Explanation, Recommendation, and Simulation Result.

8.8 RM5 - Information Proposition and Product Boundary​

RM5 represents the transition from formed Information to an explicit proposition of informational value.

GEARM owns Information and Information Proposition. Product concepts remain owned by applicable Product semantics.

Information
  -> Information Proposition
       /               \
 direct/contextual   Product Intent
   consumption          |
                    Information Product

Both branches are valid. Productization is optional and intentional.

8.9 RM6 - Consumption, Decision and Action​

RM6 includes Consumer, Consumption Event, Recommendation, Recommendation Actor/Occurrence, Decision, Decision Actor/Event/Rationale, Action, Action Actor/Event.

Information -> may inform Recommendation -> may inform Decision -> may authorize Action

Every arrow is optional. Recommendation is not mandatory. Decision need not produce Action. Pre-authorized Action is valid where governance permits.

8.10 RM7 - Outcome, Value, Feedback and Evolution​

RM7 includes Outcome, Outcome Observation, Outcome Attribution, Analytical Value, Value Evidence, Consumer/Decision/Action/Outcome Feedback, and Evolution relationships.

Outcome -> Outcome Observation -> Feedback -> new Information Need / evolved semantics or Process

Usage, Consumption, Decision, Action, and Outcome do not by themselves establish Value.

8.11 Cross-Cutting Concerns​

Analytical Provenance MAY connect concepts across every domain. Stable Identity and Version apply across definitions, Products, Processes, Outputs, and events where relevant. Time includes Effective, Observation, Source Event, Processing, Publication, Consumption, Decision, Action, and Outcome Observation times. Context MAY include Analytical Subject, Population, domain, jurisdiction, Consumer, purpose, time, environment, or Product context.

Quality/Fitness MAY apply across Data Quality, Analytical Quality, Decision Quality, Action Quality, and Outcome effectiveness, which SHOULD remain distinguishable.

8.12 Definition Graph and Execution Graph​

The Definition Graph represents enduring governed analytical semantics and design-time relationships among Information Needs, Use Cases, Semantic Definitions, Product dependencies, Processes, Logic, Output Definitions, and Information Propositions.

The Execution Graph represents concrete runtime activity among input Product versions, Executions, Output Occurrences, Consumption Events, Recommendation Occurrences, Decision Events, Action Events, Outcome Observations, and Feedback occurrences.

The Execution Graph SHOULD reference the Definition Graph elements that gave runtime occurrences meaning.

Definition Graph
+
Execution Graph
+
external Product/Data/AI semantics
+
Provenance relationships
=
GEARM Semantic Graph

The Semantic Graph is logical and does not require a single graph database.

8.13 Concept Placement Matrix​

ConceptPrimary domain
Information Need / Analytical Intent / Analytical Use CaseRM1
Measure/Metric/Indicator/KPI/KRI/Threshold/Population/Dimension/Classification/Score DefinitionsRM2
Data Product / AI Product / Information Product dependency; Governed Analytical InputRM3
Analytics Capability / Method / Process / Logic / Execution / Output / runtime observationsRM4
Information / Information PropositionRM5
Information ProductReferenced at RM5 boundary
Consumer / Consumption Event / Recommendation / Decision / ActionRM6
Outcome / Outcome Observation / Analytical Value / FeedbackRM7
Analytical Provenance / LineageCross-cutting

Primary placement does not prevent cross-domain relationships.

8.14 Graph-Shaped Cardinality and Recursion​

GEARM SHOULD assume many-to-many relationships unless more specific constraints apply. Outputs MAY become inputs to downstream Processes, enabling chained and recursive Analytics without requiring every intermediate Output to become a Product.

8.15 Human/Machine Neutrality and External Boundaries​

Consumer, Recommendation Actor, Decision Actor, and Action Actor MAY be human or machine where governance permits.

GEARM references BPS Product semantics, GEDRM Data semantics, applicable Data Product specifications, AIPS AI Product semantics, and applicable Information Product semantics rather than absorbing those intrinsic ontologies.

8.16 Reference Model vs Reference Architecture​

A GEARM logical domain does not imply a corresponding GEARA architecture plane.

GEARA MAY combine responsibilities from several GEARM domains, split one GEARM domain across several architectural responsibilities, and introduce architecture-specific concerns not represented as standalone GEARM domains.

GEARM Domain != GEARA Plane
GEARM Domain != System
GEARM Domain != Team
GEARM Reference Model != Workflow

8.17 Minimal and Rich Patterns​

A small conforming semantic pattern may include Information Need, Governed Input, Metric Definition, Analytical Process, Metric Observation, and Consumer, with no Productization, Decision, Action, Outcome, or Feedback because they are not applicable.

A rich pattern MAY span all seven domains, several Products and analytical archetypes, Information Product, human/machine Consumers, Recommendation, Decision, Actions, Outcomes, and Feedback.

8.18 Evolution and Extensibility​

Evolution is governed change of a Semantic Definition, Use Case, Process, Product, or related construct in response to new Intent, evidence, Feedback, policy, or context. Evolution is a relationship across versions and SHOULD preserve historical identity/provenance where required.

Future GEARM versions MAY introduce concepts concerning Decision Intelligence, optimization, causal Analytics, autonomous agents, knowledge-oriented Products, advanced simulation, or other analytical semantics. New concepts SHOULD fit existing domains where coherent before new domains are introduced.

8.19 M8 Principles​

  • M8-PR01 GEARM domains organize semantic concerns, not implementation components.
  • M8-PR02 GEARM SHALL permit branching, convergence, chaining, reuse, recursion, and many-to-many relationships.
  • M8-PR03 GEARM SHOULD begin conceptually with Information Need.
  • M8-PR04 Governed Analytical Semantics SHALL remain distinct from runtime execution.
  • M8-PR05 Governed Analytical Input SHALL remain a contextual role.
  • M8-PR06 Information Proposition MAY be consumed directly or intentionally productized; Productization is not mandatory.
  • M8-PR07 Consumption, Recommendation, Decision, Action, Outcome, Value, and Feedback SHALL remain separately identifiable.
  • M8-PR08 Analytical Provenance SHOULD connect material relationships across every domain.
  • M8-PR09 GEARM SHALL support Definition Graph and Execution Graph views.
  • M8-PR10 GEARM domains SHALL NOT prescribe GEARA planes, systems, platforms, teams, or topology.
  • M8-PR11 External Product, Data, AI, and domain semantics SHALL be referenced rather than silently redefined.
  • M8-PR12 Feedback and Outcome MAY drive governed evolution and new Information Needs without uncontrolled semantic redefinition.

M9 - Semantic Invariants

9.1 Purpose​

A Semantic Invariant is a relationship, distinction, or constraint whose preservation is required for consistent interpretation of GEARM concepts.

Semantic Invariants protect the Reference Model from semantic collapse.

Governing principle: Implementation consolidation is permitted; semantic collapse is not.

GEARM recognizes distinction invariants (A != B), specialization invariants (A IS-A B), subset invariants, non-inheritance invariants, role invariants, and boundary invariants.

A distinction invariant does not automatically imply RDF/OWL class disjointness. Distinct concepts may legitimately overlap at instance level while remaining different in meaning.

Invariant identifier stability. Normative GEARM invariants use the stable identifier namespace GEARM-INV-nnn. Historical conceptual-draft identifiers of the form M9-INV-nnn map one-to-one to GEARM-INV-nnn by retaining the numeric suffix. The section in which an invariant is published does not form part of its normative identity.

9.2 Need, Intent and Use-Case Invariants​

IDNormative invariant
GEARM-INV-001Information Need != Analytical Intent
GEARM-INV-002Analytical Intent != Product Intent
GEARM-INV-003Analytical Intent != implementation requirement
GEARM-INV-004Analytical Use Case != Information Need
GEARM-INV-005Analytical Use Case != Information Product
GEARM-INV-006Analytical Use Case != Analytics Capability
GEARM-INV-007A dashboard, report, model, dataset, or technology requirement SHALL NOT automatically be treated as an Information Need.

9.3 Definition and Occurrence Invariants​

IDNormative invariant
GEARM-INV-010Semantic Definition != runtime occurrence
GEARM-INV-011Measure Definition != Measure Observation
GEARM-INV-012Metric Definition != Metric Observation
GEARM-INV-013Indicator Definition != Indicator Observation
GEARM-INV-014Threshold Definition != Threshold Evaluation
GEARM-INV-015Population Definition != Population Snapshot
GEARM-INV-016Classification Definition != Classification Result
GEARM-INV-017Score Definition != Score Occurrence
GEARM-INV-018Signal Definition != Signal Occurrence
GEARM-INV-019Alert Definition != Alert Occurrence
GEARM-INV-020Analytical Process != Analytical Execution
GEARM-INV-021Analytical Output Definition != Analytical Output Occurrence
GEARM-INV-022Consumer != Consumption Event
GEARM-INV-023Decision != Decision Event where a reusable Decision type is modeled.
GEARM-INV-024Action != Action Event where a reusable Action type is modeled.
GEARM-INV-025Outcome != Outcome Observation

9.4 Analytical Semantics Invariants​

IDNormative invariant
GEARM-INV-030Measure != Metric
GEARM-INV-031Metric != Indicator
GEARM-INV-032Indicator != KPI/KRI designation
GEARM-INV-033KPI IS-A Indicator with governed Performance and Key designation.
GEARM-INV-034KRI IS-A Indicator with governed Risk and Key designation.
GEARM-INV-035Key status is contextual governance designation and SHALL NOT be inferred merely from calculation or frequency of use.
GEARM-INV-036Threshold IS-A Analytical Condition
GEARM-INV-037Threshold != Threshold Evaluation
GEARM-INV-038Threshold != Alert
GEARM-INV-039Threshold != Decision Policy
GEARM-INV-040Analytical Rule != Business Decision Rule
GEARM-INV-041Population != Dimension
GEARM-INV-042Cohort IS-A Population
GEARM-INV-043Dimension != Classification
GEARM-INV-044Score != Metric
GEARM-INV-045Score != Classification
GEARM-INV-046Score != Probability unless governed definition explicitly establishes probabilistic meaning.
GEARM-INV-047Indicator != Signal
GEARM-INV-048Signal != Alert
GEARM-INV-049State != Signal
GEARM-INV-050Presentation attributes such as Red/Amber/Green SHALL NOT themselves establish canonical semantic state.

9.5 Analytics Formation Invariants​

IDNormative invariant
GEARM-INV-060Analytics != AI
GEARM-INV-061Analytics != Information
GEARM-INV-062Analytics != Productization
GEARM-INV-063Analytics Capability != Analytical Method
GEARM-INV-064Analytics Capability != Analytical Process
GEARM-INV-065Analytical Method != Analytical Process
GEARM-INV-066Analytical Process != Analytical Logic
GEARM-INV-067Analytical Process != Analytical Execution
GEARM-INV-068Analytical Logic != Analytical Semantic Definition
GEARM-INV-069Method or technology SHALL NOT by itself determine Analytical Output semantic type.
GEARM-INV-070Observation != Inference
GEARM-INV-071Derivation != Inference
GEARM-INV-072Evaluation != Decision
GEARM-INV-073Assessment != Decision
GEARM-INV-074Insight != Recommendation
GEARM-INV-075Prediction != Observation
GEARM-INV-076Forecast IS-A Prediction
GEARM-INV-077Not every Prediction is a Forecast.
GEARM-INV-078Scenario != Forecast
GEARM-INV-079Simulation Result != Observed Outcome
GEARM-INV-080Anomaly != Signal
GEARM-INV-081Correlation != Causation
GEARM-INV-082Explanation != Provenance
GEARM-INV-083Reason Code != Explanation
GEARM-INV-084Data Quality != Analytical Quality

An Analytical Output SHALL be classified according to what it semantically represents, not merely the technology, algorithm, model, or Product used to produce it.

9.6 Information and Product Boundary Invariants​

IDNormative invariant
GEARM-INV-090Analytical Output != Information Product
GEARM-INV-091Information != Information Product
GEARM-INV-092Information Proposition != Information Product
GEARM-INV-093Analytical Intent != Product Intent
GEARM-INV-094Persistence SHALL NOT imply Productization.
GEARM-INV-095Reuse SHALL NOT imply Productization.
GEARM-INV-096Distribution SHALL NOT imply Productization.
GEARM-INV-097Discoverability or registry presence SHALL NOT imply Product qualification.
GEARM-INV-098Number of Consumers SHALL NOT imply Productization.
GEARM-INV-099Structured-data representation SHALL NOT make Information a Data Product.
GEARM-INV-100Use of Analytics SHALL NOT create an Analytics Product Product Family.
GEARM-INV-101Use of an AI Product SHALL NOT cause downstream constructs to inherit AI Product ontology.
GEARM-INV-102Use of a Data Product SHALL NOT cause downstream constructs to inherit Data Product ontology.

9.7 Role, Dependency and Ownership Invariants​

Governed Analytical Input, Consumer, Decision Actor, Action Actor, and Analytical Evidence are contextual roles. Role participation SHALL NOT alter intrinsic identity.

IDNormative invariant
GEARM-INV-110dependsOn != IS-A
GEARM-INV-111consumes != owns
GEARM-INV-112invokes != specializes
GEARM-INV-113Composition SHALL NOT imply semantic equivalence among components and result.
GEARM-INV-114Upstream Product ownership SHALL NOT imply downstream Product ownership.
GEARM-INV-115Producer or Transformer SHALL NOT automatically be treated as Product Owner.
GEARM-INV-116Platform implementation SHALL NOT automatically establish analytical or Product ownership.

9.8 Consumption, Decision and Action Invariants​

IDNormative invariant
GEARM-INV-120Consumer != Decision Actor
GEARM-INV-121Consumer != Consumption Event
GEARM-INV-122Recommendation Actor != Decision Actor
GEARM-INV-123Recommendation != Decision
GEARM-INV-124Recommendation acceptance SHALL NOT imply analytical correctness.
GEARM-INV-125Decision != Action
GEARM-INV-126Decision Actor != Action Actor
GEARM-INV-127Decision confidence SHALL NOT imply Decision authority.
GEARM-INV-128Technical execution capability SHALL NOT imply governed Decision authority.
GEARM-INV-129Action != Outcome
GEARM-INV-130Outcome != Outcome Observation
GEARM-INV-131Outcome != Feedback
GEARM-INV-132Outcome != Analytical Value
GEARM-INV-133Usage != Analytical Value
GEARM-INV-134Consumption != Analytical Value
GEARM-INV-135Decision != Analytical Value
GEARM-INV-136Decision Quality != Analytical Quality
GEARM-INV-137Decision Quality != Action Quality
GEARM-INV-138Automation != Autonomy
GEARM-INV-139Delegated execution SHALL NOT automatically imply transfer of ultimate accountability.

9.9 Outcome and Causality Invariants​

IDNormative invariant
GEARM-INV-140Traceability != Causality
GEARM-INV-141Association != Causality
GEARM-INV-142Temporal Order != Causality
GEARM-INV-143Attribution != Proven Causality
GEARM-INV-144Outcome Observation != Causal Proof
GEARM-INV-145Action occurring before an Outcome SHALL NOT by itself establish causality.
GEARM-INV-146Counterfactual estimates SHALL remain distinguishable from directly observed Outcomes.

9.10 Feedback and Evolution Invariants​

IDNormative invariant
GEARM-INV-150Feedback SHALL NOT itself authorize semantic, Process, Product, or policy change.
GEARM-INV-151Current semantic definition SHALL NOT overwrite historical meaning of previous analytical results.
GEARM-INV-152Evolution SHOULD preserve version relationships sufficient for historical interpretation where required.
GEARM-INV-153Implementation evolution and semantic evolution SHALL remain separately identifiable where they differ.

9.11 Provenance Invariants​

IDNormative invariant
GEARM-INV-160Analytical Lineage subset-of Analytical Provenance
GEARM-INV-161Analytical Lineage != Analytical Provenance
GEARM-INV-162Definition Provenance != Execution Provenance
GEARM-INV-163Semantic Provenance != Logic Provenance
GEARM-INV-164Method Provenance != Logic Provenance
GEARM-INV-165Product Provenance != Product Ownership
GEARM-INV-166Consumption Provenance != Decision Provenance
GEARM-INV-167Decision Provenance != Action Provenance
GEARM-INV-168Provenance != Explanation
GEARM-INV-169Provenance != Audit
GEARM-INV-170Provenance != Observability
GEARM-INV-171Provenance != Analytical Evidence
GEARM-INV-172Provenance != Correctness
GEARM-INV-173Provenance Completeness != Analytical Quality
GEARM-INV-174Productization SHALL NOT reset required provenance.
GEARM-INV-175Current metadata SHALL NOT substitute for historical version evidence where reconstruction is required.
GEARM-INV-176Federated provenance SHALL NOT be considered incomplete solely because it is physically distributed.
GEARM-INV-177More captured provenance SHALL NOT automatically be considered better provenance.
GEARM-INV-178Stable identity SHALL remain distinct from version identity.

9.12 Identity, Version and Time Invariants​

IDNormative invariant
GEARM-INV-180Logical Identity != Version Identity
GEARM-INV-181Semantic version SHALL be independently identifiable from implementation version where they evolve independently.
GEARM-INV-182Product version SHALL remain distinguishable from Output Port version.
GEARM-INV-183Observation Time SHALL NOT automatically equal Processing Time.
GEARM-INV-184Processing Time SHALL NOT automatically equal Publication Time.
GEARM-INV-185Publication Time SHALL NOT automatically equal Consumption Time.
GEARM-INV-186Consumption Time SHALL NOT automatically equal Decision Time.
GEARM-INV-187Decision Time SHALL NOT automatically equal Action Time.
GEARM-INV-188Action Time SHALL NOT automatically equal Outcome Observation Time.
GEARM-INV-189Effective Time SHALL remain distinguishable from occurrence time where semantically material.

9.13 Definition Graph, Execution Graph and Semantic Authority Invariants​

IDNormative invariant
GEARM-INV-190Definition Graph != Execution Graph
GEARM-INV-191Execution occurrences SHOULD reference applicable Definition Graph entities where governed definitions exist.
GEARM-INV-192Runtime Execution SHALL NOT redefine canonical Semantic Definition merely because it produced an occurrence.
GEARM-INV-193Current Definition Graph state SHALL NOT automatically describe historical Execution Graph semantics.
GEARM-INV-200Semantic Authority != Instance Ownership
GEARM-INV-201Semantic Authority != Authoritative Source
GEARM-INV-202Semantic Authority != Architecture Authority
GEARM-INV-203Implementation prevalence SHALL NOT establish Semantic Authority.
GEARM-INV-204Storage location SHALL NOT establish Semantic Authority.
GEARM-INV-205Registry storage SHALL NOT by itself make the Registry Semantic Authority.
GEARM-INV-206Downstream implementation SHALL NOT silently redefine an upstream concept while claiming semantic equivalence.
GEARM-INV-207Label similarity SHALL NOT establish semantic equivalence.
GEARM-INV-208equivalentTo != specializes
GEARM-INV-209Specialization SHALL preserve meaning of the specialized concept.

9.14 External Specification Boundary Invariants​

IDNormative invariant
GEARM-INV-210GEARM SHALL NOT redefine generic Product semantics owned by BPS.
GEARM-INV-211GEARM SHALL NOT redefine generic enterprise Data semantics owned by GEDRM.
GEARM-INV-212GEARM SHALL NOT redefine AI Product intrinsic semantics owned by AIPS.
GEARM-INV-213GEARM SHALL NOT redefine Information Product intrinsic semantics owned by the applicable Product specialization.
GEARM-INV-214Reference to an external concept SHALL NOT imply conformance of that external concept to its originating specification.

9.15 Reference Model and Architecture Invariants​

IDNormative invariant
GEARM-INV-220GEARM Reference Model != GEARA Reference Architecture
GEARM-INV-221GEARM Domain != GEARA Plane
GEARM-INV-222GEARM Domain != System
GEARM-INV-223GEARM Domain != Team
GEARM-INV-224GEARM Domain != Processing Stage
GEARM-INV-225Reference Model ordering SHALL NOT be interpreted as a mandatory workflow.
GEARM-INV-226Logical semantic decomposition SHALL NOT require one-to-one implementation decomposition.

9.16 Quality Invariants​

IDNormative invariant
GEARM-INV-230Good Data Quality SHALL NOT by itself establish Analytical Quality.
GEARM-INV-231Analytical Quality SHALL NOT by itself establish Decision Quality.
GEARM-INV-232Decision Quality SHALL NOT by itself establish Action Quality.
GEARM-INV-233Analytical Quality SHALL NOT be inferred solely from adoption or usage.
GEARM-INV-234Analytical Value SHALL NOT be inferred solely from Analytical Quality.

9.17 Human/Machine, Co-Location and Mapping Rules​

Equivalent semantic role participation SHALL NOT imply equivalent legal, policy, ethical, or accountability treatment.

Machine Actor != Autonomous Decision Authority
Agent != Decision Actor by default
Automation != Autonomy
Execution != Accountability Transfer

Multiple GEARM concepts MAY be realized by the same physical component or actor. Physical co-location or temporal immediacy SHALL NOT imply semantic equivalence.

Local models MAY use different terminology. Exact equivalence MAY be claimed only where applicable GEARM meaning/invariants are preserved. A physical object packaging several GEARM concepts SHALL NOT be mapped as exactly equivalent to all of them merely because they share one implementation object.

Distinct concepts may overlap at instance level; they must not be redefined as identical. A quantitative construct MAY legitimately be both Metric and Indicator, a person may be Consumer and Decision Actor, and an Information Product may also play Governed Analytical Input.

9.18 Machine-Readable Invariant Catalogue​

GEARM-A3 establishes the canonical machine-readable Semantic Invariant Catalogue in gearm-0.1.invariant-catalogue.yaml. Each normative GEARM-INV-* invariant is indexed with its stable identifier, legacy identifier where applicable, title, source statement, involved concepts and relationships where resolvable, invariant class, requirement level, source section, validation class, and rationale.

The catalogue classifies validation as hybrid or semantic-assessment for GEARM 0.1. It does not claim that every invariant is fully machine-executable. Later SHACL, schema, testcase, and conformance artifacts MAY implement machine-checkable portions of applicable invariants and SHALL trace those constraints back to the canonical GEARM-INV-* identifier.

Not every invariant can be fully validated mechanically.

9.19 M9 Principles​

  • M9-PR01 Concepts declared distinct SHALL NOT be treated as semantically equivalent for implementation convenience.
  • M9-PR02 Physical consolidation SHALL NOT remove logical semantic distinctions.
  • M9-PR03 Governed definitions SHALL remain distinguishable from runtime manifestations where material.
  • M9-PR04 Contextual roles SHALL NOT alter intrinsic semantic or Product identity.
  • M9-PR05 Consumption, dependency, invocation, or composition SHALL NOT transfer ontology.
  • M9-PR06 Method or technology SHALL NOT alone determine Output semantic type.
  • M9-PR07 Analytics, Information Formation, persistence, reuse, distribution, and discovery SHALL NOT independently establish Product status.
  • M9-PR08 Evidence, Signals, Alerts, Assessments, Predictions, and Recommendations SHALL remain distinct from governed Decisions.
  • M9-PR09 Decision, Action, Outcome, Feedback, and Value SHALL remain separately identifiable.
  • M9-PR10 Lineage, Provenance, Explanation, Observability, Audit, Quality, Correctness, Attribution, and Causality SHALL remain semantically distinguishable.
  • M9-PR11 Canonical meaning SHALL derive from applicable Semantic Authority rather than technology or storage location.
  • M9-PR12 GEARM domains SHALL NOT be interpreted as mandatory GEARA planes or implementation components.

M10 - Extension and Conformance Philosophy

10.1 Purpose​

M10 defines GEARM philosophy for semantic conformance, scope, versioning, terminology mapping, specialization, extension, Profiles, deviations, external semantic integration, machine validation, and conformance evidence.

Governing principle: A GEARM-conformant subject preserves applicable meaning, distinctions, relationships, and invariants even where local terminology, technology, topology, or organizational realization differs.

10.2 GEARM Conformance​

A subject conforms to GEARM where, within declared scope:

  • applicable GEARM concepts retain canonical meaning;
  • applicable M9 Semantic Invariants are preserved;
  • local terminology is appropriately mapped;
  • external concepts are referenced according to their Semantic Authority;
  • specializations preserve upstream meaning;
  • extensions do not contradict mandatory GEARM semantics;
  • implementation choices do not falsely redefine GEARM concepts.

GEARM conformance does not require every GEARM concept to be used.

10.3 Scope, Applicability and Version​

Every conformance claim SHALL identify subject, scope, and exact GEARM version.

A conformance scope MAY cover an enterprise semantic model, domain model, Analytical Use Case, analytics platform semantic model, Information Product analytical model, ontology, Profile, metadata model, software implementation, repository, or reference implementation.

A requirement applies only where its subject matter exists in scope. Absence of an optional concept SHALL NOT itself constitute non-conformance.

Where only a subset is relevant, GEARM prefers Scoped Conformance over ambiguous "Partial Conformance".

10.4 Semantic vs Implementation Conformance​

GEARM defines semantic conformance and does not prescribe one implementation model.

Semantic Conformance != Technology Conformance

A conforming implementation MAY use relational, graph, file, event, API, semantic-layer, BI, lakehouse, AI, human-workflow, or hybrid technologies.

10.5 Terminology and Semantic Mapping​

Local terminology MAY differ from GEARM if explicit mappings preserve meaning. Supported mappings MAY include equivalentTo, specializes, broaderThan, narrowerThan, and relatedTo.

equivalentTo != specializes
similar label != semantic equivalence

Exact equivalence SHOULD be claimed only where applicable canonical meaning and invariants are preserved.

10.6 Specialization, Extension and Deviation​

A Specialization narrows or contextualizes a GEARM concept while preserving upstream meaning. It MAY add domain semantics, constraints, narrower Population, regulatory characteristics, or additional relationships.

An Extension adds concepts, properties, relationships, classifications, or constraints while preserving GEARM core.

A Deviation conflicts with, overrides, or does not satisfy an applicable GEARM requirement.

Specialization = narrows existing concept
Extension = adds semantics
Extension != Deviation

A documented deviation does not make a violated mandatory requirement conformant.

10.7 GEARM Profiles​

A GEARM Profile is a governed specialization for a defined context. It MAY select concepts, make optional concepts mandatory, introduce constraints, establish mappings, introduce extensions, reference external specifications, and add conformance requirements.

A Profile MAY tighten GEARM but SHALL NOT weaken applicable mandatory core semantics while claiming conformance.

Profiles MAY constrain cardinality or applicability without turning those constraints into universal GEARM rules.

GEARM-A8 provides the structural machine schema for governed GEARM 0.1 Profile declarations. It supports declared Profile scope; selected and required canonical concepts and relationships; applicability statements; permitted tightening of non-SHALL core invariants to SHALL; Profile-specific cardinality and additional constraints; terminology and semantic mappings; governed extensions; referenced or explicitly composed external specifications; and additional conformance and evidence requirements. A8 does not provide a mechanism to weaken a core SHALL, and a Profile document cannot use the canonical GEARM namespace as its extension namespace. A Profile Schema PASS establishes structural validity only: it does not prove that an applicability exclusion is justified, that a mapping preserves meaning, that an extension is semantically compatible, or that an external specification independently conforms.

10.8 External Specifications and Independent Conformance​

GEARM MAY interoperate with external specifications concerning Data Products, Decision models, risk taxonomies, regulatory semantics, statistical metadata, domain ontologies, knowledge models, and other adjacent concerns.

Referencing an external specification does not absorb it into GEARM normative core.

GEARM conformance != BPS/AIPS/Data Product/GEARA conformance
GEARM-conformant use of AI Product != AIPS certification of that AI Product

Cross-specification conformance claims remain independent unless a Profile explicitly composes them.

10.9 Extension Authority and Namespace Separation​

An extension SHOULD identify the authority governing its additional semantics. Extension ownership does not transfer Semantic Authority over canonical GEARM concepts.

Machine-readable extensions SHOULD use namespaces or equivalent mechanisms distinguishing canonical GEARM concepts, Profiles, enterprise/domain extensions, and external specifications. The canonical GEARM namespace SHOULD be reserved for concepts formally incorporated into GEARM.

10.10 Conformance Dimensions​

GEARM conformance MAY be assessed across:

  • Semantic Concept Conformance;
  • Invariant Conformance;
  • Relationship Conformance;
  • Mapping Conformance;
  • Extension Conformance;
  • Profile Conformance;
  • Provenance Semantic Conformance;
  • Version Conformance.

These are assessment dimensions, not maturity scores.

10.11 Conformance Is Not Maturity, Quality, Value or Certification​

Complexity != Conformance
Technology Sophistication != Conformance
Maturity != Conformance
GEARM Conformance != Analytical Quality
GEARM Conformance != Model Accuracy
GEARM Conformance != Business Value

GEARM 0.1 does not require a centralized certification authority. Conformance MAY be self-declared, internally assessed, or externally certified according to applicable governance.

10.12 Machine Validation and Semantic Assessment​

Some constraints MAY be machine-executable through RDF/OWL, SHACL, JSON Schema, registry validation, or automated runners.

Other requirements require semantic/governance judgement, such as whether a local concept genuinely preserves meaning, whether an extension contradicts an invariant, whether a supposed Information Need is actually an implementation requirement, or whether an attribution claim overstates causality.

Future constraints SHOULD identify one validation class:

  • Machine-Executable;
  • Semantic-Assessment;
  • Hybrid.

Passing machine validation SHALL NOT establish complete conformance where applicable Semantic-Assessment or Hybrid constraints remain unevaluated.

Machine Validation + Semantic Assessment = Complete Conformance Evidence

where both are applicable.

10.13 Ontology Validation Boundary and Disjointness​

Ontology reasoning can detect some contradictions but cannot establish every business-semantic distinction.

A GEARM distinction invariant does not automatically imply RDF/OWL class disjointness. Concepts may be semantically different while the same instance legitimately participates in both.

Semantic distinction SHALL NOT automatically be encoded as ontology disjointness.

Formal disjointness SHOULD be asserted only where simultaneous classification would itself violate the GEARM model.

10.14 Conformance Evidence, Declaration and Status​

A GEARM assessment SHOULD retain evidence such as concept/ontology mappings, machine-validation results, semantic review findings, Profile/extension declarations, deviations, versions, test cases, and provenance examples.

A conformance declaration SHOULD identify specification/version, subject, scope, Profile/version, external specifications, extensions, deviations, semantic mappings, machine-validation result, semantic-assessment result, evidence, assessment date, and assessment authority.

A GEARM assessment SHOULD use one of:

  • Conforms;
  • Does Not Conform;
  • Assessment Incomplete;
  • Not Applicable.

GEARM does not define percentage, tier, maturity, or weighted conformance scores.

10.15 Semantic Conflict and Currentness​

Where a local or external specification conflicts with GEARM, the conflict SHALL be explicit. The implementation SHOULD determine whether the concept is a specialization, different concept, incorrect mapping, deviation, or Profile-specific concern.

A conformance assessment is valid relative to subject version, GEARM version, Profile version, semantic mappings, and evidence at assessment time.

Material semantic change MAY invalidate all or part of an assessment. Targeted reassessment MAY be used where change affects only bounded concepts/relationships/evidence.

10.16 Semantic vs Technical Compatibility​

A semantic version is backward compatible only where existing Consumers can continue to interpret relevant meaning without violating semantic contracts.

schema-compatible != semantically compatible

A change MAY be semantically breaking where it alters meaning, Population, grain, unit, time window, classification, threshold interpretation, Product proposition, or relationship semantics even if physical schema is unchanged.

Conversely, a technically breaking implementation change MAY preserve semantic identity where governed meaning is unchanged.

10.17 Canonical Conformance Rule​

A GEARM conformance claim SHALL state what was assessed, against which GEARM version and applicable Profile, within what scope, using what semantic mappings and extensions, with what deviations and evidence, and with what result.

10.18 Extension Lifecycle and Deprecation​

An extension MAY remain local indefinitely. Where it proves generic, reusable, broadly applicable, and semantically stable, it MAY be proposed for a future GEARM version. Local prevalence alone SHALL NOT make an extension canonical.

GEARM or a Profile MAY deprecate a concept, relationship, or mapping. Deprecation SHOULD identify the element, version, replacement where available, migration guidance, and compatibility implications.

Where extensions materially participate in Analytics, Provenance SHOULD identify extension identity/version.

10.19 Product, Performance and GEARA Boundaries​

GEARM conformance does not determine Product qualification, predictive accuracy, model performance, fairness, safety, regulatory compliance, analytical fitness, or business value.

GEARM conformance concerns semantic alignment. GEARA conformance concerns architecture responsibilities, relationships, controls, and architecture constraints. The two claims are independent but complementary.

10.20 Machine-Readable Artifacts​

The GEARM 0.1 machine-readable artifact programme is staged. The following artifacts are currently established:

  1. Concept Registry — GEARM-A1: gearm-0.1.concept-registry.yaml.
  2. Relationship Registry — GEARM-A2: gearm-0.1.relationship-registry.yaml.
  3. Semantic Invariant Catalogue — GEARM-A3: gearm-0.1.invariant-catalogue.yaml.
  4. RDF / OWL Representation — GEARM-A4: gearm-0.1.ttl.
  5. JSON-LD Context — GEARM-A5: gearm-0.1.context.jsonld.
  6. SHACL Constraints — GEARM-A6: gearm-0.1.shacl.ttl.
  7. Structural JSON / JSON-LD Schema — GEARM-A7: gearm-0.1.schema.json.
  8. Profile Schema — GEARM-A8: gearm-0.1.profile.schema.json.
  9. Canonical Example Set — GEARM-A9: examples/.
  10. Positive Test Cases — GEARM-A10: testcases/positive/ with authoritative expected-outcome inventory in testcases/manifest.json.
  11. Negative Test Cases — GEARM-A11: testcases/structural-invalid/, testcases/semantic-invalid/, and testcases/profile-invalid/, sharing testcases/manifest.json.
  12. Automated Conformance Runner — GEARM-A12: testcases/run_conformance.py, with baseline dependencies in testcases/requirements-conformance.txt.
  13. Cross-Artifact Reconciliation — GEARM-A13: reconciliation/run_reconciliation.py, with packaged result reconciliation/reconciliation-report.json.
  14. Regression Suite — GEARM-A14: regression/run_regression.py, with governed baseline regression/baseline.json and packaged result regression/regression-report.json.
  15. Release Closure — GEARM-A15: release/run_release_closure.py, with frozen release inventory release/manifest.json, checksum set release/SHA256SUMS, release notes, and packaged result release/release-closure-report.json.

GEARM-A4 provides a conservative RDF/OWL representation of the established A1-A3 machine source artifacts. GEARM-owned concepts are represented as OWL classes; explicit specialization is represented through rdfs:subClassOf; canonical relationships are represented as RDF properties; and invariant records are represented as first-class machine resources. A4 SHALL NOT infer OWL disjointness, domain/range restrictions, inverse relationships, transitivity, functionality, or other stronger axioms unless those semantics are explicitly established by the normative GEARM sources. External and boundary concepts are referenced rather than re-owned.

GEARM-A5 provides the JSON-LD 1.1 compact-term context for GEARM-owned concepts, canonical relationships, A4 metadata, invariant identifiers, and controlled-vocabulary namespaces. It deliberately does not declare a default @vocab: only explicitly declared GEARM terms or prefixed IRIs expand into the GEARM namespaces. Canonical relationship terms are IRI-valued through @type: @id. External Product, Data, AI Product, Information Product, and boundary vocabularies are not assigned invented GEARM aliases; callers SHALL use the authoritative external IRI or an independently governed external context.

GEARM-A6 implements conservative SHACL constraints for machine-checkable portions of the A3 invariant catalogue. It records coverage for all 180 normative invariants, provides partial executable constraints for 85 Hybrid invariants, and leaves the remaining 35 Hybrid plus 60 Semantic-Assessment invariants explicitly assessment-required. Distinction constraints detect explicit semantic collapse through equivalence declarations but SHALL NOT infer class disjointness or prohibit legitimate instance overlap. Canonical specialization constraints validate the established IS-A axioms, and relationship-separation constraints prevent selected dependency/mapping predicates from being collapsed into specialization. A SHACL PASS SHALL NOT by itself establish complete GEARM conformance.

GEARM-A7 provides the Draft 2020-12 structural JSON / JSON-LD schema for GEARM semantic resources, semantic graph documents, semantic and terminology mappings, applicability statements, extensions, deviations, assessment-evidence references, and conformance claims. A7 enumerates all canonical A1 concept types, all canonical A2 relationships, and all A3 invariant identifiers used by applicable structural records. It permits explicitly namespace-qualified external or extension terms while preventing undeclared unqualified terms from silently entering the GEARM namespace. JSON Schema validates representation structure only: a schema PASS SHALL NOT establish semantic invariant conformance, SHACL conformance, Profile conformance, or complete GEARM conformance.

GEARM-A8 provides the Draft 2020-12 structural schema for governed GEARM Profile declarations. It references the canonical A1 concept set, A2 relationship set, and A3 invariant set; provides structural fields for Profile scope, applicability, selection, mandatory Profile requirements, mappings, extensions, external-specification composition, cardinality constraints, and additional conformance/evidence requirements; and restricts invariant tightening to GEARM invariants whose core requirement level is below SHALL. A8 SHALL NOT be interpreted as proving that Profile-specific constraints preserve semantic meaning: Profile conformance remains subject to the applicable GEARM invariants and semantic assessment.

GEARM-A9 provides a compact informative example set covering Metric Observation, Threshold Evaluation, AI-assisted Prediction, Recommendation–Decision–Action–Outcome separation, non-productized Information Proposition usage, analytical chaining, terminology mapping, and a governed GEARM Profile. The examples are structurally valid against the applicable A7/A8 schemas but remain non-normative and SHALL NOT be treated as reference implementations or complete conformance evidence. During A9 validation, a structural ambiguity in the A8 EvidenceRequirement.supports union was corrected from oneOf to anyOf; this permits canonical invariant identifiers that are also valid URI-reference strings without changing Profile semantics.

GEARM-A10 establishes deterministic expected-PASS positive testcases and an authoritative testcase manifest. Each manifest entry declares the validator layers expected to run, relevant invariants, expected machine result, and whether semantic assessment remains required. A positive testcase SHALL mean only that the declared machine-validation layers are expected to pass; it SHALL NOT be interpreted as complete GEARM conformance where semantic assessment remains applicable.

GEARM-A11 establishes deterministic expected-FAIL negative testcases in three distinct failure classes. structural-invalid fixtures are expected to fail A7 while making no broader semantic claim. semantic-invalid fixtures are intentionally A7-valid and JSON-LD-expandable but are expected to fail the targeted machine-checkable portion of an A6 SHACL invariant. profile-invalid fixtures are expected to fail A8 and exercise Profile boundaries. An expected negative result SHALL be interpreted only at the validator layer and scope declared by the testcase manifest.

GEARM-A12 provides the executable machine-conformance regression runner for the A10/A11 manifest. It executes A7 JSON Schema validation, deterministic offline A5 JSON-LD expansion, A6 SHACL validation, and A8 Profile Schema validation as declared by each testcase; compares actual outcomes with manifest expectations; verifies expected A6 invariant violations; and returns deterministic process status. GEARM JSON-LD documents MAY carry identified top-level @graph content, so A12 parses JSON-LD as a dataset and validates the union of its quads to avoid silently omitting named-graph semantic content. The packaged native SHACL engine fails closed if A6 begins using unsupported Shape constructs; an optional PySHACL engine MAY be used when installed. An A12 suite PASS means that declared machine-regression expectations matched and SHALL NOT be interpreted as complete GEARM conformance where semantic assessment remains required.

During A12 integration, the GEARM-TC-014 manifest metadata was corrected to reference the actual A6 canonical-specialization invariants GEARM-INV-033, GEARM-INV-034, GEARM-INV-036, GEARM-INV-042, and GEARM-INV-076. The testcase subject, A6 Shapes, and validation semantics were unchanged; this was a manifest-reference correction rather than a semantic change.

GEARM-A13 provides deterministic cross-artifact reconciliation across A1-A12 and the normative human-readable source. It validates canonical identity and count consistency, reference resolution, exact A3-to-M9 invariant parity, A4 representation fidelity and conservative OWL guardrails, A5 namespace/context parity, A6 coverage and Shape mappings, A7/A8 registry-derived enumerations, A9 example validity, A10/A11 manifest integrity, and successful execution of the A12 46-case suite. A13 SHALL fail closed on an unresolved mismatch. An A13 PASS establishes artifact-stack consistency only and SHALL NOT replace semantic assessment or independently establish complete GEARM conformance.

Initial A13 reconciliation found one genuine cross-artifact metadata defect: A3 and A4 still recorded the pre-A6 machineConstraintStatus value not-yet-implemented for all invariants, despite A6 having established coverage. A13 reconciled this non-semantic metadata to partial-executable for 85 invariants, assessment-required for 35 Hybrid invariants without a safe executable reduction, and assessment-only for 60 Semantic-Assessment invariants. No invariant statement, requirement level, validation class, semantic relationship, or normative meaning changed.

GEARM-A14 establishes the release-facing regression baseline for the GEARM 0.1 A1-A13 machine stack. It fingerprints canonical identifiers and content, RDF/SHACL graph structure, schemas, examples, testcase fixtures and expected outcomes, A12/A13 executable implementations, and the normative M9 invariant table. A14 also executes A13 live, which in turn executes the complete A12 suite, so the regression gate requires both the established 46/46 testcase result and the established 51/51 reconciliation result. A14 is fail-closed on baseline drift. It does not automatically refresh its canonical baseline: intentional change requires a reviewed candidate baseline and governed replacement. An A14 PASS demonstrates preservation of the established machine regression baseline; it SHALL NOT be interpreted as semantic approval of all future changes or as complete GEARM conformance.

GEARM-A15 closes the planned GEARM 0.1 executable-artifact programme as GEARM-0.1-RC1, an Executable Release Candidate. A15 freezes the complete A1-A14 machine subject plus this normative specification through release/manifest.json, verifies the release subject and A15 support files through release/SHA256SUMS, records release notes and explicit known limitations, and executes A14 live. Because A14 executes A13 and A13 executes A12, the A15 gate transitively requires the established 19/19 A14 regression result, 51/51 A13 reconciliation result, and 46/46 A12 testcase result. A15 SHALL fail closed on manifest, checksum, package, documentation, boundary-metadata, or live-gate mismatch. An A15 PASS closes the identified release candidate only; it SHALL NOT replace semantic assessment, establish conformance of an arbitrary implementation, or silently promote the candidate to final Released status.

The planned GEARM 0.1 A1-A15 executable-artifact programme is therefore complete for RC1. Future semantic or machine-artifact changes SHALL follow governed change/versioning and, where they affect the established baseline, SHALL trigger the applicable A12-A15 gates and an intentional new candidate or version.

Machine-readable artifacts SHALL preserve the normative semantics defined by this human-readable specification.

Where a machine-readable artifact contradicts the normative GEARM semantic specification, the contradiction SHALL be treated as a defect to be reconciled rather than silently redefining GEARM semantics.

10.21 M10 Principles​

  • M10-PR01 GEARM conformance SHALL be based on preservation of applicable meaning, relationships, and invariants.
  • M10-PR02 Every conformance claim SHALL identify subject, scope, and GEARM version.
  • M10-PR03 Only requirements applicable to declared scope SHALL determine conformance.
  • M10-PR04 Local terminology MAY differ where explicit mappings preserve meaning.
  • M10-PR05 Specializations MAY narrow concepts but SHALL preserve upstream meaning.
  • M10-PR06 Extensions MAY add semantics but SHALL NOT silently redefine GEARM core.
  • M10-PR07 Profiles MAY tighten/contextualize GEARM but SHALL preserve mandatory core semantics.
  • M10-PR08 Conflicts with mandatory semantics SHALL be declared as deviations.
  • M10-PR09 Cross-specification conformance claims remain independent.
  • M10-PR10 Machine validation SHALL complement rather than replace semantic assessment where judgement is required.
  • M10-PR11 Semantic distinction SHALL NOT automatically become ontology disjointness where legitimate instance overlap is possible.
  • M10-PR12 Conformance claims SHOULD be evidence-based.
  • M10-PR13 Material semantic change MAY invalidate affected portions of prior conformance and SHOULD trigger proportionate reassessment.
  • M10-PR14 Semantic compatibility SHALL remain distinguishable from schema/API/implementation compatibility.
  • M10-PR15 Machine-readable artifacts SHALL implement rather than redefine the normative GEARM semantic model.

11. GEARM 0.1 Canonical Baseline Summary

GEARM 0.1 establishes the bounded semantic foundation:

M1   Purpose & Scope
M2   Ecosystem & Semantic Authority
M3   Core Concept Model
M4   Analytical Semantics Model
M5   Analytics & Information Formation Model
M6   Consumption, Decision & Outcome Model
M7   Analytical Provenance Model
M8   Reference Model
M9   Semantic Invariants
M10  Extension & Conformance Philosophy

The canonical semantic spine is:

INFORMATION NEED
  -> ANALYTICAL INTENT
  -> ANALYTICAL USE CASE
  -> ANALYTICAL SEMANTICS + GOVERNED INPUTS
  -> ANALYTICS
  -> INFORMATION FORMATION
  -> INFORMATION
  -> INFORMATION PROPOSITION
       -> optional Productization -> INFORMATION PRODUCT
  -> CONSUMPTION
  -> RECOMMENDATION?
  -> DECISION?
  -> ACTION?
  -> OUTCOME?
  -> FEEDBACK
  -> EVOLUTION / NEW INFORMATION NEED

Analytical Provenance may span the complete graph.

The ecosystem boundary is:

BPS / PIN
Generic Product Semantics
        |
        +---- Data Product semantics
        +---- AIPS / AI Product semantics
        +---- Information Product semantics
                         \
GEDRM -------------------> GEARM
 Data semantics             |
                            | semantic foundation
                            v
                          GEARA
                            |
                     architecture/profile
                            v
                           HDIP

The hard downstream architecture rule is:

GEARM Domain != GEARA Plane.

GEARA MUST derive architectural responsibilities from GEARM semantics rather than mechanically converting the seven GEARM domains into seven architecture planes.