# 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.