Polaris

Core Concepts

Understanding how Polaris manages technology governance

Polaris is an enterprise technology catalog that helps organizations govern which software technologies are approved for use, track what is actually running in their systems, and ensure compliance between the two.

Core distinction
Technologies are governed strategic choices approved by architecture teams. Components are actual software artifacts discovered in your systems through SBOM scanning. Polaris connects the two to surface compliance gaps.

Technology

A Technology is a governed software entity that requires architectural approval, lifecycle management, and version constraint compliance.

Strategic decision
Enterprise-wide architectural choice with long-term impact
Requires approval
Must go through governance processes before adoption
Version constraints
Subject to enterprise version standards and security oversight
Team stewardship
One team is responsible for each technology
Lifecycle managed
Tracked through the TIME framework (Tolerate, Invest, Migrate, Eliminate)
Linked to components
Maps to one or many discovered software components

Component

A Component is a software artifact discovered in systems through SBOM (Software Bill of Materials) scanning.

Concrete artifact
An actual software package or dependency in use
Discovered automatically
Found through SBOM scanning, not manually defined
Includes transitive deps
Captures the full dependency tree, not just direct dependencies
Compliance tracked
Monitored for compliance, security, and licensing
Optional technology link
May or may not map to a governed Technology
System-specific
Used in one or more systems across the organization

Technology vs Component

Technology
Definition
Governed strategic choice
Governance
Requires approval and oversight
Scope
Enterprise-wide decision
Discovery
Defined by architecture teams
Examples
"React" (framework choice)
Lifecycle
Managed through version constraints
Relationship
One-to-many with Components
Component
Definition
Actual software artifact in use
Governance
Tracked for compliance
Scope
System-specific dependency
Discovery
Discovered through SBOM scanning
Examples
"[email protected]" (npm package)
Lifecycle
Discovered and monitored
Relationship
Optional many-to-one with Technology

How Polaris Works

Governance Decision
Architecture team approves a Technology (e.g., React)
Team Approval
Individual teams approve the Technology for their use
Implementation
Developers use Components that implement that Technology (e.g., [email protected])
Discovery
SBOM scanning discovers Components in Systems
Compliance Check
Components are validated against approved Technologies
Violation Detection
Components without corresponding Technology approval are flagged

TIME Framework

The TIME framework categorizes technologies based on their lifecycle stage and organizational adoption strategy.

Invest
Strategic technologies receiving active investment. Recommended for new projects.
Tolerate
Legacy technologies being phased out. No new projects should use these.
Migrate
Technologies being actively replaced. Existing usage should be transitioned.
Eliminate
Technologies that must be removed due to security, compliance, or strategic reasons.
Usage in Polaris
Each technology can be assigned a TIME classification to help teams understand whether to adopt it for new projects, the urgency of migration efforts, and how resources should be allocated.

Team Approvals

Each team independently assigns a TIME category (Tolerate, Invest, Migrate, Eliminate) to the technologies it uses. Compliance violations are detected when a component appears in an SBOM without a corresponding team approval, or when the assigned category is Eliminate.

How it works

Identify
A team identifies a technology it uses or plans to use
Categorise
A team member or superuser sets the TIME category for that technology
Compliance checked
SBOMs are scanned; components without a team approval, or with an Eliminate category, are flagged as violations

Stewardship

Each technology has designated stewards responsible for:

Review requests
Evaluate and respond to team approval requests
Maintain documentation
Keep technology documentation current and accurate
Communicate updates
Notify teams of updates, deprecations, and changes
Support teams
Help teams using the technology with questions and issues

Why Team Ownership?

Continuity
People change roles and leave organizations. Team-level stewardship survives personnel changes without manual reassignment.
Shared accountability
Technology decisions benefit from collective judgment. Team ownership distributes responsibility across multiple people rather than creating a single point of failure.

Audit Trail

The audit trail captures governance decisions — changes to version constraints, approvals, team structure, and system ownership. Operational data that changes frequently through automated processes (components discovered via SBOM, repositories) is excluded.

Governance Operations

Version constraint lifecycle
Creation, activation, deactivation, archiving, and deletion of version constraints
License decisions
Allowing or denying licenses, and enabling or disabling the license whitelist
Technology approvals
TIME framework categorization, version-specific approvals, and revocations

Relationship Changes

Team membership
Adding and removing team members
Ownership changes
System ownership and technology stewardship assignments
Constraint enforcement
Changes to which teams a version constraint applies to
Access
The audit log is accessible to all authenticated users. Navigate to /audit to view the full history of governance decisions.