Checks sit on both sides of it.
Each approach has something it is good at. The rows below are where they differ.
| By hand | Straight to an AI model | MARS | |
|---|---|---|---|
| First read of each case | An analyst, one case at a time. | The model. | MARS gathers the evidence, then asks the model. |
| What the model is given | No model is involved. | Whatever is pasted in, as written. | The evidence MARS collected, marked as evidence. |
| Text in an email aimed at the AI | Does not apply. | Reads as part of the request. | Stays data, inside a marked boundary. |
| An answer with nothing behind it | Depends on the analyst. | Looks the same as a sound one. | Rejected, or held for review with a reason. |
| When the evidence is thin | The analyst escalates. | Nothing stops it answering. | The case stays undecided and goes to a person. |
| Response actions | The analyst carries them out. | Whatever is built around the model decides. | Proposed by MARS, approved by a person, checked afterwards. |
| Where case data goes | It stays in the tools you already use. | To the model's provider. | It stays on your host. You choose the model endpoint, a local one included. |
| Record of each decision | Tickets and notes, where they are kept. | A chat history. | A signed audit log, with the evidence behind each verdict. |
| Changing the model or its instructions | Does not apply. | Nothing checks what changed. | A change to the instructions is detected and needs sign-off. Known cases can be replayed to compare quality first. |
| What it takes to run | Analyst hours that grow with volume. | Very little. | A host to operate and Microsoft connections to configure. |
The middle column describes sending case content to a general-purpose model with nothing around it. It does not describe any particular product.
The model reads and reasons. MARS decides what it sees and what becomes of its answer.