Architecture scenarioMedium~10 minRAG & Vector Search / 6 of 18

Interview question

What metadata and provenance would you store in a RAG index?

Designs index records that support filtering, authorization, freshness, citations, diagnosis, and safe reprocessing.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I store a stable chunk ID, document ID, source version, source URI or locator, section path, offsets, content hash, timestamps, language, and the parser, chunker, and embedding versions. Filterable metadata includes tenant, document type, status, and access principals where required. The searchable text and vector are never the only representation of a source.

Full answer below

Practice focus

Practical index schema design beyond vectors and raw text.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A useful RAG record needs enough identity and policy metadata to be governed after ingestion.
I store a stable chunk ID, document ID, source version, source URI or locator, section path, offsets, content hash, timestamps, language, and the parser, chunker, and embedding versions. Filterable metadata includes tenant, document type, status, and access principals where required. The searchable text and vector are never the only representation of a source.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a policy library, effective and expiration dates allow retrieval to exclude superseded material before ranking. Sensitivity and retention metadata control which provider and logs may receive the text, while source offsets support precise citations. I keep fields intentionally typed and filterable instead of packing operational data into an opaque metadata blob.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Metadata has its own contract and migration path because changing field meaning can silently alter authorization or ranking. I distinguish user-visible source labels from internal storage locations and avoid exposing secrets through citations. Provenance records let an operator reconstruct why a chunk existed, which source version it represented, and which pipeline configuration produced it. Reconciliation checks compare the index with the source system so missing updates and orphaned records become measurable defects.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Storing only text and an embedding vector.
Using mutable filenames as the only identity.
Treating access metadata as display-only information.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

A retrieved chunk cannot be traced to one source version.
Expired documents remain eligible for retrieval.
Metadata changes have no migration or validation plan.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which fields must be filterable?
How would you model document versions?
What should a user-facing citation expose?

Continue the section

Next in RAG & Vector Search: Build a retrieval query

Step 7 of 18

How would you build or rewrite a retrieval query for RAG?

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Opening drill

Architecture scenarioMedium~10 minRAG & Vector Search / 6 of 18

Interview question

What metadata and provenance would you store in a RAG index?

Designs index records that support filtering, authorization, freshness, citations, diagnosis, and safe reprocessing.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Practical index schema design beyond vectors and raw text.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A useful RAG record needs enough identity and policy metadata to be governed after ingestion.
I store a stable chunk ID, document ID, source version, source URI or locator, section path, offsets, content hash, timestamps, language, and the parser, chunker, and embedding versions. Filterable metadata includes tenant, document type, status, and access principals where required. The searchable text and vector are never the only representation of a source.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a policy library, effective and expiration dates allow retrieval to exclude superseded material before ranking. Sensitivity and retention metadata control which provider and logs may receive the text, while source offsets support precise citations. I keep fields intentionally typed and filterable instead of packing operational data into an opaque metadata blob.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Metadata has its own contract and migration path because changing field meaning can silently alter authorization or ranking. I distinguish user-visible source labels from internal storage locations and avoid exposing secrets through citations. Provenance records let an operator reconstruct why a chunk existed, which source version it represented, and which pipeline configuration produced it. Reconciliation checks compare the index with the source system so missing updates and orphaned records become measurable defects.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Storing only text and an embedding vector.
Using mutable filenames as the only identity.
Treating access metadata as display-only information.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

A retrieved chunk cannot be traced to one source version.
Expired documents remain eligible for retrieval.
Metadata changes have no migration or validation plan.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Which fields must be filterable?
How would you model document versions?
What should a user-facing citation expose?

Continue the section

Next in RAG & Vector Search: Build a retrieval query

Step 7 of 18

How would you build or rewrite a retrieval query for RAG?

What metadata and provenance would you store in a RAG index?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section

What metadata and provenance would you store in a RAG index?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section