Skip to content
David Scott
All systems
03AI-native application operationsBuilt / Active Development

Career Ops

A governed job-search and application system that turns verified opportunities into structured application packages, matches the correct candidate profile and resume version, handles major ATS workflows, and keeps a human approval boundary before consequential actions.

Next.jsTypeScriptPlaywrightATS adaptersState / approval gatesCodex / Claude Code

01Overview

Career Ops is an AI-native application-operations product for managing a job search from verified opportunity through package preparation, form handling, human review, and tracking. It combines zero-token source discovery, role fit evaluation, candidate profile and resume-version matching, application packages, ATS-specific execution adapters, live form inspection, dry-run safety, and an approval gate before any consequential action. It is built as an active product, not a concept, but it is deliberately governed: it does not blindly auto-submit applications.

02Problem

A serious job search becomes operational work very quickly. Opportunities come from many sources, postings expire, ATS forms change, duplicate applications are easy to create, and each application mixes low-risk identity fields with high-risk compensation, authorization, demographic, and role-specific questions. A spreadsheet can track the work, but it cannot enforce that the right resume, package, profile, version, source, and approval are still aligned at the moment of action.

03David's role

  • Adapted and extended Career Ops into David's active application-operations environment, including candidate profile, resume library, application package review, apply queue, liveness, and ATS execution flows.
  • Built and hardened the web command-center layer around application packages, package hashes, profile snapshots, answer memory, review states, and exact approval checks.
  • Implemented and verified major ATS handling paths across Greenhouse, Lever, Ashby, Workday, and a generic manual-assist fallback.
  • Added deterministic liveness and dry-run gates so jobs are rechecked before action and unsupported or uncertain states stop instead of guessing.
  • Designed the human-intervention model for login, MFA, CAPTCHA, sensitive questions, unknown required fields, unsupported controls, and uncertain submission confirmation.

04Architecture

A local-first application-operations layer sits over the Career Ops file model. Discovery and liveness checks produce verified job records. Candidate profile and resume records are snapshotted into application packages, each with a version and package hash. An application manifest records the form Career Ops inspected. The apply queue projects readiness from packages, liveness, manifests, sessions, profile hash, and tracker state. ATS adapters drive dry runs or live sessions, but exact package approval is rechecked immediately before final submission.

05How it works

  1. 01Discover
  2. 02Score
  3. 03Package
  4. 04Inspect
  5. 05Review
  6. 06Apply
  7. 07Confirm
  8. 08Track
Pipeline stages. Accented stages are where a person decides.
  1. 01

    Discover

    Public job sources and ATS feeds are scanned and normalized, with liveness checks used to distinguish live postings from expired, redirected, or uncertain ones.

  2. 02

    Score

    Jobs are evaluated against the candidate profile and resume context, then prioritized by fit, compensation, company signals, and posting legitimacy.

  3. 03

    Package

    A structured application package captures the job, role fit explanation, selected resume, profile snapshot, required answers, review questions, and package hash.

  4. 04

    Inspect

    Career Ops reads the live ATS form, discovers fields and questions, classifies answers as SAFE_AUTOFILL, REVIEW_REQUIRED, or USER_REQUIRED, and persists material discoveries back to the package.

  5. 05

    Review

    The human reviews package questions, resume choice, sensitive answers, and any intervention items before approving the exact package version and hash.

  6. 06

    Apply

    Greenhouse, Lever, Ashby, Workday, or generic manual-assist adapters fill approved fields, upload the approved resume, and stop for login, MFA, CAPTCHA, unsupported controls, or unapproved required data.

  7. 07

    Confirm

    Submission requires a fresh liveness check and exact approval validation. If confirmation is uncertain, the run parks for human resolution instead of retrying blindly.

  8. 08

    Track

    Application sessions, outcomes, package history, and tracker status are recorded so duplicates and stale approvals are blocked later.

06AI & technology

  • AI coding CLI operating model through shared Career Ops modes for evaluation, tailoring, research, and application assistance
  • Fit scoring and prioritization over candidate profile, resume, job description, compensation, company signals, and posting legitimacy
  • Application package generation with selected resume, profile snapshot, material summary, review questions, and answer memory
  • Deterministic liveness, readiness, package validation, and execution gates designed to minimize unnecessary model calls
  • Playwright-backed form inspection, dry-run execution, resume upload checks, field readback, and confirmation capture

07Integrations

  • Greenhouse, Lever, Ashby, and Workday ATS adapters, with a generic manual-assist fallback for unsupported or unfamiliar portals
  • Public ATS and job-board sources for discovery and liveness verification, including Greenhouse, Lever, Ashby, Workday, and other provider modules
  • Candidate profile, resume library, package store, application sessions, liveness store, answer memory, and markdown tracker files
  • Codex and Claude Code workflows through shared Career Ops instructions, modes, and CLI entry files

