RAW TO RELIABLEby Lee YaoData Engineer & Analytics Systems Builder
Menu
Back to Lab
System 01Local-First Workflow SystemHuman-in-the-loop

RAW TO RELIABLE / LAB CASE STUDY / SYSTEM 01

Job Search OS

A local-first job research and application workflow for importing roles, evaluating fit, tracking evidence, detecting duplicates, and preserving human review at every step.

The system turns an inconsistent browser-based job search into a controlled workflow with structured ingestion, offline analysis, persistent state, duplicate protection, and reviewable outputs.

System stateActive Development
Automation prepares the decision. The user keeps control of the decision and submission.

Core capabilities

  • Chrome Extension
  • URL and JD Import
  • Import Inbox
  • Evidence-Based Fit Score
  • SQLite Tracker
  • Duplicate Detection
  • Draft Recovery
  • Bilingual Interface
  • Local Analytics
  • Human Review
  • Security Controls

Technology

PythonStreamlitSQLiteSQLAlchemyYAMLChrome ExtensionManifest V3JavaScriptFastAPIPydanticpytest

01 / Executive Overview

Executive Overview

Job Search OS is a developing local-first workflow system designed to make job evaluation more structured, consistent, and reviewable. It connects browser-based job discovery with a local analysis environment where job descriptions can be imported, scored, compared, tracked, and preserved without delegating the final decision or application submission to automation.

The system emerged from a practical problem: job postings arrive through inconsistent sources and formats, while fit decisions depend on more than keyword overlap. The workflow therefore combines structured extraction, profile evidence, configurable scoring, duplicate protection, persistence, local analytics, and human review.

Implemented

  • Current State

    Browser ingestion, canonical local analysis, persistence, tracking, duplicate protection, and a read-only dashboard are implemented.

In Progress

  • Active Refinement

    Score calibration, source-field cleanup, interface refinement, and ranked-shortlist workflow design.

Planned

  • Target Assistance

    Application-material drafts, controlled browser prefilling, historical workflow analytics, and expanded exports.

Job Search OS interface showing the main workspace and job analysis controls.
PRODUCT OVERVIEW

Job Search OS workspace for importing, analyzing, and reviewing job opportunities.

02 / Problem

Problem

Traditional job-search workflows are fragmented across browser tabs, saved links, spreadsheets, ATS pages, résumé versions, and memory. The same role may be evaluated multiple times, copied inconsistently, or scored differently depending on how its description was imported.

Keyword matching alone also fails to capture whether the candidate has evidence for the employer’s actual requirements. A useful system must preserve the source job description, normalize the input, compare it against a structured profile, explain the evidence behind the score, detect duplicates, and maintain application state.

Product problem dimensions

  • 01Inconsistent job-description formats
  • 02Repeated manual copy and paste
  • 03Duplicate postings
  • 04Unexplained fit scores
  • 05Scoring consistency across ingestion paths
  • 06Lost drafts and analysis state
  • 07Fragmented application tracking
  • 08Weak separation between automation and final human decisions

03 / Product Principles

Product Principles

  1. 01

    Local First

    Job descriptions, evaluations, drafts, and tracking state remain in a local workflow by default.

  2. 02

    Evidence Before Score

    A fit score is supported by explicit evidence, missing requirements, and reviewable reasoning rather than keyword overlap alone.

  3. 03

    One Source, One Record

    Normalization and duplicate detection work together to prevent the same job from producing multiple inconsistent records.

  4. 04

    Human Review at Every Decision Boundary

    Automation may extract, organize, analyze, and draft, but the user reviews the result and controls final submission.

  5. 05

    Recoverable State

    Drafts and tracked jobs survive interruptions and remain reloadable across local sessions.

  6. 06

    Explainable Workflow

    The interface shows how a job entered the system, why it received its score, and what evidence supports the result.

  7. 07

    Security Proportional to Local Integration

    A local browser-to-application bridge still requires authentication, rate limiting, controlled origins, and careful input handling.

04 / System Architecture

System Architecture

JOB SEARCH OS / LOCAL PRODUCT ARCHITECTURE / FIG. 01
ImplementedIn ProgressPlanned

