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
A Technology is confirmed from a Component that SBOM scanning actually discovered in your systems — it can never exist without that evidence. A Platform is the deliberate exception: infrastructure and services (databases, cloud platforms) that SBOM scanning can never observe, declared manually by a superuser instead. Polaris uses this discovery-first model to keep governance grounded in what's actually running, not just what's been typed into a form.

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)
Requires a component
Can only be created by claiming at least one discovered, unlinked software component — never created from scratch

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
Confirmed by architecture teams from a Component that SBOM scanning already discovered
Examples
"React" (framework choice)
Lifecycle
Managed through version constraints
Relationship
One-to-many with Components (at least one required)
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

Platform

A Platform is the deliberate exception to Technology's evidence requirement: infrastructure and services that SBOM scanning can never observe from a source repository, no matter how real their usage is.

No evidence required
Unlike Technology, never needs a linked Component — that is the entire point of the entity
Superuser-only creation
The deliberate, narrow exception to evidence-based governance
Same stewardship model
One team stewards each Platform, same as Technology
Same TIME framework
Tracked through Tolerate, Invest, Migrate, Eliminate, same as Technology
Typical examples
Databases, cloud services, container runtimes — PostgreSQL, MongoDB, Docker
No version tracking yet
Version/EOL tracking for Platforms is not yet built — a known gap, not an oversight
Why superuser-only?
Platform is the one place a governance record can exist without evidence behind it. Restricting creation to superusers keeps that exception rare and deliberate, rather than becoming a backdoor around the Technology catalog's evidence requirement.

How Polaris Works

Implementation
Developers add a real dependency to a project (e.g., [email protected])
Discovery
SBOM scanning discovers the Component in a System, initially unlinked to any Technology
Confirmation
A superuser confirms the unlinked Component from the Component Link Queue, creating the Technology (e.g., React) from it
Team Approval
Individual teams set a TIME category for the now-evidence-backed Technology
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.

No approval is a violation, distinct from Eliminate
A technology with no recorded team approval is 'unclassified' — a distinct state from an explicit Eliminate vote, not the same value. Both are treated as compliance violations, so nothing is ungoverned by omission, but Polaris keeps 'never reviewed' distinguishable from 'actively banned' since stewards need to know which one they're looking at.

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.

Technology Radar

The Technology Radar aggregates every team's individual TIME approval for a technology into a single, organization-wide consensus view — a majority vote across all teams that have recorded a stance.

Tie-break order
When teams are evenly split, the Radar resolves the tie by favoring the more cautious category: Eliminate outranks Migrate, which outranks Tolerate, which outranks Invest. A tied vote never resolves toward the more permissive stance.

Version Sprawl

Version sprawl detection flags components in use at too many distinct versions across the organization at once — a signal that a technology has drifted out of consistent, centrally-governed use.

Direct usage only
Only versions a System depends on directly count toward sprawl — versions that appear solely as transitive dependencies are excluded
Minimum version count
A component must be in use at a minimum number of distinct versions across the organization before it is flagged at all
EOL-weighted severity
Sprawl is scored by severity, weighted more heavily when one or more of the versions in use is past end-of-life

License Compliance

Every license discovered through SBOM ingestion is checked against an organization-managed allow list, maintained by superusers.

No review defaults to not allowed
A license with no explicit allowed/denied decision recorded is treated as not allowed — the same outcome as one a superuser has actively reviewed and denied. There is no neutral or unreviewed state, the same default-deny posture used for TIME approvals above.
Bulk updates are all-or-nothing
Approving or denying many licenses at once is transactional: if any license in the batch doesn't exist, the entire update is rejected and none of the valid ones are applied.

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.

Failures and sensitive reads are audited too
A failed governance operation — for example a rejected technology creation — still produces an audit entry, not just successful ones. Certain sensitive reads, such as viewing the full user list as an admin, are logged as well, even though nothing was changed. Audit writes are best-effort: if writing the audit entry itself fails, the operation it was recording still completes — auditability never blocks or breaks the action it documents.

Governance Operations

Version constraint lifecycle
Creation, activation, deactivation, archiving, and deletion of version constraints
License decisions
Allowing or denying licenses on the organization-managed allow list
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.