Vocabulary

Purpose: Canonical reference for how every key concept is named, defined, and used across all blog posts, website copy, documentation, and marketing material. Consistent terminology is a trust signal. Inconsistent terminology erodes it.

Structure: Five registers — Platform, Architecture, Governance, OS Agents, Infrastructure. Each entry: canonical form, plain-English definition, technical definition, never-use synonyms, phase introduction (blog series), related terms.

How to use this document link

• Canonical form is the exact spelling, capitalisation, and phrasing that must appear in all published content.
• Never use lists the alternatives that must not appear — even informally in drafts, because drafts become posts.
• Phase refers to the blog series phase in which the term is introduced by name. Before that phase, describe the concept without naming it.
• Related terms are cross-references within this vocabulary — always use the canonical form when referencing them.

Register 1 — Platform concepts link

These are the highest-level terms. They define what Synedrix OS is, how it is packaged, and how it relates to the businesses that use it.

Synedrix OS link

Canonical form: Synedrix OS (always both words, always capitalised, never abbreviated to “the OS” on first mention in a new piece)

Plain-English: The governed operating layer for agentic business systems. A reusable software substrate on which business domain packs run — not an application, not a chatbot platform, not a collection of AI features.

Technical: A reusable multi-agent operating system providing orchestration, agent lifecycle management, memory primitives, governance, tool mediation, and observability for business execution.

Never use: Synedrix platform, the Synedrix system, our AI platform, the agentic platform, the OS (first mention only)

Phase: Post 04 (first brand mention). Posts 01-03 describe the category without naming it.

Related terms: domain pack, business instance, operating substrate, governed operating layer

Operating substrate link

Canonical form: operating substrate (lowercase)

Plain-English: The shared foundation that every domain pack runs on. It provides orchestration, governance, and observability so that domain packs do not need to rebuild these capabilities themselves.

Technical: The domain-agnostic layer of Synedrix OS comprising the orchestration runtime, agent registry, policy engine, memory abstractions, event schema, and observability framework — all inherited by domain packs without modification.

Never use: base layer, platform layer, shared infrastructure, common layer, foundation layer

Phase: Post 04

Related terms: Synedrix OS, domain pack, business instance

Domain pack link

Canonical form: domain pack (always two words, always lowercase)

Plain-English: A modular business capability package that runs on Synedrix OS and introduces everything specific to one business domain — its agents, workflows, events, tools, and policies. Examples: Synedrix Trading, Synedrix Commerce, Synedrix Ops.

Technical: A modular package that contributes domain-specific entities, events, agents, workflows, tool adapters, domain policies, KPIs, and analytics vocabulary to a Synedrix OS business instance. It inherits the OS substrate rather than reimplementing it.

Never use: module, plugin, vertical, domain module, business module, app, add-on, extension

Phase: Post 05

Related terms: Synedrix OS, business instance, operating substrate, rule of inclusion, Capability Module

Business instance link

Canonical form: business instance (always two words, always lowercase)

Plain-English: A deployed runtime combining Synedrix OS with one or more domain packs, configured for a specific company, team, or business unit. This is where credentials, thresholds, and approver assignments live.

Technical: A deployed runtime composed of Synedrix OS plus one or more domain packs, with tenant-specific configuration — thresholds, secrets, approver mappings, enabled workflows, and environment settings.

Never use: tenant, deployment, installation, instance, customer environment, client setup

Phase: Post 05

Related terms: domain pack, Synedrix OS, rule of inclusion, Business Instance Extension

Business Instance Extension (BIE) link

Canonical form: Business Instance Extension (capitalised, full form on first mention; BIE is the defined acronym thereafter)

Plain-English: A customization built for exactly one customer’s business instance — never reused elsewhere. It can be a configuration value, a policy parameter, a workflow hook, a customer-specific agent, or an adapter mapping.

Technical: A customer-specific, non-reusable customization layer registered under a single business instance; a governed overlay within the Business Instance layer, not a numbered architectural layer. Registered as a first-class artifact — discoverable by the Registry & Capability Agent, governed by Policy Guard, traced by Audit & Lineage.

Never use: extension (bare), instance plugin, custom module, tenant extension

Phase: Post 05

Related terms: business instance, domain pack, Capability Module, rule of inclusion, extension point

Capability Module link

Canonical form: Capability Module (capitalised, two words)

Plain-English: An optional, sellable capability a domain-pack vendor builds once and licenses to specific customers, without forking the base pack.

Technical: A reusable, independently versioned, licensable sub-package of a domain pack that contributes agents and workflows to the shared registry using the same schema as core domain-pack agents, enabled per business instance via an explicit entitlement flag. Never bundled into the base pack by default; never a Business Instance Extension.

Never use: add-on, plugin, sub-pack, module (bare)

Phase: Post 05

Related terms: domain pack, Business Instance Extension, entitlement flag

Extension point link

Canonical form: extension point (lowercase)

Plain-English: A named place in a domain pack’s workflow where a customer’s Business Instance Extension is explicitly allowed to attach a hook.

Technical: A hook point a domain pack declares in its instance configuration boundary (extension_points), specifying an invocation pattern (event or sub_workflow) a Business Instance Extension may bind to. A pack that declares no extension points accepts no Business Instance Extension hooks.

Never use: hook (bare, without “extension point”), plugin point, override point

Phase: Post 05

Related terms: Business Instance Extension, domain pack, workflow contract

Entitlement flag link

Canonical form: entitlement flag (lowercase)

Plain-English: The per-customer switch that turns a Capability Module on or off.

Technical: The business-instance-owned value that gates whether a given Capability Module’s agents and workflows are active for that instance. Inactive by default; a Capability Module’s registry entries exist platform-wide, but only entitled instances may invoke them.

Never use: license flag, feature flag (a general term; this is the specific Capability Module gate), access flag

Phase: Post 05

Related terms: Capability Module, business instance

Domain-pack version pin link

Canonical form: version pin (short form in running prose); domain_pack_version (when referencing the field)

Plain-English: The specific version of a domain pack a business instance has actually chosen to run — never automatically bumped when the vendor publishes a newer one.

Technical: The domain_pack_version field a business instance owns and explicitly updates via a governed, audited action. Publishing a new domain-pack, Capability Module, or Business Instance Extension version registers it in the shared registry; it never propagates into a running instance until the instance updates its own pin.

Never use: pinned version (as a bare noun phrase without “domain-pack”), locked version, frozen version

Phase: Post 05

Related terms: domain pack, business instance, agent registry, append-only

Rule of inclusion link

Canonical form: rule of inclusion (lowercase)

Plain-English: The decision rule that determines which tier of the platform owns a given capability. Reusable across domains without domain knowledge belongs to the OS. Domain-specific logic belongs to the domain pack. Thresholds and credentials belong to the business instance.

Technical: The three-condition boundary test: (1) if a capability is reusable across domains without domain knowledge, it belongs in the OS; (2) if it requires domain entities, tools, or policies, it belongs in the domain pack; (3) if it is a threshold, credential, or environment setting, it belongs in the business instance.

Never use: responsibility split (this is the matrix, not the rule), ownership rule, tiering rule

Phase: Post 05

Related terms: domain pack, business instance, responsibility matrix, operating substrate

Responsibility matrix link

Canonical form: responsibility matrix (lowercase)

Plain-English: The full capability-by-capability table that records what Synedrix OS owns, what domain packs own, and what business instances configure. The rule of inclusion applied to every concern in the platform.

Technical: The canonical per-capability ownership split across OS, domain pack, and business instance tiers, as defined in Synedrix OS - Responsibility Matrix v0.2.

Never use: RACI, ownership table, responsibility chart

Phase: Post 05

Related terms: rule of inclusion, domain pack, business instance, org chart

Coordination debt link

Canonical form: coordination debt (lowercase, no hyphen)

Plain-English: The accumulated cost of using humans as middleware between systems — the time lost to status chasing, context translation, routing decisions, and approval handoffs that could be handled by an orchestrated system.

Technical: The systemic inefficiency created when human actors perform coordination tasks — routing, translating, escalating, reconciling — that could be handled by orchestrated multi-agent workflows under explicit policy.

Never use: process inefficiency, operational overhead, coordination overhead, workflow debt

Phase: Post 01 (series-opening concept)

Related terms: orchestration, human-in-the-loop, workflow, operating substrate

Agentic system link

Canonical form: agentic system (lowercase)

Plain-English: A software system where specialised agents collaborate under orchestration to achieve goals — reacting to events, routing work dynamically, and handling exceptions within their authority rather than handing everything back to a human.

Technical: A multi-agent system in which specialised agents with declared authority boundaries participate in orchestrated workflows, governed by a shared policy engine and observable through a shared event and tracing infrastructure.

Never use: AI system (too broad), autonomous system (implies no human control), agent-based system, multi-agent system (acceptable but less precise)

Phase: Post 03 (introduced as a category); Post 04 (Synedrix OS named as an example)

Related terms: orchestration, agent, workflow, governance

Governed operating layer link

Canonical form: governed operating layer (lowercase, no hyphen)

Plain-English: The positioning phrase for Synedrix OS. “Governed” because policy enforcement, audit, and human control are built into the runtime rather than added on top. “Operating layer” because it provides shared infrastructure that every domain pack above it depends on.

Technical: The combination of a reusable multi-agent operating substrate with native governance primitives — policy enforcement, authority boundaries, HITL checkpoints, and immutable audit trails — enforced at the OS layer for all domain packs simultaneously.

Never use: AI governance platform, governed AI platform, governance layer (governance is a component, not the full layer)

Phase: Post 04

Related terms: Synedrix OS, governance, operating substrate

Coordination model link

Canonical form: coordination model (lowercase)

Plain-English: The structural pattern by which an organisation moves information, routes decisions, and manages handoffs. The claim of the series is that the dominant coordination model — meetings, inboxes, approvals, spreadsheets — is the problem, and an agentic operating layer replaces it.

Technical: The set of mechanisms by which goals, tasks, information, and decisions flow between actors in a business system. Synedrix OS replaces the human-middleware coordination model with an orchestrated, policy-governed, event-driven equivalent.

Never use: operating model (broader and often used in a strategy context), workflow model, process model

Phase: Post 01

Related terms: coordination debt, orchestration, workflow, work chart, org chart

Org chart link

Canonical form: org chart (two words, lowercase)

Plain-English: The chart of who is accountable to whom inside an organisation: leadership, authority and sign-off. In an agent-run organisation it still answers who is accountable, not who does the work.

Technical: The human accountability structure. It is distinct from the work chart, which describes how work moves, and from the responsibility matrix, which splits ownership across Synedrix OS, domain packs and business instances. Synedrix OS reads its twelve agents as a coordination model beneath the org chart and never as a hierarchy of machine executives, per ADR-OS-015.

Never use: responsibility chart (reserved against responsibility matrix), agent hierarchy, agent org chart, reporting line (when applied to agents)

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: work chart, responsibility matrix, coordination model, human domain steward

Work chart link

Canonical form: work chart (two words, lowercase)

Plain-English: How work actually moves through an organisation: tasks and outcomes exchanged between people and agents, with escalation points where a human must decide. It sits alongside the org chart rather than replacing it.

Technical: The execution-side counterpart to the org chart. In Synedrix OS it is expressed by the work graph: goals decomposed into task graphs, executed by agents under policy, with declared escalation paths ending at named human roles. Accountability stays on the org chart; execution lives on the work chart.

Never use: agent org chart, AI org chart, agent hierarchy

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: org chart, agentic organisation, coordination model, human domain steward

Agentic organisation link

Canonical form: agentic organisation (British spelling, lowercase)

Plain-English: An organisation in which agents carry out much of the day-to-day work and people remain accountable for outcomes, approvals and exceptions.

Technical: An organisation whose work graph is largely executed by governed agents, with accountability and authority held by humans through the control roles derived from agent escalation paths. Descriptive term only: it asserts no headcount, job design or maturity stage.