Source Capture

SystemImplemented
Job SourcesLinkedIn / Greenhouse / Lever / Ashby
SystemImplemented
Browser ExtractionJSON-LD / DOM / selected text
SystemImplemented
Chrome ExtensionManifest V3 explicit capture

Local Ingestion

SystemImplemented
Local Receiver127.0.0.1 / FastAPI
SystemImplemented
Trust ControlsToken / origin / rate / payload
SystemImplemented
Import InboxReview / retry / archive / delete

Analysis & State

SystemImplemented
Canonical InputNormalized JD + scoring fields
SystemImplemented
Fit & EvidenceRules / profile / gaps / warnings
SystemImplemented
SQLite Workflow StateDrafts / Tracker / snapshots
SystemImplemented
Local DashboardRead-only current-state analytics

Decision Boundary

User ControlImplemented
Prioritize & ReviewEvidence-led user decision
User ControlPlanned
Application DraftsRésumé and answer assistance
User ControlPlanned
Controlled PrefillVerify every browser field
User ControlImplemented
Submit ManuallyFinal action remains with user

Automation boundary ends before final submission.

A local-first workflow connecting browser-based job discovery to reviewable analysis, persistent tracking, and user-controlled application decisions.

05 / Job Ingestion

Job Ingestion

Supported extraction strategies cover several common sources and explicit fallback handling without claiming universal ATS compatibility.

01

Browser Extension Import

Implemented

The Manifest V3 extension captures the currently visible posting, lets the user review extracted fields, and sends a bounded payload only to the local receiver.

  • Chrome / Edge
  • Explicit capture

02

URL Import

Implemented

The application imports supported public job URLs through guarded HTTP handling and the same canonical analysis contract used by pasted input.

  • Greenhouse
  • Lever
  • Ashby
  • JSON-LD

03

Pasted Job Description

Implemented

A job description can be pasted directly when automated extraction is unavailable, incomplete, or not appropriate.

  • Offline analysis
  • Draft-safe

04

Selected Text Extraction

Implemented

Explicitly selected page text replaces prior capture content and records its provenance when structured extraction is unreliable.

  • Fallback
  • Provenance

05

Source Metadata Cleanup

In Progress

Canonical job-description normalization is implemented; source-specific company, title, location, URL, and questionnaire cleanup continues.

Confirmed extraction coverage

  • LinkedIn visible job details
  • Greenhouse
  • Lever
  • Ashby
  • JSON-LD JobPosting
  • Conservative visible DOM
  • Explicit selected text

06 / Import Inbox

Import Inbox

The Import Inbox separates browser capture from permanent job records. Imported roles remain inspectable, retryable, and removable before a durable Tracker decision.

IMPORT INBOX / REVIEW QUEUE / FIG. 02
01ImplementedReceived

The local receiver accepts and stores a validated payload.

02ImplementedReview

Company, title, location, URL, source, description, provenance, and warnings remain inspectable.

03ImplementedValidate

Confidence, analysis result, and duplicate state inform the next action.

04ImplementedDecide

The user retries, archives, deletes, or approves a save.

05ImplementedPersist

An approved item becomes a durable Tracker record at most once.

A review queue keeps uncertain extraction, duplicate state, and save decisions visible before persistence.

01

Source & Timestamp

Implemented

Each item preserves capture platform, source URL, import time, provenance, confidence, and extraction warnings.

02

Offline Analysis Preview

Implemented

Inbox items can be analyzed locally and display fit results without starting optional company research.

03

Duplicate Status

Implemented

Existing Tracker matches and repeated captures remain visible before a permanent save.

04

Retry, Archive & Delete

Implemented

Failed items can be retried; reviewed items can be archived; Inbox deletion does not remove an already-saved Tracker record.

05

Idempotent Save

Implemented

Stable input fingerprints and save state prevent repeated processing from producing multiple records.

07 / Fit Score & Evidence

Fit Score & Evidence

The Fit Score is a configurable prioritization aid. It summarizes how strongly a job description aligns with the candidate profile, required skills, role direction, constraints, and available evidence. It is not an employment prediction or an objective measure of candidate quality.

