An AI opportunity pipeline with human approval gates

The problem and my role

Repeated discovery creates repeated work. The same role can appear across runs, a previously rejected source can return, and a noisy feed can consume attention and model calls before producing anything worth reviewing. Generating a document for every plausible match compounds that noise.

I designed this workflow around my own search, keeping the decision to pursue an opportunity with me. The public repository shares the architecture and operating documents. The implementation, tracker state, target data, and profile material remain private.

How the documented pipeline works

1. Discover opportunities across Greenhouse, Ashby, and Lever.
2. Compare items with tracker state and history.
3. Apply disqualifiers, suppression, and cooldown rules.
4. Score eligible opportunities against a fixed profile using an LLM.
5. Present candidates for explicit human approval.
6. Generate approved artifacts and report the run’s results.

This case study describes the public architecture snapshot linked below. It does not expose the private system or imply that every setting in the published snapshot represents the latest internal implementation.

Where should approval sit in an AI workflow?

Place approval at the transition from a proposed decision to the action it authorizes. Here, scoring prepares a candidate for review; it does not grant permission to generate the next artifact. A high score or a previously approved source is not a substitute for approval of the current item.

Filter before spending model calls

The documented design applies hard disqualifiers and suppression before LLM scoring. That keeps known exclusions from consuming scoring capacity and prevents a persuasive model output from becoming a reason to ignore a fixed constraint.

Bound discovery as well as scoring

Discovery uses preferred, candidate, and explore lanes. The public snapshot describes caps for the candidate and explore lanes, plus a rolling limit around model calls. Those controls address different sources of noise: how much enters the pipeline and how much scoring work it can perform.

Give generated artifacts stable identities

Artifacts are keyed by source and item family so updates can refresh an existing output. That is useful for repeated runs, but it also makes overwrite behavior a validation concern. “Generate again” needs a clear answer to which existing artifact may change.

Evidence, tradeoffs, and limits

The public repository contains the architecture, pipeline-specific behavioral rules, a review checklist, and a session-start routine. These let a reader inspect the intended constraints and how changes are reviewed. They are documentation evidence, not a public execution trace or independently reproducible benchmark of the private implementation.

The published snapshot also identifies unresolved work: cooldown calibration, changing application forms, duplicate-title handling, artifact overwrite edge cases, and making manually invoked review checks more automatic. Those are useful limits to keep visible when discussing what the architecture demonstrates.

The transferable lesson is to separate eligibility, model judgment, authorization, and output management. Each has a different failure mode and deserves its own check. The project demonstrates that design approach without claiming an employment outcome or a measured return from automation.

Inspect the public architecture

• Architecture, constraints, and documented limitations
• Pipeline operating rules
• Review checklist
• Session-start routine