Turn job postings into structured data

Mission

Help a learner turn job text into trustworthy inputs without building Dataaxy-scale job ingestion or matching infrastructure.

Product boundary

This module teaches extraction from a user-provided job description. It does not cover scraping, enrichment pipelines, ranking, deduplication, or internal Dataaxy job-quality signals.

Before you start

The response contract and evidence rules created in module 1
Basic ability to read a JSON object; no programming is required
Three job postings for the independent exercise, provided manually
A place to save the schema and examples, such as a repository or public gist

Objective

Create a stable data card that turns one messy job description into evidence the role-fit assistant can safely use.

Primary source

Use the schema principles in this guide to make extraction predictable. The lesson applies them conceptually; no API integration is required yet.

OpenAI Structured Outputs Guide

Why structure matters

LLM output becomes more useful when the downstream product expects a shape. Instead of asking for a long free-form summary, ask for a record your application can display, compare, and test.

A clean extraction schema is also a portfolio asset. It shows that you can turn ambiguous text into product-ready data.

The goal is not to recreate a production job-ingestion system. The goal is to make a small, inspectable data card that supports one assistant response.

Role family and title
Seniority level
Required skills and tools
Core responsibilities
Evidence quotes from the posting
Uncertainty markers when the posting is vague

Keep the first schema small

Do not model the entire labor market in the first pass. Pick fields that directly support the assistant: evidence comparison, gap analysis, and candidate preparation.

A smaller schema is easier to debug and easier to explain in a portfolio walkthrough.

Use a data card instead of a database

For a learning project, a data card is enough. It is a single structured object that explains how the assistant understood the role. It can live in a JSON file, a notebook cell, or a small fixture.

That constraint is healthy. It keeps the learner focused on extraction quality and prevents the lesson from drifting into job-board infrastructure.

Good portfolio scope: one job description in, one data card out
Out of scope: crawling, deduplication, ranking, alerts, recruiter dashboards
Quality signal: every extracted claim has text evidence or an uncertainty marker

Make uncertainty explicit

Use three confidence states. Explicit means the posting states the value directly. Inferred means the text strongly suggests the value but leaves room for interpretation. Unknown means the posting does not provide enough evidence.

A missing quote can never become a must-have. Keep the field unknown or move the ambiguity into open_questions so a human can resolve it.

This policy makes the data card trustworthy because readers can separate source facts from model interpretation.

Explicit: the value and its evidence appear directly in the posting
Inferred: the value is plausible, but the evidence is indirect
Unknown: the source does not support a reliable value
Open question: the missing information becomes a concrete follow-up

Common mistakes

The common failure is pretending the model knows more than the job description says. If the posting does not mention remote policy, salary, or seniority, the assistant should say so.

Another failure is mixing extraction with recommendation. First produce the data card. Then let the assistant reason over it in a separate step.

Do not infer salary from title alone
Do not convert every nice-to-have into a must-have
Do not score candidate fit inside the extraction step
Do not include platform-ranking fields in the public lesson

Worked example

Build an evidence-backed data card

The same fictional Nordwind posting now becomes a structured input. Every important classification keeps its source quote and confidence state.

Relevant source excerpts

"You will model mobility and revenue data in BigQuery."
"You will maintain dbt projects and document core metrics."
"You will partner with analysts and engineers."
"You will improve data quality checks and contribute to orchestration workflows."
"Advanced SQL and hands-on dbt experience are required."
"Experience with Airflow or a similar orchestration tool is valuable."
"Python is a plus."
"You bring a senior mindset."
"German is nice to have."
"We are a hybrid-friendly team based in Berlin."

Candidate context carried forward from module 1

Amina remains the learner-facing use case, but her evidence is not mixed into the job data card. The assistant will compare the two sources in a separate step.

Amina K. — Data Analyst, 3 years
- Uses SQL in BigQuery every day
- Builds Looker dashboards for product teams
- Maintains a personal dbt project in a public repository
- Uses pandas for small Python scripts
- Has not used an orchestration tool in production

Evidence-backed role-fit data card

{
  "role": {
    "title": "Analytics Engineer",
    "family": "analytics_engineering",
    "confidence": "explicit",
    "evidence": "Analytics Engineer — Nordwind Mobility"
  },
  "must_have": [
    {
      "skill": "Advanced SQL",
      "confidence": "explicit",
      "evidence": "Advanced SQL and hands-on dbt experience are required."
    },
    {
      "skill": "dbt",
      "confidence": "explicit",
      "evidence": "Advanced SQL and hands-on dbt experience are required."
    }
  ],
  "nice_to_have": [
    {
      "skill": "Airflow or similar orchestration",
      "confidence": "explicit",
      "evidence": "Experience with Airflow or a similar orchestration tool is valuable."
    },
    {
      "skill": "Python",
      "confidence": "explicit",
      "evidence": "Python is a plus."
    },
    {
      "skill": "German",
      "confidence": "explicit",
      "evidence": "German is nice to have."
    }
  ],
  "responsibilities": [
    {
      "work_type": "data_modeling",
      "summary": "Model mobility and revenue data in BigQuery",
      "confidence": "explicit",
      "evidence": "You will model mobility and revenue data in BigQuery."
    },
    {
      "work_type": "analytics_engineering",
      "summary": "Maintain dbt projects and document core metrics",
      "confidence": "explicit",
      "evidence": "You will maintain dbt projects and document core metrics."
    },
    {
      "work_type": "collaboration",
      "summary": "Partner with analysts and engineers",
      "confidence": "explicit",
      "evidence": "You will partner with analysts and engineers."
    }
  ],
  "seniority": {
    "value": null,
    "confidence": "unknown",
    "evidence": "You bring a senior mindset."
  },
  "work_location": {
    "value": "Berlin hybrid",
    "confidence": "inferred",
    "evidence": "We are a hybrid-friendly team based in Berlin."
  },
  "open_questions": [
    "How many office days does hybrid-friendly mean?",
    "What ownership or experience demonstrates a senior mindset?",
    "What is the salary range?"
  ],
  "excluded_fields": [
    {
      "field": "fit_score",
      "reason": "The posting does not define a defensible scoring model."
    },
    {
      "field": "job_ranking",
      "reason": "This card describes one manually provided role only."
    }
  ]
}

