The practical ones, answered before you ask.

What arrives, and in what order?

The file comes first. You read it, have your platform team read it, and then decide whether to run it. Nothing happens before that.

Your administrator runs it inside your instance and keeps the output. If you want the written summary, you send us that output and we write up what it found — and what it could not assess.

There is no point in the sequence where you have to trust us about something you cannot see.

What access does it need?

Somebody at your end who can run an administrative script in your own instance — which in practice means the people who already administer it.

No account is created for us. No integration user, no API key, no login. Nothing is installed either, so there is no application to approve, no plugin to activate and nothing to uninstall afterwards.

How much of our instance does it read?

A bounded amount, on purpose. The check works within a date window and stops at a row limit, and both of those are printed next to every conclusion it draws — so you can see the basis for each statement rather than inferring it.

This matters on a large production instance. An unbounded scan of record history is the kind of thing that makes a database administrator’s afternoon worse, and it is also less accurate: activity from several years ago is not evidence that a seat is in use today.

Do you ever get access to our instance?

No. Not during the diagnostic, not during the full analysis, and not for the standing watch — which also runs inside your instance rather than on anything of ours.

The check makes no outbound calls, so nothing is sent to us or to anyone else. We see exactly what you choose to email us, and nothing besides. There is more detail on the privacy page.

What if our release classifies things differently?

Then it stops and tells you, rather than reporting something confident and wrong.

It is built and verified against a current release. The one failure that would genuinely damage you is a plausible-looking number produced from an assumption that does not hold on your instance — so refusing to answer is the correct behavior there, and it is what the check does.

How is it invoiced, and by whom?

By AiStarDev LLC, a Georgia company, as an ordinary invoice for a fixed one-off amount agreed before any work starts. No subscription, nothing metered, nothing that renews by itself, and no tier anyone gets moved up to.

Because nothing is installed and nothing is bought from a marketplace, this is a straightforward engagement rather than a software purchase — usually the shorter path through a procurement process.

What will our security team want to know?

The four questions they always ask have short answers here.

• What does it change? Nothing. It creates, updates and deletes no records.
• What leaves the environment? Nothing. There are no outbound calls.
• What credentials does the vendor hold? None.
• What is installed? Nothing.

The useful part is that your own people can confirm all four by reading the file before it runs. That is a stronger position than a vendor assurance, including this one.

What if it finds nothing worth acting on?

That is a real possible outcome, and it is not a wasted exercise. You end up with a written record of what was examined, what it showed, and what could not be assessed.

That is a considerably better thing to take into a renewal conversation than a position you are holding from memory. We would rather tell you the count looks defensible than manufacture a finding — and taking it no further is a perfectly reasonable outcome.