Iteration · handoff to analysts and engineers

How model changes propagate (pipeline Entity I/O, graph instances, inspector labels), the flow of adding a mapping when a new dataset arrives, and a paragraph each handing off to analysts (Graph explorer entry) and engineers (new dataset mapping pattern).

10분

Assume the graph you've built so far is sitting in your collection. A model isn't a one-shot asset — the cycle continues as the data schema changes, new datasets arrive, and analysts and engineers stack work on top. This lesson closes the Path by covering that maintenance cycle and handoff to both sides in one go.

Propagation scope of a model change — watch three places at once

Knowing how far a change to a single attribute or relation row reaches lets you decide faster.

Change	Affected places	Next action
Attribute rename (e.g. `health_score` → `latest_health_score`)	(a) graph instance keys, (b) mapped dataset column, (c) widget column references	Align the backing dataset column name, or bypass by renaming only the alias in the builder
Attribute type change (e.g. Text → Integer)	(a) graph instance casting failures, (b) pipeline Entity I/O execution failures	Cast upstream of the dataset (Engineer Path lesson 04), then map
Identity Keys change	The biggest propagation. Instance identification breaks	Forking into a new collection / entity is safer. Mark the old entity as deprecated.
Relation type change (`STOCKED_AT` → `STORED_IN`)	Every Cypher query · Graph explorer deep links · widget queries	A type change is practically a new relation creation + old relation deletion. Do them in one pass.
Cardinality change (1:N → N:N)	Validation signals change. Widget aggregation logic is semantically affected	Validate new query results in the Graph explorer once and align with collaborators

The rule: a model change looks at three places at once — the backing dataset, graph instances, and inspector labels. Deciding from a single place causes silent result changes in the other two.

When a new dataset arrives — adding a mapping

Suppose an engineer just dropped a new mart dataset into the collection (e.g. maintenance_events as the backing of IOT_MaintenanceEvent). The modeler's flow is short:

In the builder, define a new entity IOT_MaintenanceEvent via the five areas of lesson 02 (name · alias · description · schema · Identity) — event_id is the Identity Key.
Connect maintenance_events as the backing via lesson 03's mapping flow.
Add a relation IOT_triggers from the existing IOT_Machine via lesson 04's canvas drag — source IOT_Machine, target IOT_MaintenanceEvent. The relation itself has attributes anomaly_id, severity, detected_at, so map a backing dataset (e.g. anomaly_events) once more.
In lesson 05's Graph explorer, click the IOT_Machine label → double-click neighbor expansion → confirm the new IOT_MaintenanceEvent nodes appear alongside.

This cycle is a miniature of the entire Path. Once it feels familiar, adding one new entity closes inside 10 minutes.

Handing off to analysts — a Graph explorer entry link

Analysts may not be intimate with graphs. Where to start from is the key of the handoff.

In the Graph explorer, build the starting state you want the analyst to see (e.g. click RI_Region label → double-click Capital region) and copy the URL. The starting node and query are prefilled into URL query parameters.
Place that link in your collection's README or in a one-page analyst-facing dashboard along with a three-line description — like "Capital-region branches and the products stocked there".
Together with that single link, suggest entering Analyst Path lesson 04 — First dashboard and widget. The flow of putting one of your entities onto a widget input is right there.

Once this paragraph is filled, even an analyst who can't enter the Graph explorer themselves can produce a first result screen on top of your model.

Handing off to engineers — the new dataset mapping pattern

Engineers' flow ends at ingesting data from external systems. The key of the handoff is which entity's backing that data becomes.

Author the table below once in your collection's README:

Dataset the engineer will create	Backing of which entity / relation	Identity Keys (columns)
`machines`	`IOT_Machine`	`machine_id`
`sensors`	`IOT_Sensor`	`sensor_id`
`maintenance_events`	`IOT_MaintenanceEvent`	`event_id`
`sensor_readings`	`IOT_reads_from` (relation)	(interval_seconds, latest_recorded_at)

Split permissions so an engineer can map immediately when a new dataset arrives. Keep source datasets in the engineer's collection and the model in the modeler's collection, and create a single shared group that holds Editor on both collections (for mapping).
Demonstrate one of your domain's entities to the engineer as an example — the five-step mapping of lessons 02–03 is the guide as-is.

Once this paragraph is filled, the engineer has an automatic signal that closes their own flow into a form suitable for the model.

Permission setup — governance over model resources

The model itself is a shared organizational asset. Permissions usually follow this pattern.

Modeler group — Builder Editor + Graph Explorer Editor.
Engineer group — Backing dataset Editor + Builder Viewer (mapping is applied by the modeler after agreement).
Analyst group — Graph Explorer Viewer + Widget Editor.
Governance / audit group — Graph Explorer Viewer + Collection Activity Log Viewer.

When each of the three roles holds Editor only on their own surface, tracing whose decision made a model change is natural.

Path complete — what comes next

If you've gotten this far, you've built one cycle of the semantic layer by hand. Candidates for next learning:

Analyst Path lesson 04 — First dashboard and widget — Put one of your graph's entities onto a widget input and watch the model = the analyst's input close inside one portal.
Engineer Path lesson 03 — First pipeline — The flow of regularly populating the backing dataset from external systems. Natural when you also own the responsibility of who feeds the data.
Workshop: Retail Inventory Intelligence — The 4 + 3 graph of this Path appears tied into one real scenario where the analyst, engineer, and modeler viewpoints meet. About 90 minutes.

Checking off every lesson in this Path records the Path as complete. Your next learning surfaces as a recommendation in the home's "Continue learning" panel.

Well done.