FIT SCORE / EVIDENCE MODEL / FIG. 03
01Job Description
02Canonical Requirements
03Candidate Profile
04Evidence Matching
05Configurable Rules
06Fit + Explanation + Warnings

Decision support only / Not a hiring probability / Human interpretation required

A configurable prioritization flow that keeps requirements, evidence, gaps, and warnings inspectable.

01

Deterministic Local Fit

Implemented

Configurable YAML rules evaluate role, skill, seniority, work arrangement, responsibilities, and hard-stop conditions.

02

Evidence-Based Fit

Implemented

Normalized requirements are matched to a validated profile and explicit evidence categories, with partial and missing evidence kept distinct.

03

Decision Explanation

Implemented

Overall fit, recommendation, strengths, gaps, evidence sources, limitations, and warnings remain reviewable in the analyzer.

04

Canonical Ingestion Contract

Implemented

Equivalent URL, browser, and pasted inputs share normalized job-description handling and provenance-neutral deterministic scoring.

05

Bilingual Presentation

Implemented

English and Simplified Chinese catalogs cover application navigation, analysis, Inbox, dashboard, and settings workflows.

06

Optional Company-Aware Research

Implemented

An explicit consent-gated OpenAI workflow can add sourced company context without replacing offline scores or running by default.

07

Calibration & Profile Tuning

In Progress

Thresholds, role-family treatment, evidence explanations, and prioritization behavior continue to be refined against deterministic regression cases.

Job Search OS scoring interface showing job-fit score, matched requirements, evidence, and skill gaps.
FIT ANALYSIS

Role-fit analysis combining an overall score, evidence, skill alignment, and identified gaps.

Job Search OS profile page showing structured candidate experience, skills, and supporting evidence.
PROFILE EVIDENCE

Structured candidate profile used as evidence for repeatable job-fit analysis.

08 / Tracker & Persistence

Tracker & Persistence

Draft, Inbox, and Tracker records have distinct lifecycle roles so temporary analysis state does not silently become a permanent application record.

01

SQLite Tracker

Implemented

Saved jobs, deterministic analysis snapshots, status, notes, source metadata, recommendations, and score fields persist locally.

02

Draft Recovery

Implemented

The active analyzer draft survives reruns, language changes, and ordinary interruptions without becoming a Tracker record.

03

Load, Update & Copy

Implemented

Saved jobs can be reopened, intentionally re-analyzed, updated, or copied into a new draft.

04

Archive, Trash & Export

Implemented

Archived and soft-deleted jobs remain distinct, while Markdown, JSON, and filtered dashboard CSV outputs support local review.

05

Local Analytics Dashboard

Implemented

A read-only dashboard summarizes persisted current-state workflow, fit, skills, sources, recommendations, and attention signals without triggering analysis or external calls.

06

Historical Stage Events

Planned

Reliable status-entry history is not yet stored, so the dashboard does not fabricate historical funnel dates.

Job Search OS application tracker showing saved roles, companies, scores, status, and tracking fields.
APPLICATION TRACKER

Centralized tracker for saved roles, fit scores, application status, and follow-up workflow.

Local record lifecycle

  1. 01

    Draft

    Implemented

    Form or imported content under review in the analyzer.

  2. 02

    Inbox

    Implemented

    Browser payload awaiting analysis or a user decision.

  3. 03

    Tracked

    Implemented

    Approved persistent job and analysis record.

  4. 04

    Archived

    Implemented

    Preserved but removed from the default active view.

  5. 05

    Deleted

    Implemented

    Removed from the Inbox or moved to Tracker Trash according to record type.

09 / Duplicate Detection

Duplicate Detection

The same role can arrive through tracking parameters, repeated browser captures, or different source representations, so duplicate protection uses several explicit signals.

01

Canonical URL

Implemented

Normalized source URLs and existing import provenance identify repeated links.

02

ATS & Source Identifier

Implemented

External job IDs are combined with the source platform where available.

03

Content & Metadata

Implemented

Normalized job-description content, company, and title provide another duplicate signal.

