Architecture
One browser model, not one GUI per runtime.
Each engine publishes an opt-in cold telemetry snapshot through the established metrics boundary. The Workbench daemon normalizes that source-neutral contract and serves a browser model for a deployment-owned target manifest.
LibHFT engines
└─ opt-in local metrics / UDS
└─ allowlisted Workbench collector
└─ normalized read-only browser modelThe UI does not need runtime-specific protocol logic to decide whether a Java/JNI or .NET Native session is healthy. Provider differences remain in the source facts rather than in separate dashboards.
Operational semantics
Unknown is not zero, and disconnected is not always failed.
Evidence supports operation
Active sessions or confirmed passive HA standbys satisfy the declared profile.
Service continues with evidence
Resend activity, validation counters or other conservative conditions require attention.
Safety or continuity failed
Store failure, split ownership or a profile-specific terminal condition is visible.
Evidence is unavailable
Missing telemetry is preserved as unavailable rather than converted into a reassuring zero.
Session inspection
Connection, sequence, validation and store facts.
The inspector groups the canonical fields into operational questions:
- Is the transport connected and the FIX session active?
- What are the expected inbound and next outbound sequences?
- Is resend recovery pending, and what range is involved?
- Have validation or reject counters advanced?
- Is the durable store healthy, and how much bounded capacity remains?
- Is HA enabled, is primary ownership known, and does the fleet show split ownership?
Security boundary
The browser cannot choose what the daemon fetches.
Targets are declared in a checked deployment manifest. The browser cannot submit an arbitrary host, port, path or credential. The public model excludes endpoint addresses, CompIDs, credentials, store paths and unknown manifest fields.
The Workbench has no acknowledge, reset, reconnect or sequence-mutation route. Any future control console requires independent authorization, audit and threat modeling rather than a button added beside a health badge.
Scenario evidence
The UI is exercised with real transitions.
Browser scenarios cover order-entry and market-data flows, resend recovery, validation rejection, store pressure, HA standby, reconnect and split-brain presentation across the established runtime surfaces. The interface retains genuine lifecycle differences instead of normalizing every engine into the same synthetic green state.