Concept · Requisition enrichment pipeline

Every open req, rewritten against its own market.

Today the same body copy ships to every location, so the postings compete with each other instead of ranking. This runs each requisition through local wage and housing data, rewrites it for that market, and emits the structured data Google for Jobs needs.

1 · Pull

Open requisitions from the ATS feed — title, location, pay band, shift.

2 · Enrich

Join to BLS wages, HUD rents, and Census commute for that county.

API
3 · Rewrite

Draft a market-specific body from the req plus the joined data.

LLM
4 · Mark up

Emit JobPosting JSON-LD with salary, location, and validity dates.

Auto
5 · Review

Recruiter approves or edits before publish. Nothing ships unread.

REQ-40118 · updated 2 days ago
Current postingAs published today

Truck Driver

Dot Transportation, Inc. · Bullhead City, AZ

Body copy unique to this locationNo — shared across 14 reqs
Location-specific terms0
JobPosting structured dataMissing
Pay visible to crawlersImage only
After the pipelineDraft for recruiter review

Class A CDL Driver — Bullhead City, AZ

Dot Transportation, Inc. · Mohave County

Body copy unique to this locationYes
Location-specific terms11
JobPosting structured dataComplete
Pay visible to crawlersIn markup + body
Emitted JSON-LD✓ Valid JobPosting · eligible for Google for Jobs

  






  
What it changes

  
Six location pages currently carry the non-branded search traffic for the whole company. This is about widening that, not inventing it.

  

    
Reqs in scope
300+
Across every DC and DTI domicile

    
Human time per req
~4 min
Review and approve, not write

    
Refresh cadence
Weekly
Wage and rent joins re-run on release

  








  Concept mockup for discussion. Requisition copy shown on the left is a paraphrased stand-in for a templated posting, not Dot Foods' actual text. Wage, rent, and commute figures are illustrative placeholders in the shape the live APIs return.