Skip to main content
Sixty applications for one support engineer, and a hiring manager with an afternoon. Some applicants don’t meet the stated requirements, and saying so should take a rule, not a read. The rest deserve a proper ranking against what the role needs, with a reason for each place. And who gets a call is the manager’s decision, not a model’s. You want the gates to be rules a script checks, so every exclusion has the rule beside it and nobody is dropped on an impression. You want the ranking of the rest done against your brief and checked against it, not taken on trust from one model. And you want to read that ranking and pick the shortlist yourself. Obversa puts the rules in a function, the ranking in a tournament, and the decision in your hands. A script applies the filters and writes the eligible and the excluded, each with its rule. Two rankers from different model families rank the eligible applicants against the brief, each in its own worktree; a judge function scores each ranking against the brief, and only the better one lands. Then the run stops for your shortlist. This file is a three-stage pipeline: the gates, the tournament, and the person.

Run it

Set the project up as Installation describes. Copy the file with briefs/, applications/ and filters.json beside it into a folder of its own, sign in to Claude Code and Codex, and run it there. The folder becomes a Git repository if it isn’t one, because each ranker works on a branch and the winner lands:
Terminal
The output below is the proof’s offline run, with scripted seats standing in for the models, so the words are the script’s and the shape is the run’s.
Output, from the offline proof
Six applications, three eligible. The gates excluded one applicant on years, one on the required skill and one on work region, and wrote each rule beside the name in shortlist/excluded.json. Two rankings were written; the judge scored one lower for dropping an eligible applicant and ranking one the gates had excluded, and the complete ranking landed as shortlist/ranking.md. The run stopped on the person’s question.

The file

The gates are three rules, and the function returns the one an application fails:
examples/use-cases/hiring/shortlist.ts (excerpt)
The judge is a function too. It scores a ranking against the brief: a point for each eligible applicant present, two more for all of them, a point for a reason on every line, and three off for each applicant the gates excluded:
examples/use-cases/hiring/shortlist.ts (excerpt)
The tournament runs one ranker per model family, each writing shortlist/ranking.md in its own worktree, and the judge reads that file and the gates’ result from the worktree. Only the highest-scoring ranking merges onto the main branch. Then the person is asked:
examples/use-cases/hiring/shortlist.ts (excerpt)
The gates’ result is committed before the rankers start, so each worktree holds the same eligible list; a ranker can’t see an application the gates excluded unless it goes looking. The brief tells each ranker to rank the eligible file and nobody else, and the judge takes points off when one does.
briefs/role.md
examples/use-cases/hiring/shortlist.ts

The team’s shape

What the run did

The proof runs the file against two scripted seats and checks what the page describes: three eligible and three excluded with their rules, the complete ranking on the main branch and not the one with a stray, and the run stopped on the person’s question. Obversa recorded the run as one event log, so it shows the gates, the two candidate branches, the judge’s score for each, the merge of the winner, and the question, in order. Nothing here contacts an applicant, and nothing decides who is hired. The rules are the hiring manager’s, written where anyone can read them; the ranking is checked against the brief before a person sees it; and the shortlist is the person’s.

Next steps