Less than most tools ask of them. A leader names a team, Performix invites the members, they answer a short protected survey, and a few days later the leader opens a single card. There is no dashboard to configure, no taxonomy to maintain, no weekly login that becomes a chore and then a guilt.

The whole loop is five steps: decide to run it, invite the team, wait for responses, read the result, act on it. Then run it again on a cadence to see whether the action worked. The work the operator does is deciding and acting. Everything between those two — the measurement, the math, the protection of the respondents — is the product's job, not theirs.

One card. It names the binding constraint — which of the four conditions is starving the team — and it names the accountable action, the owner of that action, and the date to remeasure. That is the entire output. Not a report. Not a grid of charts. A single decision, stated plainly enough that the room cannot leave with four different interpretations of it.

The card above is the real rendered form, not a mockup of one. The discipline behind it is the discipline behind the whole product: a diagnostic settles on one thing, and the artifact that carries it refuses to dilute that one thing into a dashboard.

Short, and unlike the surveys people brace for. It does not march every respondent through the same hundred-item battery. It narrows — asking the next question that is worth asking given what the instrument already knows about the team, and stopping when more questions would not change the answer. For most respondents that is a few minutes.

The questions themselves are mostly forced-choice trade-offs rather than one-to-five agreement. "Which of these is most true, and which is least?" is a harder question to game and a more honest one to answer than "rate your agreement from one to five." And every answer is protected — tokenized so that no respondent can be re-identified, and gated so that results never render below a minimum N.

Not from a product manager guessing at what sounds insightful. The items are derived from a research substrate — the literature on work design, motivation, situational performance, and measurement is distilled into constructs, the constructs into candidate items, and the candidates are validated before any of them reach a respondent. The pipeline above is that path, from published research to a validated item bank.

This is where AI does real work — proposing candidate items, mapping new evidence onto existing constructs — but it does that work against typed, validated measurement recipes, not by improvising questions on the fly. The substrate is the reason the survey can be short: the instrument already knows what each item measures and how much it is worth asking.

By psychometrics, not by a language model. The four conditions — Capability, Alignment, Motivation, Support — are scored from the responses, and the diagnostic identifies which one is binding: the condition that, relieved, would unblock the others. The illustration above is the model — four dials, and the job is finding the one that is starving.

The methods underneath are named and ordinary in the measurement world, if not in the HR-tools world: item-response theory for scoring and adaptive selection, Monte Carlo with value-of-information gating to decide which question is worth asking next, and Wilson confidence intervals so the result is a range with a stated confidence, not a false point estimate. None of that is an LLM. A language model could not tell you whether the constraint is Capability or Alignment, because it is not a measurement instrument.

The card travels. Because the output is a single image-shaped artifact rather than a dashboard locked behind a login, it can be played in the app, queued like a playlist, dropped into an email, or placed on a slide. Leadership does not adopt a new tool to receive the diagnosis; the diagnosis comes to them in a form they already know how to consume.

The player above is that surface — a sequence of insight cards a leader moves through, each one a settled diagnosis for a team, rather than a wall of metrics they have to interpret. The portability is the point: a result that cannot leave the tool that produced it does not reach the person who can act on it.

You do not restructure your data to fit Performix. A mapping wizard connects your HRIS and lines your fields up against the common shape the instrument expects — the surface above is that mapping step. Where the match is obvious it is proposed for you; where it is ambiguous you decide. The work is minutes of confirmation, not a migration project.

The mapping runs against typed, machine-readable contracts, which is why an agent can do most of it and why the parts a human confirms are unambiguous. And the same protection that covers survey responses covers this: the data feeds the diagnostic, it does not feed a surveillance surface.

The loop closes with remeasurement. A diagnostic that names a constraint and stops there is theater. So the action has an owner and a date, and a few weeks later — four to twelve, depending on the action — the team is pulsed again against the same dimension.

Two outcomes, both useful. If the constraint has relaxed, the binding condition moves to whatever is next-most-starved, and the team works on that. If it has not, then either the action was wrong or the diagnosis was — and both of those are detectable, which is more than a quarterly engagement re-run can say. The remeasurement is what makes the whole thing falsifiable rather than reassuring.

This is the load-bearing question, so here is a real answer rather than a description of one. Above are three teams, each diagnosed independently and each landing on a different binding constraint — Capability for one, Motivation for another, Support for the third. Same instrument, three different verdicts, because the constraint is a property of the team, not of the tool.

Read across a single team and you have the whole output in one line: the dimension that is binding, the specific sub-constraint underneath it, the recommended remedy, and the value-of-information score that says whether acting now is worth it. That last column is the discipline — the diagnostic tells you not just what is binding but whether the next move is worth making. One honest worked example beats a dozen asserted ones.

Two-sided, and the distinction matters more than almost anything else here. AI is not the diagnostic. The engine that decides which condition is binding is psychometrics — measurement methods that return a number with a confidence interval, not text that sounds right. A language model cannot measure a team, and we do not pretend it can.

AI isa first-class consumer of the substrate around the engine. Connecting source systems, mapping fields, generating candidate items, extracting evidence from documents — that is exactly the work agents are now good at, and Performix is built for them to do it against typed contracts. The field's mistake is to use AI where measurement is required and human consultants where pipelines should be agents. We reverse both.

An engagement survey measures a feeling — how people feel about being here — and reports it as a score that goes up or down. Performix measures conditions — whether the four things a team needs to perform are present — and reports which one is missing. The two correlate, because miserable teams often have a starved condition behind the misery, but they are different objects.

The practical difference is what you do on Monday. An engagement score that dropped tells you something is wrong and leaves you to guess what. A binding-constraint diagnosis tells you the one thing to fix and who owns fixing it. One produces a feeling about the team; the other produces a decision.

A BI dashboard shows you everything and lets you sort it out. That is a confession dressed as a feature: the tool does not know which signal matters, so it shows all of them. Reading a dashboard feels rigorous and rarely is — the reader leaves with an impression, and two readers leave with two different ones.

Performix collapses the many signals into one. The output of BI is a chart; the output of Performix is a decision. We are not opposed to dashboards for the things dashboards are good at — operational monitoring, where you genuinely want all the gauges. We are opposed to using one to answer "what is wrong with this team," because that question has a single best answer and a dashboard structurally refuses to give it.

An AI HR copilot generates text in response to a prompt. Ask it about a team and it will produce fluent, plausible commentary — which is exactly the problem, because plausible is not measured. There is no instrument underneath it; there is a model predicting what a thoughtful answer sounds like.

Performix runs psychometric methods on a precomputed substrate and returns a measurement with a confidence range. The output is not commentary about your team — it is a diagnosis of it. As covered in Q10, we use AI heavily, but around the engine, never as the engine. The difference between commentary and measurement is the whole difference.

Coaching operates on the individual — it makes a person better at their role. Performix operates on the team-as-system. A diagnosis that points to Support does not tell anyone to be coached; it tells the organization to fix what the team needs in order to do its job. The two are complementary, not competing: coaching can be the action a diagnosis recommends.

Consulting is custom and recurring — a firm studies your situation and bills you to keep studying it. Performix is a product that runs on a cadence at a known cost, and produces the same instrument every time so the results are comparable across teams and across quarters. Consulting can read the diagnostic; it is not the diagnostic.