Companion Collections
When you assign a compliance baseline to a target collection, Athena automatically creates two read-only companion collections alongside it — one holding the machines that pass the baseline and one holding the machines that fail it. Membership tracks evaluation results automatically, so you can deploy software, run commands, or schedule jobs against only the devices in the compliance state you care about, using the same collection plumbing you already use everywhere else.
Companion collections are created by a baseline assignment. To create the assignment (and therefore the companions) you need the Operator or Admin role. See Compliance & Baselines for how to author rules and baselines, and Compliance Evaluation for when machines re-evaluate.
What gets created#
A baseline assignment binds one baseline to one target collection. The moment that assignment is created, Athena creates two extra collections next to your normal collections:
| Companion | Default name | Members |
|---|---|---|
| Compliant | Compliant: <Baseline> | Devices in the target collection that fully pass the baseline. |
| Non-Compliant | Non-Compliant: <Baseline> | Devices in the target collection that fail the baseline (including any that haven't been evaluated yet). |
Both companions are always created for every assignment — there is no opt-in switch and no
per-assignment checkbox. They are created even when they start empty (for example, when
nothing has been evaluated yet), so the pair always exists and the counts simply read
0.
On the Collections page, companions appear as type Compliance
and carry a lock icon marking them read-only. The Compliant companion renders with a green
badge; the Non-Compliant companion renders amber/red, so you can tell the two apart at a
glance.
If you assign the same baseline to more than one target collection, the second pair of
companions would collide on name. Athena detects the clash and appends the target
collection name, e.g. Non-Compliant: Windows 11 Baseline (Laptops), so every
companion stays uniquely identifiable.
How membership is decided#
Companion membership is always the intersection of the assignment's target collection with the baseline's evaluation results. A device is never in a companion unless it is also a member of the target collection the baseline was assigned to.
A device counts as compliant for the baseline only when every rule in the baseline has been evaluated and landed in a passing state. The passing states are:
| Result state | Meaning |
|---|---|
Compliant | The rule was checked and the machine meets it. |
Not Applicable | The rule doesn't apply to this machine (so it isn't held against it). |
Remediated | The machine failed the rule but the assignment's remediation brought it back into line. |
Everything else keeps a device out of the Compliant companion and in the Non-Compliant companion — that includes rules that came back non-compliant, rules that errored, and rules that have never been evaluated on that machine. This is deliberately conservative: a device only lands in the Compliant collection once the whole baseline has passed, so if you deploy to the Compliant companion you are targeting known-good machines and never a half-checked one.
Every device in the target collection is in exactly one companion — Compliant or Non-Compliant — with no overlap and no gaps. Devices that have not finished evaluating fall on the Non-Compliant side until they pass. The operator's mental model: if in doubt, a device is not in the Compliant collection.
Staying in sync#
You never manage companion membership by hand — Athena recomputes it for you. Membership is refreshed automatically when:
- New evaluation results arrive. As agents report compliance results, Athena updates the companions for the affected baseline right away, so a machine moves between Compliant and Non-Compliant as its results change.
- The target collection's membership changes. When a device joins or leaves the target collection (for example a machine that comes online and newly matches a dynamic target), the companions are recomputed so they always reflect the current target audience.
Because companions are computed, not curated, there is nothing to refresh manually and no way to pin a device in or out of one. To change who is evaluated, change the baseline's target collection; to change what "compliant" means, edit the baseline's rules.
Read-only by design#
Companion collections are system-managed. On the Collection details page a banner reads "This collection is managed by a Baseline assignment and is read-only." and the edit affordances are hidden. Hovering the lock in the Collections list shows:
| Companion | Lock tooltip |
|---|---|
| Non-Compliant | Read only — managed by Baseline |
| Compliant | Read only — compliant devices, managed by Baseline |
You cannot rename a companion, change its description, add or remove members, or delete it directly — those actions are reserved for the assignment lifecycle. Companions are read-only as audiences, but they are fully usable as targets: point deployments, remote commands, and scheduled jobs at them exactly as you would any other collection.
Lifecycle#
| Event | What happens to the companions |
|---|---|
| You create a baseline assignment | Both the Compliant and Non-Compliant companions are created immediately (empty if nothing has evaluated yet). |
| Agents evaluate the baseline | Membership is recomputed automatically as results arrive; devices move between the two companions. |
| Target collection membership changes | Companions are recomputed so they only ever contain current members of the target collection. |
| You delete the baseline assignment | Both companions are removed automatically. The target collection and its own members are untouched. |
A baseline and its target collection cannot be changed after the assignment is created. To point the baseline at a different collection, delete the assignment and re-create it — the companions are removed and re-created against the new target.
Compliant & Non-Compliant counts#
The Compliance → Assignments page shows a live count for each assignment: a
green Compliant column and an amber/red Non-Compliant column, reading pass
→ fail. When a count is greater than zero it links straight to the matching read-only
companion collection so you can see (and target) exactly those machines; a count of
0 shows as plain muted text with no link.
Using companions as targets#
Companion collections shine when you want an action scoped to a compliance state. A few common patterns:
| Goal | Target this companion |
|---|---|
| Roll out a change only to machines you know are fully compliant. | Compliant: <Baseline> |
| Push a remediation package, run a fix-up command, or schedule a job against the machines that are failing. | Non-Compliant: <Baseline> |
| Report on how the fleet is trending for a baseline. | Either — the two counts add up to the target collection. |
Because a companion is a normal collection under the hood, anywhere you can pick a collection you can pick a companion. See Software Deployment → Targeting, Remote Command Execution, and Scheduled Jobs for the actions you can aim at one.
Companion membership changes as machines re-evaluate. A device that was in the Non-Compliant companion when you scheduled a job may have moved to Compliant by the time the job runs (or vice-versa). This is usually what you want — actions naturally follow the current compliance state — but keep it in mind for time-sensitive rollouts.