Never use: autonomous organisation, AI-run company, lights-out organisation

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: work chart, org chart, human middleware, coordination model

Human middleware link

Canonical form: human middleware (lowercase, no hyphen)

Plain-English: The role humans are forced to play when they act as the translation layer between siloed systems — reformatting data, routing requests, chasing status, and reconciling state that the systems cannot exchange directly.

Technical: Human actors performing coordination tasks that could be handled by an orchestrated system — routing, context translation, state reconciliation, approval handoff — typically because systems lack interoperability and shared context.

Never use: manual work, human bottleneck, human translation layer (acceptable variant but less precise)

Phase: Post 01

Related terms: coordination debt, coordination model, orchestration

Register 2 — Architecture link

These terms define how the platform is built — its layers, components, and structural patterns.

Orchestration link

Canonical form: orchestration (lowercase)

Plain-English: The layer that decomposes goals into tasks, routes each task to the right agent, manages sequencing, handles retries and timeouts, and inserts approval checkpoints. The stable center of the system — not a thin message router, and not a fat agent.

Technical: The process of goal decomposition, workflow selection, task routing to specialist agents, parallelism and sequencing management, retry and timeout coordination, approval checkpoint insertion, and escalation handling. In Synedrix OS, orchestration is the responsibility of the Orchestrator Agent and the workflow contract layer.

Never use: workflow engine (too narrow), AI conductor, agent coordinator, pipeline

Phase: Post 03 (described without being named); Post 07 (named explicitly)

Related terms: Orchestrator Agent, workflow, goal, task, agent

Orchestrator Agent link

Canonical form: Orchestrator Agent (capitalised — it is a proper noun, an OS-owned agent)

Plain-English: The OS-owned agent responsible for orchestration. It routes and sequences work but never executes domain-specific business logic, makes domain decisions, or writes to external systems directly.

Technical: OS-owned control agent (os-agt-001). Decision scope: execute (invokes agents and workflows). Does not own domain heuristics. All side effects are delegated to specialist agents through governed invocation.

Never use: orchestration agent, the orchestrator (acceptable shorthand after first mention in a post), coordinator agent, routing agent

Phase: Post 07

Related terms: orchestration, agent, workflow, decision scope

Agent link

Canonical form: agent (lowercase unless part of a proper name)

Plain-English: A software actor with a single defined job, a clear boundary on what it can do, and an explicit path for escalating what it cannot. Not a chatbot. Not a general-purpose assistant.

Technical: A scoped software component with a declared mission, authority boundary, input/output contract, tool permissions, memory scope, and escalation path. Participates in workflows; does not own them.

Never use: bot, AI assistant, AI worker, virtual assistant, autonomous system, model, AI agent (redundant — agent is already an AI concept in this context)

Phase: Post 01 (described without naming); Post 04 (named as “agent”)

Related terms: agent archetype, authority boundary, agent registry, decision scope, workflow

Agent archetype link

Canonical form: agent archetype (lowercase)

Plain-English: The category of role an agent plays in the system, which determines its authority profile. There are six archetypes: control, execution, intelligence, interface, interop, and audit.

Technical: The six canonical archetype classifications in Synedrix OS: control (routing, policy, registry), execution (domain actions with side effects), intelligence (analysis and forecasting, no direct side effects), interface (human-facing assistants), interop (A2A/MCP protocol agents), audit (read-only explainability and trace synthesis). Not the same axis as agent family (below): archetype classifies the kind of work an agent does; family classifies which OS-owned governance grouping it belongs to. The two enums share the labels “control” and “intelligence” by coincidence, not because they are the same classification — Audit & Lineage Agent (os-agt-008) is the clearest case where they diverge: archetype audit, family Observability.

Never use: agent type, agent category, agent class (class is a capability tag namespace, not the archetype)

Phase: Post 08

Related terms: agent, agent family, authority boundary, decision scope, capability tag

Agent family link

Canonical form: agent family (lowercase; capitalised as a proper adjective when naming one — Control, Intelligence, Observability)

Plain-English: Which of the three OS-owned groupings an agent belongs to — Control, Intelligence, or Observability. This is a different classification from agent archetype (above): family groups agents by governance role within the OS-owned registry; archetype groups agents by the kind of work they perform. The two are easy to conflate because “control” and “intelligence” happen to be spelled the same way in both, but they answer different questions and a single agent’s values on the two axes can differ.

Technical: The family field of the agent registry schema (Agent Registry §2). Five enum values: control, intelligence, observability for the twelve OS-owned agents, plus domain and customer reserved for domain-pack-contributed agents — domain packs may not register into control or observability. Not to be read off agent archetype: Audit & Lineage Agent (os-agt-008) is family observability with archetype audit; General Chat Agent (os-agt-009), Consolidation & Reflection Agent (os-agt-011), Memory Curator Agent (os-agt-010), and Memory Access Broker Agent (os-agt-012) are the other agents worth checking directly against the registry rather than assuming from the name.

Never use: agent category (ambiguous with archetype), agent type, agent group, agent class (class is a capability tag namespace, distinct from both family and archetype)

Phase: Post 08

Related terms: agent archetype, agent registry, decision scope

Specialised agent link

Canonical form: specialised agent (note: use British spelling throughout — specialised not specialized, organised not organized, governed not just governed)

Plain-English: An agent with a single, sentence-stateable mission — narrow by design so that its failure surface is narrow, its authority is auditable, and it can evolve without restructuring the system around it.

Technical: An agent conforming to the Synedrix OS design principle of narrow mission, explicit authority boundary, testable contracts, and fault isolation — as opposed to a mega-agent that combines multiple responsibilities.

Never use: focused agent, narrow agent, single-purpose agent

Phase: Post 08

Related terms: agent, mega-agent, agent archetype, authority boundary, mission

Mega-agent link

Canonical form: mega-agent (hyphenated, lowercase)

Plain-English: An anti-pattern — a single agent designed to handle multiple responsibilities that should be separated across specialised agents. Fails for the same reasons as monolithic software.

Technical: An anti-pattern in which a single agent combines orchestration, domain logic, tool execution, and governance responsibilities, producing an unrestricted authority surface, an opaque failure mode, and an ungovernable system.

Never use: general-purpose agent, all-in-one agent (use mega-agent consistently as the named anti-pattern)

Phase: Post 08

Related terms: specialised agent, agent archetype, authority boundary

Mission link

Canonical form: mission (lowercase)

Plain-English: The single sentence that defines why an agent exists and what it does. If it cannot be written in one sentence, the agent is doing too much.

Technical: The top level of the four-level hierarchy (mission / goal / task / action). Owned by the agent, static, versioned with the agent definition. Defines the agent’s purpose independent of any specific workflow invocation.

Never use: purpose (acceptable in plain prose but mission is the canonical term), role, function, job

Phase: Post 08

Related terms: goal, task, action, agent, workflow

Goal link

Canonical form: goal (lowercase)

Plain-English: A bounded desired outcome in a specific context, handed by the orchestration layer to the workflow system. Goals are workflow-owned, not agent-owned.

Technical: The second level of the four-level hierarchy. Workflow-owned and defined in the workflow contract’s purpose field. The orchestrator decomposes goals into tasks — goal decomposition is the orchestration layer’s responsibility, not the agent’s.

Never use: objective (acceptable in plain prose but goal is the canonical term), target

Phase: Post 07

Related terms: mission, task, action, orchestration, workflow contract

Task link

Canonical form: task (lowercase)

Plain-English: A structured unit of work handed by the orchestrator to a specific agent. The agent only sees the task it has been handed — not the goal, not other tasks running in parallel.

Technical: The third level of the four-level hierarchy. Orchestration-owned. Created by the orchestrator decomposing a goal, assigned to an agent via the workflow role and input contract at invocation time. Its start record is written to agent_invocations before execution; its terminal outcome is recorded separately.

Never use: job, work item, unit of work

Phase: Post 07

Related terms: goal, action, orchestration, agent invocation

Action link

Canonical form: action (lowercase)

Plain-English: A single atomic step an agent performs to complete a task — typically a tool call, a write, an event emission, or a structured output.

Technical: The fourth and lowest level of the four-level hierarchy. Agent runtime-owned. Executed within the agent’s authority envelope. Recorded in the tool call log and Langfuse trace.

Never use: step, operation (acceptable in SQL context but not agent context), execution

Phase: Post 07

Related terms: task, tool call, tool binding, agent invocation

Workflow link

Canonical form: workflow (one word, lowercase)

Plain-English: An orchestrated sequence of events, tasks, agent invocations, and tool calls designed to produce a business outcome. Every workflow has a contract.

Technical: An orchestrated sequence of events, tasks, agent invocations, and tool calls governed by a workflow contract that declares its inputs, outputs, side effects, approval requirements, agent roles, and observability signals.

Never use: pipeline, process, automation, flow, runbook

Phase: Post 03

Related terms: workflow contract, orchestration, agent, workflow class

Workflow contract link

Canonical form: workflow contract (two words, lowercase)

Plain-English: The formal declaration that makes a workflow governable — it states the workflow’s inputs, outputs, every side effect, which agents participate, what approvals are required, and what gets observed. A workflow without a contract is ungovernable.

Technical: A 14-section structured declaration covering: workflow ID, domain, version, purpose, trigger, input contract, validation rules, agent roles, tool dependencies, side effects, approval requirements, output contract, idempotency strategy, retry policy, error policy, observability signals, and security scope.

Never use: workflow spec (acceptable but less precise), workflow definition, workflow schema

Phase: Post 16

Related terms: workflow, side effect declaration, approval requirements, observability

Workflow class link

Canonical form: workflow class (lowercase)

Plain-English: The category of a workflow, which determines which sections of its contract are mandatory. Five classes: operational, decision-support, approval-gated, asynchronous callback, monitoring and alerting.

Technical: One of five canonical workflow classifications in Synedrix OS: operational (deterministic pipelines), decision-support (recommendations, no high-impact writes), approval-gated (policy or HITL required before side effects), asynchronous callback (submit-then-callback), monitoring and alerting (detection workflows emitting incidents).

Never use: workflow type, workflow category

Phase: Post 16

Related terms: workflow contract, approval requirements

Side effect link

Canonical form: side effect (two words, lowercase)

Plain-English: Any persistent or external write produced by a workflow — a database write, an API call, an email sent, a payment triggered. Every side effect must be declared in the workflow contract. Undeclared side effects are a compliance violation.

Technical: Any durable or externally visible action produced by a workflow execution — including writes to data stores, calls to external systems, notifications, and financial transactions. Declared in the side_effects section of the workflow contract.

Never use: external action, write operation, output action

Phase: Post 16

Related terms: workflow contract, approval requirements, governance

Event link

Canonical form: event (lowercase)

Plain-English: A fact — a record that something happened, with a timestamp, a source, and a correlation identity. Not an instruction. Not a command. An event tells the system what occurred; it is the system’s job to decide what happens next.

Technical: An immutable fact conforming to the Synedrix OS common event envelope, emitted by an agent, workflow, tool adapter, or external system to record that a state change occurred. Events encode facts, not instructions.

Never use: message, signal (acceptable in plain prose but event is canonical), notification (specific delivery mechanism, not the same as an event), command (events are facts; commands are instructions — a category error)

Phase: Post 03 (used without definition); Post 17 (defined explicitly)

Related terms: event envelope, correlation ID, causation ID, event taxonomy

Event envelope link

Canonical form: event envelope (two words, lowercase)

Plain-English: The shared structure that wraps every event in the system — the common set of fields (event ID, event type, source, timestamp, correlation ID, causation ID, policy context, and others) that all events must carry, regardless of domain.

Technical: The canonical common event container defined in Synedrix OS - Event Taxonomy Standard v0.2, comprising: event_id, event_type, domain, entity_type, entity_id, source_type, source_id, timestamp, correlation_id, causation_id, payload, policy_context, severity, version.

Never use: event schema, event wrapper, event container, event structure

