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
- Keep unknown and ambiguous steps visible instead of hiding them
- Move between Repository context, BPM milestones, and related events more naturally
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 can explain the step, but not one clear Service |
| 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.
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 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 |
| 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 |
Use runtime inspection when you want runtime truth. Use an authored Dynamic diagram when you want stable reference documentation.