Inspect Grouped Log Views as Runtime Diagrams
In addition to authored diagrams in a Diagram Set, Architecture Diagrams can inspect a grouped Log View as an on-demand runtime diagram. This view turns related events into a readable runtime story without asking the user to create or save a diagram first.
- Read the runtime path behind one grouped Log View
- Switch between Participants mode and Systems mode without leaving the investigation
- Toggle Horizontal or Vertical layout mode to fit your analysis workflow
- Keep unknown and ambiguous steps visible instead of hiding them
- Move between Repository context, BPM milestones, and related events more naturally
Diagram: Polished horizontal runtime view with matched Component Type icons, entity tags, and the updated column layout.
Diagram: Alternate runtime layout of the same capability. Users can switch the same runtime trace between Horizontal and Vertical mode.
Horizontal and Vertical layout modes
Users can switch the runtime diagram orientation at any time:
- Horizontal mode keeps long end-to-end flows readable across wider screens and works well with the docked or detached Steps panel
- Vertical mode gives a compact top-to-bottom reading pattern when screen height is easier to use than width
The layout toggle changes the visual arrangement only. The underlying steps, participants, systems, monitoring state, and node metadata stay the same.
Killer feature - Runtime architecture from grouped search fields
This is an investigation-first runtime capability, not a designer workflow.
When you open a grouped Log View, Nodinite uses grouped search-field context plus Repository bindings to generate a dynamic runtime architecture view on demand.
- No manual modeling step
- No canvas preparation
- No diagram authoring required
This is why teams use it as a "what actually happened" view during incidents and handover analysis.
What this iteration adds for UseContracts=true
The grouped runtime inspection path is now contract-aware when UseContracts=true is enabled.
- A grouped runtime trace now resolves real Contract candidates from Transport Contract context
- When exactly one Contract is resolved, that contract is used as the runtime participant node
- In Systems mode, contract ownership takes precedence when placing the step inside a System boundary
- Deterministic contract-owned traffic is less likely to end up in Unknown System
Understanding the runtime inspection flow
Related events"] Resolve[" Repository resolution
Service, Contract, System"] Participants[" Participants mode"] Systems[" Systems mode"] Issues[" Issues
Unknown or ambiguous steps"] Group --> Resolve Resolve --> Participants Resolve --> Systems Participants --> Issues Systems --> Issues style Group fill:#87CEEB style Resolve fill:#FFD700 style Participants fill:#90EE90 style Systems fill:#90EE90 style Issues fill:#FF6B6B
Diagram: The grouped Log View provides the related events, the Repository resolves the best available participant or System context, and the runtime inspection view keeps unresolved issues visible for investigation.
Participants mode
Participants mode is the detailed runtime view. It focuses on the participant that best matches each step in the grouped Log View.
| What the user sees | When it appears |
|---|---|
| Service | One clear Service can explain the step |
| Contract | One clear Contract is resolved for the step. When this is true, the participant node uses the contract |
| Ambiguous participant | Several Services or Contracts can explain the same step |
| Unknown participant | The related events do not provide enough Repository context to resolve a participant |
Participants mode is the best place to understand handoffs, drill into an unexpected step, and compare the runtime path with the event list.
When a step resolves to a Service, you can continue from architecture context into operational context, including live health and remote actions via the same service entity.
Systems mode
Systems mode rolls the same runtime path up into System boundaries. This gives teams a cleaner overview when a transaction crosses several Services in the same System.
Systems mode behaves best when:
- each Service or Contract belongs to the right System
- System names are understandable to business and technical users
- users want a quick system-to-system story before drilling deeper
When a resolved Contract and a fallback Service point to different owners, Systems mode prioritizes the contract owner for boundary placement.
When the System cannot be determined with confidence, the step stays visible in Unknown System instead of being forced into a misleading boundary.
Issues are part of the answer
This feature is designed to show uncertainty instead of hiding it. That is why unknown and ambiguous steps remain visible.
The Issues view is useful when you need to answer questions such as:
- Which related events still lack a clear participant?
- Where do several candidates compete for the same runtime step?
- Which Services or Contracts still need a clear System owner?
For operational teams, this means the runtime inspection view is both a troubleshooting aid and a quality signal for the Repository.
What Repository data helps most
| Repository data | Why it matters in the runtime diagram |
|---|---|
| Service | A clear Service gives the user the most precise participant |
| Contract | A Contract keeps the step understandable when Service resolution is not precise enough |
| System | System ownership makes Systems mode readable |
| Transport Contract | Transport Contract context helps the flow stay understandable across sender and receiver steps |
| Repository bindings | Good bindings reduce Unknown and ambiguous steps |
Runtime inspection vs authored Dynamic diagrams
This runtime diagram is not the same thing as an authored Dynamic diagram in a Diagram Set.
| Runtime inspection from grouped Log Views | Authored Dynamic diagram |
|---|---|
| Opened on demand from related events | Created and saved as documentation in a Diagram Set |
| Generated from grouped search-field context and Repository data | Manually curated by authors for long-term documentation |
| Shows what the selected runtime path actually did | Shows the intended or curated sequence a team wants to document |
| Can roll participants up into Systems mode | Follows the normal Dynamic diagram authoring rules |
| Best for troubleshooting and investigation | Best for architecture communication and long-term documentation |
Service operations directly from runtime context
The runtime view is not only visual. Service-resolved steps connect to operational actions:
- Live service health for monitored services
- Service-level troubleshooting context during incident triage
- Remote Actions where permissions and resources allow it
See Monitoring – Operational Health on Nodes for the service monitoring model used in C4 surfaces.
Steps panel
The Steps panel lists every step in the runtime trace with its sequence number and participant names. It is docked to the right edge of the diagram by default.
Docking and detaching
| Behaviour | How to trigger |
|---|---|
| Docked to the right | Default position. The panel stays anchored to the right edge of the view. |
| Floating / detached | Click the detach icon on the panel. It becomes a free-floating window you can drag to any position on the full page — including away from the diagram canvas. |
| Return to dock | Click the same icon again to snap the panel back to its docked position on the right. |
Detaching the Steps panel is useful when a transaction spans many participants and you want to keep both the diagram and the step list visible simultaneously across a larger screen area.
Scope for this release
This iteration improves grouped runtime inspection classification and placement. Import behavior is intentionally unchanged.
Use runtime inspection when you want runtime truth. Use an authored Dynamic diagram when you want stable reference documentation.