Production architecture and ontology evolution

Graph technology should be chosen from workloads and guarantees, not from the attractiveness of a node-link demo. List query shapes, write rates, release frequency, graph size, inference needs, authorization boundaries, latency objectives, recovery targets, and portability requirements. RDF stores provide standards-aligned semantics and SPARQL; property-graph systems may provide other traversal and operational ergonomics. A system can use more than one projection, but one governed claim model must remain the source of truth.

Separate the authoring plane from the serving plane. The authoring plane receives source artifacts, maps and validates claims, resolves identities, computes inference, and builds releases. The serving plane exposes approved snapshots through bounded APIs, saved SPARQL, search indexes, embeddings, or graph projections. This separation prevents exploratory writes from mutating production truth and allows serving indexes to be rebuilt from governed releases.

Use immutable ontology releases. A release includes term definitions, axioms, shapes, mappings, documentation, competency queries, and migration rules. Semantic versioning can communicate intent, but compatibility must be determined by evidence. Adding a class may be compatible; changing the domain of a widely used property can produce new inferred types; adding disjointness can reveal inconsistency; tightening a shape can block old records. Run impact tests over representative and worst-case graphs.

Deprecation is a migration, not a comment. Mark a term deprecated, name its replacement when one exists, stop new authoring, translate incoming legacy values, migrate stored claims, and monitor residual use. Keep resolvable documentation for historical identifiers because old evidence and exports will continue to cite them. Never recycle an IRI for a different meaning.

Schema-on-read does not remove release management. Flexible graphs can accept new predicates easily, which makes accidental vocabularies and misspelled IRIs especially dangerous. Enforce namespace ownership, lint mappings, validate allowed predicates at product boundaries, and report undeclared term growth. Extensions need declared owners and promotion criteria before they become core vocabulary.

Partitioning follows access and query locality. Tenant, geography, source sensitivity, or release may define graph boundaries. Replication and caching must include authorization and release identity in keys. Cross-partition queries should be deliberate because they can leak existence through timing or aggregates even when values are redacted. An ontology shared across tenants does not imply their instance data may be joined.

Reasoning has an operational budget. Measure classification time, entailment growth, incremental invalidation, query rewriting size, and worst-case axioms. Keep inferred graphs replaceable. If a stable subclass closure is materialized, mark the ontology release and make deletion dependencies explicit. Avoid placing heavyweight reasoning in a synchronous request path unless latency and failure behavior are proven.

Backups must restore a coherent knowledge release, not only database pages. Test restoration of source manifests, ontology, shapes, resolution decisions, asserted and derived graphs, search projections, and current release pointers. Define recovery-point and recovery-time objectives. A graph that restores without the mapping version or identity ledger may be online but unauditable.

Cost is driven by more than triple count. Long literals, secondary indexes, embeddings, duplicate projections, provenance granularity, inference expansion, global aggregates, and frequent full rebuilds matter. Attribute compute and storage to releases, sources, query classes, and tenants. Optimization should preserve evidence and reproducibility; deleting provenance to make storage charts smaller is usually false economy.

Evolution succeeds when consumers can move independently. Publish stable contracts, provide compatibility views, announce deprecations, and record usage by query template and API version. A canary release can run competency queries and compare answer diffs before promotion. Require human review for semantic changes whose downstream consequence cannot be safely inferred from syntax alone.