ADR 052: Model Forge emits no events — consumers pull synchronously

Date: 2026-07-15

Status: Accepted

Decision Makers: @derlinne, @luckey

Context

The platform coordinates provisioning via events, so Model Forge's role relative to the message bus must be defined.

Decision

Model Forge is a synchronous model store. It does not publish to a message bus. Downstream consumers (pipeline engines, the Config Adapter) obtain the DataSetDatasetA data-related element that contains processed data and makes it available for consumption. A Dataset is populated via Pipelines and carries Metadata and access permissions. manifest and its referenced artifacts by synchronous reads on the embedded Java facade (ADR 051) integrated in the portal-backend.

Rationale

• Model Forge owns the design-time model, not runtime orchestration. Eventing, saga coordination and provisioning are platform concerns handled outside Model Forge (in CIVITAS/CORE V2, by the Portal Backend).
• A single source of truth (the PostgreSQL registry) plus a pull API avoids a second delivery channel that could drift from the registry.
• Everything a consumer needs for flow translation is available by synchronous reads (manifest plus referenced artifacts), so no separate push payload is required.

Consequences

Model Forge has no message-broker dependency, topic or producer configuration — consumers always pull synchronously.

See also

• Portal Backend Integration