Phase: Post 17

Related terms: event, correlation ID, causation ID, event taxonomy

Correlation ID link

Canonical form: correlation ID (two words, capital I in ID)

Plain-English: The identifier that links every event in a single end-to-end journey — from the first trigger through every agent, workflow, and tool call involved. A missing correlation ID is a lineage gap.

Technical: A stable identifier threaded through all events, invocations, and tool calls belonging to a single business transaction or goal execution. Required field in the event envelope. Preserved across async boundaries and A2A interactions.

Never use: trace ID (this is a different concept in Langfuse), request ID, transaction ID

Phase: Post 17

Related terms: causation ID, event envelope, lineage, observability

Causation ID link

Canonical form: causation ID (two words, capital I in ID)

Plain-English: The identifier that points to the specific event or step that caused this event. Enables causal reconstruction — answering not just “what happened” but “what triggered what.”

Technical: The identifier of the prior event or workflow step that directly caused the current event. Required for causal chain reconstruction in audit and lineage queries. A missing causation ID makes causal reconstruction impossible.

Never use: parent ID, trigger ID, source event ID

Phase: Post 17

Related terms: correlation ID, event envelope, lineage, audit trail

Memory fabric link

Canonical form: memory fabric (two words, lowercase)

Plain-English: The collective term for Synedrix OS’s seven specialised memory stores and the governed lifecycle that moves records through them. Not a single database, and not only a set of databases — a structured set of specialised stores plus the control plane over them.

Technical: The seven-store memory architecture of Synedrix OS — working memory (Redis), canonical memory (Supabase), temporal memory (QuestDB), graph memory (Neo4j), semantic memory (Qdrant), LLM trace memory (Langfuse), behavioural memory (PostHog) — together with the memory control plane defined in Memory Fabric Spec. Each store has distinct access patterns, retention requirements, and query semantics. The store axis (substrate) is orthogonal to the tier axis (what kind of memory a record is).

Never use: memory layer, data layer, storage layer, database layer

Phase: Post 10

Related terms: memory control plane, memory tier, memory record, working memory, canonical memory, temporal memory, graph memory, semantic memory, memory profile

Working memory link

Canonical form: working memory (lowercase)

Plain-English: The fast, short-lived store for state that matters right now — what agents need to coordinate in real time during a workflow execution. Not authoritative. Not auditable. Ephemeral by design.

Technical: Redis-backed ephemeral hot state. Holds operational state, pub/sub broadcast channels, workflow deduplication windows, idempotency keys, rate-limit counters, and agent heartbeats. Not a source of truth.

Never use: cache, hot cache, Redis layer, real-time store

Phase: Post 10

Related terms: memory fabric, canonical memory, Redis

Canonical memory link

Canonical form: canonical memory (lowercase)

Plain-English: The authoritative record of everything that matters — agent definitions, workflow audit trails, policy decisions, approvals, and business entities. When something happened and what was decided, written once and never overwritten.

Technical: Supabase Postgres-backed authoritative transactional state. Holds business entities, workflow audit trails, decision logs, policy and approval state, operator configuration, and domain-pack data models. The write-authoritative source for lineage links synced to Neo4j.

Never use: database, main database, primary store, Postgres layer

Phase: Post 10

Related terms: memory fabric, working memory, append-only, audit trail

Temporal memory link

Canonical form: temporal memory (lowercase)

Plain-English: The time-series store — facts ordered by time. Used for trend analysis, demand patterns, event volume history, and any question that involves “over time.”

Technical: QuestDB-backed high-volume time-series store. Holds temporal facts, materialized aggregations, event windows, and historical patterns used by intelligence agents for forecasting and anomaly detection.

Never use: time-series database, QuestDB layer, historical store

Phase: Post 10

Related terms: memory fabric, graph memory, intelligence agent

Graph memory link

Canonical form: graph memory (lowercase)

Plain-English: The relationship store — who called whom, what depends on what, which agent produced which outcome. Used for lineage queries and dependency analysis.

Technical: Neo4j-backed relationship and lineage graph. Holds workflow and outcome lineage, agent influence networks, entity relationship graphs, and cross-system dependency context. Receives lineage links synced from canonical memory (Postgres as write-authoritative source).

Never use: Neo4j layer, graph database, relationship store

Phase: Post 10

Related terms: memory fabric, lineage, canonical memory, audit trail

Semantic memory link

Canonical form: semantic memory (lowercase)

Plain-English: The similarity store — used when the question is “what does this most resemble?” or “have we seen something like this before?” Powers case recall and similarity-based retrieval.

Technical: Qdrant-backed vector store. Holds semantic retrieval collections, similarity search indexes, and metadata-aware filtered vector queries for RAG and agent-assisted case recall.

Never use: vector store, embeddings store, Qdrant layer

Phase: Post 10

Related terms: memory fabric, working memory

Memory profile link

Canonical form: memory profile (two words, lowercase)

Plain-English: The declaration attached to each agent specifying which memory stores it may read and which it may write, at what access level. Memory scope is a security boundary, not a configuration detail.

Technical: An agent definition sub-object declaring per-store access levels (read / write / none) for working memory, canonical memory, temporal memory, graph memory, semantic memory, and LLM trace memory. Part of the agent’s authority definition, versioned with the agent.

Never use: memory config, memory settings, memory access rules

Phase: Post 10

Related terms: memory fabric, authority boundary, agent registry

Memory control plane link

Canonical form: memory control plane (three words, lowercase)

Plain-English: The part of the memory fabric that decides how memory comes to exist, moves, ages and ends — as opposed to the stores, which only decide where it sits. Persisting a fact and deciding it is worth remembering are different acts, and the control plane owns the second one.

Technical: The Layer 7 lifecycle: formation, consolidation, reflection, promotion, recall mediation, decay and erasure. Driven by three OS agents — Memory Curator (os-agt-010, the only committer), Consolidation & Reflection (os-agt-011, recommends only), Memory Access Broker (os-agt-012, approves access). Specified in Memory Fabric Spec.

Never use: memory layer, memory engine, memory service, cognitive memory layer

Phase: Post 10

Related terms: memory fabric, memory tier, memory record, promotion, consolidation, reflection

Memory tier link

Canonical form: memory tier (two words, lowercase)

Plain-English: What kind of memory a record is — a transient working value, something that happened, a durable fact, a learned procedure, a trait of a person. Distinct from which database it lives in.

Technical: One of eight tiers: working, episodic, semantic, procedural, profile, relational, graph, temporal. Orthogonal to the substrate axis: one tier may be written to one store and projected into others, and neither axis may be inferred from the other. Defined in Memory Fabric Spec §3.

Never use: memory type, memory class, memory kind, memory category

Phase: Post 10

Related terms: memory fabric, memory substrate, memory record, promotion

Memory record link

Canonical form: memory record (two words, lowercase)

Plain-English: A single governed unit of memory. Every one carries where it came from, what it was derived from, how confident the system is in it, and when it was true — not just its content.

Technical: A record carrying the envelope in Memory Fabric Spec §4: memory_id, tier, scope, content, content_hash, provenance, derived_from[], confidence, validity_interval, consolidation_state, supersedes, retention_class, compliance_labels, version. A record without provenance.source_event_id is non-compliant.

Never use: memory item, memory entry, memory object, memory blob

Phase: Post 10

Related terms: memory tier, memory control plane, provenance, validity interval, tombstone

Promotion link

Canonical form: promotion (lowercase; memory promotion where context needs it)

Plain-English: Moving a memory record from a shorter-lived tier to a longer-lived one — for example from a session’s working memory into durable episodic memory. It is a governed act, not a background copy.

Technical: A tier transition emitting memory.record.promoted with the record’s correlation_id and causation_id unchanged. Gated by the Memory Access Broker (os-agt-012) and, for the cases in Memory Fabric Spec §7.3, by Policy Guard (os-agt-002). The inverse is demotion.

Never use: memory upgrade, memory migration, memory transfer, persisting

Phase: Post 10

Related terms: memory tier, demotion, memory control plane, consolidation

Consolidation link

Canonical form: consolidation (lowercase)

Plain-English: Merging several memory records into one that says the same thing more usefully — the memory equivalent of writing up your notes.

Technical: Merging or summarising several records into one derived record of the same or higher tier, with derived_from[] naming every source and consolidation_state: consolidated. Recommended by os-agt-011, committed by os-agt-010, emitting memory.record.consolidated. Runs in the background, never in an agent’s hot path.

Never use: memory compaction, summarisation, memory merge, deduplication

Phase: Post 10

Related terms: reflection, memory control plane, memory record, promotion

Reflection link

Canonical form: reflection (lowercase)

Plain-English: Deriving a higher-order conclusion from consolidated memory — a stable trait of a person, or a reusable method distilled from work that went well repeatedly.

Technical: Inference of a profile trait or a procedural skill from consolidated records, emitting memory.reflection.completed or memory.skill.distilled. Recommended by os-agt-011 and committed by os-agt-010; a reflected record carries consolidation_state: reflected and the full derived_from[] chain.

Never use: self-improvement, learning, introspection, memory evolution

Phase: Post 10

Related terms: consolidation, procedural memory, profile memory, memory control plane

Tombstone link

Canonical form: tombstone (one word, lowercase)

Plain-English: The durable marker left behind when a memory record’s content is destroyed. Erasure removes what was said; the tombstone preserves that something was said and that it was destroyed under an approval.

Technical: The record written when erasure completes, retaining memory_id, tier, scope.tenant_id, content_hash, provenance, derived_from, validity_interval, the approval reference and the erasure timestamp, with consolidation_state: tombstoned. Graph-memory lineage survives erasure. Emits memory.record.forgotten. See Memory Fabric Spec §8.4.

Never use: soft delete, deletion marker, redaction record

Phase: Post 10

Related terms: erasure, memory record, retention class, audit trail

Recall link

Canonical form: recall (lowercase; memory recall where context needs it)

Plain-English: An agent asking the memory fabric for what it needs to know. In Synedrix OS this is an explicit, authorised request — never context that simply appears.

Technical: A tool call (tool:memory-recall) bound only when present in the resolved active_tool_set, brokered by os-agt-012, with scope resolved and filters pushed into the store query before retrieval. Emits memory.recall.requested and then memory.recall.served or memory.recall.denied. Ambient memory injection is non-compliant.

Never use: memory lookup, context injection, memory retrieval, RAG

Phase: Post 10

Related terms: memory control plane, memory profile, tool authorization, memory tier

12-layer architecture link

Canonical form: 12-layer architecture (numeral, hyphen, lowercase)

Plain-English: The structural model that separates Synedrix OS into 12 distinct layers, each with a clear statement of what it owns and — equally important — what it must not own.

Technical: The canonical layer taxonomy defined in Synedrix OS - Layer Taxonomy Table v0.2, comprising: Human Interface, Goal and Intent, Orchestration, Agent Runtime, Agent Registry, Tool Abstraction, Memory and Data, Event, Governance and Controls, Observability, Domain Pack, Business Instance.

Never use: architecture layers, platform layers, system layers, the layers

Phase: Post 09

Related terms: operating substrate, domain pack, business instance, orchestration

Tool binding link

Canonical form: tool binding (two words, lowercase)

Plain-English: The declaration that an agent is permitted to use a specific tool, at a specified access level, with specific approval requirements. Not all tools are available to all agents — a tool binding is an explicit grant.

Technical: An agent definition sub-object specifying: tool ID, adapter type (native or MCP-backed), allowed operations, side-effect class, approval tier, rate limits, retry rules, idempotency expectations, and audit mode.

Never use: tool permission, tool access, tool configuration

Phase: Post 15

Related terms: agent, MCP, authority boundary, side effect

Tool abstraction layer link

Canonical form: tool abstraction layer (lowercase)

Plain-English: The platform layer that mediates every interaction between agents and external tools or services. Agents call tools through this layer — they never call external systems directly.

