Live

Dashboard

The browser dashboard is the main operator surface for RTMify Live. It is served locally at http://127.0.0.1:8000 and queries the local SQLite graph, not the source spreadsheets directly.

Primary groups

Data

Requirements · User Needs · Tests · Risks · RTM

Core tabular traceability views over requirements, user needs, tests, risks, and the RTM row-per-chain view.

Analysis

Impact · Review · Gaps

Graph-level impact analysis, suspect/review surfaces, and chain-gap reporting.

BOM

Design BOMs · Components · Coverage · Part Usage · Gaps · Impact

Hardware and software Design BOM workspace. These views query the same graph available through the REST API and MCP.

  • —Design BOMs — grouped list of ingested Design BOMs by product and bom_name, including source format, item count, ingest time, warning count, and the server-rendered Design BOM detail tree
  • —Components — searchable flattened BOMItem view across products and Design BOMs, with resolved trace-link counts, warnings, supplier/category context, and direct navigation into parent assemblies
  • —Coverage — per-BOM and aggregate requirement/test linkage counts, no-trace counts, and unresolved-ref warnings
  • —Part Usage — where-used lookup for one part across products and parent assemblies
  • —BOM Gaps — unresolved requirement/test refs and other no-link conditions at BOM-item level
  • —Impact — BOM-centered impact and coverage analysis for one product BOM

Software / SOUP

SOUP Registers · Components · Gaps · Licenses · Safety Classes

Unified software inventory workspace for manual SOUP registers and automated software BOMs from CycloneDX/SPDX ingestion.

  • —SOUP Registers — product-scoped software BOM list with source format, warning count, and selected register detail
  • —Components — flattened software component view with supplier, license, purl, safety class, anomaly notes, and SOUP statuses
  • —Gaps — components missing anomaly evaluation, requirement links, test links, or carrying unresolved refs
  • —Licenses / Safety Classes — filtered operational views over software inventory metadata

Guide

Error Codes · MCP & AI

In-app reference content, MCP connection info, the current API token, inbox path, and token regeneration.

Code

Repos · Annotations · Commits

Repo registration, traceability annotations, implementation/test coverage, and recent commit evidence.

Reports

RTM · DHR · Coverage · Design BOM · SOUP

On-demand reports generated from the live graph rather than static document snapshots. Both the Design BOM report and the SOUP Register report are product-scoped, accept an optional bom_name, and are available as PDF, Markdown, and DOCX.

Settings and uploads

Settings

Design BOM Sync

The settings menu includes a dedicated Design BOM Sync tab. It manages the optional secondary read-only Design BOM source and supports Google Sheets, Excel Online, or a local XLSX file.

SOUP Sync

The settings menu also includes SOUP Sync. It is a second concrete read-only source, anchored to one Product via full_product_identifier, and supports Google Sheets, Excel Online, or a local XLSX workbook exposing SOUP Components.

Uploads

Design BOM uploads

The dashboard upload surface accepts .csv, .json, and .xlsx Design BOM artifacts. XLSX uploads go through POST /api/v1/bom/xlsx.

SOUP uploads

The SOUP workspace accepts .json and .xlsx uploads, links to the downloadable SOUP template, and the Reports group includes a product-scoped SOUP Register report in PDF, Markdown, and DOCX formats. SOUP inbox .xlsx files use the SOUP__{full_product_identifier}.xlsx filename convention. See the BOM/SOUP ingestion guide for details.

Guide → MCP & AI

This tab still shows the MCP endpoint URL, current API token, inbox directory path, and token regeneration. That is also where most operators confirm the inbox path before setting up BOM drops.

Workbook write-back boundary

Live still writes operational status back to the primary RTM workbook. The Design BOM source is intentionally different:

  • The primary RTM workbook continues to receive RTMify Status and verification write-back.
  • The secondary Design BOM sync source is read-only. Live ingests it, but never writes status back into that workbook.
  • The secondary SOUP sync source is also read-only and is anchored to one Product in config rather than per-row spreadsheet data.

The dashboard is graph-native

BOM views are not a spreadsheet mirror. They query the graph that connects Products, DesignBOMs, BOMItems, requirements, tests, test groups, code evidence, and serial-number evidence, so where-used and impact answers come from traversable relationships rather than flat rows.