Compute journeys

How many nodes, are they reporting, which is behind, what the wrappers are doing, how much work is in flight, and how that load moved over the last day and week.

Security: the fleet is the installation's and carries no tenant's data, so everyone the permission admits may read it whole. The work counts are the installation's own observed ledger: the service is already inside each tenant when it dispatches that tenant's work and when it takes the result back, so it records what it did as a fact about its own operation. They need no cross-tenant read — the ledger is installation data — and no second journey.

One job end to end: its state, its node, its timings, its inputs and outputs, and where its time went.

Security: rows. A member sees their own job, a tenant administrator their tenant's, the super administrator all of them. One journey.

A job's full detail — its app version, package, command, inputs, exit code and stderr — plus the node's own logs, so the work can be reproduced locally.

Security: this is the one genuine boundary, and it is a capability rather than a journey. The job's own detail is rows and narrows as in use case 2. A node's logs are installation logs and may carry another tenant's inputs, so pulling them is a capability the super administrator holds and another tenant administrator does not. Same screen, one control withheld.

What capacity the nodes have, what a job needs, what is scheduled to kick in soon, and whether the grid can absorb it.

Security: rows again. A tenant sees its own arrivals and its own share; the installation's totals are the installation's.

The apps, their versions and packages, and the concurrency policy that caps how many of a thing run together.

Security: writing the catalogue is the super administrator's; reading it is everyone's, because a tenant needs to know what it may submit. A permission on the write, one journey.

Drain a node for maintenance, requeue stuck work, stop a runaway.

Deferred. This is control, not observation, and the Operations area's mode is reading. It may belong with the scheduler journeys.

The watch screen's Usage tab carries one more chart, from the installation's own ledger rather than from the fleet's samples:

The job is the anchor of a chain that spans three components: the scheduler holds the job that fires, reporting holds the definition and the run it fired, and compute holds the batch, the workunits and the results that run produced. The chain is one picture, because the question "what caused this job, and what else ran with it" cannot be answered inside any one of the three.

The chart belongs to the Follow a job screen, because a person reaches the chain from a job and the compute rows are where the chain is read. Diagnose and reproduce a failure reuses the same chart from the failed run, which is the same chain with one result chosen. The reporting run screen and the scheduler monitor read the chain from their own ends and reuse the same chart rather than inventing a parallel one. The chain is the answer to the open question "jobs versus reports" below, and Compute job lifecycle is where its middle is confirmed.

Allocation left this use case for the Usage view; the planning capacity use case no longer claims it.

• A time range, not the newest row. Every chart above spans time. The grid serves it with get_grid_series and get_node_series, which return stored samples in whole buckets over a range. Expose the telemetry stats surface is the same need on the telemetry logs' side rather than on the grid's.
• A range selector and one shared axis. The poller keeps thirty days, so last hour, day and week are all answerable; the panels must share one time axis so a spike lines up across them.
• A metric per panel, not a chart type per panel. The heatmap is the same chart whether it is coloured by work, failures or bytes.
• Almost nothing here needs a new write. grid_sample and node_sample carry the load, throughput, outcome and queue series, and host carries the capacity, so those gaps are reads and not collection. The capacity headroom series is the exception: it wants a used-against-total figure, and host states only the total (cpu_count, ram_mb, gpu_type). No row states the cores, memory or GPU in use, so that one series needs collection as well as a read.

frames would not answer the question the walk is for. The charts are drawn from mock series in the prototype's own idiom, at the sizes the real screen would give them, so the walk can judge whether a heatmap of nodes is legible and whether the timeline earns its space.

HostMdiWindow, BatchMdiWindow, WorkunitMdiWindow, ResultMdiWindow, QueueMonitorMdiWindow, QueueChartWindow, ComputeConsoleWindow, ComputeDashboardMdiWindow, ConcurrencyPolicyController, AppMdiWindow, AppVersionMdiWindow, TransferProgressDelegate and the Report* family. Not one of them has a journey behind it. The legacy client is not the target — the journeys are — but its breadth measures what is missing.