Back to buildsBUILD RECORD

Operations Snapshot Dashboard / Local dashboard / 2026

Reading two systems through checked snapshots.

A local operations view keeps each source's result and freshness visible, including when one refresh fails or the latest snapshot is invalid.

Confidential work. Names and identifying business details have been changed.

ROLE
Software engineering
STATE OF THE BUILD
In progress
RECORD UPDATED

THE WORK

The project.

Operations Snapshot Dashboard brings Operations Ledger and Research Workflow Engine into one local read-only view without sharing their databases. Independent MCP clients fetch versioned snapshots, then schema, digest and time checks determine what can be shown. A useful response from one source can remain visible while the other reports a failure.

ATTEMPTS & CORRECTIONS

What changed along the way.

  1. Keeping the local view available after the terminal closes
    At first
    The dashboard ran from a manually started server and stayed available only while that terminal session remained open.
    What needed to change
    Closing the terminal took the view down. I wanted it to remain available without keeping a terminal open or having a browser window appear every time I logged in.
    My direction
    I asked for the view to remain available without opening it at login or requiring a terminal process to stay open.
    The change
    The existing read-only server now has a per-user background service that starts at login and restarts after an unexpected exit. It opens no browser, keeps its loopback address and saves no dashboard snapshots. Source refreshes still happen only while a page is open, and installation checks the configured runtime and service health before reporting success.
    The result
    Service availability no longer depends on a visible terminal or browser window, while source records remain read-only from the dashboard. Test definitions check the service configuration and exclude browser and credential data. Installation and live health weren't checked again for this account.

IMPLEMENTATION

Design choices.

  1. Select first, validate second. The latest update is the one that needs checking; searching backwards for a passing record would hide a producer failure behind older data.
  2. Staleness and invalidity need different displays. Expired data can remain useful when labelled, but a failed schema or digest check supplies no accepted payload for that snapshot.
  3. Versioned MCP exports keep private table structures out of the UI. Producers can change their internals independently, while a new unsupported export version still requires an explicit consumer update.
  4. The dashboard has no business database and no write actions. The source applications remain responsible for changes and reconciliation, so the view doesn't become a third place to maintain the same records.
  5. Loopback is part of the current design. Moving the view onto a public address would require authentication and authorization; changing the listen address alone wouldn't provide them.

HOW IT FITS TOGETHER

Architecture.

  • The HTTP server belongs to the Operations Ledger project and listens on loopback. Before requesting data, it checks the Host header, GET or HEAD method, URL length and reporting input. It exposes a reading interface, not another route for ledger writes.
  • Separate STDIO MCP clients connect to the ledger and research engine. Each starts and refreshes independently, so a failure in one doesn't discard the other's response. The dashboard owns neither source database.
  • For each snapshot identity, the model selects the newest record before validating it. Supported schema versions, required capabilities, canonical payload digests and timestamps decide whether the selected payload can be accepted. An older passing record can't silently conceal a broken latest update.
  • The combined response retains each source's status, accepted payload and error reason. An open browser page schedules refreshes; a transport failure changes the view to unavailable. Otherwise valid data that has expired can stay visible with a stale label rather than being presented as current.
Explore the architecture map9 components · 10 connections

Independent snapshot producers behind a read-only interface

Two source services feed one validated view without sharing storage or exposing dashboard mutations.

Direct callAsync taskResponse / returnBlocked / denied
Local browser
Coordinator
Source services

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (10)
  1. 01 · Dashboard request → 02 · Loopback HTTP guardGET projection · Direct call
  2. 02 · Loopback HTTP guard → 08 · Visible failure stateinvalid request boundary · Blocked / denied
  3. 02 · Loopback HTTP guard → 03 · Independent MCP clientsvalidated period · Direct call
  4. 03 · Independent MCP clients → 04 · Ledger exportersnapshot request · Async task
  5. 03 · Independent MCP clients → 05 · Research exportersnapshot request · Async task
  6. 04 · Ledger exporter → 06 · Snapshot acceptancesnapshot or failure · Response / return
  7. 05 · Research exporter → 06 · Snapshot acceptancesnapshot or failure · Response / return
  8. 06 · Snapshot acceptance → 07 · Combined view modelaccepted data and status · Direct call
  9. 07 · Combined view model → 09 · Read-only renderingview projection · Response / return
  10. 07 · Combined view model → 08 · Visible failure statesource limitation · Response / return

MADE WITH

TypeScript · Node.js · MCP · JavaScript · HTML · CSS · Lucide

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

  1. Code and development records reviewedReviewed

    The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

    Scope of this check
    Code review, not a fresh run of the app

NEXT

Still to work through.

Snapshot checks establish whether the returned data fits the expected format, digest and timing rules. They still depend on sensible producer timestamps and don't establish that the underlying business facts are complete. This write-up didn't run the dashboard or inspect live data.

FROM THE SAME WORK

Technical note

Validate the newest snapshot, not the newest valid one