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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.interlynk.io/interlynk-core-concepts/core-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.