Technical: Layer 6 of the 12-layer architecture. Provides a uniform adapter interface, MCP integration point, approval enforcement for write operations, rate limiting, and tool-call audit logging. Must not own business logic.

Never use: tool layer, adapter layer, integration layer

Phase: Post 09

Related terms: tool binding, MCP, 12-layer architecture

Agent registry link

Canonical form: agent registry (lowercase)

Plain-English: The shared catalogue of every agent in the system — what it is, what it can do, what lifecycle stage it is in, and what it is permitted to be invoked for. The OS owns the registry schema and lifecycle state machine.

Technical: The OS-owned component providing stable agent identity and discovery, version lineage, lifecycle state management, dependency declarations, capability tags, and per-instance enable/disable controls. Defined in Synedrix OS - Agent Registry Spec v0.1.

Never use: agent catalogue, agent database, agent directory, agent store

Phase: Post 15

Related terms: lifecycle state, capability tag, agent archetype, agent registry spec

Lifecycle state link

Canonical form: lifecycle state (two words, lowercase)

Plain-English: The current status of an agent in its journey from creation to retirement. Each state has orchestration implications — draft agents cannot be invoked in production; retired agents must be rejected by orchestration.

Technical: One of six canonical states in the agent lifecycle: draft (must not be invoked in production), active (eligible for routing), deprecated (may be invoked; warnings emitted; replacement must be declared), retired (orchestration must reject invocation), disabled (business-instance level; treated as retired for that tenant), suspended (temporarily halted by policy or incident). Every state transition emits an auditable event.

Never use: agent status, agent state, deployment status

Phase: Post 15

Related terms: agent registry, promotion gate, orchestration

Capability tag link

Canonical form: capability tag (two words, lowercase)

Plain-English: A structured label attached to an agent in the registry that enables orchestration routing. Tags must come from governed namespaces — role:, domain:, class: — not free-text.

Technical: A governed vocabulary tag in one of three namespaces: role: (validator, executor, analyzer, router, escalator, observer), domain: (ops, commerce, finance), class: (control, intelligence, interface). Free-text tags are permitted as supplementary but must never be the primary routing signal.

Never use: agent tag, agent label, routing tag

Phase: Post 15

Related terms: agent registry, agent archetype, orchestration

Promotion gate link

Canonical form: promotion gate (two words, lowercase)

Plain-English: The evaluation checkpoint that an agent must pass before it can advance to a new lifecycle state. No agent goes from draft to active without passing all blocking evaluation suites. Enforced by the OS registry — not a process suggestion.

Technical: A registry-enforced evaluation requirement that must be satisfied for a specific lifecycle transition. Key gates: draft-to-active (all blocking eval suites must pass), prompt version bump (output quality suite must pass), model version change (full suite must pass), suspended-to-active (full suite plus incident review).

Never use: deployment gate, release gate, go-live gate

Phase: Post 20

Related terms: lifecycle state, evaluation suite, agent registry, blocking suite

Register 3 — Governance link

These terms define how Synedrix OS maintains control, accountability, and trust.

Authority boundary link

Canonical form: authority boundary (two words, lowercase)

Plain-English: The formally declared limit of what an agent is permitted to do — what it can recommend, approve, or execute, and when it must escalate. A structured, versioned record enforced by the platform. Not a prompt instruction.

Technical: A machine-readable agent definition sub-object comprising: decision scope (recommend / approve / execute), boolean capability flags (can_recommend, can_draft, can_execute, can_approve, can_delegate), risk tier, governance class, approval requirements, and escalation path.

Never use: permissions, access controls, agent rules, agent guidelines, agent constraints, scope (too vague)

Phase: Post 12

Related terms: decision scope, governance class, risk tier, Policy Guard Agent, HITL Gateway Agent

Decision scope link

Canonical form: decision scope (two words, lowercase)

Plain-English: The three-tier classification of what an agent is permitted to do: recommend (propose only), approve (validate and block), execute (trigger side effects). The most important field in an authority boundary.

Technical: One of three canonical values: recommend (may produce proposals and analysis; no side effects), approve (may evaluate and emit binding allow/block/escalate decisions; does not initiate actions), execute (may trigger side effects; requires a non-empty approval_required declaration if risk tier is medium or above).

Never use: action scope, permission level, authorisation level

Phase: Post 12

Related terms: authority boundary, governance class, risk tier, Policy Guard Agent

Governance class link

Canonical form: governance class (two words, lowercase)

Plain-English: The category of oversight that applies to an agent’s execution: autonomous (no approval needed), policy-gated (must pass the Policy Guard), or HITL-required (must have explicit human approval before proceeding).

Technical: One of three canonical values: autonomous (agent proceeds without approval gates; appropriate for low-risk intelligence agents), policy-gated (all actions must pass Policy Guard evaluation), hitl-required (explicit human approval required via the HITL Gateway Agent before side effects proceed).

Never use: approval class, oversight level, autonomy level

Phase: Post 12

Related terms: decision scope, authority boundary, HITL, Policy Guard Agent

Risk tier link

Canonical form: risk tier (two words, lowercase)

Plain-English: The risk classification of an agent, which determines the strictness of governance controls applied to it. Four tiers: low, medium, high, critical.

Technical: One of four values: low (autonomous execution permitted, standard eval requirements), medium (policy-gated recommended, standard eval), high (policy-gated required, strict eval, compliance rate must be maintained), critical (HITL-required, highest eval standards, 1.0 compliance rate mandatory).

Never use: risk level, risk category, risk class

Phase: Post 12

Related terms: governance class, authority boundary, evaluation suite, compliance rate

Governance link

Canonical form: governance (lowercase, used without modifier unless specifying “OS-level governance” or “domain-level governance”)

Plain-English: The set of controls — policy enforcement, authority boundaries, human approval checkpoints, and audit trails — that make autonomous execution trustworthy. Built into the runtime, not added on top.

Technical: The OS-level governance layer comprising the Policy Guard Agent, HITL Gateway Agent, policy engine, approval matrix, compliance labels, kill-switch groups, and immutable audit infrastructure — enforced at runtime for all workflows.

Never use: AI governance (too generic), guardrails (informal), controls (acceptable but less specific)

Phase: Post 11

Related terms: Policy Guard Agent, HITL, authority boundary, audit trail

Policy Guard Agent link

Canonical form: Policy Guard Agent (capitalised — proper noun, OS-owned agent)

Plain-English: The OS-owned agent that evaluates every proposed action against the active policy ruleset before execution proceeds, and emits a binding allow, block, or escalate decision. Its block is final within the current workflow — no human decision, including a HITL approval, reverses it; a human changes the policy and the action is re-proposed.

Technical: OS-owned control agent (os-agt-002). Decision scope: approve. Input: action_type, action_payload, requesting_agent_id, workflow_id, correlation_id. Output: decision (allow/block/escalate), policy_rule_triggered, risk_score, requires_hitl. Does not itself execute business actions.

Never use: policy agent, guardrail agent, compliance agent, governance agent

Phase: Post 11

Related terms: governance, decision scope, HITL Gateway Agent, authority boundary

HITL link

Canonical form: HITL (acronym, always uppercase, defined on first use in each post as “human-in-the-loop”)

Plain-English: A required approval checkpoint — the system cannot proceed until a human makes an explicit decision. Not a monitoring arrangement. Not a fallback. A first-class contract in the workflow.

Technical: Human-in-the-loop. A governance pattern in which the HITL Gateway Agent routes a structured approval request to a designated reviewer, enforces a timeout contract, captures the structured human decision (approved/rejected/timeout), and returns the outcome to the workflow. HITL approval does not bypass the Policy Guard — both must pass.

Never use: human approval (acceptable in plain prose but HITL is the canonical term), human review, human checkpoint, human gate

Phase: Post 13

Related terms: HITL Gateway Agent, governance class, Policy Guard Agent, HOTL

HOTL link

Canonical form: HOTL (acronym, always uppercase, defined on first use as “human-on-the-loop”)

Plain-English: A monitoring arrangement — a human can observe and intervene, but the system does not pause and wait for their decision. Different from HITL: HOTL is observational, HITL is required.

Technical: Human-on-the-loop. The system continues execution; the human has intervention capability but is not in the execution path. Declared in the workflow contract’s approval_requirements section.

Never use: human oversight (too generic), passive oversight

Phase: Post 13

Related terms: HITL, governance, workflow contract

HITL Gateway Agent link

Canonical form: HITL Gateway Agent (capitalised — proper noun, OS-owned agent)

Plain-English: The OS-owned agent that manages human approval requests — routing them to the right reviewer, enforcing the timeout contract, capturing the structured decision, and returning the outcome to the workflow.

Technical: OS-owned control agent (os-agt-004). Receives structured approval requests from the Orchestrator Agent. Routes to reviewer_role. Enforces timeout_seconds. Captures: decision (approved/rejected/timeout), reviewer_id, rationale, decided_at. Does not interpret or modify the human decision it receives.

Never use: approval agent, human approval agent, review agent

Phase: Post 13

Related terms: HITL, governance class, Policy Guard Agent, workflow contract

Append-only link

Canonical form: append-only (hyphenated, lowercase)

Plain-English: A record that can be created but never updated or deleted after creation. The architectural basis of a trustworthy audit trail. Not a convention — enforced at the schema level.

Technical: A schema-level constraint applied to invocation starts and outcomes, lifecycle events, and compliance breach event records in the Synedrix OS agent database schema. Records conforming to this constraint are never updated after INSERT. This is a structural property, not a runtime policy.

Never use: immutable log, write-once (acceptable but less precise), audit log (audit log describes the purpose; append-only describes the constraint)

Phase: Post 14

Related terms: audit trail, canonical memory, agent invocation, compliance event

Audit trail link

Canonical form: audit trail (two words, lowercase)

Plain-English: The complete, immutable record of what happened in the system — every agent invocation, every policy decision, every tool call, every human approval. Answering the three audit questions (what / why / under whose authority) is only possible with a proper audit trail.

Technical: The set of append-only records in the Synedrix OS schema — invocation starts and outcomes, policy decision records, tool call logs, lifecycle events, and compliance breach events — that collectively enable reconstruction of any past system action with full causal and authority context.

Never use: audit log (acceptable but less precise), activity log, system log, execution history

Phase: Post 14

Related terms: append-only, agent invocation, lineage, Audit and Lineage Agent

Lineage link

Canonical form: lineage (lowercase)

Plain-English: The traceable chain that connects an outcome back through every agent, workflow, tool call, and policy decision that produced it. Written to canonical memory first, then projected to graph memory for queryable relationship analysis.

Technical: The network of agent_lineage_links records (source_type, source_id, target_type, target_id, relation, context) written to Supabase Postgres as the authoritative source and synced to Neo4j for graph queries. Relation types (enforced by a CHECK on agent_lineage_links.relation): invoked, contributed-to, escalated-to, governed-by, depends-on, replaced-by.

Never use: provenance (acceptable but academic), trace (trace refers to Langfuse LLM traces specifically), history

Phase: Post 14

Related terms: audit trail, graph memory, canonical memory, Audit and Lineage Agent, correlation ID

Compliance label link

Canonical form: compliance label (two words, lowercase)

Plain-English: A tag attached to an agent or workflow that signals specific regulatory or governance requirements — for example, pii-access, audit-required, or high-impact. Used by the Policy Guard to route and enforce appropriately.

Technical: A structured metadata label attached to agent definitions and workflow contracts, consumed by the Policy Guard Agent to apply appropriate enforcement rules. Examples: audit-required, pii-access, high-impact, financial-transaction.

Never use: compliance tag, governance label, risk label

Phase: Post 11

Related terms: Policy Guard Agent, governance, workflow contract, authority boundary

Kill-switch group link

Canonical form: kill-switch group (hyphenated, lowercase)

Plain-English: A named group of agents or workflows that can be disabled simultaneously through a single operator action — a circuit breaker for coordinated shutdown in incident scenarios.

