Overview

This section describes the domain model of the Interlynk platform — how data is organized, how entities relate, and how to operate them safely. Understanding these concepts is essential for configuring the platform, building automation, and troubleshooting issues.

---

System Model Overview

Interlynk organizes software supply chain data in a hierarchical model. Each level of the hierarchy adds specificity, from the broadest grouping (Product) down to individual security findings (Vulnerability).

Organization
└── Product
    └── Environment
        └── Version (SBOM)
            ├── Parts (embedded sub-SBOMs)
            │   └── Components
            │       └── Vulnerabilities
            └── Components
                └── Vulnerabilities

Data Flow

1. A team member creates a Product to represent a software artifact.

2. Each Product contains one or more Environments (e.g., Development, Production) that reflect deployment stages.

3. When an SBOM is uploaded to a Product's Environment, it creates a Version — a point-in-time snapshot of the software's composition.

4. Each Version contains Components — the libraries, packages, and modules that make up the software.

5. Versions may also contain Parts — references to other Product Versions that are embedded or bundled alongside the primary SBOM.

6. The platform maps Vulnerabilities to Components using package identifiers (PURL, CPE) and vulnerability databases.

Isolation Boundaries

Boundary	Scope	Behavior
Organization	Top-level tenant	All data is scoped to the organization. Users, tokens, policies, and vulnerabilities are isolated between organizations.
Product	Logical grouping	Products are independent. Policies, labels, and settings do not cross Product boundaries unless explicitly configured at the organization level.
Environment	Deployment stage	Environments within a Product are independent. Each has its own settings, automation rules, and Version history. Vulnerability data does not merge across Environments.
Version	Point-in-time snapshot	Each Version is an immutable record of the software's composition at upload time.

Lifecycle Flow

SBOM Upload → Version Created → Processing Pipeline → Operational State

Processing Pipeline:
  1. SBOM Checks (quality, completeness)
  2. Internal Component Labeling
  3. Automation Rules execution
  4. Vulnerability Scanning
  5. Component Support Analysis
  6. Policy Evaluation

After processing completes, the Version and its Components are available for querying, reporting, and compliance evaluation.