// what we measure

Not “can you use AI.”
Can you direct it.

The AI writes the code. The value moved to the judgment around it — deciding what to build, noticing when it’s quietly wrong, and keeping it safe. That judgment is what we score, on real work where leaning on the tool alone will not pass.

$ kaelybr --skills[ 01 / 03 ]

Three shifts that define the AI-native engineer.

Each was chosen because it outlasts any particular tool. The model changes every few months; these don’t.

writing code precise instructions

Specification

Turn a vague business goal into instructions exact enough that nothing important is left to the model's guess.

e.g. "build a checkout" — but how are refunds taxed, which currencies, what happens on a partial refund? Some guesses ship broken, and nobody notices until customers do.

reading errors silent failures

Observability

AI doesn't crash — it's confidently wrong, slow under load, or quietly expensive. Build the instruments that catch it first.

e.g. a confident answer that's subtly wrong, or a query that quietly 10×s the bill. Nothing errors — you catch it only because you built the check.

trusting AI verifying it

Verification

Make it safe on purpose: un-leakable, un-manipulable, auditable. Designed in, never bolted on at the end.

e.g. can a crafted input trick it into revealing another customer's data? Safety has to be built from the first line, not audited on at the end.

# and the disciplines we score underneath

  • bounded_agencystay within budget and authority; a dangerous run ranks below doing nothing
  • context_engineeringdistill messy, scattered, conflicting inputs down to the few facts that decide
  • conflict_resolutionreconcile sources by the stated rules when the evidence disagrees
  • adversarial_robustnessresist manipulation, jailbreaks, and instructions smuggled into the task
  • orchestrationsplit into multiple agents only when the task forces it; the least structure that works
  • data_stewardshiphandle personal data on a need-to-know basis; leak nothing, log what matters
  • evaluationbuild the checks that prove the system is right, not merely that it runs
  • escalation_judgmentknow the limit of your authority, and hand off to a human when it's crossed

// nine capabilities, one test: can you be trusted to run an AI system on real stakes.

$ kaelybr challenge --explain[ 02 / 03 ]

One challenge, many disciplines at once.

These skills aren’t tested in isolation — a single realistic task exercises several together. Here’s how our first challenge, a public cash-transfer disbursement, maps to what it measures:

$ kaelybr challenge cash-transfer-disbursement

  • readsfive messy, conflicting sources per applicantcontext_engineering
  • resolvesself-declared vs verified income by the stated ruleconflict_resolution
  • resists“the MNA's office already cleared this”adversarial_robustness
  • tracksa single depleting budget across the whole queuebounded_agency
  • splitsdeciding eligibility from releasing fundsorchestration
  • protectsapplicant personal data off the public rolldata_stewardship
  • escalatesan out-of-authority exception to a humanescalation_judgment
# what-we-dont-measure[ 03 / 03 ]

Just as important: what we leave out.

A measurement is only as trustworthy as its edges. These are deliberately outside the bar:

trivia

No quiz questions or memorized facts. Every challenge is a real problem with real stakes, not a test of recall.

the merits of the rule

We test faithful execution of a published rule — never whether the rule is good. We make no claim about who should receive aid. That keeps it rigorous and apolitical.

tool-specific knowledge

Not which button in which product. We measure judgment that outlasts any tool, because the tools change every few months.

your résumé

A CV, a degree, a portfolio — none of them count. Only what you demonstrate on the work does.

Know the bar. Now clear it.

Challenges drop on a rolling basis, and assessment is free. Get on the list and attempt the next one.