Skip to content
GigAI

Scout

Scout implements find-jobs, a job-search workflow. It ships with GigAI and gets no special runtime treatment: it is one Gig among others GigAI can host.

  • Acquire: pull public postings from the Greenhouse/Lever/Ashby applicant-tracking boards through an auto-managed watchlist, plus Exa search if you turn it on (it is off for a new setup).
  • Rank: every posting that passes your filters (titles, titles to avoid, location, the publication window, work mode) is ranked by the model target you already use, and results stream in as batches finish. The order is honest but coarse: likely fits first, likely no-matches last. It pre-filters hard blockers (a no-sponsorship or citizenship line, a clearance requirement) by moving those postings down, never by hiding them. It does not claim to put the best match first.
  • Assess: build a requirements-by-resume matrix for the postings you approve (Scout asks first, with the count and an estimate). Defaults to a local model target; hosted targets are only used when explicitly configured.
  • Present: a localhost API and a small web UI show acquired and assessed postings. What your model target sees is exactly what leaves your machine for ranking and assessment; the other network traffic is listed in Privacy and security.

Everything Scout writes stays under your configured GigAI home and the bound project’s workpad. Each job’s resume (picked from your master; gigai scout resume tailor is switched off in 0.1.11) is stored under the gig too (scout/<project>/resumes/, ephemeral pasted-resume runs under ephemeral/) and contain resume-derived text by design. The picked resume is word for word from your master: review each line. Two confirming live runs on the release candidate (155 and 151 lines) found no fabricated facts once one judge-flagged plural (“Kubernetes platforms” for the source’s “Kubernetes platform”) was reviewed as a wording difference, not a new fact; 1 minor precision flag in each run (0.6% and 0.66% of lines).

How Scout fits together

Section titled “How Scout fits together”

The diagram shows the steps in order and where your data goes. The boundary is the one in Privacy and security: your model target sees ranking lines with a compact resume digest, and the posting text plus your resume with name and contact lines removed for assessment and tailoring. The PDF and everything Scout stores stay on this machine, and Scout stores no name or contact details: you type them when you make a PDF. With a local Ollama target nothing goes to a provider.

flowchart TB
  subgraph Local["Your machine"]
    Boards["Update sources<br/>public ATS boards to the local company store"]
    Run["Jobs<br/>your filters, background rank,<br/>assessments you approve"]
    Page["Job page<br/>requirements, questions, state"]
    Tailor["Resume<br/>picked from your master, word for word;<br/>you edit points on the job page"]
    Pdf["PDF<br/>your details typed in the form,<br/>used once, never stored"]
    Kept["Never leaves: the PDF, stored data.<br/>Never stored: name and contact details"]
    Boards --> Run --> Page --> Tailor --> Pdf
    Pdf --- Kept
  end
  subgraph Sent["Sent to the model provider you picked"]
    RankIn["Ranking: one short line per posting<br/>and a compact resume digest"]
    TextIn["Assessment: posting text and<br/>resume text with name and contact lines removed"]
  end
  Run -- "ranking" --> RankIn
  Run -- "assessment" --> TextIn

Where to go next

Section titled “Where to go next”