Documentation / Ressources / Référence / Glossary

Glossary

Cross-cutting definitions used throughout the documentation. Terms are grouped by concern; within a group they read top-down from the most fundamental.

Platform & planes

  • Meridian — the clinical-workflow automation platform: an empty engine plus a plugin system that contributes all clinical vocabulary and behavior.
  • Engine (core) — @meridian/engine-core: the generic interpreter, the meta type-system, and the dataflow primitives. It contains no clinical content.
  • SDK — @meridian/shared: the stable contract a plugin compiles against (manifest schemas, the behavior/adapter/source contracts, the type system).
  • Configuration plane — the config-plane app: where workflows are designed, runs are monitored, agents and plugins are inspected.
  • Control plane — Restate: durable execution — journaling, replay, crash recovery, human-in-the-loop suspension.
  • Execution plane — the engine plus the ports it drives (FHIR, LLM, …), run by the Restate endpoint.

Plugins

  • Plugin — a self-contained package that contributes vocabulary and behavior through a single plugin.yaml manifest. Loaded by the host; never a build-time dependency of the engine.
  • Manifest (plugin.yaml) — a plugin's declaration of everything it contributes: value-sets, dimensions, context kinds, types, conversions, declared events (contributes.events), nodes, adapters, port sandboxes, agents, event sources, event bindings and message bindings.
  • Contribution point — one of the manifest's declarable kinds (see above).
  • dependsOn — a plugin's declared dependency on another plugin, with the semver range of its versions the plugin accepts ("^0.2.0"), used for load ordering and cross-plugin type resolution, and checked at load against the version present. The plugin and its dependsOn dependencies, transitively, form its closure: a trigger's event:, the context kinds of a declared event and the types of its fields must come from that closure.
  • Registry — a version store for published plugins (a GCS bucket or a directory), laid out @publisher/name/<version>/… with immutable versions.
  • SDK range (sdk:) — the plugin contract version a plugin requires; the host refuses and logs a plugin whose range excludes its own contract version (contrat plugin incompatible — plugin ignoré). Declared events need ^0.1.1; a plugin that uses them with a lower range loads, with the warning « plage sdk insuffisante ».

Type system

  • TypeRef — the recursive description of a data shape: primitive, coded, quantity, object, ref, list, or any.
  • Value-set — a terminology backing a coded value (an enumerated code system, or an external one resolved by a terminology port).
  • Dimension — a physical dimension backing a quantity value (a canonical UCUM unit plus conversion factors).
  • Object type — a structured datatype or clinical resource, declared with typed field descriptors.
  • Conversion — a declarative From → Into rule between two types.

