The action is pinned in the snippets, and the ref does not pin the tool

README.md

@@ -437,11 +437,15 @@ you put the decorator, your deployment, and whether your policy is the right pol
 [GitHub Action](https://github.com/CTRLRun/ctrlrun/blob/main/docs/verify.md#in-ci):
 
 ```yaml
-      - uses: CTRLRun/ctrlrun@main
+      - uses: CTRLRun/ctrlrun@v0.6.0
         with:
           policy: ctrlrun.yaml
 ```
 
+The ref pins the action's steps and **not** the package they install: `install` defaults to
+`ctrlrun`, which is whatever PyPI has that day. Add `install: ctrlrun==0.6.0` to pin the tool
+as well as the workflow.
+
 ## What it guarantees, and what it can't
 
 The six guarantees, and which of the three ways in carries each:

action.yml

@@ -40,7 +40,9 @@ inputs:
     default: "3.11"
   install:
     description: >-
-      The pip requirement to install. Defaults to the published package; set it to `.` to
+      The pip requirement to install. Defaults to the published package, **unpinned** — the
+      ref you pin the action to does not pin this, so a pinned action still installs whatever
+      PyPI serves that day. Give it `ctrlrun==<version>` for a reproducible run, or `.` to
       verify with the checkout rather than with the last release.
     required: false
     default: ctrlrun

docs/cookbook/verify-in-github-actions.mdx

@@ -47,12 +47,15 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: CTRLRun/ctrlrun@main
+      - uses: CTRLRun/ctrlrun@v0.6.0
         with:
           policy: ctrlrun.yaml
 ```
 
-Pin `CTRLRun/ctrlrun` to a release tag once you rely on it.
+The ref pins the action's steps and not the package they install: `install` defaults to
+`ctrlrun`, unpinned, so the job takes whatever PyPI serves that day. Add
+`install: ctrlrun==0.6.0` to pin the tool too, and pin `CTRLRun/ctrlrun` by commit rather than
+by tag where you want a ref nobody can move.
 
 ## What the agent sees
 

docs/guides/verify-in-ci.mdx

@@ -75,7 +75,7 @@ guarantees pass.
         runs-on: ubuntu-latest
         steps:
           - uses: actions/checkout@v4
-          - uses: CTRLRun/ctrlrun@main
+          - uses: CTRLRun/ctrlrun@v0.6.0
             with:
               policy: ctrlrun.yaml
     ```
@@ -96,7 +96,10 @@ guarantees pass.
     | `badge-path` | `verify-badge.json` | where the Shields endpoint JSON goes |
 
     Outputs: `passed`, `failed`, `applicable`, `not-applicable`, `badge-message`, `report-path`.
-    Pin the action to a release tag or a commit rather than `@main` once you rely on it.
+    The ref pins the action's steps and **not** the package they install: `install` is
+    unpinned by default, so `@v0.6.0` still takes whatever PyPI serves on the day. Pin both —
+    `install: ctrlrun==0.6.0` — where the run has to be reproducible, and pin the action by
+    commit rather than by tag where the ref has to be immovable.
   </Step>
 
   <Step title="Publish the badge, if you want it">

docs/verify.md

@@ -217,7 +217,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: CTRLRun/ctrlrun@main
+      - uses: CTRLRun/ctrlrun@v0.6.0
         with:
           policy: ctrlrun.yaml
 ```
@@ -226,6 +226,13 @@ The action installs `ctrlrun`, runs `ctrlrun verify --json --junit`, renders the
 and the badge JSON **from that report** — not from a second run, so they cannot disagree — and
 uploads the three files as one artifact.
 
+**The ref pins the action's steps and not the package they install.** `install` defaults to
+`ctrlrun`, unpinned, so `@v0.6.0` runs whatever version PyPI serves on the day the job runs —
+pinning the action is not pinning the thing being verified with. Set `install: ctrlrun==0.6.0`
+where you want the run to be reproducible, and pin the action by commit rather than by tag
+where you want a ref that cannot be moved; this repository holds its own workflows to the
+commit form and a test enforces it.
+
 It fails the job when a guarantee failed and when the configuration was refused, and succeeds
 when guarantees are N/A. N/A is not a failure and it is not a pass; the job's green means
 "nothing that could be checked was wrong", which is exactly what the badge says.

docs/verify/get-the-badge.mdx

@@ -22,7 +22,7 @@ proved, and updates itself.
         runs-on: ubuntu-latest
         steps:
           - uses: actions/checkout@v4
-          - uses: CTRLRun/ctrlrun@main
+          - uses: CTRLRun/ctrlrun@v0.6.0
             id: verify
             with:
               policy: ctrlrun.yaml
@@ -31,7 +31,10 @@ proved, and updates itself.
 
     The action installs `ctrlrun`, runs it against your policy in a scratch store with no
     network, renders the job summary and the badge JSON from that one report, and fails the job
-    if a guarantee failed. Pin the action to a release tag once you rely on it.
+    if a guarantee failed.
+
+    The ref pins the action's steps and not the package they install: `install` defaults to
+    `ctrlrun`, unpinned. Add `install: ctrlrun==0.6.0` where you want the run reproducible.
   </Step>
 
   <Step title="Publish the badge JSON">