TeamStation AI / Research / Evaluation Research / Counterfactual Tests for AI Engineer Scores
Test AI engineer scoring for proxy bias with paired counterfactuals, adversarial probes, cognitive liveness, audit evidence, and human review.
A practical protocol for testing whether an AI engineer score changes when language form changes but technical meaning stays fixed.
An AI scoring system can appear scientific and still reward the wrong thing. The score may move because an engineer uses a different English structure, names a different school, lives in a different country, or writes with less polish. None of those signals proves the person can reason through a production system.
The failure becomes serious when evaluating AI engineers across Latin America. A model can quietly turn language form into a proxy for technical depth, then hand the bias back as a clean number.
At TeamStation, the safer rule is simple: treat every score as a claim that needs evidence. Test whether the score survives a change that should not matter. Attack the output for leaked background information. Then connect the result to a live engineering work sample and human review.
That is the applied method behind TeamStation's Zero Trust Scoring doctrine. The doctrine explains the control. The protocol below turns that control into a practical test for an evaluation team.
Short answer
Take one technical response and create a second version with the same engineering meaning but standardized English. Score both versions through the same model and settings.
If the capability score moves beyond a limit chosen before the test, reject the score for review. The system may be responding to language form instead of engineering meaning.
Then train or evaluate a separate adversarial model that tries to recover a defined background label from the score or approved score representation. If that model performs better than a random classification baseline on representative held out data, the score may still carry proxy information.
Neither test proves total fairness. Together they create useful evidence that can expose a scoring system that appeared clean before anyone challenged it.
Why surface form can become a proxy
Models learn patterns from data, including patterns nobody intended to make decision grade. Accent markers, syntax, vocabulary, school names, location, and response polish can become shortcuts.
Imagine two engineers describe the same queue failure. Both identify the retry storm, the idempotency risk, and the recovery order. One answer uses standard US business English. The other carries Spanish sentence structure. If the technical content is the same, a capability score should not jump because one response sounds more familiar to the evaluator.
A normal accuracy check is too weak here. A model can predict the training label well and still use a bad route to get there. Counterfactual testing asks a causal question: what happens to the decision when we change one irrelevant surface feature and hold the meaning steady?
The counterfactual fairness literature frames the broader idea as a decision that should remain stable across a protected change when the relevant causal facts stay fixed. The original research by Kusner, Loftus, Russell, and Silva gives the formal foundation. An engineer evaluation needs a narrower operational version with visible transformation rules and audit records.
The paired counterfactual test
Let S original be the capability score for the original technical response. Let S normalized be the score after a controlled language normalization that preserves the technical claims, assumptions, and difficulty.
The observed score movement is:
FormulaDeltaESL = |Soriginal - Snormalized|
The test passes only when that movement stays inside a threshold selected before the evaluation. TeamStation's internal registry represents the public constraint as:
Formula|cq - cq_prime| <= tautrans
The threshold is not universal. It depends on the score range, calibration, task, sample, and cost of a false decision. What matters is that the team sets it before seeing the candidate result and does not move it to rescue a preferred outcome.
The transformation also needs a contract. It may repair grammar and normalize phrasing, but it cannot add missing architecture, remove a bad assumption, improve a weak tradeoff, or make the answer more complete. If the transform changes the engineering meaning, the paired test is invalid.
Here is the proof object an evaluation team should preserve:
| Gate | Evidence | Pass condition | Failure action |
|---|
| Semantic preservation | Original and normalized responses plus transformation record | Technical claims, constraints, and difficulty remain equivalent | Discard the pair and rebuild the transform |
| Score stability | Both scores, model version, prompt version, and preset threshold | Score movement stays inside the declared limit | Reject the score for bias review |
| Adversarial probe | Held out probe data, label definition, AUC, and confidence interval | No useful background recovery is demonstrated | Inspect leakage, features, data, and calibration |
| Cognitive liveness | Constraint shift work sample and evaluator notes | Reasoning updates when the system condition changes | Lower confidence and require more work evidence |
| Human accountability | Named reviewer, decision basis, limits, and appeal path | A person owns the final decision | Do not automate the decision |
The result is not a glossy scorecard. It is an audit packet.
The adversarial recovery test
The paired test can catch local instability, but it may miss proxy information that survives the normalization. A second diagnostic asks whether an attacker can recover a defined background attribute from the output.
An adversarial model receives the approved score representation and attempts a binary classification for the specific audit label. For that defined probe, an AUC near 0.5 means the adversary performs near the random classification baseline on the evaluated data.
That result must be stated carefully. AUC near 0.5 is necessary evidence for that probe, not sufficient proof of fairness or zero leakage. A weak adversary, bad labels, a small sample, class imbalance, or population drift can all hide a problem. A different attack may still recover information.
Research on adversarial learning for fair representations supports the use of an adversary to reduce or test unwanted information in a learned representation. The practical lesson is not that one number settles the case. The lesson is that a scoring system should survive an active attempt to expose what it carries.
The TeamStation formula registry now records the same boundary: the adversary must be appropriately powered, tested on representative held out data, and treated as one diagnostic inside a larger governance chain.
Cognitive liveness checks the person, not the polish
Counterfactual stability protects the score from one kind of surface noise. It does not prove that the engineer owns the reasoning.
That is why the protocol also needs cognitive liveness. Give the engineer a realistic system problem, capture the first model, then change one constraint. Make the data store read only. Cut the latency budget. Remove a model provider. Move a privacy boundary. Ask what changes, what stays true, what evidence they would inspect, and where human approval belongs.
Think about closing one bridge after somebody explains a route across the city. A memorized route keeps driving toward the closure. A real map can reroute and explain the new tradeoff.
The constraint shift test for engineering judgment makes that method visible. The Cognitive Fidelity Index and Turing Trap research add the larger warning: polished output can sound senior while the underlying system model stays thin.
For AI engineering, the distinction matters a lot. Syntax is cheap. A candidate or coding agent can generate a clean answer fast. The evaluator needs evidence of model ownership, verification behavior, uncertainty calibration, and recovery after the conditions change.
A five step operating protocol
Use the following sequence before an AI generated score becomes decision grade:
1. Define the work. Build the exercise from the real system boundary, role depth, and failure cost. A Python engineer and an LLM engineer should not receive a generic intelligence prompt dressed as a technical test. 2. Freeze the scoring contract. Record the model, prompt, rubric, score range, transform policy, stability threshold, and prohibited features before reviewing the result. 3. Run the counterfactual pair. Score the original and meaning preserving normalized response with the same settings. Preserve both artifacts and the score delta. 4. Attack the representation. Test whether an appropriate adversary can recover a defined background attribute from held out data. Report the probe design, AUC, uncertainty, and limits. 5. Join the math to work evidence. Review code, architecture, constraint shifts, verification choices, collaboration behavior, and delivery telemetry. Keep a human accountable for the final call.
The wider Axiom Cortex engineer vetting system connects these evidence lanes without pretending one metric can summarize a person. The neuro psychometric vetting model is useful only when its signals remain tied to the work, bounded by governance, and reviewed as evidence instead of destiny.
NIST's AI Risk Management Framework treats fairness with harmful bias as one characteristic inside trustworthy AI, alongside validity, reliability, transparency, privacy, security, safety, and accountability. The NIST AI RMF is a good external boundary because it makes clear that governance is a system, not a single fairness metric.
Why the method matters for LATAM engineering teams
The science is not about preferring one country. It is about stopping location and language from replacing evidence.
When a CTO evaluates engineering capacity in Mexico or Colombia, the capability question should stay tied to the work: can the engineer design, build, verify, explain, and recover inside the target system?
The same rule applies when comparing operating models. A TeamStation and Toptal comparison or a TeamStation and BairesDev comparison should examine evaluation proof, team design, governance, delivery visibility, and total coordination cost. It should not reduce a serious capacity decision to a brand list or hourly rate.
The LATAM developer salary and quality of life index provides market context, but compensation and geography do not replace role depth. They sit downstream from the capability model.
Once the engineer launches, the Distributed Engineering Operating System and Nearshore Control Plane carry the evidence forward. Prehire signals should meet delivery telemetry. If the live work contradicts the model, the model needs repair.
What the protocol cannot prove
No counterfactual test proves a scoring system is fair across every person, task, population, and future model version.
The protocol can fail when:
- the normalized response changes the technical meaning;
- the threshold is chosen after the result;
- the adversary is too weak to find recoverable information;
- the audit labels are invalid or used without a lawful purpose;
- the sample is too small or does not represent the deployment population;
- the scoring model, prompt, or calibration drifts after validation;
- accessibility needs or communication context are ignored;
- a reviewer treats one passing diagnostic as permission to skip human judgment.
The system therefore needs repeated audits, versioned evidence, protected data controls, an appeal path, and accountable review. Raw candidate data does not belong in a public research corpus.
TeamStation also does not publish a secret internal threshold as if it were a universal constant. The public method should be inspectable. The deployment threshold should be calibrated for the actual score, task, data, and decision cost.
The operating decision
An AI engineer score should answer a narrow question about demonstrated capability. It should not smuggle language familiarity, geography, or presentation polish into the answer.
The practical control is a chain:
- hold engineering meaning steady and change the surface form;
- measure the score movement;
- attack the representation for leaked background information;
- test whether the engineer can update a live system model;
- preserve the evidence and keep a human responsible.
That chain is slower than trusting a clean number. It is much faster than launching the wrong person, discovering the proxy in production, and trying to explain a decision nobody can reconstruct.
A score is not proof. A score that survives controlled attack becomes evidence.
Sources and related TeamStation research
