> ## Documentation Index > Fetch the complete documentation index at: https://docs.garnet.ai/llms.txt > Use this file to discover all available pages before exploring further. # Comment anatomy > How to read the Garnet Runtime Review comment — the headline, provenance line, job folds, process trees, and the per-fold permalink. The **Garnet Runtime Review** is the comment Garnet posts on your PR. It records what happened on the commit — every outbound connection and the process lineage that made it — and it does not judge: no status glyphs, no verdicts. One comment per PR, updated in place as jobs finish and commits land. A comment covering three jobs, as it renders: ```text theme={null} See what ran — every outbound connection and its process lineage. > Runtime behavior for jobs triggered by commit 692fee1 · recorded at the kernel through 2026-07-13 23:54:31 UTC ▸ 💡 Reading this review 3 jobs recorded on this commit ▸ CI / build ↗ — 2 recorded processes · 3 recorded destinations ▸ CI / lint ↗ — 2 recorded processes · 3 recorded destinations ▾ CI / test ↗ — 2 recorded processes · 5 recorded destinations test · job └─ systemd └─ hosted-compute-agent └─ Runner.Listener └─ Runner.Worker └─ bash ├─ npm install │ └─ → registry.npmjs.org └─ npm test └─ sh └─ node ├─ → registry.npmjs.org ├─ → api.garnet.ai ├─ → github.com └─ → images.unsplash.com · also recorded: unsplash.imgix.net View Run Profile in Garnet ↗ ``` In the real comment, workload lineage (`bash`, `npm install`, `node`) renders **bold** and runner scaffolding (`systemd`, `hosted-compute-agent`, `Runner.Listener`, `Runner.Worker`) renders *italic*. All job folds start collapsed — the tree above is shown expanded for illustration. ## The headline The first content line is invariant — **See what ran** — *every outbound connection and its process lineage.* — byte-identical on every PR comment. It is the one full-contrast line; everything that follows is the record. ## The provenance line Quoted under the headline: *Runtime behavior for jobs triggered by commit `sha` · recorded at the kernel · 2026-07-13 23:54:23 UTC*. The sha names the commit that triggered the recorded jobs and links to it; *recorded at the kernel* names the vantage point (the eBPF sensor, not log-scraping); the timestamp is the recorded profile's own timestamp — always absolute UTC (`YYYY-MM-DD HH:MM:SS UTC`), never the renderer's clock. When more than one profile is recorded it reads *recorded at the kernel through ``*. The word *recorded* appears exactly once on this line. ## The explainer The *💡 Reading this review* fold teaches the notation with a mini process-to-destination example: each job fold connects recorded process lineage to recorded outbound destinations; **bold** lineage is attributed to a GitHub step below `Runner.Worker`, *italic* lineage is runner scaffolding. Typography only shows attribution context — it is never a security claim. The explainer is open on the first recorded result and collapsed on later updates. ## The jobs-count line One thin line between the quoted preamble and the first fold: *N jobs recorded on this commit*. It counts what is recorded and nothing else — it never reads *k of n* and never carries a denominator. The job list speaks for itself. ## Job folds Each recorded job is one fold, headed by its provenance and its counts: ```text theme={null} workflow / job ↗ — N recorded processes · M recorded destinations ``` * The `workflow / job` breadcrumb follows GitHub's own containment model and always names both — even when only one workflow is recorded. * The **job name carries the link**: it points to the job's GitHub Actions run, the page holding its log and Step Summary. There is no separate run number in the heading — the run's identity lives in the link. * The counts are countable from the tree inside: `N` is the distinct recorded process identities (lineage + PID + process), `M` is the destination lines visible in the fold — resolver rows included; notes never subtract. The heading is a caption for the tree and never contradicts it. * All data-bearing folds start collapsed, ordered by workflow then job name. ## The process tree The expanded tree is the recorded lineage, unfiltered. The record is egress-centric: processes without recorded egress do not appear. | You see | It means | | :--------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `build · job` (root, italic) | The job itself — a label, not a parent process. | | **bold** node | Lineage attributed to a GitHub step below `Runner.Worker` — the step name renders alongside it as `· step: `. | | *italic* node | Runner scaffolding, or lineage not attributed by that rule. An italic node can still carry a recorded `· step:` label. De-emphasis only — it never changes counts or ordering. | | `→ domain` | A recorded destination. The first recorded name is the identity; a bare IP means no domain was recorded for that connection. | | `· also recorded: …` | Secondary recorded names for the same destination — annotations, never extra rows or extra counts. | The comment is domain-first: no ports, protocols, address annotations, or `[pid · process]` suffixes render here — that fidelity lives on the [Garnet Runtime Summary](/reference/github-actions#garnet-runtime-summary). ### Factual notes A destination carries an italic parenthetical only for structural facts the record proves. The set is closed: | Note | Meaning | | :-------------------- | :-------------------------------------------------------------------------------------------------------------- | | *(dns resolver)* | A loopback address on port 53 — the local resolver stub. It renders and counts like any other destination line. | | *(instance metadata)* | A protocol-defined instance-metadata address (`169.254.169.254`, `169.254.170.2`, `fd00:ec2::254`). | Everything else renders exactly as recorded, untagged. Notes never filter, subtract, or alter counts. ## Zero-egress jobs A job whose record carries no outbound destinations renders as one quiet line instead of a tree: ```text theme={null} no outbound destinations recorded. ``` The linked job name works the same as in a fold. ## The per-fold permalink Each fold closes with exactly one Garnet link, pinned right: **View Run Profile in Garnet ↗**. It opens the job's full record on the [public run report](/run-profile#the-public-run-report) — `app.garnet.ai/public/runs/?profile=` — selected on the job's own Garnet Profile ID. It is the only Garnet link in the comment: no top run-index link, no bottom footer, no "Powered by Garnet". The GitHub Actions link lives on the job name in the heading. Report visibility follows the repository's visibility on GitHub: public repository ⇒ public report; private repository ⇒ the link requires signing in to the project. The `?profile=` selector is exact — a wrong or missing profile ID returns a 404, never a silent fallback. ## Waiting state Before any job's profile lands, the comment shows a waiting body — the headline, commit provenance only (no timestamp, count, or link), the explainer open, and: ```text theme={null} ⏳ Run Profiles for this commit are still being recorded — this comment updates in place as jobs finish. ``` It fills in as jobs finish; one comment per PR, updated in place on each push.