Living Software Catalog and Version Drift

Catalogs Landing

IllustrationEnlarge illustration

This illustration shows the top level of the catalog area. A heading gives the number of catalogs, next to actions for creating one and an overflow menu, and an explainer strip defines a catalog as a team's organized library of software components — services, APIs, jobs and the systems they belong to. A search field and a visibility filter sit above a showing-of-total line. The body is a three-column grid of catalog cards, each with an icon, a name, a badge marking it public, internal or private, a one-line summary, and a footer carrying a component count, a linked-project count and small classification chips such as a domain or tier marker. Names and figures shown are sample data standing in for a real organization's libraries.

Components Table with Owners and Health

IllustrationEnlarge illustration

This illustration shows the components list, headed by a count of how many are in the catalog and a create action. An explainer strip describes components as the individual building blocks of the software — each service, frontend, library or API — tracked with its owner, dependencies and lifecycle. Below it, a search field sits beside filters for type and lifecycle, over a showing-of-total line. The table gives each component an icon and a type sub-label, an owner shown as an avatar with a name, a lifecycle badge reading active, experimental or deprecated, a tier badge in a gold, silver and bronze scheme, a version string and a health column drawn as a small progress bar with a numeric score and a check mark. All rows are sample data.

Component Detail and Dependency Graph

IllustrationEnlarge illustration

This illustration shows a single component opened from the catalog. A back link sits above a header carrying the service name, a one-line description with its owner, a share action, and badges for kind, lifecycle and tier. Beneath the header, summary cards give the type, the lifecycle with a small progress indicator, the current version, the number of catalogs the component belongs to, and a set of tag chips. A tab row spans overview, catalogs, scorecard, docs, dependencies with a count, the originating template and settings, with dependencies selected. The canvas below draws five upstream packages as nodes, most labeled with a version and each with a badge marking a runtime or peer relationship, with curved edges converging on the service node. Zoom and fit controls sit in the corner. All names and versions are sample data.

Environment Topology and Version Drift

IllustrationEnlarge illustration

This illustration shows the environment topology view, described in its subtitle as the current deployed version of every component across development, staging and production. Header actions offer promoting a version and recording a deployment. The table lists components with a type sub-label down the left and one column per environment; each cell pairs a colored status dot with a version string, or shows a dash-and-add placeholder where no deployment has been recorded for that environment. The sample rows show several shapes at once — a service running ahead in development, a frontend trailing in production, a service and an infrastructure module with no production entry, a machine-learning pipeline service whose production cell is flagged red, and a mobile app with no staging record. A legend at the foot separates in sync, behind or drifting, and stale production.