more
```
**Changed job.** The tree renders as a diff fence instead of a `` block — `+` new, `−` no longer recorded, unmarked in both:
```md theme={null}
@@ vs @@
```
**Substrate fold.** Nested inside the job fold, holding resolver chatter and unattributed runner chains. Every recorded chain renders somewhere, and each count equals what sits directly beneath it:
```html theme={null}
dns + runner substrate · chain(s)
```
**Destination leaf.** The first recorded name, defanged at the final dot; a bare IP only when no name was recorded. Two structural tags exist — `(dns resolver)`, a loopback address on port 53, and `(instance metadata)`, one of `169.254.169.254`, `169.254.170.2`, `fd00:ec2::254`. Ports, protocol, and PIDs stay in the [Garnet Execution Summary](/quickstart#action-reference) and the JSON:
```md theme={null}
└─ → registry.npmjs[.]org
└─ → 169.254.169.254 (instance metadata)
```
**Attribution.** Carried by typography: `` is lineage attributed to a workflow step below `Runner.Worker` — the PR's own workload — and `` is runner scaffolding. Attribution context, not trust.
**No egress, and truncation.** Both are stated, never silent:
```md theme={null}
/ — no outbound destinations recorded.
rendered of destination associations
```
**Per-job permalink.** The last line of every fold. Read the `profile` parameter; ignore the campaign parameters after it:
```html theme={null}
View this job's Execution Profile in Garnet →
```
Three transforms apply to display only — the Execution Profile, the [Garnet Execution Summary](/quickstart#action-reference), and the JSON keep the recorded value:
* Hostnames are defanged at the final dot: `registry.npmjs.org` renders as `registry.npmjs[.]org`.
* Step names lose the runner's ordinal prefix and any unexpanded workflow expression: `4. Run workload ${{ matrix.name }}` renders as `Run workload`. The comment never shows an ordinal.
* Process names lose a trailing run of four or more digits: `provjobd1326539233` renders as `provjobd`.
Fail closed on three states: **no marked comment** (recording never ran), **pending headline** (wait, don't fail), **`garnet:commit` ≠ head SHA** (stale record). In all three there is no runtime evidence for the current head — fall back to your normal policy. The comment carries recorded facts and no verdict; the decision is yours.
## Agentic reviewers
Paste one prompt — the reviewer finds the comment, checks the pin, and correlates the diff with what actually ran.
Paste into the reviewer's instructions, alongside the PR URL:
````md theme={null}
# Review this pull request against its kernel-recorded execution record
## Locate the record
1. On the PR, find the comment containing the marker ``.
It is a kernel-recorded record of what this PR's CI executed: every recorded
execution chain and every outbound destination, per job.
2. Confirm it covers the current head: the marker ``
must equal the PR's head SHA. If the comment is missing, still recording
(headline reads "Execution Profiles recording for jobs"), or pinned to an
older commit, report "no execution record for the current head" and stop
treating the run as verified. Absence of evidence is not a clean run.
## Read the record
3. The metadata blockquote carries the run-scope facts: execution chains,
destinations, whether anything changed since the previous profiled commit,
and when it was recorded.
4. Each job fold carries its own facts: a leading `+A −R` delta when the job
changed, a sentence naming which steps reached how many destinations, and
the tree itself. Inside a changed job, the diff fence marks `+` new and
`−` no longer recorded against the previous profiled commit.
5. In the tree, bold lineage is the PR's own workload (attributed to a workflow
step), italic lineage is runner scaffolding, and `→ name` leaves are outbound
destinations with the final dot defanged. The nested "dns + runner substrate"
fold holds resolver chatter and unattributed runner chains.
## Correlate and report
6. For every workload destination and spawned process, state whether the diff
explains it (a dependency change explains registry traffic and an install
chain). Name what the diff does not explain: unexpected hosts, install-script
activity, interpreters that have no reason to be in the chain.
7. On a comparison comment, review the delta first: what this commit added or
stopped doing at runtime, and whether the diff accounts for it.
8. The record covers the current head only. Say so if the PR has earlier pushes.
Emit exactly this shape:
```md
**Execution review of ` / `, recorded at [``]()**
> * execution chains · destinations · since ``*
<2–4 sentences: which steps ran, which destinations they reached, and what
the delta was. Recorded facts only.>
| Destination | Chain | Explained by |
| :--- | :--- | :--- |
| | | |
**Unexplained:**
**Recommendation:** , the evidence it rests on, and what a
re-run should record.
Grounding: [Execution Profile](), recorded at the kernel,
pinned to `` · correlation sources:
```
Rules that keep the shape deterministic:
- Every row and every claim cites the record or the code. No citation, no finding.
- Chains and destinations are copied from the comment. Never invent a process or
a destination, and never repair a defanged name into a live link.
- Counts you quote must equal the counts the comment renders.
- If the record is missing, pending, or stale, keep the shape, state that reason
in place of the facts, and recommend against treating the run as verified.
- The record carries no verdict. The judgment is yours, and it traces to the
record or the diff.
````
The same contract as standing repo rules — for reviewers that read `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, or a custom-instructions field. Add once; every review follows it:
```md theme={null}
# Execution record (Garnet) — reviewer instructions
Before finalizing any review of a pull request in this repository:
1. Find the PR comment containing the marker ``.
It is the kernel-recorded record of what this PR's CI executed: every
recorded execution chain and every outbound destination, per job.
2. Verify it covers the head: `` must equal the PR's
head SHA. If it doesn't, or the comment is missing or still recording, treat
the PR as having **no execution record** and say so. That is not a clean run.
3. Read the metadata blockquote for run-scope facts, then each job fold: the
`+A −R` delta, the sentence naming steps and destination counts, and the tree.
Bold lineage is the workload, italic is runner scaffolding, `→ name` leaves
are destinations.
4. Cross-check the diff. Name every destination and process the diff does not
explain, citing its chain, or state that the record is fully explained.
5. Report: what ran, the delta since the previous profiled commit, a
Destination | Chain | Explained by table, the unexplained set, and a merge or
hold recommendation. The record carries no verdict — you supply the judgment,
and never invent a chain or destination.
```
Two demo pull requests carry the same manifest-only diff and different recorded egress — useful for checking that a reviewer reads the record rather than the diff: [registry-only egress](https://github.com/garnet-labs/garnet-runtime-review-demo/pull/1) and [an install script reaching named hosts](https://github.com/garnet-labs/garnet-runtime-review-demo/pull/8).
## Custom harnesses and gates
For a reproducible decision instead of a judgment, parse the comment directly. **StampHog** — [PostHog's merge-gate agent](https://github.com/PostHog/posthog/blob/master/.github/workflows/pr-approval-agent.yml) — does exactly that in the demo repository: every static gate green, held solely on recorded egress the diff never mentions.
`garnet_runtime.py` — locates the comment, checks the pin, extracts destinations, splits by attribution. Start here, not from scratch.
The harness consuming the record end to end, posting its own decision next to Garnet's. The same harness on a [replayed upstream change](https://github.com/garnet-labs/posthog/pull/44).
Harness already locks its own output shape and gates? Keep it — carry the primitive into it instead: (1) fail closed on the three evidence states above, (2) gate on the comment's own `+A −R` delta against the previous profiled commit, (3) make every finding cite its recorded chain and destination.
Every fold's permalink has a JSON twin at the same exact selector:
```text theme={null}
https://app.garnet.ai/api/public/runs/?profile=
```
The selector is required. Wrong or missing `?profile=`, or a bare `/public/runs/` URL, returns a 404 by design — never a silent fallback. See [The public run report](/run-profile#the-public-run-report).