> > > SpecLogosSvoSemanticsSpec

Logos SVO Semantics Specification

Purpose

This specification defines the semantic core of the Logos Subject-Verb-Object model. It describes how Subject, Action, Object, and object state references form a typed organizational model before any projection format is selected.

Logos SVO is the source model. BPMN, UML, Mermaid, PlantUML, D2, UI forms, database materializations, and auxiliary JSON artifacts are projections of that model.

Scope

This document covers:

the SVO transformation principle;
core element types;
object state references;
symbol-table and reference resolution;
semantic graph construction;
inferred process graph construction;
include versus use;
process interface inference.

Non-Goals

This document does not define BPMN-specific constructs; see ProjectionBpmn.md.
This document does not define the general projection mapping layer; see ProjectionMappingSpec.md.
This document does not define the canonical grammar of every Logos file type; see LogosLanguageSpec.md and LogosFileSpec.md.

Terminology

Term	Meaning
Subject	Actor, role, system, organizational unit, or autonomous participant.
Action	Semantic transformation that consumes inputs, involves subjects, and produces outputs.
Object	Thing, document, resource, data item, material, claim, state carrier, or output.
Object state	Qualified object reference such as `Invoice[approved]`.
Semantic graph	Graph of subjects, actions, objects, states, and relationships.
Process graph	Derived action-to-action graph inferred from object/state dependencies.
Process interface	Declared or inferred inputs, outputs, exposed actions, and consumed dependencies of a process module.

Model or Contract

SVO Transformation

The core transformation pattern is:

Object/Input State -> (Subject performs Action) -> Object/Output State

An action is not merely a workflow box. It is a typed transformation with explicit preconditions and products. Sequence is inferred from state compatibility, not drawn as a primary fact.

Core Element Types

Subject defines the performer or responsible participant.

Object defines the state carrier being consumed, produced, stored, moved, or interpreted.

Action defines the transformation. It should normally declare in, out, and a performer-like relation (performer, actor, system, subject, or a relationship that resolves to a subject).

Object State References

An object reference may include a state:

Invoice[received]
Invoice[registered]
Invoice[paid]

The object identity and state qualifier are separate semantic dimensions. The same object may appear in several states across a process. A state transition does not create a new object type unless the model explicitly declares one.

Symbol Table and Reference Resolution

The compiler builds a symbol table for declared elements and aliases. Reference resolution must:

resolve element IDs before labels;
preserve stable IDs;
detect duplicate IDs;
detect unresolved references;
normalize object state references;
preserve source provenance for diagnostics.

Semantic Graph

The semantic graph links:

subjects to actions through performer/responsibility relations;
actions to input objects and states;
actions to output objects and states;
hierarchy and membership relations;
explicit domain relations declared in the source model.

The semantic graph is notation-neutral. It is the contract consumed by the projection mapping layer.

Inferred Process Graph

The process graph is derived from the semantic graph. The basic rule is:

Action A precedes Action B
if A produces an object/state consumed by B.

The inferred edge is a semantic dependency. A projection may render it as a sequence flow, message flow, transition, call relation, UI dependency, or database-derived relation depending on the selected target.

Include and Use

include composes physical files into one logical model. It is for splitting a large model into maintainable source files.

use or import declares a semantic dependency on another process, module, or library model. It is for cross-process and cross-module dependency.

Do not use include to mean process dependency.

Process Interface

A process module should declare or imply:

external inputs;
produced outputs;
exposed actions;
consumed definitions;
stable IDs.

Two process modules can be related if the outputs of one intersect the inputs of the other. This enables process maps, value stream views, dependency graphs, and BPMN collaborations without merging every process into one diagram.

Rules

SVO semantics are independent of any projection notation.
Sequence must be inferred from object/state dependencies unless an explicit modeling rule says otherwise.
Decisions are action attributes or rules, not primary ontology elements.
Start and end points are projection-scope artifacts unless declared as domain events or facts.
Reachability is evaluated within a selected process scope.
Semantic warnings should distinguish invalid models from legitimate external inputs or process outputs.

Examples

element Accountant
    type: Subject

element Invoice
    type: Object

element RegisterInvoice
    type: Action
    performer: Accountant
    in: Invoice[received]
    out: Invoice[registered]

element PayInvoice
    type: Action
    performer: Accountant
    in: Invoice[registered]
    out: Invoice[paid]

The inferred process dependency is:

RegisterInvoice -> PayInvoice

The reason is semantic: RegisterInvoice produces Invoice[registered], which PayInvoice consumes.

Validation

The compiler should validate:

unresolved references;
duplicate stable IDs;
action without performer when performer is required by profile;
action without meaningful input or output when strict mode requires transformation;
ambiguous output-to-input matches;
invalid include or use cycles;
process interface mismatch.

Compatibility

Existing BPMN-specific examples should be interpreted as projection examples, not as SVO ontology. BPMN terminology belongs in ProjectionBpmn.md. SVO terminology belongs here.

Open Questions

Which strict-mode warnings should be required for MVP and which should remain advisory?
Should Decision remain only an action attribute, or should some future profile allow explicit decision elements as projection hints?

SOTER