[Feature request] Support semantic edge domains and configurable edge styling in graph rendering

[mvillmow]

[Feature request] Support semantic edge domains and configurable edge styling in graph rendering

Summary

Model Explorer needs first-class support for semantic edge domains in the base graph renderer.

Today, a graph can contain multiple kinds of edges with very different meaning: regular data flow, model inputs, model outputs, residual/highway paths, and shape/control flow. In practice, host applications may need more than a fixed small number of these domains.

The current model appears to treat base edges mostly as one visual class, with overlays handling extra emphasis. That makes architecture-style graphs harder to read when different edge categories need to be visible simultaneously as part of the default rendering.

Analysis

For model architecture and compiler-style graphs, edge semantics are often as important as node semantics. A user may need to distinguish, at the same time:

• normal data edges
• input boundary edges
• output boundary edges
• residual/highway edges
• shape/control/metadata edges
• additional domain-specific categories defined by the host graph producer

Overlays are useful for interaction and temporary highlighting, but they are not a full substitute for semantic edge classes in the default graph. They introduce separate UI state and are not the same as the graph declaring its native edge meaning.

The missing capability is a way for an input graph to describe an arbitrary edge domain/class and have that classification survive graph processing, grouping, layout, and rendering so the default visualization can encode it directly.

Suggested Solution

1. Add a first-class notion of semantic edge domains/classes to the graph model, rather than treating edge styling as effectively global.

2. Allow host applications or graph producers to define style mappings for those domains, including at least color, width, and dashed/solid treatment.

3. Support an arbitrary number of edge domains instead of limiting the system to a small built-in set. Built-in defaults are useful, but the design should remain extensible.

4. Preserve edge-domain information through internal processing steps so the renderer can apply consistent styling after grouping, namespace transforms, and layout.

5. Keep overlays as a separate optional layer for interaction/highlighting, not the only mechanism for representing semantic edge categories.

Motivating examples for built-in defaults could include data, input, output, residual, and shape, but the API/design should not assume that those are the only useful domains.

Environment

• Model Explorer source: current main branch
• Use case: architecture-style and traced model graphs where node and edge semantics both matter
• Rendering mode: standard graph visualization, not only custom overlays

[sourcelite]

Hi @mvillmow, thanks for bringing this feature request and suggested solution.

to evaluate the proposed arch could you please provide a few more details:

1. can i ask you for a snippet that will show how you are envision these semantic edge domains being defined within thta input graph format (for example - changes to the json schema or python api)?
2. how do you want the host application mapping these style to domain (for example - passed as a separate configuration object during init or etc)?
3. do you have reference image to show the desired styling difference (like the colour, width, dashed or solid)

Thanks!

[mvillmow]

@sourcelite Sorry for the late response. I was out last week. Here is what I have.

This shows how I am utilizing this feature:
https://github.com/user-attachments/assets/ae154aec-b28f-462c-bf88-cc53a1f7ab40

This is where I am annotating it in the attributes:
https://github.com/user-attachments/assets/57b8df6e-a006-4dbb-a389-1626670c12f4

For me the simplest version would be:

1. Let each edge carry one semantic domain/class, for example edge_domain: data, residual, input, output, shape, etc.

Something like:

incomingEdges: [
  {
    sourceNodeId: 'a',
    sourceNodeOutputId: '0',
    targetNodeInputId: '0',
    metadata: {edge_domain: 'data'},
  },
  {
    sourceNodeId: 'b',
    sourceNodeOutputId: '0',
    targetNodeInputId: '1',
    metadata: {edge_domain: 'residual'},
  },
]

2. Keep styling separate from the graph data.

So the graph only declares the semantic class, and the host app / visualizer config maps that to style like color, width, dashed vs solid.

3. The screenshots above are the reference for the kind of visual difference I want.

I do not need a very complex styling system. I mainly just need the default graph rendering to distinguish different edge categories at the same time, instead of treating them all as one base edge type unless I use overlays.

[github-actions]

Marking this issue as stale since it has been open for 7 days with no activity. This issue will be closed if no further activity occurs.

[mvillmow]

@sourcelite Need anything else from me? Don't want this to get marked as stale and deleted