Technical: A named group defined in the policy engine configuration that allows coordinated disablement of multiple agents or workflows through a single policy action. Used for incident response and controlled shutdown.

Never use: circuit breaker (this is a related but distinct runtime concept), emergency stop, shutdown group

Phase: Post 11

Related terms: Policy Guard Agent, governance, lifecycle state, suspended

Evaluation suite link

Canonical form: evaluation suite (two words, lowercase)

Plain-English: A named set of evaluation checks that an agent must pass — either before a lifecycle transition (blocking) or on an ongoing basis (non-blocking). Every agent must have at least one blocking suite before going active.

Technical: A named collection of evaluation checks covering one or more of the three dimensions (output quality, policy compliance, operational health). A suite with blocking: true must pass for any associated promotion gate to clear.

Never use: test suite (this is software testing terminology; evaluation is the correct term for agent quality assessment), eval (acceptable as shorthand after first mention)

Phase: Post 20

Related terms: promotion gate, blocking suite, compliance rate, lifecycle state

Blocking suite link

Canonical form: blocking suite (two words, lowercase)

Plain-English: An evaluation suite that must pass before an agent can advance to a new lifecycle state. It cannot be skipped or overridden by domain packs or business instances.

Technical: An evaluation suite with blocking: true. Required to clear before the associated promotion gate transition can proceed. Enforced by the OS registry. High-risk and critical-risk agents must have at least one blocking compliance suite requiring a 1.0 compliance rate.

Never use: mandatory suite, required suite, gate suite

Phase: Post 20

Related terms: evaluation suite, promotion gate, compliance rate

Compliance rate link

Canonical form: compliance rate (two words, lowercase)

Plain-English: The fraction of an agent’s invocations that were compliant with its authority boundary and policy rules. High-risk and critical-risk agents must maintain a rate of 1.0 — any breach triggers a review.

Technical: Calculated as: compliant invocations / total invocations over a defined period. High-risk and critical-risk agents require a compliance rate of 1.0. Any breach emits an agent.evaluation.compliance-breach event, triggers an alert, and flags the agent for review before next deployment.

Never use: pass rate, success rate, policy adherence rate

Phase: Post 20

Related terms: evaluation suite, blocking suite, compliance event, risk tier

Human operator link

Canonical form: human operator (lowercase)

Plain-English: The person accountable for agent and workflow registration, edge cases not yet safely encoded, and resumption after a timeout. A role someone holds, not a job title; one person may hold several.

Technical: One of the six OS-level human control roles. Derived from the escalation_path terminal of os-agt-001, os-agt-003, os-agt-009, os-agt-010, os-agt-011 and os-agt-012, per the AI-Native Org Chart. Domain-pack and business-instance role names such as trading-operator are never additions to this set. Which of the six control roles such a name maps to, one or several, is a business-instance decision this vocabulary does not specify.

Never use: admin, sysadmin, user (too generic)

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: HITL, human risk owner, business instance owner

Human risk owner link

Canonical form: human risk owner (lowercase)

Plain-English: The person accountable for the active policy ruleset (the policy rules; instance thresholds belong to the business instance owner), and the role that changes the rules through a governed policy change. No human, including this role, reverses a Policy Guard block. A role someone holds, not a job title; one person may hold several.

Technical: One of the six OS-level human control roles. Derived from the escalation_path terminal of os-agt-002, per the AI-Native Org Chart. Domain-pack and business-instance role names such as trading-operator are never additions to this set. Which of the six control roles such a name maps to, one or several, is a business-instance decision this vocabulary does not specify.

Never use: risk manager, compliance officer (that is the human compliance owner)

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: Policy Guard Agent, HITL, human operator

Human domain steward link

Canonical form: human domain steward (lowercase)

Plain-English: The person accountable for that function’s domain-pack behaviour, KPI vocabulary and approval points, and for turning a forecast or analytic signal into a decision. A role someone holds, not a job title; one person may hold several.

Technical: One of the six OS-level human control roles. Derived from the escalation_path terminal of os-agt-005, os-agt-006 and os-agt-007, one per business function, per the AI-Native Org Chart. Domain-pack and business-instance role names such as trading-operator are never additions to this set. Which of the six control roles such a name maps to, one or several, is a business-instance decision this vocabulary does not specify.

Never use: product owner, data steward

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: Domain pack, Analytics Agent, Forecasting Agent, Anomaly Detection Agent

Human compliance owner link

Canonical form: human compliance owner (lowercase)

Plain-English: The person accountable for audit findings that require action, erasure requests, and retention classes. A role someone holds, not a job title; one person may hold several.

Technical: One of the six OS-level human control roles. Derived from the escalation_path terminal of os-agt-008, per the AI-Native Org Chart. Domain-pack and business-instance role names such as trading-operator are never additions to this set. Which of the six control roles such a name maps to, one or several, is a business-instance decision this vocabulary does not specify.

Never use: auditor (too broad), risk owner (that is the human risk owner)

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: Audit & Lineage Agent, Audit trail, human risk owner

Senior reviewer link

Canonical form: senior reviewer (lowercase)

Plain-English: The person accountable for contested decisions and timed-out approvals. A role someone holds, not a job title; one person may hold several.

Technical: One of the six OS-level human control roles. Derived from the escalation path of os-agt-004, per the AI-Native Org Chart. Domain-pack and business-instance role names such as trading-operator are never additions to this set. Which of the six control roles such a name maps to, one or several, is a business-instance decision this vocabulary does not specify.

Never use: supervisor, manager, approver (too generic)

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: HITL Gateway Agent, HITL, human operator

Business instance owner link

Canonical form: business instance owner (lowercase)

Plain-English: The person accountable for approver role assignments, thresholds, timeouts, notification endpoints, deployment mode, entitlement flags and secrets. A role someone holds, not a job title; one person may hold several.

Technical: One of the six OS-level human control roles. Derived from the Business Instance column of the Responsibility Matrix (Layer 12), per the AI-Native Org Chart. Domain-pack and business-instance role names such as trading-operator are never additions to this set. Which of the six control roles such a name maps to, one or several, is a business-instance decision this vocabulary does not specify.

Never use: tenant admin, customer admin

Phase: Not yet named in the blog series. Defined in the AI-Native Org Chart; no phase post covers it by name yet.

Related terms: Business instance, deployment mode, responsibility matrix

Register 4 — OS-owned agents link

The twelve agents owned by Synedrix OS, across three families — Control, Intelligence, Observability (see agent family, Register 2). These are proper nouns — always capitalised, always named in full on first mention per post. Every entry below states both its family and its archetype explicitly, because the two do not always match — see agent family’s own entry for why that matters.

Orchestrator Agent (Family: Control) — see Register 2 (Architecture). Repeated here for completeness.

Policy Guard Agent (Family: Control) — see Register 3 (Governance). Repeated here for completeness.

HITL Gateway Agent (Family: Control) — see Register 3 (Governance). Repeated here for completeness.

Registry and Capability Agent link

Canonical form: Registry and Capability Agent (capitalised)

Plain-English: The OS agent that resolves which agents, workflows, and capabilities are available and active for a given goal or task, and returns a structured capability map to the Orchestrator Agent for routing.

Technical: OS-owned agent (os-agt-003). Family: Control · Archetype: control. Decision scope: recommend. Queries the agent registry, reads capability tags and lifecycle states, and produces a routing-ready capability map. Does not modify the registry at runtime.

Never use: capability agent, registry agent, discovery agent

Phase: Post 15

Related terms: agent registry, orchestration, capability tag

Analytics Agent link

Canonical form: Analytics Agent (capitalised)

Plain-English: The OS agent responsible for synthesising operational insights and performance reports across all active domain packs. Read-only by design — it writes only its own report records.

Technical: OS-owned agent (os-agt-005). Family: Intelligence · Archetype: intelligence. Decision scope: recommend. Reads broadly from canonical memory, temporal memory, and observability data. Writes only to its own analytics report table. No side effects on business entities.

Never use: reporting agent, analytics engine, insights agent

Phase: Post 08 (as an archetype example)

Related terms: intelligence archetype, memory profile, decision scope

Forecasting Agent link

Canonical form: Forecasting Agent (capitalised)

Plain-English: The OS agent that generates forward-looking predictions from temporal patterns — demand forecasts, trend projections, capacity estimates — for use by domain pack workflows.

Technical: OS-owned agent (os-agt-006). Family: Intelligence · Archetype: intelligence. Decision scope: recommend. Reads from temporal memory and semantic memory. No direct side effects. Outputs structured forecast records consumed by domain pack orchestration.

Never use: prediction agent, forecast engine

Phase: Post 08 (as an archetype example)

Related terms: intelligence archetype, temporal memory, Analytics Agent

Anomaly Detection Agent link

Canonical form: Anomaly Detection Agent (capitalised)

Plain-English: The OS agent that monitors for deviations from expected patterns across domain packs and emits structured incident events when anomalies are detected.

Technical: OS-owned agent (os-agt-007). Family: Intelligence · Archetype: intelligence. Decision scope: recommend. Reads from temporal memory and canonical memory. Emits anomaly.detected events but does not take remediation actions. No side effects on business entities.

Never use: anomaly agent, detection agent, monitoring agent

Phase: Post 08 (as an archetype example)

Related terms: intelligence archetype, temporal memory, event

Audit and Lineage Agent link

Canonical form: Audit and Lineage Agent (capitalised)

Plain-English: The OS agent that answers explainability queries — reconstructing what happened, why, and under whose authority, from immutable records. Strictly read-only. May never modify, redact, or amend any audit record.

Technical: OS-owned agent (os-agt-008). Family: Observability · Archetype: audit. These diverge deliberately — see agent family’s own entry — so never describe this agent as belonging to an “audit family”; Observability is its only family. Decision scope: recommend. A query target, not a callable tool in the workflow sense. Correlates invocation starts and outcomes, policy decision records, tool call logs, and lifecycle events into structured run lineage. Read-only without exception.

Never use: audit agent, lineage agent, explainability agent, compliance agent

Phase: Post 14

Related terms: audit trail, lineage, append-only, governance, agent family

General Chat Agent link

Canonical form: General Chat Agent (capitalised)

Plain-English: The OS agent that answers visitor questions about Synedrix OS on standalone chat surfaces — such as the public website — by retrieving grounded context from a semantic knowledge base and composing a cited response. It sits outside every domain pack.

Technical: OS-owned agent (os-agt-009). Family: Intelligence · Archetype: intelligence · Canonical ID os-int-general-chat-001. Decision scope: recommend. Retrieves read-only from a Qdrant semantic knowledge base and composes an answer via self-hosted inference; triggers no side effects. Runs as a standalone LangGraph service invoked directly (e.g. from a Vercel frontend), not orchestrated by an n8n workflow — a bounded governance-bridge exception that holds only while no write-class tool is bound to it.

Never use: chatbot, chat assistant, support agent, website agent

Phase: Not yet named in the blog series — deployed and documented in DGX Vercel Chat Agent Deployment, but no phase post covers it by name yet.

Related terms: agent family, semantic memory, decision scope, agent registry

Memory Curator Agent link

Canonical form: Memory Curator Agent (capitalised)

Plain-English: The only OS agent permitted to commit durable memory. Every other agent proposes a memory record; the Memory Curator forms, consolidates, promotes, demotes and erases it, so every durable record has exactly one point of commit and complete provenance.

Technical: OS-owned agent (os-agt-010). Family: Control · Archetype: control · Canonical ID os-ctl-memory-curator-001. Decision scope: execute. Requires a Memory Access Broker (os-agt-012) scope decision on every operation, plus Policy Guard (os-agt-002) approval for erasure, promotion into relational, visibility widening beyond tenant, or promotion of records carrying regulated compliance labels. Part of the memory control plane alongside os-agt-011 and os-agt-012.

Never use: memory writer agent, memory commit agent, memory agent (ambiguous — three agents touch memory)

Phase: Post 10

