Checkpoint: A Job Is a Candidate for Attention, Not Yet a Recommendation

The first half of career-ops connects two things that are often separated: ownership of career evidence and the cost of discovering opportunities. This checkpoint brings them together to answer a practical question: what has a job actually earned before it consumes full evaluation effort? The answer is not a score or an application decision. It is an inspectable record, a bounded amount of evidence, and a reason to look more closely.

What the discovery gate has earned

A role that reaches this point has passed through more than a search result. It has been normalized into the scanner's job shape, compared against the candidate's configured constraints, and checked against the records that already exist. Depending on the source, the record may include a title, company, URL, location, posting date, compensation, or description. It can then be placed in the pipeline with enough context for a person or a later mode to know what is being considered.

That record has three useful properties. First, it has an owner: it belongs in the user's pipeline and history rather than existing only in a browser tab or a search index. Second, it has an identity: URL normalization and company-role checks reduce the chance that the same opening is treated as a new opportunity every morning. Third, it has an evidence trail: the source path, filtering decision, liveness result, and any warnings can remain visible rather than collapsing into an unexplained yes or no.

None of those properties proves that the job is desirable. They make a later judgment less wasteful and more accountable. A profile and tracker can tell the system that a role is relevant to a target family, but only the full job description can reveal whether the work actually matches the candidate's intended function. A live page can establish that an application path exists, but it cannot establish that the employer's culture or compensation is acceptable. Discovery earns the right to ask better questions; it does not answer them in advance.

This is where the file architecture and the scanner's cost model reinforce each other. If the pipeline were ephemeral, a cheap filter would have to be repeated each time. If discovery were the only record, the candidate could not tell whether a role was removed because it was a duplicate, expired, outside a location rule, or simply uncertain. Durable state turns filtering into a sequence of decisions that can be inspected and corrected.

flowchart LR A["Owned record"] --> B["Deduplicated identity"] B --> C["Liveness result"] C --> D["Warnings and uncertainty"] D --> E["Evaluate"] D --> F["Defer or verify"] D --> G["Stop"]

The gate has three exits because the evidence can support three different actions. A role with an active page and no blocking constraint may deserve evaluation. A role with a transport failure may need verification rather than deletion. A role that is a known duplicate or fails a declared hard location constraint may not deserve more attention.