Retrieval means finding useful source passages before asking a model to answer. Imagine answering homework with an open textbook: first find the right page, then explain what it says.

Our fictional Cedar Academy assistant may use published course material. It must not use another school's drafts or private notes. Start with a source register, a list of documents the app may use.

For each source, record its stable ID, account, title, version, origin and allowed use. A stable ID stays tied to that source. A version identifies an edit. Being allowed to read a document does not automatically mean you may upload it to a model or republish it. Use your own fictional material or suitably licensed content.

An index is a searchable copy of source information. Keep it separate from the register. A withdrawn source must stop appearing in search, cached answers and citation lookups too. Take the account from a verified server session; a browser-supplied account ID is not proof of access.

First complete Build Your First AI API Integration and SQL and Relational Data. Use Node.js 22 or newer; Node 24 is the current long-term support release. Required exercises use local fictional samples and no paid API. One optional embedding step needs your own key.

Save the following as rag-source-register.mjs and run node rag-source-register.mjs.

const register = [
  { id: 'cedar-js', account: 'cedar', version: 1,
    status: 'published', permitted: true, title: 'JavaScript start' },
  { id: 'oak-draft', account: 'oak', version: 1,
    status: 'draft', permitted: true, title: 'Private draft' }
];
const verifiedSession = { account: 'cedar' }; // local fixture only
const usable = register.filter(s => s.account === verifiedSession.account &&
  s.status === 'published' && s.permitted);
console.log(usable.map(s => `${s.id}@${s.version}`));

Expected behavior: The only returned identifier is cedar-js@1. The fixture session is not a production authentication mechanism.

1. Write four original source paragraphs: HTML prerequisites, JavaScript prerequisites, a practice schedule and a course contact policy.
2. Give each a register entry with a stable ID, version, fictional account and permission note.
3. Add an Oak account source with a tempting relevant title.
4. Build a table showing which records can be indexed for each account, and write the expected result before running the filter.
5. Reserve the final 20 minutes to explain your policy in the project README.

Remove the account filter condition and observe the extra record. Restore it, then mark the Cedar source withdrawn. Investigate whether your indexing plan would leave old derived rows searchable, and describe the required invalidation.

Question: Does a correct-looking title prove that a source is permitted?

Answer: No. The application's verified account, source status and documented processing permission determine eligibility.

Question: Can an index replace the source register?

Answer: No. It loses source history and lifecycle decisions unless those are maintained explicitly.

Commit a fictional source register and an authorization matrix. Note in the README that every later stage (search index, cache and citation lookup) must start from eligible source IDs.

Next, you will split each source into sections that keep their location.

PostgreSQL row security. Reviewed 2026-10-07.