peopleanalyst

Trust & verification

Built with AI. Answered without one.

When you ask the People Analytics Toolbox a question, no AI model touches your request or your data. You get the same answer every time you ask, and you can trace where it came from. The AI work that makes this possible — building and checking the datasets underneath — is finished before you ever ask.

  1. 1.Read the guarantee — two minutes.
  2. 2. Verify it yourself — one command, no account.
  3. 3. Hand your security team the answer sheet.

The four questions that stall your security review

If you've tried to buy an AI analytics product, you've watched a deal die in security review. The reviewer asks four questions. Most vendors can't answer them, because their product calls an every time you use it:

You shouldn't have to choose between modern tooling and answers you can defend.

AI at build time. Deterministic at run time.

Our answer to all four questions is architectural, not contractual. Most AI products run the model when you click — a fresh roll of the dice for every answer. Here, AI does its work before your request ever arrives: building datasets, adversarially checking its own output, and shipping the validated result into rule engines and tables. By the time you ask a question, the thinking is already done and frozen. The engine that answers you doesn't call a model — it looks up a number, or runs a rule, that was already built and checked before your request existed.

A concrete example: minimum-wage rules aren't a live model guess. A connector reads statutory text on a schedule, a second AI pass independently tries to falsify the first pass's extraction, and only a rule that survives both lands in the table your request actually reads at serving time.

How to verify this yourself

This isn't a claim you have to trust — it's a public, machine-readable field on the toolbox's own contract registry. Call it yourself:

curl -s https://peopleanalyticstoolbox.com/api/registry| jq '.servingLlm'

Fetched live from production when this page last rendered. Registry generated at 2026-07-02T20:39:16.045Z (July 2, 2026).

{
  "guarantee": "AI runs at build/refresh time; serving is deterministic. Every runtime AI import site is declared in a CI-enforced manifest with a fallback posture — client requests never require an external model unless listed under hardDependencies.",
  "manifestVersion": "0.1.0",
  "enforcedBy": [
    "npm run check:runtime-llm",
    ".github/workflows/runtime-llm-guard.yml"
  ],
  "hardDependencies": [],
  "counts": {
    "aiImportSites": 14,
    "serving": 9,
    "scheduledOnly": 5,
    "servingWithFallback": 9
  }
}
AI call sites (total)
14
Reachable from a request
9
Build/refresh-only
5
Hard dependencies
0

What the CI guard actually enforces

The guarantee above isn't a policy document — it's checked on every change. A job (npm run check:runtime-llm, wired into .github/workflows/runtime-llm-guard.yml) scans the codebase for every place that imports an AI model client, and cross-checks each one against a committed manifest. The build fails if:

Every declared call site carries one of three postures: deterministic (a non-AI code path produces the response), degrade (the AI-touched enhancement is skipped and the response stays valid without it), or refuse(the single request fails if AI is unavailable). The manifest's own stated target is zero refuse postures — and the published hardDependencies count above is exactly that: today, zero.

The security-questionnaire answer sheet

The questions a procurement or security reviewer actually asks — answered directly, in the same words we'd use on a call.

Does the vendor send our data to an LLM to produce our answer?
No. Request-time answers come from deterministic rule engines and validated data, not a generative step. Any AI work behind a dataset happened earlier, offline, against our own reference material — never against your data.
If we ask the same question twice, will we get the same answer?
Yes. Same input, same answer, every time. That is what “deterministic” means here, and it is the property our CI guard enforces before any change can ship.
Could the product hallucinate or fabricate a figure in our answer?
Not at serving time — there is no generative model between your request and the number you get back. The datasets those answers read from are adversarially checked before they ever land in a serving table.
If your AI provider has an outage, does our service go down with it?
No. The published hardDependencies list is empty — zero. Every AI call site reachable from a request path carries a declared fallback (skip the enhancement, or serve a deterministic response), so no request needs a model to respond.
How do we verify any of this ourselves, instead of taking your word for it?
Call GET /api/registry and read the servingLlm field — no key required. It is generated from a manifest that CI enforces: an undeclared AI call site fails the build, so the published claim cannot silently drift out of date.
Where does AI get used at all, then?
At build and refresh time — constructing and adversarially verifying datasets (for example, extracting and cross-checking statutory rule text, or drafting classification structures) before they reach a serving table. That work runs on a schedule against our own reference material, with no client request in the loop.

What this buys you

Coverage only AI can build — every jurisdiction, every job, every metric — with numbers you can put in front of a CFO, an auditor, or a security reviewer without flinching: the same answer every time, traced to its source, and never built from your data. That's the difference between a tool you demo and a tool you defend.

Try it in the Toolbox Dev Console →Read the live contract registry →Call PeopleAnalyst's own feeds as an API →