Skip to main content

AI Trust Principles

Engineers are right to be skeptical of AI in operations. An answer can sound right and be wrong, and the engineer is the one accountable when it is.

Our philosophy is data first. When an engineer and an AI have the right data and can analyze it effectively, they find causes that would otherwise stay buried: a handful of events among billions, or a pattern that only shows over months.

So we've built technology that captures a continuous, curated record of every device, with query tools efficient enough for an AI to analyze billions of data points in seconds. You build with the AI models, tools and workflows you already use. SparkLogs supplies the data and the means to query it, and you decide how the AI is put to work.

Ten principles guide how we put AI to work on that data. Each one exists to earn an engineer's trust. These principles lead to answers that are accurate, verifiable, clear about their scope, and actionable.

The principles​

You stay in charge

  1. AI is built to accelerate engineers, not replace them.
  2. You choose the AI and shape how it works.

You can check every answer

  1. Every factual claim cites its data.
  2. Confidence is banded from the evidence.
  3. "Nothing found" comes with what was checked.
  4. The AI states its scope.
  5. Likely causes are labeled as analysis.

You control and can review what the AI does

  1. The AI works within your access.
  2. What a device reports is data, never instructions.
  3. Audit logs record every AI tool call.

You stay in charge​

1. AI is built to accelerate engineers, not replace them​

An investigation has a lot of tedious work in it: pulling the relevant records, searching them for patterns, comparing devices. The AI does that work in seconds, and it brings judgment of its own: which signals matter, what to look at next, what the likely cause is.

With a time machine for every device and a capable AI companion, the engineer's time is spent on what matters most: reviewing the findings and deciding what to do. You remain accountable for operational decisions, so the product is built to inform them.

2. You choose the AI and shape how it works​

SparkLogs works with Claude, Cursor, Codex, Microsoft Copilot Studio and any other client that supports MCP. Your data goes to the AI you chose, under your agreement with its vendor. You can switch models as they improve, or run your own agents beside your PSA and RMM.

The skills and playbooks that guide an investigation are open source. You can read exactly what the AI is told, change it to fit your process, and contribute what you learn. Feedback from engineers in our Foundry program shapes the playbooks.

You can check every answer​

3. Every factual claim cites its data​

Each result the AI receives from SparkLogs carries a link back to its source: the device page at that moment, or the query in Explore. The AI is instructed to cite those links for every fact it states. You can open any of them and see the same data the AI saw. See Your AI and the app.

The links are always there. Whether a model cites every one is up to the model, and in our experience current models do. If an answer states a fact with no link, ask for it.

4. Confidence is banded from the evidence​

A model's wording sounds equally sure whether its evidence is strong or thin. In a formal investigation report, each finding carries a confidence band (high, medium, low or insufficient evidence), set from what the data shows. See Agentic RCA.

In an ordinary chat there are no bands. Ask how sure it is and what that rests on.

5. "Nothing found" comes with what was checked​

Finding no evidence of a problem is different from there being no problem. The AI is instructed to report it as "no evidence of this in these sources over this time range", and never as "everything is healthy".

SparkLogs helps by reporting what it knows about its own data. Results say when a device was off, when a data feed was behind, and when Windows could not supply part of an event log. See Collection health.

6. The AI states its scope​

No tool can list everything it cannot see. The AI can say what it did check: which devices, which sources, and what time range. It can say where that data had gaps. And for a given kind of problem, it can name the systems it has no data from that commonly matter, such as the backup target with no agent, or a vendor's cloud console. The playbooks carry those lists for each kind of problem.

7. Likely causes are labeled as analysis​

What a device recorded is a fact, and why it happened is a judgment. In a formal report, the two are separate: the report states what was observed, and candidate causes come as their own step, each with the check that would confirm it or rule it out.

In a chat, the AI will offer likely causes as it goes, which is usually what you want. Treat them as leads, and verify the evidence before taking irreversible actions.

You control and can review what the AI does​

8. The AI works within your access​

A connected AI app acts as the person who approved it. It can reach only the organizations that person can reach, and it is further limited to the scopes they approved, so an assistant can analyze trends and device health without being able to read raw log lines. An API token for automation holds access of its own, which can be no more than its creator's. The platform checks every request against that person's access as it stands at that moment. When their role or organizations change, their connected apps and tokens change with them at once. See Access.

9. What a device reports is data, never instructions​

Logs and device data can contain any text, including text written by someone who wants to mislead an AI. SparkLogs marks everything a device reported as untrusted data, inside boundaries the text itself cannot forge, and tells the AI to treat it as evidence to verify and never as instructions. That applies to the results your AI receives over MCP and to the investigation prompt the app copies for you.

You also decide how much device text an AI sees. Approve an app without the raw log scope and it works from curated patterns, signals and device health, and cannot read individual log events. Most interactive work is better with raw logs available. The option is there for higher-risk uses, such as an agent that runs unattended and acts on what it finds. See Access.

Two more things limit what a misled model could do: the AI works within your access, and audit logs record its calls. If your AI also has tools that can change things, such as your RMM or PSA, require confirmation in those tools for any action. The instruction template tells custom agents to ask before any step that modifies a system.

10. Audit logs record every AI tool call​

Each query an AI app or API token makes to SparkLogs is written to the audit log, with who approved the app, which tool it called, which organizations it read, and whether it was allowed. Entries are kept for 37 months. A service manager can review what an assistant queried, and an auditor can confirm what data it read. See Audit Logs.

The audit log covers what was asked of SparkLogs. Your conversation with your AI, what you type and what it writes, is not recorded by us.

Dedicated to continual improvement​

Every day, we learn and improve how we live by these principles and our Spark promise. When an answer overreaches, misses something or states more certainty than the data supports, ask your AI to send us feedback. It takes seconds, and those reports are how the tools, instructions and playbooks improve.