People Analytics Toolbox

Tools HR teams and analysts can run, and developers can call, for surveys, workforce data and decisions.

I built People Analytics Toolbox as a set of analytics tools for HR teams, people analysts and developers. The same analytical work kept recurring in the products I was making. A survey needed careful measurement. A team report needed protection for small groups. A forecast needed an honest account of uncertainty. Rebuilding those methods inside each product made it easier for the calculations to drift or for a privacy check to disappear.

Putting the tools in one place gives each method a practical home. An analyst can run it in the browser, and a developer can call the same calculation from software. Privacy rules sit inside the analytical path, where they can block an unsafe result before it is returned. The toolbox now supplies shared analytics to my other products as well as its public catalog. I am building toward a common foundation where people teams can begin with sound methods and developers can reuse them without quietly creating a different answer.

Who it is for

People Analytics Toolbox is for HR and people analytics teams that need sound measurement, survey work, workforce analysis and decision methods without building the statistical machinery themselves. It is also for developers who want to call a tested people-analytics tool instead of rewriting the method for each product.

The problem

People teams are asked to explain engagement, performance, pay and retention with numbers that can look more certain than the measurement behind them. They still have to choose a suitable method, protect small groups and make the result useful for a decision. When those steps are rebuilt for each study or product, methods drift and privacy checks are easier to miss. The team spends time reconstructing the analysis and may end up with a precise-looking answer that cannot carry the decision.

What I built

People Analytics Toolbox is a set of analytics tools for HR teams, people analysts and developers working with measurement, surveys, workforce data and decisions. It includes psychometric measurement, preference studies, workforce segmentation, forecasting, decision analysis and privacy checks that stop team reports from exposing individuals. Each running tool works in the browser for a person, while software and AI agents call the same method through a typed, versioned input and output interface. The calculation and its privacy rules stay together across direct and automated use. The toolbox also provides the shared analytics used by my other products, so those products can call an established method instead of creating another implementation.

What is new in it

Each running tool pairs a browser experience with a typed, versioned software interface. An analyst and an automated workflow reach the same calculation instead of maintaining separate implementations.
Privacy checks run before team-level results are returned. Groups below the minimum size receive a blocked result, so a detailed report cannot expose an individual.
Survey tools use IRT-weighted adaptive item selection; preference studies include MaxDiff and conjoint designs with utility estimation; confidence intervals are chosen for the shape of the data.
Forecasting tools include Monte Carlo simulation, expected value of information and sequential stopping. They help teams represent uncertainty and judge whether gathering more evidence is worth the effort.

Where it stands

The aim is a common analytical foundation built so that people teams can start with sound measurement, privacy and decision methods, while developers reuse the same calculations in their own products. The toolbox is live, with 50 of its 60 registered tools running in the browser and callable by software or AI agents.

More screens

Toolbox workflow — HRIS sources → segmentation-studio normalization → data-anonymizer privacy gate → 8-service roster → MetricEnvelope outputs → MCP + HTTP gateway → consumer fleet. (Animated illustration.)

How it works

Data plane — HRIS sources to privacy-gated cohorts.
Workday SOAP, OneModel, and the survey collectors all land in segmentation-studio's 35-field canonical map before anything downstream is allowed to look at them. Whatever the upstream system is, the records exit the normalizer in one shape — and then they hit the privacy gate. The gate is the load-bearing part. Min-N, k-anonymity, deterministic HMAC tokenization, and a substitution-strategy registry live inside data-anonymizer as a foundational primitive, not a settings page. Cohort-level rollups exist only because the gate is the thing every tool service that surfaces team-level results has to call before it returns. Below the floor, the answer is blocked — not averaged into uselessness.

Analytical tool service roster — seven of the 50 working tool services, each with its own typed Zod contract.
Forty-nine live tool services — the seven named here, from reincarnation and preference-modeler through the HRIS spine to the compensation cluster, are a representative slice — and each ships its own typed Zod contract and its own CONTRACT_VERSION. Algorithms live here; consumer apps vendor the contracts, not the code. The discipline is what makes the foundation-not-product posture executable. Adoption is one tool at a time; there is no all-or-nothing migration. Additive changes are semver bumps. Breaking changes are major bumps with affected-consumer notes, and consumers re-vendor when they're ready.

MCP + HTTP gateway with chat-orchestration.
The MCP gateway is the primary dispatch. Stateless — which kills the cross-lambda session-affinity flakes that hounded the earlier in-process call shape — with per-consumer auth, scope-restricted keys, and a fire-and-forget audit row per tool call landing in `mcp.mcp_audit`. Any AI agent calls any tool service without bespoke integration. The HTTP routes are parallel transport for engineering teams; same algorithms, different shape. The chat-orchestration stack sits on top — durable conversation history, SSE-streamed admin chat, chat-turn into runPlan via the composite adapter, an intent-router catalog grounded to the live MCP registry. That's the substantive new orchestration capability of the hub. It's what makes AI-native legible: one operator, productive at the scale of a software company.

Consumer flow — typed-contract composition across the portfolio fleet.
Performix migrated to MCP transport on 2026-05-11 as the first external consumer — vendoring reincarnation, data-anonymizer, segmentation-studio, and calculus contracts rather than re-implementing the algorithms. DevPlane sits on the wildcard key for operator coordination. Vela and PA-site consume against the same gateway. Future products extend the fleet via the same contract-vendoring pattern — there is no other shape. Two things are doing work here, and the analytics discipline gets understated when the architecture story takes the foreground. The architecture is what makes solo-operator multi-product cadence possible. The analytical discipline — protected feedback, honest small-N CIs, construct-grounded codegen, value-of-information rather than dashboard intuition — is what makes the foundation worth trusting at all.