← Back to docs

Job search

Job search

Job Search uses personal search profiles to find, verify, and store listings that match the user's criteria.

  • Profile path: /job-search/config
  • Verified listings path: /job-search
  • Access: Logged-in users

Search profiles

A user can create several profiles for different types of work. Each profile can contain:

  • Location filters such as city, area, remote work, or country
  • Keywords
  • Negative keywords plus exclusions for companies, domains, or sources
  • Relevance rules
  • Custom instructions

A profile is eligible for automatic runs only after it contains at least one criterion or instruction and has been enabled.

AI profile name suggestions

On /job-search/config, every search profile has an "AI suggestions" button. The helper analyses that profile's saved keywords, locations, instructions, relevance rules, and exclusions and returns short name suggestions.

The helper can only be used for profiles owned by the logged-in user. A suggestion must be selected explicitly before it is placed in the name field, and it is not saved until the user clicks "Rename". The AI helper never renames a profile automatically.

Negative keywords

Negative keywords are used when a role or phrase should not appear in future matches for a specific search profile. On /job-search/config, they can be entered manually under Exclusions by selecting the Keyword type.

On /job-search, listings linked to a search profile also provide an AI - negative keyword action. The helper uses the stored listing fields together with that exact profile's saved search criteria and proposes up to three specific words or short phrases. It must not invent advertisement body text that Tools has not stored.

An AI suggestion never changes the profile automatically. The user must click Add on a selected suggestion before it is saved as a negative keyword in the listing's own profile. Repeating the same save does not create a duplicate. Adding a negative keyword and dismissing the current listing are separate actions.

If a visible listing still matches a saved negative keyword in its title, employer, or location, Job Search shows a "Negativ: ..." badge under the listing title. The match information is retained if the listing is dismissed, but the badge is hidden while dismissed and shown again if the listing is restored. A newly saved AI suggestion that matches the current listing can add the badge immediately without reloading the page.

Older listings without a linked search profile must not silently use another or default profile. The negative-keyword AI action is therefore unavailable for those listings.

Results

New and updated listings are stored under the correct user and search profile. A link is verified before the listing is shown. Previously reported listings are marked so the same result is not treated as new on every run.

Web-search execution and zero-result diagnostics

Job Search keeps the saved profile criteria separate from the machine-output and verification contract when asking the provider to search the web. This prevents schema and verification instructions from becoming the provider's actual web-search query.

Web search remains mandatory. New provider calls use the Responses API's native Structured Outputs contract for the machine-readable listing fields instead of relying on a model-authored Markdown table. The historical Markdown parser remains available only as a compatibility fallback for older stored/provider responses.

A provider HTTP success is not automatically treated as a successful Job Search run. The response must complete normally, use the required web-search tool and produce parsable structured output. Incomplete provider responses fail explicitly rather than becoming an empty result set.

Each run records provider evidence in the dedicated Job Search audit trail, including whether web search was used, exposed search queries/calls, source or citation counts when available, parsed candidate count, provider response state and an evidence state. A run where web search was used but no sources, citations, or parsed candidates were exposed is recorded as a degraded evidence state rather than being indistinguishable from a verified zero-match search. A provider response that does not use mandatory web search fails the run.

Sanitized Job Search audit summaries can also be routed through the shared Alert Engine Slack audit category. These summaries may include provider status, exposed search queries and aggregate evidence counts, but not raw provider bodies, credentials or private prompt content.

Email and SMS

Notification channels are configured separately for each search profile.

  • Email is enabled by default.
  • SMS is disabled by default and must be selected explicitly.
  • SMS can only be enabled when the account has a saved mobile number.
  • A run without genuinely new listings stays quiet for the profile owner.
  • When a run finds genuinely new verified listings, owner delivery is recorded in the shared Alert Engine delivery ledger and is attempted immediately after the run.
  • Failed owner delivery can be retried without rerunning the job search.
  • Email contains the familiar Job Search Markdown table with the new listings.
  • SMS contains the profile name, number of new listings, a short first match, and a link to the listings page.
  • The same result set cannot be sent twice through both the old Job Search path and the shared Alert Engine path.
  • SMS eligibility is checked again when a queued or failed delivery is retried. Turning SMS off or removing the valid mobile number before retry prevents that SMS from being sent.

Email delivery can be disabled centrally by an administrator. The separate administrator report and failure reporting are not affected by the user's profile choices.

Shared Alert Engine

Job Search profiles participate in the shared Tools Alert Engine. This gives Job Search and Web Search Alerts a common run, result, deduplication, owner-delivery, and retry lifecycle while keeping the existing Job Search screens and search schedule unchanged.

  • Each Job Search profile maps to its own owner-scoped Alert Engine record.
  • Job Search still performs the search only once through the normal Job Search flow; Alert Engine records the corresponding run and verified results instead of starting a second search.
  • Profile enable/disable state and email/SMS preferences stay synchronized with the linked alert record.
  • Job Search continues to own its existing schedule; the Web Search Alerts scheduler does not start Job Search runs.
  • Successful new-result email/SMS delivery uses the common Alert Engine delivery ledger. Delivery retries are independent from search execution, so retrying a message does not trigger another search.
  • The existing Job Search email and SMS presentation is preserved even though delivery state is now shared with other Alert Engine providers.
  • Older Job Search delivery timestamps remain synchronized for compatibility and audit history, but they do not form a second sending path.
  • When an administrator assigns a profile to another user, previous run/result history remains scoped to the previous owner. A new owner-scoped Alert Engine record is created for future activity.

Administrator profile management

In the administrator overview, an administrator can rename a configured search profile or assign it to another user. These actions are saved over AJAX and update the row directly without a full page reload. The normal form buttons remain available and still work without JavaScript.

The rename controls also include an "AI suggestions" button. It uses the same profile analysis as the user's own profile list. A suggestion must be selected explicitly before it is placed in the name field, and it is not saved until the administrator clicks "Rename".

When a profile is assigned to another user, its search criteria move with it. Historical runs, listing history, previous dismissals, and Alert Engine history remain with the previous user according to the existing ownership rules.

Administrator run history

The administrator overview keeps Job Search execution history paginated at 20 runs per page instead of growing indefinitely.

  • Run now on a historical row starts that row owner's current/default Job Search profile. It does not replay the historical run or its old profile metadata.
  • Run for all active profiles runs every active, configured profile.
  • Interactive administrator runs show a live progress bar with percentage, elapsed time and the current phase while the same search moves through preparation, web search, result and link verification, and finalization. During a longer provider web-search phase, the status advances when the provider reports real search lifecycle events instead of remaining at the initial provider percentage for the entire request.
  • Provider-phase percentage changes are event-driven. The interface does not invent progress from elapsed time when the provider has not reported a new execution event.
  • Running all profiles shows the same real provider progress mapped into the complete profile group without resetting the overall percentage.
  • The progress display only reads status from the running operation and never starts a second Job Search. Normal form submission remains available as the non-JavaScript fallback.
  • Run actions and run-history pagination update inline over AJAX, while normal POST/redirect navigation remains available without JavaScript.
  • Check all links again applies consistently to both a single-user run and the all-profile action.

Entry points

Job Search can be reached from:

  • Job Search on the Services page
  • Job Search on the profile page
  • Search profiles under /job-search/config
  • The Job Search administrator overview