| Authority | FROZEN |
|---|---|
| Version | v0 |
| Last Amended | 2026-03-26 |
| Scope | Four primitives, wiring matrix, causal roles |
| Verified Against Tag | v1.0.0-alpha.1 |
| Change Rule | v1 only |
This document defines the foundational ontology of the system. It establishes what is primitive, what is composed, and what is explicitly out of scope.
This ontology is intentionally minimal. It is designed to remain stable even as the system grows in complexity.
To qualify as a foundational ontological primitive, a candidate must satisfy all of the following:
- Irreducible — It cannot be expressed as a composition of other primitives.
- Distinct Causal Role — It plays a unique role in the causal structure of an executable system.
- Execution-Real — It exists and operates at runtime, not only at authoring or conceptual time.
- Non-Normative — It does not encode policy, preference, belief, or subjective judgment.
- Universally Required — It is required for any executable decision system, not only trading systems.
Anything that fails one or more of these criteria is not an ontological primitive.
The system defines exactly four ontological primitives. This set is closed.
Role: Introduces data into the system.
A Source answers: What exists at this evaluation point?
Characteristics:
- No inputs
- No transformation of graph-derived inputs; adapter shaping only
- No inference
- No side effects
- Deterministic data materialization from node parameters plus the current
ExecutionContext
Source may "materialize" values from the environment, but may not "derive" values from other graph values. Adapter behavior is a trust boundary; semantic shaping must be declared as parameters or adapter metadata.
Source establishes origin, not meaning.
Role: Transforms values deterministically.
A Compute answers: What is true, given these inputs?
Characteristics:
- Pure
- Deterministic
- Side-effect free
- May be stateless or stateful (if explicitly declared)
- Must declare at least one input (zero-input nodes are Sources by definition)
Compute establishes truth, not causality or intent.
Role: Converts continuous values into discrete events.
A Trigger answers: When does something happen?
Characteristics:
- Emits events
- No side effects
- Deterministic
- Stateless. Execution-local bookkeeping (ephemeral scratch during evaluation) is permitted but does not constitute state—it is not observable, serializable, or preserved across evaluations.
Trigger parameters may encode temporal structure only and must not condition on action semantics or outcomes. Trigger governs when events propagate; it is blind to downstream action content and consequences.
Trigger and Compute share execution semantics; they differ in declared causal role and wiring permissions.
Trigger establishes causality, not action.
Amended 2025-12-28 by Sebastian (Freeze Authority)
Prior language stating "May hold internal state" was a semantic error that conflated execution-local bookkeeping with ontological state. This amendment aligns ontology.md with execution.md §5 and freeze.md §2.6. Triggers are stateless primitives.
See: TRG-STATE-1 in invariants/INDEX.md
Role: Attempts to affect the external world.
An Action answers: What command is attempted as a result of this event?
Characteristics:
- Consumes events
- Causes side effects
- Deterministic command emission
- No internal state
- Emits non-causal outputs (see below)
Action outputs are non-causal and take two forms:
- Outcome records — exactly one non-wireable
outcomeoutput per evaluation pass (includingSkippedwhen gating suppresses execution) - Effect descriptions — zero or more non-causal operational instructions for post-episode realization
Neither participates in graph causality. Outcome records are metadata for accountability and are only surfaced if mapped to graph boundary outputs. Effect descriptions are operational instructions emitted as intent. Adapters declare which effect kinds are accepted; host-facing run/report surfaces carry the buffered effects separately; host dispatches these descriptions after episode completion; host-internal effects may be realized by host handlers, while truly external effects cross prod boundary channels.
Action establishes agency, not logic or policy.
Amended 2026-01-11 by Claude (Structural Auditor)
Prior language mentioned only "acknowledgment records" without distinguishing them from effect descriptions. This amendment clarifies that Actions emit two types of non-causal outputs: acknowledgments (to orchestrator) and effects (to the host boundary for dispatch). Both are non-causal; effects enable the cross-episode state pattern described in execution.md §5.4. Sebastian override authorization.
Amended 2026-03-15 by Codex (Docs)
Clarified that effect descriptions are post-episode intent records, not direct graph-time world work. Adapters declare the accepted contract, host dispatches after the episode, and true external I/O belongs to prod boundary channels rather than the graph itself. Sebastian freeze-authority authorization.
Amended 2026-03-16 by Codex (Docs)
Corrected the earlier amendment note so the historical wording no longer implies that effect descriptions are executed "to adapter" rather than dispatched at the host boundary. Sebastian freeze-authority authorization.
The following wiring rules are authoritative for v0:
Source → Compute : allowed
Source → Trigger : forbidden (v0)
Source → Action : allowed only for non-Event payload inputs (non-Event payload types: Number/Series/Bool/String); does not satisfy Action gate requirement
Compute → Compute : allowed
Compute → Trigger : allowed
Compute → Action : allowed only for non-Event payload inputs (non-Event payload types: Number/Series/Bool/String); does not satisfy Action gate requirement
Trigger → Trigger : allowed
Trigger → Action : allowed for Event gate inputs only (Event → Event); every Action must have at least one Trigger-provided Event input
Action → * : forbidden (terminal)
* → Source : forbidden
For Action edges, wiring legality is determined per edge by the destination Action input port type: Action execution is gated solely by Event inputs, and non-Event payload inputs (Number/Series/Bool/String) are values only and do not determine whether an Action runs.
Graphs violating these rules are invalid.
Some concepts are essential for authoring, but not ontological primitives. These are macro-primitives.
Macro-primitives:
- Are composed from ontological primitives
- Exist for ergonomics and intent expression
- Compile away before execution
- Add no new runtime semantics
Risk is not an ontological primitive.
Reason:
- Risk is normative
- Risk is subjective
- Risk encodes policy and preference
- Risk is fully expressible via Compute (measurement), Trigger (violation detection), and Action (enforcement)
Risk answers: Is this intent allowed to proceed?
That is a policy question, not a causal role.
Risk therefore exists as a macro-primitive: UI-visible, reusable, composable, compiled into compute → trigger → action.
The distinction between Risk and temporal patterns often described as throttle/debounce/once/latch behavior in v0:
- Trigger primitives govern when events propagate (temporal semantics)
- Risk operators govern whether actions execute (acceptability of outcomes)
- Memoryful temporal behavior is expressed as composition, not as primitive trigger operators
- Trigger primitives are blind to action content; Risk operators are not
These follow the same rule as Risk:
- Not execution-real
- Not causal
- Not irreducible
They are named compositions, not primitives.
The following concepts are explicitly not primitives:
- State — orthogonal property, not a causal role
- Time — data/context, introduced via Source
- Event — value type, not a role
- Intent — runtime-real effect metadata, but not a separate ontological primitive
- Belief / Uncertainty — epistemic, not causal
- Environment — interface, not mechanism
- Evaluation / Execution — infrastructure, not a primitive
Each of these either collapses into an existing primitive or exists outside the execution ontology.
All executable behavior in the system is expressed as compositions of:
Source → Compute → Trigger → Action
This is the canonical explanatory flow; the implementation is a DAG with role-constrained edges.
No additional ontological primitives are permitted.
Higher-level constructs must:
- Decompose into these primitives
- Obey their manifest contracts
- Compile away before execution
This ontology is designed to be:
- Minimal
- Non-overlapping
- Deterministic
- Future-proof
New features must be added via composition, not new primitives.
The following features are explicitly out of scope for v0. When added in future versions, they must preserve the invariants listed:
- Trigger state introspection — must not allow mutation
- Action feedback wiring — must not introduce cycles in a single evaluation pass; must preserve DAG or introduce explicit multi-phase execution
- Presence triggers (Source → Trigger) — must not bypass Compute semantics
- Outcome events — must preserve DAG or introduce explicit multi-phase execution
- Multi-graph coordination — must remain an orchestration concern, not introduce new primitives
The ontological primitive set is complete.
No additional foundational abstractions are required or permitted.
This ontology is the authoritative foundation of the system.
The authoring layer enables composition of primitives into reusable, nestable structures. It is specified separately in concepts.md and cluster-spec.md.
- Authoring constructs are called clusters
- Clusters may contain primitives and other clusters (arbitrary nesting)
- Clusters have boundary kinds that mirror the four primitives: SourceLike, ComputeLike, TriggerLike, ActionLike
- The wiring matrix applies to clusters exactly as it applies to primitives
All authoring constructs compile away before execution.
At runtime, only the four ontological primitives exist. The authoring layer provides ergonomics and modularity without expanding the ontology.
📍 Specified in: concepts.md, cluster-spec.md