From Job Hunting to CareerOps: A Candidate-Controlled Operating System
This chapter examines career-ops as a job-search system, not as a résumé generator with a few extra commands. Its central question is practical: how can AI help a candidate decide which opportunities deserve attention, prepare a credible application, and preserve the candidate's authority over the final action? The repository's answer is to build a staged evidence pipeline. Cheap discovery narrows the field, structured evaluation separates different kinds of judgment, personalization stays tied to the candidate's own records, and submission remains a human decision.
That arrangement matters because job search is often measured by the wrong output. A large application count can look like progress while hiding three accumulating costs: time spent on roles that were never a fit, documents that blur rather than clarify a candidate's evidence, and repeated actions that consume reputation without producing useful learning. career-ops is designed around a different scarce resource: the candidate's attention. Its value is not that it makes every application faster. It is that it tries to make the decision to invest in an application more deliberate.
From volume to signal
The project's CareerOps Manifesto makes the contrast explicit. It prefers ten applications a candidate believes in over two hundred they do not, signal over volume, and evidence over keywords. That is more than a slogan about being selective. It changes what the system must optimize.
A volume-first tool would treat a job posting as a trigger for output. Find a URL, generate a résumé, fill a form, and move on to the next URL. A candidate-side decision system treats the posting as an uncertain object to investigate. Is it still live? Does its scope match the candidate's direction? Which requirements are central in this particular posting, and which are boilerplate? Is a warning about the employer, the channel, or the source strong enough to change the next step? What evidence supports the candidate's claims, and what is still unknown?
Those questions also explain why the repository refuses to collapse everything into one ranking. A role can be a strong skills match but have an unconfirmed culture fit. A posting can look legitimate but ask for work the candidate does not want. A missing signal can justify verification without justifying rejection. The system's central task is therefore allocation: decide where to spend more attention, and make the basis for that allocation inspectable.
The approach has an ethical dimension as well as an operational one. The manifesto says the candidate's agent should work for the candidate, not for a platform or employer; that an agent may help with everything except the candidate's yes; and that the candidate's data should remain portable, exportable, and deletable. These are design commitments, not evidence that the tool guarantees a better hiring outcome. They define what the repository is trying to preserve while it automates parts of the search.
What career-ops actually is
career-ops is not a hosted matching service with a central database. It is an open-source repository whose parts cooperate inside a user's workspace. Markdown modes describe how an AI coding CLI should reason about a job, a CV, a company, or an application form. Node.js utilities handle deterministic work such as scanning public sources, checking liveness, building documents, validating facts, merging tracker entries, and checking pipeline integrity. Templates turn structured content into a CV or cover letter. Provider modules translate different job boards into a common job shape. Human-readable reports and tracker files preserve what happened.
The AI is supplied at the edge. The repository supports several coding CLIs, and its core logic is intentionally not tied to one model provider. That distinction is important. The prompts and file contracts define the workflow; the chosen CLI supplies model execution for tasks that require interpretation, such as matching a role to a candidate's evidence or drafting an explanation. Deterministic scripts handle work where repeatability matters more than open-ended reasoning. This division makes the system portable, but it does not make all models equivalent. The repository itself distinguishes economy, standard, and premium tiers and warns that weaker local models may struggle with the evaluation schema and résumé tailoring.
"Local-first" has a similarly precise meaning. The code, CV, profile, reports, and tracker can live in a local checkout, and the maintainers do not operate a hosted core or collect the user's workflow as a central dataset. But when a user invokes a remote AI provider through a coding CLI, the relevant local context is sent to that provider. Local storage and provider-side processing are different boundaries. A responsible user must inspect the chosen provider's terms and decide whether the convenience of remote reasoning is acceptable for the sensitivity of their career history.
The human-in-the-loop boundary is even more concrete. career-ops can evaluate a role, draft a tailored document, identify form questions, and assist with ordinary fields. It is not supposed to submit an application on the candidate's behalf. The application workflow stops for sensitive questions and before the final external action. The candidate reviews the content, handles fields that should not be clicked programmatically, solves any CAPTCHA, and decides whether to submit. The system can then record a confirmed submission, but it should not confuse prepared material with an action that actually occurred.
A role is a chain of decisions, not a single score
The diagram shows the intended shape of the system, but each arrow represents a different kind of evidence. Public sources first produce possible opportunities. The scanner can read public ATS APIs, feeds, and local parsers without spending language-model tokens, then apply configured title, location, age, compensation, and content filters. A lightweight triage step can go further by looking only at title and location. This is deliberately limited: the early stages do not claim to understand the whole job. They protect the candidate from opening every door just because a search index found it.
The surviving role becomes a candidate for structured evaluation, not an automatic recommendation. The evaluation produces separate views of the role: what the work appears to involve, how the candidate's evidence maps to requirements, how the level and compensation should be interpreted, what to emphasize in a CV, how to prepare for an interview, and whether the posting shows legitimacy concerns. A global score can summarize the judgment, but the report retains the reasoning around it. The project's current scoring contract also keeps posting legitimacy and requirement importance separate from the global fit score. That separation matters because a legitimate role may still be a poor match, while a critical requirement may deserve interview preparation without being turned into a hidden arithmetic penalty.
Personalization then changes the presentation of verified evidence rather than inventing new evidence. The system can mirror the language of a job description, reorder relevant achievements, and select a suitable document template. It cannot turn familiarity with a tool into authorship of a project, or turn a plausible number in an accumulated interview story into a confirmed metric. A fact gate can catch many unsupported metrics and explicit claims about employers, titles, tools, or authorship before a document is rendered. It cannot decide whether the candidate's story is compelling, current, or wise to tell. That remains a human judgment.
Finally, the application stage is a handoff. A live form may reveal a mismatch between the posting and the report, a second application through another channel, a knockout question, or a sensitive field the profile does not answer. career-ops is designed to surface those conditions before drafting proceeds. If the candidate supplies or confirms the missing information, the system can help prepare responses. If not, the uncertainty remains visible. The tracker records a filled or submitted state differently, so an unfinished application is not silently counted as an application sent.
The audit habit behind the design
The most useful way to read career-ops is to ask four questions at every boundary:
- What is known? For example, a public ATS may return a title, URL, location, and posting date.
- What is inferred? A role may look like an AI-platform position because its responsibilities mention evaluation and observability, but that classification is an interpretation.
- What is uncertain? A rate limit, login wall, anti-bot challenge, missing salary, or absent posting date reduces what the system can safely conclude.
- Who acts next? The scanner may add a candidate to a pipeline, the evaluator may recommend an action, but the candidate decides whether to invest further and whether to submit.
This habit prevents a common failure in automated workflows: allowing a convenient intermediate signal to become an irreversible conclusion. A search result is not proof that a posting is live. A legitimacy warning is not an accusation. A score is not a hiring prediction. A generated CV is not evidence that every sentence is true. The repository's strongest idea is therefore less about adding AI to job search than about placing boundaries around what each automated stage is allowed to mean.
That idea depends on the workspace being as explicit as the prompts. If the candidate's evidence, the system's instructions, the report history, and the derived indexes can silently overwrite one another, the promise of control is fragile. The next question is how career-ops represents those owners and preserves their records while the system evolves.