Rolequiry

Interview the job before it interviews you.

Comment

AI job-search tools helped me find roles that looked like a fit. But that fit was still being inferred from the same job description I was trying to understand.

Is this actually the work I think I am applying for — and should I let an AI decide that from the JD alone?

I did not want another fit score. I wanted to do due diligence on one job.

That is Rolequiry: a candidate-side investigation workspace that separates what an employer has stated from what a candidate still needs to know. A second official source can corroborate a published “50% travel” figure while the lived travel cadence remains unresolved. And because the agent and the page share the same case through WebMCP, changing a priority in the UI — without telling the agent — can cause Rolequiry to recompute the case and return a different investigation target on the next check.

Inspiration

Rolequiry started from a problem I kept running into in my own job search.

AI could already help me discover jobs, compare a JD with my background, and prepare an application. But that still did not tell me whether the job itself was what I thought I was applying for.

A job description is written to explain what the company wants from a candidate. It is much worse at answering what the candidate needs to know before investing years of their career in the role.

“Ownership” might mean real authority over architecture and implementation, or accountability for delivery while important decisions still require approval elsewhere. “50% travel” tells me the published requirement, but not whether that means regular weekly trips, short launch spikes, or long consecutive stretches onsite.

I have used this workflow on real technical roles I was personally evaluating, not only on the synthetic fixtures used to make the demo repeatable. What I kept finding was:

A JD could answer the literal question and still leave the decision question unresolved.

That became the core idea behind Rolequiry:

Supporting an employer's written claim is not the same as resolving the candidate's uncertainty.

Most career tools help you get the job. Rolequiry helps you investigate whether the job is worth getting.

A bad fit is expensive for both sides. If candidates understand the job better before joining, they can make a better decision — and employers are less likely to hire someone who expected a different job.

What it does

Rolequiry is a candidate-side due diligence tool for investigating a job before committing to it.

A candidate gives an agent a career summary and a job description. The agent turns the posting into testable claims and proposes the few decision variables that seem most important. The candidate confirms or changes those priorities.

From there, Rolequiry keeps the case: what the employer said, what the candidate cares about, what evidence has been found, what is still unknown, and which unanswered question is worth investigating next.

The output is a persistent pre-offer decision record: what is sufficiently resolved, what still blocks the decision, why it remains unresolved, what evidence is attached to each claim, and which question should be taken to a recruiter, hiring manager, or team member next.

A posting can say “50% travel is expected.” That settles the published number. It does not tell you whether that means weekly trips, launch spikes, or long consecutive onsite stretches for this particular team.

Rolequiry deliberately does not produce a fit score or tell the candidate to accept or reject an offer. The model can interpret and research; the candidate keeps the judgment.

Why WebMCP

An agent can already read a job description and produce a fit analysis. That was exactly the limitation I wanted to get past.

If the final career judgment should not live only inside a model answer, the candidate needs inspectable state they can change: confirmed priorities, employer claims, evidence, unresolved questions, and the next investigation target.

With WebMCP, the page and the agent work against the same Rolequiry case.

Fastest proof

  1. Ask “What should I investigate next?”
  2. Change Travel → CRITICAL directly in the page UI.
  3. Do not mention the change in chat.
  4. Ask “Check again.”

On the next check, Rolequiry recomputes from shared case state and returns a different investigation target. When the agent finds evidence, it writes that evidence back to the active claim instead of leaving it buried in conversation history.

Rolequiry owns the confirmed priorities, typed claims, evidence provenance, derived uncertainty, authoritative next probe, and decision dossier.

This problem is especially visible in forward-deployed engineering, solutions engineering, enterprise AI, and technical deployment, where similar titles can hide very different expectations around travel, coding share, technical authority, and concurrent workload.

How I used AI

ChatGPT was used for product reasoning, adversarial review, interaction design, and early live workflow testing.

One early test exposed a bad UX: the user had to understand internal claim IDs and tool order, and a claim-name mismatch could leave the case without an active probe. I changed the normal interaction to:

Analyze → confirm → investigate

A later live routing test exposed a more important failure: the model re-ranked the app-selected Travel probe because the posting already stated a 50% travel figure. I changed select_decision_changer so the returned target is explicitly app-owned and authoritative, added claim kind, status, and authority coverage to its response, and pinned that scenario as a regression.

