> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getprimo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits and platform constraints

> What auto remediation cannot do today, how Primo AI re-applies a fix, and why some issues always come back to an admin.

Auto remediation is deliberately bounded. This article states those bounds plainly so you can tell a limitation from a malfunction.

## Product limits

* **Auto remediation is all-or-nothing per company.** There is no per-issue-type toggle for Primo AI. Scoping is expressed in the text of your [remediation policy](/mdm/compliance/remediation-policy) — name there the issues it should never work.
* **Unpublishing the policy does not unassign Primo AI from tickets already open.** Those runs read the missing mandate and stop with a note instead of acting. Reassign them by hand if you want your team to take over immediately.
* **One issue carries at most one ticket.** A device with five issues can carry five tickets.
* **Your policy can only narrow behaviour.** No sentence in it grants an action the product forbids.

## How Primo AI re-applies a fix

Primo AI repeats whatever the control did in the first place. It matches the mechanism:

| If the control enforces through | Primo AI                             |
| ------------------------------- | ------------------------------------ |
| A configuration profile         | Re-sends that profile to the device  |
| A script                        | Runs that script again on the device |
| A software installation         | Re-installs the software             |
| An agent-side enforcer          | Re-runs the enforcer                 |

This covers most compliance issues, and it is what most runs do. The fix is verified by re-reading the device afterwards, not by the push succeeding.

When a control has no per-device mechanism to repeat, Primo AI says so in its note and hands the ticket back rather than pretending to act.

## Why an issue keeps coming back to you

These are the recurring reasons a compliance ticket reaches an admin instead of closing itself:

* **The device is offline.** Nothing can be pushed or verified until it syncs.
* **The device is enrolled in another MDM.** Primo observes but does not enforce.
* **The operating system edition cannot be managed** for the control in question.
* **The fix needs a purchase, a licence, or a credential** Primo does not hold.
* **The EDR was never deployed** on that device, so there is nothing to repair.
* **The device needs a re-enrollment**, which is an admin decision.

## Attribution and audit

* A policy change Primo AI makes on your approval is recorded as made by Primo AI. Its note in the ticket names the admin who approved it.
* Every action it takes on a device is recorded in the [audit logs](/mdm/audit-logs) like any other action.

## Demo companies

Demo companies run the real path with fabricated agent comments, and the demo assistant is live: a comment on a demo compliance ticket starts a real run against fake device data. Write actions on compliance settings and on the policy are blocked on demo companies.