# Core concepts

# Core concepts

A short tour of the nouns you'll meet everywhere in inline.

## Organization (workspace)

The tenancy boundary. Every connection, repo, review, finding, and setting belongs to exactly one organization. Users can belong to several and switch the active one from the sidebar. Everyone gets a personal organization automatically; teams create shared ones and invite [members](./members-invites.html).

## Connection

A link to GitHub. It's either the **inline GitHub App** (the bot, org-wide) or an **OAuth** connection under an admin's account. The connection is how inline authenticates every GitHub call — see [Connecting GitHub](./connect-github.html).

## Repository

A GitHub repo inline knows about. Connecting makes it visible; **enabling** turns on reviews. A repo inherits workspace defaults but can override most of them — severity threshold, merge gate, custom instructions, path filters, and which modules are on.

## Review

One pass over one pull request at one head commit. A review records its triage verdict (`trivial` / `substantive` / `incomplete`), a summary, its findings, and full cost accounting. Reviews are **incremental**: each one covers only what changed since the last one.

## Finding

A single issue inline raised: a file, a line range, a severity (`high` / `medium` / `low`), a category (`bug` / `security` / `performance` / `maintainability` / `style`), a confidence score, and a body. A finding is either **posted** to GitHub or **suppressed** with a stored reason — suppressed findings are never discarded, just kept out of the PR. Over its life a finding may become `addressed`, `resolved`, or carry a [feedback outcome](./feedback-loop.html).

## Background work

Almost nothing inline does happens while you wait. GitHub events and portal actions kick off work that an always-on background reviewer picks up and runs on its own — reviewing a PR, answering an `@inline` comment, harvesting feedback when a PR closes, recomputing the merge gate, building a walkthrough page, running sandbox tests, generating a fix PR, indexing a code graph, processing a CI/CD run, running a pentest engagement, or sweeping a cloud scan. You see progress live in the portal and results land on the PR.

## Severity & confidence

Two dials that govern noise. **Severity** ranks impact (`low` / `medium` / `high`, plus `critical` / `info` in the security modules). **Confidence** is the model's self-assessed certainty in `[0, 1]`. A finding must clear both the repo's severity threshold and the confidence floor to be posted. See [noise control](./review-noise.html).

## The modules

The PR reviewer is the core. Around it sit optional, per-org or per-repo modules that share the same finding / severity / dedup vocabulary:

- **[Merge gate](./merge-gate.html)** — block merges on open findings.
- **[Auto-fix](./auto-fix.html)** — verified fix PRs.
- **[Sentinel](./sentinel.html)** — dependency & repo security.
- **[Pentest](./pentest.html)** — autonomous red-teaming.
- **[Actions](./actions.html)** — CI/CD monitoring.
- **[Cloud](./cloud.html)** — Azure posture, health, spend.
- **[Compliance](./compliance.html)** — BAA/vendor coverage.

## How it learns

Three distinct mechanisms, easily confused:

- **[Memory](./repo-memory.html)** — implicit knowledge inline distills about a repo, on its own.
- **[Learnings](./learnings.html)** — explicit rules a human teaches (or approves).
- **[Skills](./learnings.html#skills)** — authored expertise packs loaded on demand.