Related terms: memory control plane, agent family, Consolidation & Reflection Agent, Memory Access Broker Agent

Consolidation & Reflection Agent link

Canonical form: Consolidation & Reflection Agent (capitalised, ampersand not “and”)

Plain-English: The OS agent that analyses accumulated memory to propose consolidations, higher-order reflections, distilled procedural skills, tier promotions and conflict resolutions. It reads broadly and writes nothing — every proposal is only durable once the Memory Curator commits it.

Technical: OS-owned agent (os-agt-011). Family: Intelligence · Archetype: intelligence · Canonical ID os-int-memory-consolidation-001. Decision scope: recommend — no write access to any memory tier. Every proposal is gated by the Memory Access Broker (os-agt-012) and committed only by the Memory Curator (os-agt-010); it cannot resolve a detected conflict unilaterally. Part of the memory control plane.

Never use: reflection agent, memory analysis agent, consolidation agent (drop “& Reflection” only in already-disambiguated running prose)

Phase: Post 10

Related terms: memory control plane, agent family, Memory Curator Agent, consolidation, promotion

Memory Access Broker Agent link

Canonical form: Memory Access Broker Agent (capitalised)

Plain-English: The OS agent that mediates every memory recall and every memory write proposal, resolving the requester’s scope against its memory profile before any store is queried. It never sees memory content itself — only whether access to it is allowed.

Technical: OS-owned agent (os-agt-012). Family: Control · Archetype: control · Canonical ID os-ctl-memory-broker-001. Decision scope: approve. Returns filter predicates pushed down into the query rather than filtering results after retrieval. A denial is terminal — the requester escalates rather than retries. Part of the memory control plane.

Never use: memory gatekeeper, access control agent, memory permission agent

Phase: Post 10

Related terms: memory control plane, agent family, memory profile, Memory Curator Agent

Register 5 — Infrastructure link

These are the canonical names for the technology components. Use these exact names — not abbreviations, not category labels.

n8n link

*Canonical form:*n8n (always lowercase, always italicised in running prose:n8n)

Plain-English: The orchestration runtime. Where workflows and agent invocations are built and executed.

Technical: Workflow orchestration layer. Owns workflow execution, agent invocation routing, retry and timeout management, and the trigger/action composition model for all domain pack workflows.

Never use: n8N, N8N, the workflow tool, the automation platform

Phase: Post 09 (tech stack mapping)

Related terms: orchestration, workflow

Supabase link

Canonical form: Supabase (capitalised)

Plain-English: The canonical relational truth store. Where authoritative records, policy state, audit trails, and agent definitions live.

Technical: Supabase Postgres 17. The canonical memory backing store. Also hosts the policy engine configuration, RLS-enforced access controls, and the write-authoritative source for lineage links.

Never use: the database, Postgres (acceptable in technical deep-dives but Supabase is the canonical product name in this platform)

Phase: Post 09

Related terms: canonical memory, append-only, audit trail

Redis link

Canonical form: Redis (capitalised)

Plain-English: The hot state and coordination bus. Fast, short-lived, not authoritative.

Technical: Working memory backing store. Pub/Sub broadcast, deduplication windows, idempotency keys, rate-limit counters, heartbeats.

Never use: the cache, in-memory store

Phase: Post 10

Related terms: working memory, coordination bus

QuestDB link

Canonical form: QuestDB (capitalised, no space)

Plain-English: The time-series store. Used for any data whose primary axis is time.

Technical: Temporal memory backing store. High-volume append-only time-series records, materialized aggregations, event windows.

Never use: the time-series database, time-series store

Phase: Post 10

Related terms: temporal memory

Neo4j link

Canonical form: Neo4j (capital N, lowercase e, capital j)

Plain-English: The graph store. Used for relationship and lineage queries.

Technical: Graph memory backing store. Receives lineage links synced from Supabase. Provides queryable graph projections for lineage and dependency analysis.

Never use: the graph database, graph store

Phase: Post 10

Related terms: graph memory, lineage

Qdrant link

Canonical form: Qdrant (capitalised)

Plain-English: The semantic memory store. Used for similarity retrieval and case recall.

Technical: Semantic memory backing store. Stores vector representations for similarity search, RAG, and agent-assisted pattern recall.

Never use: the vector store, the vector database, embeddings store

Phase: Post 10

Related terms: semantic memory

Langfuse link

Canonical form: Langfuse (capitalised)

Plain-English: The LLM engineering layer. Captures every prompt, response, trace, and evaluation for every LLM-backed agent.

Technical: LLM trace memory backing store. Manages prompt versions, traces, token usage, latency, evaluations, and cost attribution across all LLM-backed agents. Primary tool for output quality evaluation.

Never use: the LLM observability tool, the prompt management tool, the tracing layer

Phase: Post 10 (memory fabric); Post 20 (evaluation)

Related terms: LLM trace memory, evaluation suite, output quality

Hookdeck link

Canonical form: Hookdeck (capitalised)

Plain-English: The ingress gateway. All external events enter the system through Hookdeck — never directly to the orchestration layer.

Technical: Durable ingress layer. HMAC/source validation, retry and buffering, fan-out routing, replay. No domain pack or workflow exposes raw orchestration webhooks to the public internet.

Never use: the webhook tool, event gateway, ingress layer

Phase: Post 09

Related terms: event, orchestration

Hookdeck Outpost link

Canonical form: Hookdeck Outpost (capitalised, always both words)

Plain-English: The egress gateway. All outbound notifications and external event deliveries leave through Hookdeck Outpost.

Technical: Durable outbound delivery manager. Subscription-aware event delivery, retry and logging, channel abstraction (email, chat, webhooks), delivery observability.

Never use: Hookdeck egress, outbound gateway, notification gateway

Phase: Post 09

Related terms: event, Hookdeck

MCP link

Canonical form: MCP (acronym, always uppercase, defined on first use as “Model Context Protocol”)

Plain-English: The open protocol Synedrix OS uses for agent-to-tool and agent-to-context integration. MCP extends the tool abstraction boundary without replacing orchestration or governance.

Technical: Model Context Protocol. Applied at the tool abstraction boundary (Layer 6). Read-first adoption policy. Write-capable MCP tools introduced only when approval and permission semantics are clear. MCP-backed tool calls are governed and traced identically to native tool calls.

Never use: MCP protocol (redundant), tool protocol

Phase: Post 18

Related terms: A2A, tool binding, tool abstraction layer, interoperability

A2A link

Canonical form: A2A (acronym, always uppercase, defined on first use as “Agent-to-Agent protocol”)

Plain-English: The open protocol Synedrix OS uses for interactions with agents in other systems. A2A extends the platform edge without replacing internal orchestration or governance. External A2A agents are bounded peers, not trusted internal components.

Technical: Agent-to-Agent protocol. Applied at the platform edge. External A2A interactions are policy-governed and auditable. Correlation IDs and lineage are preserved across A2A boundaries. A2A-originated tasks must pass OS governance before side effects proceed.

Never use: A2A protocol (redundant), agent federation, agent interop

Phase: Post 18

Related terms: MCP, interoperability, governance, correlation ID

Series summary table link

Total terms: 74 canonical entries covering 107 distinct defined concepts (including sub-definitions and related synonyms documented as never-use variants) link

Synedrix OS · Vocabulary v0.1 · April 2026

Addendum — v0.2 additions: Deployment sovereignty vocabulary link

Added following the introduction of Core Principles v0.3 Principle 11 (Open by default, sovereign by design). These terms govern all content from the point of their introduction.

Deployment mode link

Canonical form: deployment mode (two words, lowercase)

Plain-English: The configuration that determines where Synedrix OS runs and whether model inference uses external services or local infrastructure. Three canonical modes: cloud-connected, self-hosted-hybrid, and air-gapped. Declared at the business instance level and governs all agents in that instance.

Technical: A business instance-level field with three values: cloud-connected (all components self-hosted except the Hookdeck inbound Event Gateway, external model APIs permitted), self-hosted-hybrid (all components self-hosted except the Hookdeck inbound Event Gateway, model inference split per agent between cloud and local), air-gapped (all components self-hosted except the Hookdeck inbound Event Gateway, all model inference local, no external model or API calls permitted). The Hookdeck inbound gateway is a managed service in all three modes, an accepted exception recorded in the Deployment Model Spec following the rejection of ADR-OS-013. Enforced as a validation constraint on agent runtime policies.

Never use: deployment type, deployment option, hosting mode, deployment configuration (too generic)

Phase: Post 04 (introduce with the brand)

Related terms: air-gapped deployment, self-hosted instance, local model, deployment sovereignty, business instance

Deployment sovereignty link

Canonical form: deployment sovereignty (two words, lowercase)

Plain-English: The principle that an organisation can run the Synedrix OS platform — including all model inference — within its own infrastructure. One accepted exception: the Hookdeck inbound Event Gateway, a managed service in every mode. A trust property: the organisation controls every component of the system it depends on, apart from that declared exception.

Technical: The platform-level commitment embodied in Core Principles v0.3 Principle 11, implemented through the three canonical deployment modes and enforced via the air-gapped validation invariant in the Agent Runtime Policy Spec v0.2.

Never use: data sovereignty (broader term covering data residency laws), self-hosting (describes the mechanism, not the principle)

Phase: Post 04

Related terms: deployment mode, air-gapped deployment, open source, Principle 11

Air-gapped deployment link

Canonical form: air-gapped deployment (hyphenated adjective, lowercase)

Plain-English: A Synedrix OS deployment in which no component makes external model or API calls. All model inference runs locally and no business data is sent outward. The one external connection is the inbound path from the Hookdeck gateway, so inbound event payloads transit a third party. The third and most restrictive of the three canonical deployment modes; it is not a zero-perimeter-crossing guarantee.

Technical: Deployment mode 3. Business instance declares deployment_mode: air-gapped. All agent runtime policies must declare model_type: local. Cloud model URIs in any agent runtime policy are a validation error. All outbound network traffic must be blocked at the infrastructure level, with no egress exception. Separately, inbound traffic from the Hookdeck gateway to the instance’s event receiver must be allowed (Deployment Model Spec).

Never use: offline deployment, disconnected deployment, local deployment (too vague — all three modes run local platform components)

Phase: Post 04

Related terms: deployment mode, local model, deployment sovereignty, self-hosted instance

Self-hosted instance link

Canonical form: self-hosted instance (hyphenated adjective + noun, lowercase)

Plain-English: A Synedrix OS business instance where all platform components run on the customer’s own infrastructure. All three deployment modes are self-hosted — they differ only in whether model inference uses external APIs.

Technical: A business instance in which all 11 core platform components (n8n, Supabase, Redis, QuestDB, Neo4j, Qdrant, Langfuse, PostHog, Grafana, Prometheus, Hookdeck) run on the customer’s own infrastructure. The local model inference layer (Ollama/vLLM) is additionally required in Modes 2 and 3.

Never use: on-premise deployment (narrower — implies physical servers), local deployment (ambiguous)

Phase: Post 04

Related terms: deployment mode, business instance, air-gapped deployment

Local model link

Canonical form: local model (two words, lowercase)

Plain-English: A model running on the customer’s own hardware via Ollama or vLLM, rather than called through an external cloud API. Local models receive inference requests in exactly the same way as cloud models — the agent runtime policy determines which type is used.

Technical: A model served by the local model inference layer (Ollama or vLLM), referenced in agent runtime policies using a local URI format (ollama/<model>:<tag> or vllm/<model>). OpenAI-compatible API format means no changes to agent logic or Langfuse tracing are required.

Never use: on-device model, edge model, private model (implies data privacy rather than deployment location)

Phase: Post 04

Related terms: Ollama, vLLM, deployment mode, model abstraction layer, air-gapped deployment

Model abstraction layer link

Canonical form: model abstraction layer (three words, lowercase)

Plain-English: The layer in the agent runtime that routes inference requests to either a cloud model API or a local model endpoint, transparently. From the agent’s perspective, it sends a request and receives a response — whether that comes from OpenAI or a local Llama model is determined by the runtime policy, not the agent.

