My experience does not fit neatly into one recruiting label—and that is both a strength and a practical job-search problem.

My work spans finance, sales operations, business analysis, business intelligence engineering, data analytics, analytics engineering, semantic layers, and ontology-focused AI research. I have worked across traditional manufacturing, trading, procurement, logistics, cloud computing, and FinTech. The same project can be relevant to several roles, but the language that makes that relevance visible changes with the job.

A finance analytics role may need me to foreground cost allocation and profitability. A sales operations role may care more about pipeline coverage, territory planning, and Salesforce. An analytics engineering role may look for semantic modeling, canonical metrics, and governed data products. Reusing one generic resume would flatten a career whose value comes from connecting these domains.

Chloe Resume Tailor solved the quality problem

I first built Chloe Resume Tailor inside ChatGPT MyGPT. It is a private bilingual assistant using the creator-recommended GPT-5.5 Thinking model. Given a job-description link, it researches the company and role, scores my fit with weighted criteria, recommends whether I should apply, identifies wording changes, and generates a polished targeted English resume and Word version.

The assistant works from a verified Career Project Bank and a resume style guide. It knows, for example, when to emphasize logistics profitability, finance controls, AWS partner sales analytics, workforce planning, or semantic-layer ownership—and it is instructed not to invent experience or mechanically copy proprietary JD language.

But a good assistant still left me with a workflow problem

For one role, the sequence was manageable: open the JD, request the analysis, review the score, inspect the suggested positioning, generate the tailored resume, check the Word file, then complete the application manually. It took roughly 20–30 minutes of continuous attention.

After applying to only a few companies, an entire morning could disappear. The deeper problem was not just elapsed time. I could not comfortably do anything else because every step depended on the previous one and required me to stay in the loop continuously.

The application connected the decisions

I built the BA/DA Job Application Automation to turn those separate interactions into a single reviewable flow. The current version is intentionally limited to Business Analyst and Data Analyst roles because their job descriptions and expected capabilities overlap enough to support one bounded policy, matching, and resume-routing system.

Within that scope, it discovers official Greenhouse roles, applies deterministic eligibility rules, records evidence and reason codes, routes the correct BA or DA resume, and prepares the next decision for me instead of making me shepherd every transition.

The result is not a fully autonomous application bot. I still review the company, approve company-specific additional questions, complete the email verification commonly required by Greenhouse, and handle any step that should not be delegated to software. I also retain control over final submission. But my active time falls below five minutes—and, more importantly, that attention no longer needs to be continuous.

Uncertainty is a product state

A remote label may omit the eligible country. “Occasional travel” may omit the percentage. Compensation may mean base salary, OTE, or total rewards. A system that converts all of those into yes or no is not decisive; it is hiding missing context.

That middle state changed the product. Instead of pretending to know, the system can say what it found, what it could not establish, and why a person must decide. Conservative classification is not a fallback here; it is the trust mechanism.

Personal preferences become testable policy

“Find good roles for me” sounds intuitive to a person and is unusable as a product requirement. I had to turn preferences into explicit, versioned policy.

Once the policy became code, it also became testable. Boundary cases—90% remote, a six-month contract, a salary exactly at the threshold, a changed resume hash—could be named and verified. The product no longer depended on a vague prompt remembering my preferences.

Trust needs provenance, not just a score

A match score cannot tell me whether a decision came from the title, location, salary, authorization language, or a missing fact. Each evaluation therefore stores a status, reason codes, evidence quotes, the rule version, and a timestamped audit event.

This makes a decision inspectable and reproducible. If I later change a threshold, I can distinguish a new policy from a silently changed model judgment. The local SQLite database becomes the system of record; the dashboard and reports are only views of the same history.

The action boundary should be designed first

Every future submission path must pass one centralized gate. Shadow mode and a global kill switch prevent unapproved action. Non-passing rules, unanswered company-specific questions, Greenhouse email verification, CAPTCHA or MFA, missing human confirmation, and the daily cap each create an explicit stop reason. In the current MVP, no live submitter can bypass that review boundary.

A small architecture with explicit responsibilities

I kept the application dependency-free and separated discovery, policy, application preparation, storage, notifications, and reporting. This makes the boundaries visible: a connector can discover a job, but it cannot change a policy decision; a report can explain history, but it cannot submit an application.

Reports turn automation into a reviewable history

The workflow should not disappear after it runs. Every evaluated job is stored in the local SQLite system of record with its decision, evidence, reason codes, and rule version. Reports then translate that history into formats I can actually review.

Reports also make silence meaningful. A skipped role is not simply absent; it has a reason. A repeated job is recognized through historical identifiers. A change in policy is visible through its rule version. The result is not merely a list of applications, but a trace of how each decision was made.

Building this product changed my definition of automation. The goal is not zero human involvement. It is to make human involvement brief, well-timed, and consequential.

Chloe Resume Tailor helps me express a complex career accurately for one role. The application helps me carry that quality through a repeatable workflow. Together they save time without trading away context, consent, or accountability.