Plant context graph: options · Stamped architecture

The question is how to store and query plant context: assets, topology, states, lots, genealogy, documents and their links. Today there are four shapes (section 2.3).

Option A. Relational in Postgres/Timescale (extend L2)#

What it is: Tables for assets, edges, events, lots, links; recursive CTEs for paths
Strengths: One store, one backup, one security model (RLS exists); joins with time series are local; team already runs it
Weaknesses: Deep path queries are verbose; schema changes need migrations
Evidence: L2 migrations 001–017; L3 comment against a second store

Option B. Graph database (Neo4j, Memgraph)#

What it is: Native property graph
Strengths: Easy multi-hop queries; graph algorithms
Weaknesses: Second plant record to sync; split security; time series still elsewhere
Evidence: General practice; no Stamped need yet for heavy graph algorithms

Option C. Event graph (events as nodes linking assets, lots and times)#

What it is: Every cycle, unit, load, test and stop is an event row with typed links
Strengths: Genealogy and causality questions are event joins; append-only; fits Timescale
Weaknesses: Needs discipline on event types; derived state must be computed
Evidence: Lot linkage in practice is event-based (unit to part within a time window, head index to unit)

Option D. Knowledge graph with ontology (RDF/OWL, AAS, ISA-95 models)#

Not planned for the first three plants (section 10). Kept here so the option is on record.

What it is: Semantic model with standard vocabularies
Strengths: Interoperability; formal semantics
Weaknesses: Heavy for a mid-market plant; slow to build; few Indian plants have the source models
Evidence: AAS Release 26-01 parts 1–5 (E28); ISA-95 adoption is mostly terminology (PL #176)

Option E. Hybrid: relational and event tables in L2, with Apache AGE for graph queries over the same database#

What it is: Cypher on top of Postgres
Strengths: Graph queries without a second database
Weaknesses: AGE is an extension: check managed-Postgres support and Timescale coexistence before choosing
Evidence: AGE "is provided as an extension to PostgreSQL" (E30)

Option F. Unified Namespace (MQTT topic hierarchy)#

What it is: Real-time publish and subscribe with ISA-95 style topics
Strengths: Good live integration pattern; decouples producers and consumers
Weaknesses: A transport and naming pattern, not a store; no history, no lots
Evidence: E31

Reference models to borrow from, not adopt wholesale:

Cognite's core data model separates assets (with parent, root, path), equipment, time series and activities over a start and end time, and gives annotations a confidence and a Suggested, Approved or Rejected status (E29). That last idea fits genealogy links with a link method and confidence.
ISA-95 gives the level names; ISA-88 gives recipe and batch terms; OPC UA companion specs give equipment vocabularies where a machine exposes them.

RECOMMENDED (D1): A plus C (relational plus event tables in L2), with link confidence and method on every genealogy edge borrowed from Cognite's annotation pattern. The repo's own comment, the single security model and the time-series joins all point this way, and no current question needs graph algorithms. Revisit E (AGE) only if path queries become painful; B, D and F are not planned as stores.