04

Repeated Inbox Payload

Implemented

A stable capture payload hash reuses equivalent recent Inbox submissions.

05

Idempotent Analysis & Save

Implemented

Analysis fingerprints and saved-job state keep repeated actions from creating additional records.

06

Cross-Source Semantic Matching

Planned

Broader semantic detection for materially similar reposts remains a future enhancement.

Duplicate protection is intentionally multi-signal rather than perfect. Reposted roles, materially changed descriptions, and inconsistent ATS identifiers can still require human review.

10 / Security & Local-First Design

Security & Local-First Design

The browser extension communicates with a receiver bound to the user’s local machine. Although the integration is local, it accepts structured input from a browser context and therefore uses explicit trust controls.

01

Pairing Token

Implemented

The extension and local receiver share a locally stored, rotatable token. Unauthenticated requests are rejected.

02

Constant-Time Comparison

Implemented

The receiver verifies the supplied token with a constant-time comparison to avoid simple comparison timing differences.

03

Localhost Binding

Implemented

Configuration constrains the receiver to 127.0.0.1 rather than exposing it on all network interfaces.

04

Origin & CORS Controls

Implemented

Only recognized extension origins are allowed; remote web origins and unrestricted cross-origin behavior are rejected.

05

Rate & Payload Limits

Implemented

Sliding-window request limits, JSON-only handling, schema validation, and bounded payload size constrain browser submissions.

06

Minimal Extension Permissions

Implemented

The extension requests active-tab, scripting, local storage, and localhost access without cookies, history, or broad remote hosts.

07

Local-First Storage

Implemented

Descriptions, profile evidence, scores, drafts, and workflow state remain local by default; optional research requires explicit configuration and consent.

Local first reduces exposure, but it does not remove the need for input validation, authentication, backups, dependency maintenance, and safe secret handling.

11 / Human Review Workflow

Human Review Workflow

HUMAN REVIEW / AUTOMATION BOUNDARY / FIG. 04

Automated or Assisted

The system prepares structured material for review.

ImplementedCaptureExtension, URL, or pasted input
ImplementedNormalizeCanonical analysis contract
ImplementedAnalyzeFit, evidence, gaps, warnings
PlannedDraftApplication-material assistance

User Control

The user verifies, decides, and performs final submission.

ImplementedReviewVerify input and analysis
ImplementedDecidePrioritize the role
PlannedVerifyApprove every future draft or field
ImplementedSubmitManual final action

Final submission is outside the automated boundary.

Automation prepares. The user verifies. The user decides. The user submits.
  1. 01

    Automated or Assisted

    Capture

    Import a visible role, submit a supported URL, or paste the job description.

    Implemented
  2. 02

    User Control

    Review Input

    Confirm company, title, location, URL, source, description, confidence, and warnings.

    Implemented
  3. 03

    User Control

    Review Analysis

    Inspect scores, evidence, gaps, requirements, limitations, and hard-stop warnings.

    Implemented
  4. 04

    User Control

    Prioritize

    Use the decision workspace and local dashboard to decide whether the role deserves more effort.

    Implemented
  5. 05

    Automated or Assisted

    Prepare

    Draft a selected role’s résumé emphasis and application answers without inventing evidence.

    Planned
  6. 06

    User Control

    Verify

    Review every generated or eventually prefilled field before it enters an application.

    Planned
  7. 07

    User Control

    Submit Manually

    The user performs the final submission and remains responsible for attestations and application content.

    Implemented

12 / UI Evolution

UI Evolution

The interface evolved with the workflow: from a local scoring form into a multi-page product with evidence review, recoverable state, browser capture, local analytics, and a decision-first analyzer.

  1. Product Stage 01

    Implemented

    Deterministic Local Foundation

    • Streamlit analysis form
    • YAML scoring
    • SQLite persistence
    • Duplicate warnings
    • Local exports

  2. Product Stage 02

    Implemented

    Profile & Evidence

    • Validated candidate profile
    • Evidence categories
    • Requirement matrix
    • Combined application fit

  3. Product Stage 03

    Implemented

    Optional Company Context

    • Consent-gated provider
    • Sourced research
    • Company-aware analysis
    • Cached local snapshots

  4. Product Stage 04A

    Implemented

    Recoverable Input Workflow

    • Persistent drafts
    • Tracker loading
    • Job copying
    • URL import
    • Duplicate-safe save

  5. Product Stage 04B

    Implemented

    Browser Capture & Import Inbox

    • Manifest V3 extension
    • Local receiver
    • Import Inbox
    • Retry / archive / delete
    • Extraction warnings

  6. Product Stage 05A

    Implemented

    Local Workflow Analytics

    • Read-only dashboard
    • Shared filters
    • Current pipeline
    • Fit and skill analysis
    • Attention signals

  7. Product Stage 05A.1

    Implemented

    Decision-First Analyzer

    • Canonical input consistency
    • Decision summary
    • Evidence-led tabs
    • Draft-safe input modes
    • Deterministic résumé emphasis

  8. Current Refinement

    In Progress

    Calibration & Prioritization

    • Source metadata cleanup
    • Score calibration
    • Ranked shortlist workflow
    • Interface simplification

13 / Engineering Decisions

Engineering Decisions

  1. 01

    Local-First Architecture

    Decision
    Keep the core workflow and persistence on the user’s machine.
    Rationale
    Job descriptions, résumé evidence, application drafts, and tracking data are sensitive, while the tool currently serves a single-user workflow.

  2. 02

    Inbox Before Persistence

    Decision
    Place browser imports into a review queue before treating them as permanent Tracker records.
    Rationale
    Extraction errors, duplicates, warnings, and incomplete data should remain visible before persistence.

  3. 03

    Multiple Extraction Strategies

    Decision
    Support structured data, source-specific DOM extraction, conservative generic content, and selected-text fallback.
    Rationale
    Job pages differ across ATS platforms and may change their markup.

  4. 04

    Evidence-Based Scoring

    Decision
    Pair scores with supporting evidence, gaps, and warnings.
    Rationale
    A numerical score without explanation is difficult to trust, calibrate, or correct.

  5. 05

    SQLite Persistence

    Decision
    Use a local relational store for workflow and analysis state.
    Rationale
    SQLite provides durable structured persistence without requiring a remote service.

  6. 06

    Explicit Duplicate Signals

    Decision
    Combine canonical URLs, source identifiers, content, metadata, payload hashes, and existing records.
    Rationale
    No single identifier is reliable across all sources and ingestion paths.

  7. 07

    Manual Submission Boundary

    Decision
    Stop automation before final application submission.
    Rationale
    Application content and legal attestations require direct user review and control.

  8. 08

    Exceptional Company Research

    Decision
    Keep external company research consent-gated and separate from default offline analysis.
    Rationale
    Most roles can be prioritized locally, while deeper research introduces cost, latency, external transmission, and inconsistent availability.

14 / Trade-offs

Trade-offs

  1. 01

    Local Control versus Cross-Device Access

    Local persistence reduces infrastructure complexity and keeps sensitive data close to the user, but it does not provide automatic multi-device synchronization.

  2. 02

    Flexible Extraction versus Maintenance Cost

    Supporting several ATS and fallback methods improves coverage, but page-structure changes require ongoing selector and parser maintenance.

  3. 03

    Explainability versus Scoring Simplicity

    Evidence-based scoring produces more reviewable results, but it requires a richer profile model and more calibration than keyword counting.

  4. 04

    Strict Duplicate Detection versus False Positives

    Aggressive duplicate checks reduce repeated records but may require human review when a company reposts or materially modifies a role.

  5. 05

    Streamlit Speed versus Interface Control

    Streamlit enabled rapid workflow development and testing, while complex product interactions require increasingly deliberate state and interface design.

  6. 06

    Broad Automation versus User Control

    More assistance can reduce repetitive work, but application content and final submission remain deliberate human decision boundaries.

  7. 07

    Company Research Quality versus Cost

    External research can improve context but introduces API cost, latency, and inconsistent availability, so it remains an explicit exception workflow.

15 / Current Capabilities

Current Capabilities

