Living Software Catalog and Version Drift
Catalogs, components, dependencies and deployed versions in one place, with drift between environments called out at a glance.
These images are illustrations of the concept, not screenshots of the actual product.
Overview
The software catalog is the heart of the VibeControls developer portal. This concept organizes everything a team runs into catalogs for systems and domains, each holding typed components such as services, frontends, APIs, libraries, infrastructure modules and mobile apps. Every component carries an owner, a lifecycle stage, a tier, a version and a health score, and the design adds a dependency graph for each component and an environment topology that compares deployed versions across Development, Staging and Production.
Service catalogs tend to drift from reality soon after they are written. Owners change, deprecated services linger, and nobody is quite sure which version is running in production compared with staging. The design ties the catalog to the vibes and agents where work actually happens, so it is meant to stay close to what is really deployed, and it calls out drift instead of hiding it.
The illustrations move from broad to specific. The Catalogs landing shows a grid of catalog cards with Public, Internal or Private visibility, counts of components and linked vibes, and tags, with search and a visibility filter. The Components view lists every component in a table with owner, lifecycle, tier, version and a health bar, filtered by type and lifecycle. Opening a component, here a sample payments service, shows summary tiles for type, lifecycle, version, catalog membership and tags, and tabs for Overview, Catalogs, Scorecard, Docs, Dependencies, Template and Settings; the Dependencies tab draws each package, with its version and a runtime or peer label, flowing into the service. Environment Topology then lays components against the three environments, marking each version as in sync, behind or drifting, or stale in production, with Promote version and Record deployment actions.
The catalog connects to the rest of the portal: golden-path templates scaffold new components into it, scorecards and living docs hang off each component, and AI proposals are envisioned to suggest reconciling components that no longer match what agents report.
What this concept shows
- A catalogs landing of domain cards with Public, Internal or Private visibility, component and vibe counts, and tags
- Search and a visibility filter across catalogs, with a Create Catalog action
- A components table showing owner, lifecycle, tier, version and a health score for each component
- Type and lifecycle filters, with lifecycle states such as Active, Experimental and Deprecated and tiers from Gold to Bronze
- A component detail page with summary tiles for type, lifecycle, version, catalog membership and tags
- A dependency graph showing each package, its version and whether it is a runtime or peer dependency
- An environment topology grid of deployed versions across Development, Staging and Production, colored as in sync, drifting or stale in production
- Promote version and Record deployment actions, with an add placeholder wherever no deployment is recorded
How it works
- Open Catalogs to browse the organization's systems and domains, searching by name or filtering by visibility.
- Move to Components to see every service, frontend, API and library with its owner, lifecycle, tier, version and health.
- Narrow the table by type or lifecycle, for example to find deprecated components that are still in use.
- Open a component to review its summary and switch to Dependencies to see the packages it relies on.
- Open Environment Topology to compare deployed versions across Development, Staging and Production.
- Record a deployment or promote a version to bring a drifting environment back in line.
Who it's for
- Platform engineers maintaining an internal developer portal
- Engineering managers who need clear ownership and lifecycle data
- Release managers and SREs tracking what runs in each environment
- Security reviewers checking component dependencies
- New team members learning how the system fits together
Illustrations
4 illustrations of this concept. Select one to view it full size.
Catalogs Landing
This illustration shows the Catalogs page, the entry point to the software catalog. The header states how many catalogs exist and offers a Create Catalog button and an overflow menu, and a banner explains that a catalog is 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 result count. Catalog cards fill a three-column grid, named for areas such as payments, checkout and web, machine learning, infrastructure, developer experience, notifications, mobile, data and analytics, and identity and access. Each card has a visibility badge of Public, Internal or Private, a short description, counts of components and linked vibes, and tags such as domain and tier.
Components Table
This illustration shows the Components view, which lists the individual building blocks of the catalog. A banner defines a component as a service, frontend, library or API tracked with its owner, dependencies and lifecycle. The header shows the total number of components with a Create Component button, and filters for free-text search, type and lifecycle sit above a line confirming how many components are shown. The table's columns are Component, Owner, Lifecycle, Tier, Version and Health. Each row pairs a component icon and name with its type, an owner avatar and name, a lifecycle badge such as Active, Experimental or Deprecated, a tier badge of Gold, Silver or Bronze, a version number, and a horizontal health bar with a numeric score and a check mark. The rows use placeholder names and figures as sample data.
Component Detail and Dependencies
This illustration shows the detail page for a single component, a sample payments and settlement service, reached from a Back to Components link. The header gives its name, a one-line description with its owner, badges for service type, active lifecycle and gold tier, and Share and refresh buttons. Summary tiles show the type, the lifecycle with a progress bar, the version, the number of catalogs it belongs to and its tags. Tabs cover Overview, Catalogs, Scorecard, Docs, Dependencies, Template and Settings, with counts on Catalogs and Dependencies. The Dependencies tab is open on a dotted canvas: five package nodes, each showing a version and a Runtime or Peer label, connect by curved lines into the highlighted service node on the right. Zoom in, fit and zoom out controls sit in the lower corner of the canvas.
Environment Topology and Version Drift
This illustration shows the Environment Topology page, which the design uses to compare the deployed version of every component across Development, Staging and Production. Promote version and Record deployment buttons sit in the header above an information banner. The grid lists components with their types, including services, a frontend, an API, an infrastructure module and a mobile app, and each environment cell shows a version number with a colored status dot. A legend at the bottom explains the three states: in sync, behind or drifting, and stale in production. In the sample data, several components run newer versions in Development than in Staging, one shows production lagging behind both lower environments, and cells with no recorded deployment show an add placeholder so the gap can be filled in.
Topics
- software catalog
- internal developer portal
- service catalog with ownership
- component lifecycle tracking
- service dependency graph
- environment version drift
- deployed version matrix
- dev staging production versions
- service health scores
- release promotion tracking
Related concepts
Golden-Path Templates and Scaffolding
Pick a team-approved blueprint, fill in a few variables and get a new component with its build, CI, ops deck and docs already wired.
2 illustrations
GitOps, Living Docs and Quality Scorecards
See a project's repository activity, its compiled documentation and a weighted quality score side by side, inside the vibe itself.
3 illustrations
Project Workspaces and Notes
Vibes tie a piece of work to its repo branch, folder, bound agents, environment variables and notes, so context travels with it.
3 illustrations
Human-Approved AI Plans
Coding agents propose numbered plans that people review, annotate and approve before a single step runs.
2 illustrations