Technical: The runtime mechanism that translates agent inference requests to the appropriate endpoint based on model_type and local_model_provider fields in the agent runtime policy. Both Ollama and vLLM expose OpenAI-compatible APIs, making the abstraction layer a routing and endpoint-configuration concern rather than a protocol translation concern.

Never use: model router (too narrow — routing is one function of the layer), inference layer (acceptable but less precise)

Phase: Post 07 (when orchestration and architecture are discussed in depth)

Related terms: local model, deployment mode, agent runtime policy, Ollama, vLLM

Ollama link

Canonical form: Ollama (capitalised)

Plain-English: The primary local model serving tool in Synedrix OS. Runs models on the customer’s hardware and exposes an OpenAI-compatible API. The default local inference tool for development environments and standard production air-gapped deployments.

Technical: Open-source local model serving tool (MIT licence). Exposes an OpenAI-compatible API at http://localhost:11434/v1. Supports GGUF model format via llama.cpp backend. Auto-detects NVIDIA CUDA and AMD ROCm GPUs; falls back to CPU. Used in deployment Modes 2 and 3.

Never use: the local model tool, the inference server (too generic)

Phase: Post 04 (mention with deployment modes); Post 09 (tech stack discussion)

Related terms: vLLM, local model, deployment mode, model abstraction layer

vLLM link

Canonical form: vLLM (all caps)

Plain-English: The production-grade local model serving tool for high-throughput air-gapped deployments. Recommended when multiple agents need concurrent inference or when GPU parallelism is required.

Technical: Open-source high-throughput inference engine (Apache 2.0 licence). Exposes an OpenAI-compatible API. Requires NVIDIA CUDA GPU (primary) or AMD ROCm (experimental). Recommended for production air-gapped workloads requiring batched inference or high concurrency.

Never use: vllm (lowercase), the production inference server

Phase: Post 09 (tech stack)

Related terms: Ollama, local model, air-gapped deployment, model abstraction layer

Vocabulary v0.2 addendum · April 2026

Addendum — v0.2 additions: Active development and stage vocabulary link

Added following the decision to position Synedrix OS explicitly as being in active development, open to co-founders and investors.

Active development link

Canonical form: active development (two words, lowercase)

Plain-English: The current stage of Synedrix OS — the architecture is complete and canonical, the platform is being built, the founding team is forming. Not “coming soon.” Not “beta.” Not “in stealth.”

Technical: The stage in which the canonical specification documents are complete, implementation is underway, and external access is not yet available. Distinct from “design phase” (earlier) and “early access” (later).

Never use: coming soon, stealth mode, pre-launch (too vague), under development (passive — use “in active development”)

Phase: Post 04 (first brand mention)

Related terms: Synedrix OS, deployment sovereignty, co-founder

Co-founder link

Canonical form: co-founder (hyphenated, lowercase)

Plain-English: A person who joins to build Synedrix OS alongside the founding team. Two types: technical co-founder (platform/AI infrastructure background) and commercial co-founder (enterprise GTM/sales background). Neither is subordinate to the other.

Technical: N/A — this is a team and relationship term, not an architectural one.

Never use: founding engineer (different role), early employee (different commitment level), co-CEO (premature)

Phase: Post 04 (homepage and /build-with-us page)

Related terms: active development, Synedrix OS

Build in public link

Canonical form: build in public (three words, lowercase, no hyphen)

Plain-English: The practice of publishing architectural decisions, design reasoning, and development progress openly — as Synedrix OS does through the blog series and specification documents. The blog series is the primary expression of building in public.

Never use: open development (different meaning — refers to open-source contribution model), public roadmap (narrower — a roadmap is one artefact)

Phase: Post 04

Related terms: open source, active development, deployment sovereignty

Related Documents link

Documents this vocabulary governs link

Canonical Architecture (source of vocabulary terms) link

• Synedrix OS - Consolidated Canonical Reference — Consolidated synthesis; all canonical terms in this vocabulary are rooted in the specs bundled in the master.
• Synedrix OS - Core Principles — 12 governing principles; the Governance register in this vocabulary maps to principle names.
• Synedrix OS - Taxonomy & Platform Spec — Canonical taxonomy; the Platform register in this vocabulary maps to taxonomy definitions.
• Synedrix OS - Platform Architecture & Tech Stack — 12-platform stack; the Infrastructure register in this vocabulary names all 11+ components.

Synedrix OS · Vocabulary v0.3 April 2026

Addendum — v0.3 additions: Execution pattern vocabulary link

Added following the introduction of the execution_pattern field in Workflow Contract Spec v0.3. These terms define how tasks within a workflow are sequenced and coordinated. Source: Gulli, Agentic Design Patterns(2024); Bellemare,Building Event-Driven Microservices; Kleppmann, Designing Data-Intensive Applications.

Execution pattern link

Canonical form: execution pattern (two words, lowercase)

Plain-English: The declaration in a workflow contract that describes how tasks within the workflow are sequenced and coordinated. Nine canonical patterns are defined; every workflow contract must declare exactly one primary pattern.

Technical: The execution_pattern field in a workflow contract. Comprises a primary value (one of nine canonical patterns) plus optional pattern-specific parameters: quorum for consensus, max_iterations for iterative and reflect-and-revise, branches for conditional, sub_workflows for hierarchical. Patterns may be composed; the primary names the top-level pattern.

Never use: execution model, orchestration pattern, workflow pattern, flow pattern

Phase: Post 16 (workflow contract deep-dive)

Related terms: workflow contract, orchestration, task, agent, goal

Sequential pattern link

Canonical form: sequential pattern (two words, lowercase; or sequential when referencing the field value)

Plain-English: Tasks execute strictly in order — each must complete before the next begins. The simplest and most predictable execution pattern.

Technical: Primary pattern value sequential. Each step declares its depends_on chain. Execution halts on failure unless the error policy specifies compensation. Derived from Prompt Chaining / Pipeline pattern (Gulli Ch. 1).

Never use: linear pattern, ordered pattern, step-by-step pattern

Phase: Post 16

Related terms: execution pattern, task, pipeline pattern

Parallel pattern link

Canonical form: parallel pattern (two words, lowercase; or parallel when referencing the field value)

Plain-English: All tasks launch simultaneously and the workflow waits for all to complete. Tasks must be fully independent.

Technical: Primary pattern value parallel. Requires a wait_for declaration (all, first-success, or first-completion) and a timeout_ms. Tasks share no state. Distinguished from fan-out-fan-in by the absence of an aggregation step. Derived from Parallelization (Gulli Ch. 3).

Never use: concurrent pattern, simultaneous pattern

Phase: Post 16

Related terms: execution pattern, fan-out-fan-in pattern, consensus pattern

Conditional pattern link

Canonical form: conditional pattern (two words, lowercase; or conditional when referencing the field value)

Plain-English: Execution follows one of N branches based on a runtime condition — an agent decision, a policy result, or a payload field. Exactly one branch executes per invocation.

Technical: Primary pattern value conditional. Requires a condition_source (agent role or field path) and a branches list mapping condition values to next steps. Derived from the Routing pattern (Gulli Ch. 2 — LLM-based, embedding-based, rule-based, and ML-model-based routing).

Never use: branching pattern, routing pattern, decision pattern

Phase: Post 16

Related terms: execution pattern, Policy Guard Agent, HITL

Fan-out-fan-in pattern link

Canonical form: fan-out-fan-in pattern (hyphenated, lowercase; or fan-out-fan-in when referencing the field value)

Plain-English: A single trigger fans out to N parallel sub-tasks; after all complete, an aggregation step merges their outputs before the workflow continues. Distinguished from parallel by the required aggregation; distinguished from consensus by the absence of voting quorum semantics.

Technical: Primary pattern value fan-out-fan-in. Requires fan_out.tasks, fan_out.timeout_ms, fan_out.on_partial_failure, and fan_in.aggregation. Derived from Parallelization (Gulli Ch. 3 — parallel tasks with sequential synthesis) and Multi-Agent (Ch. 7).

Never use: map-reduce pattern, scatter-gather pattern

Phase: Post 16

Related terms: execution pattern, parallel pattern, consensus pattern

Iterative pattern link

Canonical form: iterative pattern (two words, lowercase; or iterative when referencing the field value)

Plain-English: A task or task set repeats in a loop until a convergence condition is met or a maximum iteration count is reached. The canonical implementation of the ReAct (Reason + Act + Observe) loop.

Technical: Primary pattern value iterative. Requires max_iterations and convergence_condition. The on_max_iterations_exceeded field declares the fallback (escalate, accept-last, or abort). Derived from the ReAct pattern (Gulli Ch. 17).

Never use: loop pattern, retry pattern (retry is an error-handling mechanism, not an execution pattern), polling pattern

Phase: Post 16

Related terms: execution pattern, ReAct, reflect-and-revise pattern

Consensus pattern link

Canonical form: consensus pattern (two words, lowercase; or consensus when referencing the field value)

Plain-English: Multiple agents independently evaluate the same input; a quorum rule must be satisfied within a timeout window before the workflow continues. A specialisation of fan-out-fan-in where the aggregation is a voting function.

Technical: Primary pattern value consensus. Requires voters, quorum.required, quorum.of_total, timeout_ms, voting_function, and on_quorum_failure. Derived from Multi-Agent Orchestration and consensus voting patterns (Gulli Ch. 7; Bellemare Ch. 10).

Never use: voting pattern, quorum pattern, multi-agent vote

Phase: Post 16

Related terms: execution pattern, fan-out-fan-in pattern, quorum

Hierarchical pattern link

Canonical form: hierarchical pattern (two words, lowercase; or hierarchical when referencing the field value)

Plain-English: The parent workflow delegates to one or more named sub-workflows. Each sub-workflow is a full workflow contract. The parent proceeds only after declared sub-workflows complete.

Technical: Primary pattern value hierarchical. Requires a sub_workflows list with workflow_id, phase, wait_for, and optional depends_on. Each sub-workflow declares its own execution_pattern independently. Derived from Plan-and-Execute hierarchical decomposition (Gulli Ch. 6).

Never use: nested pattern, parent-child pattern, decomposition pattern

Phase: Post 16

Related terms: execution pattern, sub-workflow, orchestration

Pipeline pattern link

Canonical form: pipeline pattern (two words, lowercase; or pipeline when referencing the field value)

Plain-English: A strict data-flow chain where each step’s output is the next step’s input. The only execution pattern that permits deterministic steps with no agent role assigned.

Technical: Primary pattern value pipeline. Each step declares a transform and an agent_role (which may be null for deterministic steps). Steps with agent_role: null must not invoke LLM inference. Conceptually similar to sequential but semantically distinct: pipeline emphasises pure data transformation with no branching or state. Derived from stream processing (Kleppmann Ch. 11; Bellemare Ch. 4).

Never use: chained pattern, linear flow, ETL pattern

Phase: Post 16

Related terms: execution pattern, sequential pattern, deterministic step

Reflect-and-revise pattern link

Canonical form: reflect-and-revise pattern (hyphenated, lowercase; or reflect-and-revise when referencing the field value)

Plain-English: A producer agent generates a candidate output; a critic agent evaluates it against a quality threshold; if the threshold is not met, the producer revises. The loop continues until the threshold is met or maximum iterations are exhausted.

Technical: Primary pattern value reflect-and-revise. Requires producer_agent_role, critic_agent_role (may be the same agent for self-critique), quality_threshold.metric, quality_threshold.minimum, max_iterations, on_threshold_not_met, and critique_output_field. Distinguished from iterative by the explicit producer/critic split and quality-threshold convergence criterion. Derived from Reflection / Critique (Gulli Ch. 4).

Never use: self-critique pattern, revision loop, critic pattern

Phase: Post 16

Related terms: execution pattern, iterative pattern, evaluation suite

Deterministic step link