Workflows

  • Workflow — a declarative YAML graph (meridian/v3) of nodes wired port-to-port; the single source of truth for a process, versioned in git.
  • Node — a building block with typed input/output ports and a kind (trigger, source, sink, compute, gateway, human-task, agent, transform).
  • Port — a typed input or output socket on a node. Also, in the hexagonal sense, a contract implemented by an adapter (see below).
  • Connection — a typed edge nodeId.outPort → nodeId.inPort.
  • Trigger — the entry node that turns an inbound event into the initial context and outputs. It receives one event type: the declared event chosen in its configuration (Événement reçu), the declared event a dedicated trigger references with event:, or, for a trigger with its own address, the address it names with eventType.
  • Événement reçu (trigger.event-received) — the core trigger that receives the declared event chosen in trigger.config.event, among every event the loaded plugins declare. Its outputs are the event's fields, in declaration order.
  • Dedicated trigger — a trigger a plugin contributes for one of its declared events (event:), with outputs of its own (renamed, references, structured objects).
  • Context — the ambient variables a trigger establishes for a run, keyed by context kind. A kind is present in a run only when the event carries its identifier: an optional kind of a declared event (encounter on CommunicationReceived, MedicationPrescribed, ConditionRecorded…) is often absent.
  • Context kind — a plugin-contributed sort of ambient context (contributes.contextKinds: name, id field, ref entity) — @posos/common contributes patient, encounter, order, document. The registry is open and the core ships none.
  • Decision model — a model that answers typed questions about a state instead of writing text: a probability for a yes/no (yesno), an option for a choice, a position on a scale for a score. Used by the Décision intelligente node of @posos/decision, through the decision port (adapter typesafe: TypeSafe's Jev or a server compatible with its System One API). See Ask a decision model typed questions.
  • Behavior — the JS module a node runs (its "tier C" implementation), returning outputs from inputs.
  • Template (config) — a text config field of a node in which {name} inserts an input of the node and {context.<kind>.id} the run's context, optionally through transforms ({url|trim}). A variable without a matching input becomes an input port; an absent variable skips the node. See Templates in text fields.
  • Split-pin — wiring a single object port field-by-field without an intermediate node.
  • after / done — the implicit flow ports every node exposes to sequence and join branches without carrying data. after joins branches with AND; the OR join of exclusive branches is flow.merge (see Core primitives).
  • Absence propagation — a required input left unfed skips the node, cutting the branch downstream — the model's "else".
  • Workflow memory — durable, typed values kept from one run to the next by the core memory.* nodes; scope workflow (private to one workflow, for the run's subject), subject (shared by the subject's workflows) or workflow-global (private to one workflow, shared by all its subjects). Each write gets a version, which a conditional write checks (optimistic locking); an item expires after 30 days unless another retention is set. See Remember values between runs.

Ports & adapters (hexagonal)

  • Port (hexagonal) — a named contract behaviors depend on. The SDK types only the ports the core calls (agent, terminology); every business port — patient record, prescription, notification, or any plugin-defined port — is defined by its owning plugin, which augments the open Ports bundle.
  • Adapter — a plugin's implementation of a port (e.g. a FHIR patient record, an LLM agent runner). Selected per instance. An adapter declaring record: { contextKind } is the record port of that kind (SubjectRecordPort): it serves GET /api/records/:kind/:id and receives validation publications.
  • Instance manifest — the deployment's concrete configuration (meridian/instance-v1): which adapter for each port, connection config, required plugins, locale.

Events & ingestion

  • Event type — the type string of an event (BioResultReceived). Ingestion refuses an event whose type no loaded trigger claims: every declared event is claimed by Événement reçu, an address by its trigger.
  • Declared event (event contract) — an event type declared by one plugin in contributes.events: its context kinds (each required or optional), its typed fields (each required or not), an example and optionally a default filter. No declared type can be the address of a trigger with its own address. The contract is open (undeclared fields pass as received) and is checked at ingestion according to EVENT_CONTRACTS: observe (default), enforce or off. Shown in the trigger inspector as Declared event (« Événement déclaré »). See Events and triggers.
  • Declarative trigger — a trigger with event: and no behavior: its outputs are projected from the event's contract. Example: trigger.patient-admitted (@posos/clinical).
  • Example event — the event the console prefills for a trigger (composer, filter check, simulation): the declared example plus a <kind>-exemple placeholder for each required context kind it lacks (for a trigger with its own address, each kind the trigger establishes). Built by exampleEvent.
  • Event catalogue — the list of the loaded plugins' event types on the Plugins page (« Catalogue des événements »), which names the triggers that receive any declared event.
  • Event source — a generic ingestion mechanism (polling, an HL7 socket…) that emits raw records, knowing nothing about domain events.
  • Event binding — the declarative link source + query → event + map that turns raw records into a domain event. A binding to a declared event is checked against its contract at load (warning « binding hors contrat », the binding stays active). require drops the records whose listed fields are empty.
  • Message binding — a plugin module (messageBindings) that projects a message received on an EAI connection (HL7 v2, PN13) into one or more events.
  • MapExpr — the small grammar (dotted path, JSONPath, ref, const) that maps a raw record's fields onto an event's fields.
  • Route — the link between a published workflow and the event type its trigger receives. Every published workflow with a route on an event's type receives the event, unless its trigger filter excludes it (fan-out); each one starts its own run.
  • Trigger filter (selector) — the jexl expression trigger.selector on the event payload: it restricts the events its own workflow receives, and takes nothing away from the other workflows of the type.
  • Without filter (no filter, « sans filtre ») — a workflow whose trigger has no selector: it receives every event of its type.
  • Default filter (defaultSelector) — a filter a plugin declares on one of its events; the console prefills it when a workflow is created on that event, whatever its trigger, and publication warns when the workflow's filter does not contain it. CommunicationReceived has event.sender != "meridian".
  • Filtered event — an event of a type that published workflows receive, kept by none of their filters: POST /api/events answers 200 with runs: [], and the traffic history shows Filtered (« Filtré »).
  • Duplicate — a second delivery of an event to a workflow that already received it: no new run starts. A redelivered event does not reach workflows published after its first reception.
  • Designation — the explicit choice of one workflow by __workflowFile on POST /api/events: only that workflow receives the event, its filter is not evaluated. The workflow must receive the event's type.
  • Own address (pinnedRouting) — a trigger that receives events addressed to one precise workflow (webhook UUID, schedule, workflow call, EAI connection); such events never reach other workflows of the type. Its eventType is its address, which no declared event can take.

Execution & runs

  • Run — one execution of a workflow, journaled and recoverable by Restate.
  • Run id — the key of a run in Restate and in the run index: <eventId>:<slug> for a domain event (one run per event and workflow), the eventId for a trigger with its own address. The event's original id is the run's source event (sourceEventId).
  • Run index / run-store — the proxy's queryable list of runs (SQLite or Postgres); the execution truth stays in Restate.
  • Human-in-the-loop (HITL) — a human-task node that suspends the run until a human decision, optionally with an SLA deadline and escalation branch.
  • Simulation — running a workflow spec against a forged event in a sandbox, without a durable run — the editor's "▶ Simulate".
  • Trace code — a structured {code, params} engine trace, translated for display (the engine persists no display language).

Internationalisation

  • Instance locale — the language of persisted content (validation titles, notifications). An instance is monolingual.
  • UI locale — the viewer's display language (cookie meridian-locale), affecting only chrome, catalog labels, and docs navigation.
  • Bundle (i18n/<locale>.yaml) — a plugin's translation overlay, with keys derived from the manifest structure.
97 documents8 sectionssource : /docs · généré au build