Write records

Egress writes record output to an external system through an installed writer and workspace destination endpoint. It does not materialize ontology facts or persist platform assertions. Choose a mode supported by the actual connector; API idempotency and pipeline checkpointing do not create generic exactly-once row writes.

What you need

You need a Semogram account with workspace membership, a project in that workspace and permission to create and run pipelines. Reading or writing also requires access to the selected endpoints and external systems. Creating a pipeline does not grant those permissions.

For this self-contained fixture, use a test PostgreSQL database and its SQL client. Install Postgres read and write capabilities separately using the connection fields below. The writer needs the privileges required for target/schema setup and its supported row-level-security behavior.

Prepare the source and output

CREATE TABLE public.pipeline_demo_orders (
  order_id integer PRIMARY KEY,
  region text NOT NULL,
  total numeric(12,2) NOT NULL
);
INSERT INTO public.pipeline_demo_orders VALUES
  (1, 'North', 120.00),
  (2, 'South', 75.50);

CREATE TABLE public.pipeline_demo_output (
  order_id integer PRIMARY KEY, region text NOT NULL, total numeric(12,2) NOT NULL
);

Open workspace Plugins → Explore, find Postgres (@craven/postgres), inspect its installed contract and install the read capability. Fill these connection fields and run its supported connection check:

Open workspace Data Endpoints → New data endpoint. Use name demo_orders, namespace pipelines, direction Ingress, the installed Postgres read capability and Stream (source_stream) as the source contract. In the target fields set Schema to public and Table to pipeline_demo_orders. Save and inspect its schema/sample. demo_orders is a name you choose in Semogram; public.pipeline_demo_orders is the actual database table. Keep its returned endpoint UUID for programmatic examples.

The Postgres installation guide and endpoint guide provide additional detail; the required setup for this fixture is included here.

Install Postgres write in workspace Plugins → Explore with these connection fields (use a writer-authorized identity):

Create a destination endpoint demo_order_output, namespace pipelines, direction Egress, installed Postgres write capability, contract write, target Schema public, Table pipeline_demo_output, Write mode append. Save/check it and keep its UUID. The endpoint name is a Semogram label; this target is a dedicated physical test table.

Build the write graph

Create a pipeline reading demo_orders in full mode with parser extraction and writing its two records to demo_order_output in append mode. Show the actual input/output database targets and required permissions before saving. Run once only after approval.

{
  "dataEndpointId": "<DESTINATION_ENDPOINT_UUID>",
  "source": "orders",
  "writeMode": "append"
}

Validate the draft, inspect the endpoint/capability and any resolved approved write policy, save a version and run once. Preflight does not write the test table. Open the run and inspect the egress result, then query the actual destination:

SELECT order_id, region, total FROM public.pipeline_demo_output ORDER BY order_id;

Expect (1, North, 120.00) and (2, South, 75.50) with no change to the source.

Write modes and connector limits

Postgres's current writer supports additional keyed update/delete behavior in its own contract; a pipeline mode picker does not expose every connector action. Its published target vocabulary and runtime implementation also differ for overwrite/replace; do not treat those names as aliases. This fixture uses append, supported by both. The Postgres writer commits per row rather than one transaction across the run, so partial effects can survive failure. Other writers have different guarantees.

Do not rerun this append fixture blindly: existing primary keys can fail. Inspect output and clear only the dedicated test table through your database tools when deliberately repeating the test. A governed source-write action, a pipeline destination and a fact-store materializer are separate mutation paths with different enforcement and receipts.