Bad card with observable failures

{
  "seniority": "Senior",
  "salary_estimate": "€85,000",
  "must_have": ["SQL", "dbt", "Airflow", "Python"],
  "fit_score": 82,
  "_problems": [
    "Senior was inferred from a vague mindset phrase.",
    "The posting contains no salary evidence.",
    "Airflow and Python were promoted from valuable/plus to mandatory.",
    "The fit score has no defined inputs, weights, or evidence."
  ]
}

Role-fit data card fields

Role title and role family
Seniority and confidence level
Must-have skills with evidence quotes
Nice-to-have skills with evidence quotes
Responsibilities grouped by work type
Uncertain or missing information
Fields intentionally excluded from the portfolio project

Retrieval practice

Answer before you continue

Which fields should come directly from the job text?
How should the assistant mark uncertainty instead of guessing?
Which extraction fields would be too close to Dataaxy proprietary matching logic?

Exercise

Design a JSON-like role-fit data card, test it against three public AI or data job descriptions, and mark uncertain fields explicitly.

Create three role-fit data cards

Choose three public job descriptions from different data or AI roles. Convert each one into the same data card and compare the uncertain fields.

Copy the job title, company, and role description into a plain text sample
Extract must-have skills only when the job text gives evidence
Separate responsibilities from requirements
Mark seniority as explicit, inferred, or unknown
Write one sentence explaining what the data card leaves out

Reveal the feedback checklist

Every important field is backed by a quote or marked uncertain
The schema works on all three job descriptions
The output is useful to the role-fit assistant from module 1
The excluded fields protect Dataaxy-level matching and marketplace logic

Reveal the expected artifact

A reusable schema contract and three reviewed examples

Submit the schema contract first, followed by three data cards that use the same fields. The sample below shows the minimum contract, not a production database.

Schema contract

{
  "role": {
    "title": "string",
    "family": "string | null",
    "confidence": "explicit | inferred | unknown",
    "evidence": "string | null"
  },
  "must_have": [
    {
      "skill": "string",
      "confidence": "explicit",
      "evidence": "string"
    }
  ],
  "nice_to_have": [
    {
      "skill": "string",
      "confidence": "explicit | inferred",
      "evidence": "string"
    }
  ],
  "responsibilities": [
    {
      "work_type": "string",
      "summary": "string",
      "confidence": "explicit | inferred",
      "evidence": "string"
    }
  ],
  "seniority": {
    "value": "string | null",
    "confidence": "explicit | inferred | unknown",
    "evidence": "string | null"
  },
  "work_location": {
    "value": "string | null",
    "confidence": "explicit | inferred | unknown",
    "evidence": "string | null"
  },
  "open_questions": ["string"],
  "excluded_fields": [
    {
      "field": "string",
      "reason": "string"
    }
  ]
}

Submission checklist

- [ ] The same schema is used for three different postings.
- [ ] Every must-have includes a direct quote.
- [ ] Responsibilities are separated from requirements and retain their evidence.
- [ ] Each uncertain field is explicit, inferred, or unknown.
- [ ] Open questions turn missing information into next actions.
- [ ] No fit percentage, ranking field, or scraped dataset is included.
- [ ] One bad card explains at least three observable failures.

Review rubric

Review the data cards before continuing

Review the data cards before continuing
Criterion	Strong	Weak
Requirement evidence	Every must-have points to a direct quote that uses mandatory language.	Nice-to-haves or assumptions are promoted to requirements without evidence.
Uncertainty	Each ambiguous field is marked explicit, inferred, or unknown.	Missing seniority, salary, or location details are silently invented.
Schema stability	The same compact schema works across all three job postings.	Fields change from example to example or try to model the entire labor market.
Next actions	Open questions make missing information easy to investigate or ask about.	Unknown information is hidden or presented as a confident conclusion.
Product boundary	The card supports evidence comparison without fit scores, ranking, or scraping.	The artifact drifts into proprietary matching logic or job-board infrastructure.

Artifact to ship

Role-fit data card schema and three reviewed examples

Ship it in GitHub

Continue in the GitHub starter

Use the public Dataaxy template to keep your prompt, schema, examples, rubric, and project checklist in one recruiter-readable repository.

Open the portfolio starter kit

Ask for feedback

If you are working with an AI coach or mentor, ask it to review your artifact against the checklist before moving to the next module.