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.
# 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.
# 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.
# 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.
# 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 — block merges on open findings.
- Auto-fix — verified fix PRs.
- Sentinel — dependency & repo security.
- Pentest — autonomous red-teaming.
- Actions — CI/CD monitoring.
- Cloud — Azure posture, health, spend.
- Compliance — BAA/vendor coverage.
# How it learns
Three distinct mechanisms, easily confused: