Source data lands in a staging layer before it becomes a golden record. The Ontology node does not produce golden records from a single operation — you orchestrate a pipeline of explicit steps: create staging records, fetch them, run matching and optionally survivorship, and apply quality rules. Each step must be sequenced intentionally.
Overview
The staging-to-golden-record flow is a pipeline you build, not a single button. The critical thing to understand is that staging record creation is fire-and-forget — it does not block or wait for a record to be processed into a golden record. This means you cannot assume a golden record exists after the create step. Build the follow-on steps explicitly, in order.
Step 1: Create Staging Records
Source data from an external system is written to the staging layer as staging records. This operation is fire-and-forget — it does not block until the record is merged or promote it to a golden record automatically. Creating a staging record simply lands the data in the staging layer.
Because staging creation is asynchronous in this sense, do not assume that a golden record exists immediately after this step. The subsequent pipeline steps are what convert a staging record into a governed, deduplicated entity.
Fire-and-forget means you must sequence explicitly: A single create staging records call does not produce a clean golden record. Build the matching and quality steps as explicit follow-on nodes in the automation.
Step 2: Fetch Staging Records
After creating staging records, fetch them to make them available for processing. The fetch step retrieves the records that have been written to the staging layer and passes them to the matching and quality steps that follow.
Step 3: Run Matching (and Survivorship)
Run the matching operation against the fetched staging records. Matching compares each record against existing golden records and classifies the outcome:
Create — no match found; the record becomes a new golden record.
Update — a match is found; the record is associated with the existing golden record.
Flagged — a confidence-score match that needs review before promotion.
If survivorship is enabled, the matching step also consolidates field values using the configured strategies — selecting the winning value for each field and merging the records. Survivorship is off by default; enable it explicitly in the matching configuration if automatic field-level merging is required.
Step 4: Apply Quality Rules
Run quality rules to validate the records. Records that pass are promoted to the golden record store; records that fail are quarantined and held out. Quality rules run after matching — a record may be matched and still quarantined if it fails quality validation.
Quarantined records can be reviewed, corrected, and reprocessed through the pipeline once the data issue is resolved.
Notes
Treat the staging-to-golden-record pipeline as an explicit orchestration responsibility — the Ontology node provides the operations, but you must sequence them correctly.
Staging record creation is fire-and-forget — do not assume a golden record is available immediately after creation.
The full pipeline sequence is: create staging records → fetch → match (optionally with survivorship) → quality rules. Skipping steps results in unprocessed or ungoverned records.
Survivorship must be explicitly enabled in the matching step; it is off by default.
Quality-rule quarantine and the "flagged" matching outcome are separate concepts — quarantined records failed quality rules; flagged records hit a confidence threshold in matching.
Test the full pipeline end-to-end with representative source data before deploying to production to confirm each step transitions data correctly.
A pipeline that skips quality rules or leaves survivorship unconfigured may produce incomplete or duplicate golden records — design and test each stage before ingesting at scale.