Canonical form: deterministic step (two words, lowercase; or step_type: deterministic when referencing the field)

Plain-English: A workflow step that executes fixed logic — schema validation, format conversion, data joins, rule-based transforms, event publishing — without invoking LLM inference. Valid in sequential and pipeline patterns.

Technical: A step declaration with step_type: deterministic. Must not call any LLM endpoint. Declared with transform (what the step does) and an optional function_ref (the n8n node type or registered function that implements it). agent_role must be null or absent. Does not produce an Outcome Envelope — passes structured output directly to the next step. Typically implemented as a native n8n node (Code, Set, Merge, Filter, HTTP Request) rather than an AI Agent node. Contrast with an agent-driven step, which invokes an LLM-backed agent and returns an outcome.

Never use: non-AI step, simple step, rule-based step, agent_role: null step (that is the pipeline shorthand — use step_type: deterministic in new contracts)

Phase: Post 16

Related terms: agent-driven step, step type, pipeline pattern, sequential pattern, execution pattern

Agent-driven step link

Canonical form: agent-driven step (hyphenated, lowercase; or step_type: agent-driven when referencing the field)

Plain-English: A workflow step that invokes an LLM-backed agent. All reasoning, tool calls, policy evaluations, and decisions in a workflow happen inside agent-driven steps.

Technical: A step declaration with step_type: agent-driven (or implicitly, any step with an agent_role set). Requires agent_role (must match an entry in the workflow’s agent_roles field) and task_class (the task type). The referenced agent executes under its declared runtime policy and produces a structured outcome conforming to the Outcome Envelope (Outcome Spec v0.2). May invoke tools, call MCPs, evaluate policy, escalate, or produce a quality signal. Contrast with a deterministic step, which runs fixed logic with no inference.

Never use: AI step, LLM step, smart step (use agent-driven step consistently)

Phase: Post 16

Related terms: deterministic step, step type, agent, outcome, execution pattern

Step type link

Canonical form: step type (two words, lowercase; or step_type when referencing the field)

Plain-English: The discriminator that declares whether a workflow step is executed by an LLM-backed agent or by fixed deterministic logic. Every step in a sequential or pipeline pattern must carry a step type.

Technical: The step_type field on a step declaration. Two values: agent-driven (LLM agent required, produces an outcome) and deterministic (fixed logic, no LLM, no outcome envelope). step_type is the canonical discriminator — when present, it takes precedence over the agent_role: null pipeline shorthand. Valid in sequential and pipeline patterns. All other execution patterns (parallel, fan-out-fan-in, consensus, iterative, conditional, hierarchical, reflect-and-revise) only support agent-driven task nodes.

Never use: step class (that is task_class), step mode, task type

Phase: Post 16

Related terms: deterministic step, agent-driven step, execution pattern, sequential pattern, pipeline pattern

Vocabulary addendum · Workflow execution patterns · May 2026

Addendum — v0.3 additions: Outcome vocabulary link

Added following the introduction of Synedrix OS Outcome Spec. These terms canonicalise the return type of every agent invocation and every workflow execution.

Outcome link

Canonical form: outcome (lowercase)

Plain-English: The structured result returned by every agent invocation and every workflow execution. An outcome says what happened, whether it succeeded, what the domain-specific result was, and how confident the system is in that result. Not an event. An outcome is the return value; an event is a fact broadcast to the system.

Technical: The canonical outcome envelope defined in Synedrix OS Outcome Spec v0.2. A structured JSON object carrying: outcome_id, status, source, correlation_id, causation_id, result, quality, errors, escalation, policy, timing, and execution_context. Persisted as an append-only record in agent_invocation_outcomes (for agents) or workflow_outcomes (for workflows) in Supabase.

Never use: response (acceptable in UI context but not as a system return type), output (too generic — use outcome when referring to the full structured return type), result (refers only to the domain-specific payload inside the outcome envelope, not the envelope itself)

Phase: Post 16

Related terms: outcome status, outcome envelope, result, correlation ID, lineage, agent invocation

Outcome envelope link

Canonical form: outcome envelope (two words, lowercase)

Plain-English: The standard wrapper shape that every outcome follows. The envelope is always the same structure regardless of which agent or workflow produced it. Only the result field varies by domain.

Technical: The full JSON schema defined in Synedrix OS Outcome Spec v0.2. Comprises eleven top-level fields: outcome_id, outcome_version, status, correlation_id, causation_id, source, result, quality, errors, escalation, policy, timing, execution_context. The envelope shape is domain-agnostic; result is domain-typed.

Never use: output envelope, response envelope, return envelope

Phase: Post 16

Related terms: outcome, result, outcome status, event envelope

Outcome status link

Canonical form: outcome status (two words, lowercase)

Plain-English: The primary signal that tells orchestration, governance, and observability layers what happened in an agent invocation or workflow execution. Seven canonical values: success, partial, failure, blocked, escalated, timeout, skipped. Orchestration and error-handling layers branch on status without parsing the result payload.

Technical: The status field of the outcome envelope. Seven values: success (completed normally), partial (completed with non-fatal sub-failures), failure (failed), blocked (blocked by the Policy Guard Agent), escalated (routed to HITL or escalation path), timeout (timed out), skipped (prerequisite not met). status: success with a non-empty errors array is invalid — use partial.

Never use: execution status, run status, job status

Phase: Post 16

Related terms: outcome, outcome envelope, Policy Guard Agent, HITL, error

Result link

Canonical form: result (lowercase, when referring specifically to the result field of an outcome)

Plain-English: The domain-specific payload inside an outcome envelope. The only field in the outcome that varies by agent or workflow. Its shape is declared in the agent’s output_schema or the workflow’s output_contract.result_schema.

Technical: The outcome.result field. Always structured JSON — never a plain string, number, or array at the top level. Null when outcome status is failure, blocked, timeout, or skipped. Declared per agent in contracts.output_schema; declared per workflow in output_contract.result_schema.

Never use: output (too generic — use result when referring to the domain payload specifically), response body, payload (acceptable informally but result is canonical)

Phase: Post 16

Related terms: outcome, outcome envelope, outcome status

Partial outcome link

Canonical form: partial outcome (two words, lowercase; or partial when referencing the status value)

Plain-English: An outcome where execution completed but one or more non-fatal sub-steps failed. The result is populated but may be incomplete. The errors array is non-empty. Distinguished from failure because the workflow did produce a usable result.

Technical: Outcome with status: partial. Produced when execution_pattern is fan-out-fan-in or parallel and on_partial_failure: proceed-with-available was declared, or when a pipeline has a non-blocking validation step that fails. partial_failure_count in execution_context records how many sub-tasks failed.

Never use: incomplete outcome, degraded outcome

Phase: Post 16

Related terms: outcome status, fan-out-fan-in pattern, error

Outcome quality link

Canonical form: outcome quality (two words, lowercase; or quality when referencing the field)

Plain-English: The optional sub-object inside an outcome that carries measurable quality signals — how confident the agent is, how many iterations it took, and what the critic said. Present only for agent outcomes that produce a confidence signal, or when a reflect-and-revise or iterative execution pattern ran.

Technical: The outcome.quality object. Fields: confidence (0.0–1.0), critique_notes (critic agent feedback), iterations_used (for iterative patterns), groundedness_score (for RAG-backed agents), evaluator_agent_id. Absent for deterministic steps, policy decisions, and pure routing agents that do not produce a confidence signal.

Never use: confidence object, quality signal (acceptable in plain prose but outcome quality is canonical when referring to the field)

Phase: Post 20

Related terms: outcome, confidence, evaluation suite, reflect-and-revise pattern

Vocabulary addendum · Outcome envelope · May 2026

Addendum — v0.3 additions: Tool authorization vocabulary link

Added with Synedrix OS - Agent Runtime Policy Spec v0.3. Resolves the undocumented gap between static tool capability declarations and policy-driven tool grants at runtime.

Tool capability set link

Canonical form: tool capability set (three words, lowercase)

Plain-English: The complete list of tools an agent is ever allowed to use — declared once in the agent’s definition and treated as a hard ceiling. No runtime policy or deployment configuration can grant a tool that is not in this set.

Technical: The tool_permissions array in the agent spec. Each entry declares a tool_id, access_mode, operation_scope, side_effect_class, approval_tier, and audit_mode. This is a static, versioned declaration that lives with the agent definition — not a runtime configuration.

Never use: tool list, allowed tools, tool whitelist (avoid whitelist/blacklist terminology), tool registry (that is a different concept)

Phase: Post 15

Related terms: active tool set, tool authorization, tool_permissions

Active tool set link

Canonical form: active tool set (three words, lowercase)

Plain-English: The subset of an agent’s tool capability set that is enabled for a specific invocation. Policy and deployment configuration can only reduce this set — never expand it beyond the capability ceiling.

Technical: The resolved tool set computed at invocation time by applying the tool_authorization_policy (runtime policy) and any environment_overrides (business instance) against the agent spec’s tool_permissions ceiling. Stored in agent_active_tool_sets per agent per deployment environment. Any tool call referencing a tool outside the active set is rejected and emits agent.tool.unauthorized.

Never use: enabled tools, granted tools, tool scope (scope has a different meaning in the governance layer)

Phase: Post 15

Related terms: tool capability set, tool authorization, runtime policy

Tool authorization link

Canonical form: tool authorization (two words, lowercase; or tool_authorization_policy when referencing the field)

Plain-English: The mechanism that determines which tools from an agent’s capability set are active at runtime. Governed by a three-layer model: capability ceiling (agent definition), runtime restriction (runtime policy), and instance restriction (business instance configuration).

Technical: The tool_authorization_policy block in the agent runtime policy. Declares active_tool_set (all | declared | restricted), tool_grants, tool_suspensions, mcp_tool_policy, and a2a_tool_policy. Distinct from tool capability declaration (static, in agent spec) and from approval gates (Policy Guard, invoked at tool-call time for specific tool calls). The three layers can only restrict downward — never grant upward beyond the ceiling.

Never use: tool permissions (that is the capability ceiling, not the authorization mechanism), tool access control, tool grants (acceptable as a field name but too narrow as the concept name)

Phase: Post 15

Related terms: tool capability set, active tool set, policy, Policy Guard Agent

MCP tool policy link

Canonical form: MCP tool policy (three words; or mcp_tool_policy when referencing the field)

Plain-English: The per-agent configuration that governs which MCP servers can be called, whether MCP write operations need Policy Guard approval, and whether individual MCP server IDs are allowed or blocked. Sits within the runtime policy’s tool authorization section.

Technical: The mcp_tool_policy block within tool_authorization_policy. Fields: require_mcp_approval (boolean, default true for high/critical risk tier), mcp_server_allowlist, mcp_server_denylist, mcp_write_approval_required (default true). Implements the “Least privilege by default” and “No protocol bypass of governance” principles from the Interoperability Protocol Strategy v0.2.

Never use: MCP permissions, MCP access policy, MCP gateway (that is an infrastructure component, not a policy concept)

Phase: Post 16

Related terms: MCP (Model Context Protocol), tool authorization, Policy Guard Agent, active tool set

A2A tool policy link

Canonical form: A2A tool policy (three words; or a2a_tool_policy when referencing the field)

Plain-English: The per-agent configuration that governs how cross-system agent delegations are approved, which external agent systems are trusted partners, and the default approval posture for A2A interactions. Sits within the runtime policy’s tool authorization section.

Technical: The a2a_tool_policy block within tool_authorization_policy. Fields: require_a2a_approval (boolean, default true), a2a_trust_tier (trusted | provisional | untrusted), a2a_partner_allowlist. Trust tier governs default posture — it does not bypass Policy Guard. All A2A-originated side effects require Policy Guard approval when require_a2a_approval: true, regardless of trust tier.

Never use: A2A permissions, agent trust, external agent policy

Phase: Post 16

Related terms: A2A (Agent2Agent), tool authorization, Policy Guard Agent, active tool set