> ## 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. # What Primo AI does on a compliance ticket > The checks Primo AI runs before acting, the fixes it applies alone, when it writes to an employee, what it hands back, and what it never does. Once a compliance ticket is assigned to Primo AI, it works within the mandate of your [remediation policy](/mdm/compliance/remediation-policy). This article describes the behaviour the product guarantees, whatever your policy says — your policy can narrow it, never widen it. ## What it always does * **Reads the issue behind the ticket first.** It never works from the ticket title. It reads the exact status and the raw evidence the device reported. * **Reads your policy.** With no published policy it acts on nothing. * **Refreshes the device and re-reads its state before concluding.** A large share of compliance issues are enforcement still in flight, not real drift. * **Looks at the wider picture.** The device's other open issues, and earlier tickets on the same device and the same rule. A dozen tickets on one rule is one cause, and it reports it as one cause. * **Verifies on the device after pushing a fix,** not on its own dispatch. It does not call a push a fix. * **Ends every run with a note.** First line the outcome, last line the one thing you have to do. ## What it fixes on its own Whatever the enforcement behind the control lets it re-push: * Re-sending a configuration profile * Running the control's script again * Re-installing missing software * Re-running the enforcers Most runs are exactly this, and the employee never hears about it. ## When it writes to the employee Primo AI writes to an employee only when the operating system genuinely needs a person at the keyboard — a login to finish encryption, a passphrase, a restart — and only after everything it could do alone is done. * **Once per issue.** It does not chase. * **One instruction**, in the employee's language. * **No internal vocabulary.** No Primo screen, status, or control name appears in the message. * **It asks for a restart, it never performs one.** * **No employee assigned to the device means no message.** ## What it hands back to you Primo AI stops and hands the ticket to your team when only an admin can decide: * An operating system edition Primo cannot manage * Hardware past what the fix requires * Anything needing a purchase or a credential * A re-enrollment * An EDR that was never deployed on the device * A device that is simply offline, or enrolled in another MDM The ticket comes back with the diagnosis attached, not as a fresh unknown. ## What it never does * Wipe, lock, retire, or unenroll a device on its own reading * Close or reopen a ticket on its own initiative * Touch another device, or "the others like it" * Change the MDM control or the compliance rule to make an issue go away * Claim a fix it has not re-read on the device * Keep messaging someone who asked for a human, or asked to be left alone ## The bounds of one run One ticket, one issue, one device. One fix attempt per mechanism. One message per issue. Ending a run with the issue still open is a valid outcome, and the note says so plainly. ## Troubleshooting **Primo AI posted a note but did nothing on the device** * Check the state chip on **Compliance > Compliance issue settings**. With no published policy, runs stop without acting. * Check whether the control behind the issue can be re-pushed per device. Some cannot — see [Limits and platform constraints](/mdm/compliance/remediation-limits). * Check whether the device is offline. Primo AI hands offline devices back rather than queueing work against them. **The same rule keeps raising tickets on the same device** * Read the latest note. Primo AI looks at earlier tickets on the same device and rule, and reports the shared cause rather than repeating the fix. * The cause is usually a control that cannot enforce on that device, not a drifting device.