What is a semantic layer over an LLM API?

A unified data foundation is the translation layer between product data and model context.

It takes raw objects such as users, jobs, applications, companies, saved searches, preferences, and behavioural signals, then turns them into structured context the model can reason with.

The important word is meaning.

A database record tells the system what is stored. A semantic layer tells the model what matters.

Without that layer, every LLM feature becomes a one-off prompt project. One team formats a user one way. Another team formats the same user differently. A third team leaves out the field that explains why the recommendation was shown.

The model is then asked to be consistent while the product feeds it inconsistent context.

That is not a model problem. It is a product architecture problem.

Raw data is not designed for reasoning.

It is designed for storage, retrieval, permissions, reporting, and product behaviour. Those are different jobs.

In a job marketplace, a useful recommendation may depend on many connected signals:

• the job title
• the company
• the location
• the work type
• the salary signal
• the candidate profile
• the candidate's stated preferences
• viewed jobs
• saved jobs
• dismissed jobs
• application history
• freshness
• eligibility
• trust and safety rules

Those signals may live across different systems. Some are explicit. Some are inferred. Some are reliable. Some are stale. Some should never be shown to the model for privacy or trust reasons.

If a prompt pulls directly from raw systems, the prompt becomes the place where business meaning is assembled.

That is fragile.

Prompts are a poor place to hide domain logic.

A useful semantic layer does four things.

1. Translates business objects

It turns raw records into model-readable descriptions.

A job is not just a row in a table. It is an opportunity with a role, employer, location, requirements, application state, market context, and candidate fit signals.

A candidate is not just a profile. They have goals, constraints, history, preferences, and intent that may change over time.

The semantic layer decides how those objects are represented to the model.

2. Normalises context

Different systems often describe the same idea differently.

One system might know about "remote". Another might know about "work from home". Another might record "hybrid" as a location policy.

The model should not have to resolve that every time. The semantic layer should give it a consistent product vocabulary.

3. Enforces rules

The layer decides what context is available, what should be excluded, and what needs to be transformed before it reaches the model.

That includes privacy boundaries, consent rules, product policies, and business constraints.

4. Preserves reasons

If the product needs to explain why something was recommended, the semantic layer needs to preserve the signals behind the recommendation.

Explainability cannot be added at the end. The reasons need to survive the journey from data to model to interface.

This sounds technical. It is not only technical.

The semantic layer determines what the model can know about the user and the domain. That makes it a design decision.

Designers should care because:

• Context shapes output quality. A better prompt cannot fix weak context forever.
• Abstraction choices affect the UX. How the system represents "career direction" changes what the model can say about a person's next move.
• Privacy is part of trust. Which user signals enter the layer is a consent question, not only an implementation detail.
• Explanations need source material. If the layer does not preserve reasons, the interface can only offer generic explanation text.

In job matching work, this matters because the model is not only reading a job record. It is reasoning across role, location, work type, salary signals, application state, and stated preferences.

Those are product meanings.

Design needs to help define them.

A semantic layer does not need to be grand. The useful patterns are practical.

Entity-centric context

Build around business entities, not database tables.

For a marketplace, that might mean:

• Candidate
• Job
• Company
• Application
• Recommendation
• Preference

Each entity should have a standard context shape that any LLM feature can reuse.

Layered context assembly

Assemble context in layers:

1. static entity context
2. dynamic user context
3. session context
4. task-specific context

This keeps the system flexible. A recommendation explanation and a career coaching moment may use the same base candidate context, then add different task context.

Context versioning

Treat semantic representations like API contracts.

If you change how a Candidate is represented to the model, every feature that uses that representation may change too.

Version the context. Test the downstream effects. Do not let meaning drift silently.

Evaluation-driven iteration

Evaluate the semantic layer, not only the final LLM output.

When the output is poor, ask where the problem is:

• Did the model fail?
• Did the prompt fail?
• Did the semantic layer give weak or misleading context?

Changing the model before checking the context is expensive guesswork.

A weak prompt might pass the model a bundle of fields:

job_title: Senior Product Designer
location: Melbourne
work_type: hybrid
candidate_saved_jobs_count: 14
candidate_recent_search: product designer remote

That is data. It is not yet meaning.

A semantic layer might translate it into something closer to product context:

Candidate intent:
- looking for senior product design roles
- has recently shown interest in remote or hybrid work
- has saved multiple roles, suggesting active comparison rather than casual browsing

Job fit:
- role type matches stated and inferred interest
- location is acceptable if hybrid expectations are clear
- missing salary data may reduce confidence

Safe next actions:
- explain why this job was shown
- ask whether hybrid is acceptable
- save the job
- show similar roles

Actions requiring confirmation:
- update candidate preferences
- start an application

That second version gives the model a better job to do.

It also gives the interface better material to work with.

If you are building your first LLM-powered feature, start small.

1. Define the three or four entities that matter most.
2. Write a plain-language description of each entity.
3. Include only the fields that affect the user experience.
4. Remove anything noisy, private, stale, or irrelevant.
5. Test the context by reading it as a smart person with no system knowledge.

That last step is important.

If a person cannot read the context and understand what matters, the model will struggle too.

The first version can be a markdown file, a typed object, or a small service. The format matters less than the discipline.

Do not start by asking, "What should the prompt say?"

Start by asking, "What does the model need to understand?"

The value of a semantic layer is not cleaner architecture for its own sake.

It gives product teams a shared place to define meaning.

That makes AI features easier to improve because teams can change the context, test the effect, and reuse the improvement across multiple surfaces.

It also makes the user experience more trustworthy.

The product can explain what it knows, what it does not know, why something was shown, and what action is safe to take next.

That is the difference between an LLM feature that feels clever in a demo and an AI product that can survive real use.

Richard Simms is Principal Product Designer at SEEK, where he leads design for the Career Discovery Agent and Career Feed. He also builds Sentiuma, a personal AI knowledge infrastructure layer.