Objective, architecture and components
The implemented portion uses live history traces for CPU, GPU, VRAM, RAM and GPU temperature. It distinguishes live, stale and unavailable snapshots, and provides real time-window controls. Task, validation, organ, event and resource lanes can be separated in expanded presentation.
Shared hardware traces
CPU, GPU, VRAM, RAM and thermal samples share an interpretable time domain.
Activity lanes
Task, validation, organ and event records are shown only when source records exist.
Time windows
Controls change the rendered dataset rather than decorative labels.
Future correlation
Power, fans, tokens and richer event context remain incomplete or planned.
Validation, limits and recovery
Functional repair evidence records live resource traces, sample-age display, stale-state handling and a visual smoke result. Fan speed and power are absent when the telemetry source does not provide them. Historical resource replay is not reconstructed where older run records lack per-run traces.
- Claim
- Live hardware traces and real time-window rendering were repaired and tested.
- Method
- Focused telemetry tests, application tests, runtime suite and real GUI smoke.
- Result
- Bounded live history and stale/unavailable behaviour are evidenced.
- Limitation
- The complete end-state timeline, causal attribution, power/fan telemetry and durable organ-event coverage are not established.
- Source period
- 2026 functional-repair record.
Current state and planned development
The visual design is locked in parts and the instrument is partially implemented. Future work may add scrubbing, zoom, event annotation and a proposed portable glance surface. Those are not represented as operational today.
It relates directly to Observatory and Core Shard, which may expose bounded machine state without becoming a dashboard or a control authority.
Sources: canonical timeline functional-repair and truthful live-wiring result records. Raw metrics, machine identifiers and internal event sources are excluded.