For a shorter, non-technical introduction, see the Job Search user guide.
Job Search uses personal search profiles to find, verify, and store listings that match the user's criteria.
A user can create several profiles for different types of work. Each profile can contain:
A profile is eligible for automatic runs only after it contains at least one criterion or instruction and has been enabled.
Job Search keeps one platform-wide automatic schedule for the enabled, configured search profiles. Existing installations remain in the backward-compatible Daily mode unless an administrator changes the cadence.
Administrators can open Platform Jobs at /admin/jobs and choose Service cadence. Job Search can then use either:
If interval mode is selected before any automatic run has been recorded, the first batch is due immediately. A scheduled batch processes the enabled and configured Job Search profiles through the normal Job Search flow. Changing the automatic cadence does not itself start a manual search; administrator Run now actions remain separate.
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.
The instruction helper on the same configuration page shows a visible indeterminate progress bar and elapsed time while AI is working. Because this helper endpoint does not expose a trustworthy provider percentage, the interface does not invent one. The request button is disabled while the request is in flight, and the progress panel ends in an explicit completed or failed state.
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.
The listing surface also accepts a custom free-form negative value through the same profile-scoped save contract; AI suggestions are optional. A custom word or phrase is only persisted after an explicit owner action and uses the same ownership, duplicate protection and audit behavior as an AI suggestion.
A mobile number added or changed for SMS must be verified with a six-digit code sent to that number. Job Search cannot enable SMS notifications or send an SMS test until the saved number is verified. After a real search-criteria change, the profile owner may start a fresh search immediately; an unchanged manual rerun still follows the configured cooldown/daily limit and AI budget. Scheduled/background runs do not consume those owner-interactive limits.
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.
When a profile changes owner, its current profile-scoped inventory follows the profile: saved search criteria, current job_listings, and profile-scoped dismissals are reconciled to the new owner. Historical Job Search runs and audit records keep the owner that actually executed or caused the historical operation, so provenance is not rewritten after a later profile transfer.
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.
For Swedish searches, discovery now follows a bounded source plan instead of relying only on generic web ranking. Platsbanken and LinkedIn Jobs are deliberately covered, and the profile can add relevant source families such as Grona Jobb for green-area work, Offentliga Jobb for public-sector roles, The Hub for technical/startup roles, plus a Swedish general/category board. These sources are discovery priorities, not an allowlist: broad open-web searches and direct employer career pages remain part of the search so useful jobs elsewhere can still be found.
The source plan normally aims for about 3-5 concise discovery queries inside the existing hard limit of eight web-search tool calls, leaving capacity to open and verify promising individual advertisements. A source that is blocked or empty is not retried repeatedly just to satisfy the plan. Generic search/category pages are used only for discovery; stored results still require a canonical individual advertisement URL or direct employer listing and are de-duplicated across sources.
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.
Scheduled background runs are system work for enabled profiles and bypass the interactive per-user Job Search budget and cooldown guards. Provider-side limits still apply: short-lived OpenAI rate limits and transport timeouts are retried with bounded backoff, using the provider's requested retry delay when available. A max_output_tokens incomplete response is retried with lower reasoning effort so the listing payload has room to complete. Permanent authentication and billing/quota failures remain hard failures and are reported instead of being retried indefinitely.
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, safe source-family identifiers actually searched or used, 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.
/job-search/config/profiles groups the most common profile actions into a responsive profile panel. Search now starts the selected profile immediately through the same owner-scoped Job Search run used by other manual requests, so the normal cooldown, daily cap and provider boundaries still apply. Results are persisted through the normal flow and can then be opened on the listings page.
The SMS mobile number can be saved directly on the same page. It remains an account-level destination shared with other Tools features; Job Search does not create a separate phone book. Email and SMS test actions run without navigating away and do not change the saved notification preferences.
The page also links directly to Shop and AI Credits and shows spendable balance when a credit account exists. AI Credits fund Tools AI usage, but purchasing credits does not bypass the Job Search cooldown/daily cap or OpenAI/provider rate limits. The separate entitlement model for additional Job Search capacity remains tracked in #1879.
Notification channels are configured separately for each search profile.
Each profile also has Send test beside email and SMS. The button sends one test message to the signed-in profile owner's current account email address or mobile number. It works independently of the saved channel checkbox, because clicking the button authorizes that one test delivery only. The test does not save notification preferences, start Job Search, create a normal Alert delivery record, or change notification timestamps. The profile ownership check is enforced by the backend, and audit records contain channel/count metadata without recipient addresses or phone numbers.
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.
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 execution path.
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.
Administrators can also open the full profile editor for another user directly from the read-only inspection view. The editor changes that profile in place - keywords, locations, exclusions, relevance rules and instructions - without impersonating the user, transferring ownership or rewriting historical runs. The administrator endpoints are separately authorized and mutations are written to the dedicated Job Search audit trail with actor, target user and profile metadata.
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, the profile's search criteria, current verified listing inventory, and profile-scoped dismissals follow it to the current owner. Historical Job Search runs, dedicated audit rows, and Alert Engine run/result history keep their original user/process provenance rather than being rewritten.
Administrators can open a read-only Job Search inspection for a selected user or profile from the Job Search administrator overview. The inspection shows the selected profile criteria, current listing inventory, historical run provenance and ownership-consistency counts without impersonating the user. Run identifiers link to a run detail view with dedicated Job Search audit events and sanitized provider diagnostics; private prompts, raw provider bodies and credential-like fields are not exposed there.
The inspection also provides explicit Sync ownership actions for a profile or all profiles currently owned by the selected user. Reconciliation is idempotent, moves only current profile-scoped mutable state to the profile owner, is audited, and does not rewrite historical Job Search runs/audits or Alert Engine history.
The administrator overview keeps Job Search execution history paginated at 20 runs per page instead of growing indefinitely.
Job Search can be reached from:
Feedback about Job Search can be sent through the Tools suggestion board. Select Job Search as the service when reporting a poor match, missing source, bug or improvement idea so the feedback is connected directly to the right service.
Job Search keeps web search mandatory, but each provider request is bounded to eight web-search tool calls so one logical run cannot expand into an uncontrolled provider fanout. Scheduled runs use low reasoning effort by default; interactive/manual runs continue to use the configured reasoning level.
The instruction, profile-name and negative-keyword AI helpers use native Responses Structured Outputs. Their JSON shape is enforced by the provider contract instead of relying on prompt wording alone, while the existing access checks, usage accounting and request logging remain in place.