Document Type: Architecture Specification
Context: Semantic Graph Layer · Knowledge Engineering
Status: Public Standard
Validity: Aivis-OS Core Pipeline
References:
Entity Inventory
Semantic Graph Layer
Transport-Safe Content Layer
1. Purpose of the Specification
This specification defines the technical rules, data models, and validation criteria for the construction and operation of the Semantic Graph Layer in Aivis-OS.
The goal is to model meaning, relations, and validity in such a way that:
- internal contradictions can be stored
- external interfaces exclusively expose deterministic states
- conflicts can be explicitly identified and resolved
2. Basic Rules
2.1 Determinism at the Interface (mandatory)
External outputs (Machine Interface Layer, JSON-LD, TSCL, APIs)
must not expose contradictory assertions at any time.
The following applies to every context:
- a maximum of one canonical assertion
- all other competing assertions remain internal
2.2 Multiplicity in the Graph Core (mandatory)
The internal Semantic Graph must be able to store competing assertions in parallel.
The loss of competing information is considered an architectural error.
3. Data Model
3.1 Entity (Node)
Each entity in the graph references exactly one entity from the Cluster-Level Entity Inventory.
Properties:
entity_id(Foreign Key, stable)schema_typecanonical_name
The Semantic Graph generates no own entities.
3.2 Assertion (Edge)
The Semantic Graph manages meaning exclusively in the form of assertions. An assertion is a directed, typed statement:
Subject (Entity)
→ Predicate (Edge Type)
→ Object (Entity | Literal)
Assertions are First-Class Objects.
3.3 Mandatory Attributes of Each Assertion
Each assertion must have the following attributes:
| Attribute | Description |
|---|---|
assertion_id | stable, deterministic ID |
subject_entity_id | Reference to entity |
predicate | typed relation |
object | Entity or Literal |
scope | Context (e.g., region, organization, market) |
valid_from | Start of validity |
valid_through | End of validity (optional) |
provenance | Source |
confidence | numerical weighting (0.0 – 1.0) |
status | ACTIVE | DEPRECATED | CONFLICT |
4. Typing of Relations (Predicate Classes)
Untyped relations are not permitted.
Each assertion must be assigned to one of the following relation types:
4.1 Referential Relations
(e.g. mentions, about)
- weak semantic binding
- no transfer of authority
4.2 Structural Relations
(e.g. hasPart, isPartOf, subsidiaryOf)
- define hierarchies
- must not create cycles
4.3 Attributional Relations
(e.g. author, manufacturer, ceo, copyrightHolder)
- highly critical
- may only have one canonical assertion per context
4.4 Contextual Relations
(e.g. competitor, isSimilarTo, regulatedBy)
- serve for thematic classification
- capable of conflict
5. Conflict Model
5.1 Conflict Detection
A conflict exists if:
- two ACTIVE Assertions
- with identical
subject + predicate + scope - have different
objectvalues
In this case:
- Status =
CONFLICT - no automatic exposure
5.2 Conflict Resolution (Resolution Rules)
The selection of the canonical assertion is based on the following prioritization:
- Scope Match (exact context beats generic)
- Temporal Validity (currently valid beats historical)
- Confidence Score
- Governance Override (manual definition)
Only the resulting assertion receives the status CANONICAL.
6. Exposition (Collapsed State)
The Semantic Graph Layer exclusively delivers the following to the outside:
- Assertions with status
CANONICAL - exactly one assertion per
(entity, predicate, scope)
All other assertions remain:
- internally retrievable
- auditable
- versionable
7. Versioning & Mutation
7.1 Changes
A change in meaning does not occur by overwriting, but by:
- Adding a new assertion
- temporal or status-related deactivation of the old one
Historical truths are preserved.
7.2 Deletion
Physical deletion of assertions is not permitted, except in the case of demonstrably faulty ingestion.
8. Validation & Testing
8.1 Graph Integrity Checks
Mandatory checks:
- Orphan Assertion Check (each assertion references existing entities)
- Cycle Detection (no circular Structural Relations)
- Determinism Check (no contradictory assertions in the Exposed Graph)
8.2 Coverage Metrics
Recommended metrics:
- Assertion Density per Entity
- Ratio of typed assertions to pure text
- Proportion of conflicting assertions (monitoring, no error)
9. Interaction with Other Layers
- Entity Inventory provides stable identities
- Semantic Graph Layer models meaning & conflict
- Transport-Safe Content Layer mirrors canonical assertions
- Projection Layer serializes deterministic states
Summary
Semantic Graph Engineering is not a data modeling task, but a governance discipline for meaning. Through explicit assertions, controlled conflict capability, and deterministic exposure, Aivis-OS ensures that:
- internal reality is fully mapped
- external perception is unambiguous
- machine trust remains stable
remains – even under probabilistic systems.
Link tip
The Semantic Graph Layer shifts meaning from interpretation to architecture. It allows internal polyphony without creating external ambiguity.
Architecture Overview
Cluster-Level Entity Inventory Strategy
Semantic Graph Layer
Semantic Graph Engineering
Machine Interface Layer & Projection Strategy
Transport-Safe Content Layer
Transport-Safe Content Engineering
Evidence Monitoring & AI Visibility Observability
FAQ on Semantic Graph Engineering
Why is Semantic Graph Engineering not purely a data modeling task?
Because it’s not just about defining structures, but about regulating meaning. Semantic Graph Engineering decides which statements are allowed to be valid, how conflicts are handled, and what is exposed externally. That is governance – not schema design.
Why should external interfaces not output contradictory assertions?
AI systems cannot resolve ambiguity. If contradictory statements are exposed simultaneously, trust in the entire source decreases. Determinism at the interface is therefore a prerequisite for stable AI representation.
How does an assertion differ from a classic attribute?
An attribute describes a state. An assertion describes a verifiable claim including context, source, validity and confidence. Only this makes meaning versionable, conflict-capable and machine-assessable.
Why is internal multiplicity not a risk, but necessary?
Organizations are not really free of contradictions. A system that cannot store conflicts loses information about the state of reality. Aivis-OS allows internal multiplicity, but resolves it in a controlled manner before it becomes visible externally.
What role do Provenance and Confidence play in the Semantic Graph?
Provenance and Confidence do not determine whether something is true, but how reliable a statement is. They enable governance rules such as prioritization, temporal replacement or manual overrides – instead of arbitrary overwriting.
Contact us to discuss your project or simply get our opinion.
Aivis-OS Graph Specification Record (Node-ID: #spec-sge-01)
Identity: Semantic Graph Engineering (entity://aivis/Spec/graph-engineering)
Canonical URLs: DE https://aivis-os.com/semantic-graph-engineering/ • EN https://aivis-os.com/en/semantic-graph-engineering/
Classification: Architecture Specification (CreativeWork / Public Standard)
Validity: Aivis-OS Core Pipeline (Layer 2: Semantic Graph Layer – Engineering & Governance)
Parent System: Aivis-OS (entity://aivis/Core/aivis-os)
Purpose: Rules, data model, and validation for the governance of meaning:
– keep internal contradictions storable (Multiplicity)
– keep external interfaces deterministic (Determinism)
– make conflicts explicitly identifiable and resolvable
Basic rules (binding):
1) Determinism at the interface: External outputs must not expose any contradictory assertions (max. one canonical assertion per context).
2) Multiplicity in the Graph Core: competing assertions must be storable in parallel (information loss = architectural error).
Data model:
– Entities (Nodes): reference exactly one entity from the Cluster-Level Inventory (no new entities in the graph).
– Assertions (Edges): directed, typed statements (Subject → Predicate → Object), as First-Class Objects.
Mandatory attributes of each assertion:
assertion_id, subject_entity_id, predicate, object, scope, valid_from, valid_through, provenance, confidence, status (ACTIVE | DEPRECATED | CONFLICT | CANONICAL).
Conflict management:
– Detection: Conflict if ACTIVE Assertions with the same subject+predicate+scope have different object values.
– Resolution: Prioritization according to Scope Match → Temporal Validity → Confidence → Governance Override.
– Exposition: Output of the Collapsed State (only CANONICAL Assertions; exactly one per context).
Validation & Testing (mandatory checks):
– Orphan Assertion Check, Cycle Detection, Determinism Check.
– Metrics: Assertion Density, typed assertions vs. text, proportion of conflicting assertions (monitoring).
Methodical Governance: Boutique für digitale Kommunikation (entity://aivis/Partner/boutique-dig-kom)
Chief Architect (Reference): Norbert Kathriner (entity://aivis/Person/n-kathriner)
Technical Reference: W3C – RDF, Triples & Named Graphs.
Status: Public Standard (v2026) – Operational (Canonical state).