Skip to content

Reverse navigation from instance views

What this is

Copy-paste YAML to opt in to instance → records navigation on your data-modeling views. Validation records already store a forward DirectRelation on focusNodeInstance. The reverse property lives on the customer instance view, through that record-view property.

0.5.x contract — not 0.4.x

This is the supported reverse-navigation path for 0.5.x (record views, not containers). Do not present it as a 0.4.x Flows or container workaround. Deploy must ensure the two record views first (Record views (Flows)); apply this YAML after those views exist in the project.

Per-rule display names (sh:name on validation results) are documented in Records output. Reverse navigation is instance ↔ records; it does not replace those fields.

When to use it

Use this when a Cognite Data Fusion (CDF) app or Flow should start from an equipment, work-order, or other instance and discover that instance's data-quality or rule-engine records.

Do not add these properties to CogniteCore or expect cognite-data-quality to inject them. Customers add them to the instance views they already own (that is a customer model version bump).

Apply the YAML only after the two record views exist in the project (DataQualityValidationRecord v1 and RuleEngineResult v1 in the records space, default dataQuality). On 0.4.x, deploy still ensures containers only; record views are created by the 0.5 deploy path (Record views (Flows)).

User mental model

  • Forward: each navigable validation or inference record points at the DMS instance via focusNodeInstance.
  • Reverse: the instance view exposes a view-only multi_reverse_direct_relation through that property.
  • Record data stays in the Records service. The reverse property makes the link discoverable; it does not copy records into the graph.

Same pattern as CDF sensorLogs → SensorLog.sensor. See Connect record views to data modeling views.

Copy-paste YAML

Add one or both properties to your instance view. Keep space / externalId / version aligned with the record views in your project. If those identifiers differ from the container IDs in your tenant, use the view IDs documented at deploy time (Record views (Flows)).

Record views cannot define reverse or edge connections. Define the reverse on the instance view.

Data quality validation records

dataQualityValidationRecords:
  connectionType: multi_reverse_direct_relation
  name: Data quality validation records
  description: Validation records whose focusNodeInstance points at this instance.
  source:
    type: view
    space: dataQuality
    externalId: DataQualityValidationRecord
    version: v1
  through:
    source:
      type: view
      space: dataQuality
      externalId: DataQualityValidationRecord
      version: v1
    identifier: focusNodeInstance

Rule engine results

ruleEngineResults:
  connectionType: multi_reverse_direct_relation
  name: Rule engine results
  description: Inference records whose focusNodeInstance points at this instance.
  source:
    type: view
    space: dataQuality
    externalId: RuleEngineResult
    version: v1
  through:
    source:
      type: view
      space: dataQuality
      externalId: RuleEngineResult
      version: v1
    identifier: focusNodeInstance

If the instance view and the record views are applied together, use one POST /models/views (SDK views.apply([...])) so neither side has to exist before the other.

Non-navigable records

Reverse navigation only works when the record has focusNodeInstance. Query these through the Records API (stream filter) instead:

Kind Why it is not reverse-navigable
Grouped uniqueness (validationType = group_violation) focusNode / focusNodeInstance are omitted
RAW table validation No DMS instance identity; focusNodeInstance is omitted
Edge-view SHACL (used_for: edge) focusNodeInstance is omitted; focus is the edge URI in focusNode (see property table in Records output)

Per-rule display names (sh:name) still help on those records for dashboards (constraint display names). They do not make the records reverse-navigable.

How to read (two-step)

Record views are not in data models yet, and records are not returned by GraphQL or /models/instances/query. Follow the CDF two-step pattern (Traversing between records and the graph):

  1. Filter instances on the data-modeling side (or start from a known instance).
  2. Query the Records API with equals / in on focusNodeInstance (at most 100 {space, externalId} values per in clause).

Flows should bind view + stream, not container + stream. Schema and filter examples: Records output.

Previous section

Next section