Implemented

  • Capture

    Manifest V3 browser extension, supported public URL import, pasted descriptions, JSON-LD, source-specific DOM extraction, and selected-text fallback.

  • Review

    Import Inbox with provenance, confidence, warnings, duplicate state, retry, archive, delete, offline analysis, and controlled save.

  • Analyze

    Canonical deterministic input, configurable local score, profile-aware evidence score, gaps, warnings, bilingual presentation, and decision workspace.

  • Persist

    SQLite Tracker, draft recovery, saved-job loading, updates, copying, archiving, Trash, analysis history, and local exports.

  • Understand

    Read-only dashboard with filters, current pipeline, fit distributions, skill demand and gaps, sources, attention signals, and safe CSV export.

  • Protect

    Pairing token, constant-time verification, localhost binding, extension-origin controls, rate limiting, payload validation, and idempotent processing.

In Progress

  • Refine

    Source-field cleanup, role-specific score calibration, higher-quality explanations, and ranked-shortlist workflow.

Planned

  • Assist

    Résumé and answer drafts, controlled browser prefilling, historical stage analytics, and additional backup/export controls.

16 / Current Limitations

Current Limitations

  1. 01

    Supported ATS extraction depends on visible page structure and requires maintenance when source markup changes.

  2. 02

    Canonical job-description consistency is implemented, while company, title, location, URL, and questionnaire fields can still contain source-specific noise.

  3. 03

    Fit Score remains a configurable prioritization aid that requires human interpretation, evidence review, and continuing calibration.

  4. 04

    The product is designed for a local single-user workflow without cloud synchronization or multi-user collaboration.

  5. 05

    Batch capture and a complete ranked-shortlist workflow are not yet integrated into one review experience.

  6. 06

    Résumé drafting, application-answer drafting, and controlled browser-field prefilling are not complete product workflows.

  7. 07

    The current dashboard represents current state; the database does not yet provide trustworthy status-entry history for a historical funnel.

  8. 08

    Optional company research depends on explicit consent, an external API, source availability, and local configuration.

  9. 09

    Final application submission remains manual as a deliberate safety and accountability boundary.

17 / Next Improvements

Next Improvements

  1. 01

    Continue normalizing company names, URLs, titles, locations, and source metadata.

  2. 02

    Calibrate fit thresholds and evidence explanations across role families.

  3. 03

    Complete batch import and a reviewable ranked-shortlist workflow.

  4. 04

    Simplify the scoring interface around evidence, gaps, warnings, and decision state.

  5. 05

    Improve company-aware role analysis while keeping it an explicit exception workflow.

  6. 06

    Add résumé-customization drafts for selected high-fit roles using verified evidence only.

  7. 07

    Add application-answer drafting with explicit user review.

  8. 08

    Add controlled browser-field prefilling without automatic submission.

  9. 09

    Expand ATS extraction regression fixtures as source markup changes.

  10. 10

    Add durable status-event history for accurate application-stage analytics.

  11. 11

    Improve backup, restore, and export controls for local workflow data.

18 / Technology Stack

Technology Stack

Application
  • PythonImplemented
  • StreamlitImplemented
Persistence
  • SQLiteImplemented
  • SQLAlchemyImplemented
Scoring & Configuration
  • PythonImplemented
  • PyYAMLImplemented
  • PydanticImplemented
Browser Integration
  • Chrome ExtensionImplemented
  • Manifest V3Implemented
  • JavaScriptImplemented
  • HTML / CSSImplemented
Local Communication
  • FastAPIImplemented
  • UvicornImplemented
  • Pairing TokenImplemented
  • CORS ControlsImplemented
  • Rate LimitingImplemented
Extraction
  • JSON-LDImplemented
  • DOM ParsingImplemented
  • Selected TextImplemented
  • HTTPXImplemented
Testing
  • pytestImplemented
  • Streamlit AppTestImplemented
  • Node test runnerImplemented
Optional Research
  • OpenAI API — Exception workflowImplemented

19 / Lab Navigation

Continue through the systems.

Return to the Product Systems Lab or review the data engineering portfolio.

Back to LabView Data Systems Work