I then repeated the live-site routing flow with Grok 4.6 through OpenCode: 4/4 scored PASS pre-hardening, and 2/2 PASS on the current hardened contracts.

How I used Codex

Codex was used throughout implementation, refactoring, debugging, testing, and WebMCP contract changes. The application intentionally keeps the important decision math out of the model: coverage, unresolvedness, tension, status, ranking, and dossier generation are app-derived.

Key features

  • Candidate-confirmed priorities and app-owned next probe — the model does not get to silently choose what matters.
  • Shared UI/agent state through WebMCP — a UI change can alter the next investigation target without being restated in chat.
  • Written claims stay separate from lived-experience uncertainty — another official source can repeat “50% travel” while the actual cadence remains materially ambiguous.
  • Evidence provenance and employer-domain authority checks — mismatched or uncheckable employer sources stay visible but out of the decision math.
  • Persistent decision dossier — unresolved blockers become concrete questions routed to a recruiter, hiring manager, or team member.

How I built it

The basic loop is:

claim → candidate priority → active question → evidence → what is still unknown

Eight page-native WebMCP tools on /case share the same CaseStore as the UI. deriveCase computes coverage, unresolvedness, tension, status, probe eligibility, and ranking. deriveDossier turns those claims into case-level progress, remaining decision blockers, and an interview question pack.

WebMCP is registered page-natively through document.modelContext. There is no remote MCP server. The connected agent keeps the raw career narrative and performs external research; Rolequiry stores only the structured decision state it needs.

Employer-official research earns authority only when the source domain matches the posting’s organization. Mismatched and uncheckable sources stay recorded and visible, but they never enter coverage or tension. Rolequiry does not independently authenticate authorship or page contents.

Verification

I keep deterministic browser evidence separate from model-facing evidence.

  • 169 tests across 24 files — all passing
  • 13-step deterministic browser journey — PASS across all 8 /case WebMCP tools
  • Current hardened contracts — 2/2 model-facing PASS on September 3
  • Pre-hardening contracts — 4/4 scored model-facing PASS on September 2
  • A poisoned cross-domain EMPLOYER_OFFICIAL / CHALLENGES write is flagged without changing authority coverage, tension, or the materially ambiguous state

One additional September 2 run is explicitly unscored because its research turn stalled. Full eval details are in the public repository.

How to test it

No login is required. Open https://rolequiry.com/case in ChatGPT’s in-app browser or Chrome with WebMCP enabled.

20-second shared-state test

  1. Ask “What should I investigate next?”
  2. Change Travel to CRITICAL directly in the page UI.
  3. Do not mention the change in chat.
  4. Ask “Check again.”

Rolequiry should recompute from shared case state and return a different investigation target.

For the full flow, give the agent a career summary plus a real job description and say “Analyze this role for me.” Confirm or revise the proposed priorities, ask it to investigate the selected probe, then ask “Where does the decision stand?”

The demo video uses the real OpenAI Forward Deployed Engineer, Seoul posting as a reproducible public example. Travel is imported as “50% travel is expected.” With Travel confirmed as CRITICAL, Rolequiry keeps the published percentage distinct from the unanswered lived cadence and selects Travel concentration as the active probe. A second official posting corroborates the published 50% figure but still does not resolve the lived cadence.

Challenges I ran into

The hardest part was not registering the tools. It was deciding which decisions belong to the model, and which must belong to the application.

One model-facing run exposed an import-scoping edge case: quoting an entire paragraph for one variable could pull unrelated policy language into the claim and change how it was typed. import_role_from_claims now requires the minimal employer sentences bearing on the one decision variable each claim models, and both the broad paragraph and bounded “50% travel is expected.” case are pinned as regressions.

Accomplishments that I'm proud of

The candidate can talk normally while the agent handles the tool choreography underneath. A UI change can alter the next probe without being restated in chat, and the result persists as a pre-offer decision record instead of disappearing into conversation history.

Most importantly, the app can preserve a useful “I still don't know.” Evidence may corroborate an employer’s written claim and still leave the candidate’s actual lived-experience question open.

What's next for Rolequiry

Longer term, I want to support multiple saved cases without turning Rolequiry into another generic job tracker.

The core stays the same: the agent investigates; Rolequiry keeps the decision state and what remains unresolved.

Links

Built With

Share this project:

Updates

Submission history