08Human control & governance

  • Career Ops does not blindly auto-submit applications; the system is approval-gated and designed to stop before consequential action.
  • Submission requires the exact reviewed package hash and version, and approval is invalidated when material application data changes.
  • Applications stop for login, MFA, CAPTCHA, sensitive questions, unknown required fields, unsupported controls, closed jobs, stale liveness, and uncertain confirmations.
  • SAFE_AUTOFILL, REVIEW_REQUIRED, and USER_REQUIRED classifications separate low-risk identity fields from answers that need review or human input.
  • Duplicate protection prevents repeated live sessions or repeat submission attempts once a package has been submitted or parked as uncertain.
  • Dry-run and no-submit behavior is explicit: the system can inspect, fill, and report without crossing the final submission boundary.

09Key design decisions

The decision, the alternative it was chosen over, and why.

  1. 01

    Decision

    Make application packages hash-covered, versioned, and approval-gated.

    Instead of

    Letting the current screen state or the current package file define what gets submitted.

    Why

    An application can change after review: a resume override, a live-form question, answer memory, profile data, or job liveness can all shift materially. The package hash makes approval refer to an exact reviewed artifact, so a stale tab cannot submit a different application under an old approval.

  2. 02

    Decision

    Require fresh job liveness at APPLY time, not just during discovery.

    Instead of

    Trusting a job that was live when it entered the pipeline.

    Why

    ATS pages often keep shells alive after requisitions close. The tests cover Greenhouse, Lever, Ashby, and Workday cases where HTTP 200 is not enough. A fresh check prevents applying to a closed job and prevents the queue from presenting stale work as actionable.

  3. 03

    Decision

    Classify each form answer before filling it: SAFE_AUTOFILL, REVIEW_REQUIRED, or USER_REQUIRED.

    Instead of

    Treating all known answers as equivalent once they are present in the profile.

    Why

    Identity fields, compensation expectations, authorization answers, demographic questions, and role-specific prompts do not carry the same risk. Classification lets the system automate low-risk fields while keeping sensitive or contextual answers under human control.

  4. 04

    Decision

    Use first-class ATS adapters with a generic manual-assist fallback.

    Instead of

    Attempting one universal browser strategy across every job portal.

    Why

    Greenhouse, Lever, Ashby, and Workday fail in different ways. Adapter-specific handling keeps common paths efficient while the fallback protects the boundary: unsupported portals produce prepared answers and instructions rather than pretending automation can handle them.

  5. 05

    Decision

    Park uncertain final submissions for human resolution, never automatic retry.

    Instead of

    Retrying when a confirmation page is not detected.

    Why

    A final submit click may already have landed even if the browser did not observe confirmation. Retrying can create a duplicate application, so the system records uncertainty, holds the session, and requires David to resolve the outcome explicitly.

10Tradeoffs

  • The approval boundary slows the fastest possible application flow, but it is what makes the system safe to use on real job portals.
  • Major ATS adapters cover high-value surfaces; unfamiliar portals can still require manual assist rather than full automation.
  • Local-first files and deterministic scripts keep the system inspectable, but require careful integrity checks around package files, sessions, and tracker state.
  • The system can fill and submit only when a supported ATS path, live posting, approved package, ready resume, and resolved required fields all align.
  • The product is in active development; claims here are limited to source, tests, docs, and observed local state rather than a hosted commercial deployment.

11Outcome

Career Ops is built and actively under development as David's advanced application-operations environment. The current source contains a Next.js web UI, package review and apply queue flows, ATS adapters for Greenhouse, Lever, Ashby, and Workday, generic manual-assist fallback, liveness verification, exact approval enforcement, duplicate protection, intervention/session handling, and dry-run/no-submit safety behavior. It is accurately described as governed application operations, not blind autonomous applying.

12Evidence

Source and architecture
The Career Ops worktree includes the application package model, apply queue, liveness store, application sessions, ATS executor, answer memory, profile store, and web command-center components.
ATS execution adapters
The executor registers Greenhouse, Lever, Ashby, Workday, and a generic manual-assist adapter, with browser-first destination detection and per-ATS handling.
Safety gates
Package validation enforces version and package-hash approval, profile snapshots, selected resume status, question classifications, legal state transitions, and stale-approval refusal.
Liveness and duplicate protection tests
The test suites cover Workday closed-posting false positives, Greenhouse / Lever / Ashby liveness, APPLY-time revalidation, exact-hash apply queue behavior, duplicate submission refusal, and uncertain-confirmation handling.