How does it know this is learning content?

You tell it, with one field on the request. That is enough for it to be read for the things courses contain rather than the things a support ticket holds — and getting that field wrong is the most common reason a first load reads oddly.

What about assessments and answer keys?

Be careful here, and treat it as a tenancy decision rather than a content one. Anything you ingest becomes searchable to anyone with a search key for that workspace. If assessment material must not surface to learners, put it in a separate workspace with its own keys — a workspace is a hard boundary, whereas a filter is something someone will eventually forget to apply.

Does it work across languages?

A workspace has one content language, set at creation and frozen once the workspace holds a document. Multilingual libraries therefore mean one workspace per language today, which also keeps the entity vocabulary from mixing.

How large a library can it hold?

The plans go to hundreds of thousands of documents and the architecture is built for corpora in the millions. Graph extraction is paid once per document, not every month, so the cost of a large library sits in the initial backfill rather than recurring.

Can we see what learners are asking?

Yes, and it is often the most immediately useful thing here. Every search is kept with its query, its origin and its answer — so the gap analysis writes itself: the questions your library keeps failing to answer are the ones sitting in the history with a refusal next to them.

For learning and enablement teams

Your learners ask across the whole library. Your search answers one course at a time.

A question rarely lives inside one module. GRaaS reads the whole library at once and answers with the specific lessons behind it.

Book a demo Start free

Why a library specifically

Four things a course search cannot do for you.

The answer is spread across the library — and outside it
A learner asks one question; the answer lives in a concept from course one, a procedure from course four, and often in something that is not a course at all — what they have actually completed, or what their organisation is licensed for. That is the exact shape a graph is for.
Courses repeat themselves differently
The same concept is taught three ways for three audiences. Those become one thing rather than three near-duplicates, so asking about it finds all three treatments instead of whichever one worded it closest to the question.
Vocabulary is the curriculum
A learning organisation already has a taxonomy it cares about — competencies, objectives, prerequisites. A versioned ontology is where that taxonomy lives, and drift tells you when the content has moved past it.
Citations have to land on a lesson
An answer nobody can trace back to a specific module is worse than no answer in an education setting. Every citation resolves to a document you supplied, with your own identifier on it.

Across modules

One question, three lessons, one cited answer.

The question

Do I need to finish the security module before the deployment lab?

Two documents each hold half of it. Neither one contains the answer.

Learners should be comfortable configuring role-based access before attempting the lab exercises in section three.
Deployment Lab — Prerequisites

This module covers role-based access control, including how to scope a service credential to a single environment.
Security Fundamentals — Module 2

The fact the graph holds

Deployment Lab —prerequisite_for→ Role-based access control (confidence 0.91, 2 sources)

The answer

Yes — the deployment lab expects familiarity with role-based access control [1], which is taught in module two of Security Fundamentals [2]. Nothing else in the security course is listed as a prerequisite.

Neither course names the other. The prerequisite relationship exists because a concept appears on both sides of it — which is precisely the thing a per-course search cannot see.

Read as learning content

A lesson is not read the same way as a support ticket.

Tell us a document is course material and it is read for the things courses contain, rather than for the things a support ticket does.

It costs you one field on the request. The same text sent as a ticket would be read as a ticket, which is the correct reading of a ticket and the wrong reading of a module.

Then you curate from there: take a copy of the vocabulary it built, fold the six things your content calls a competency into one term, drop the ones nobody uses, and see exactly how much of your library each change would affect before any of it takes effect.

ingesting a lesson

POST /v1/ingest
{
  "sourceSlug": "course-library",
  "externalId": "sec-fundamentals-m2",
  "title": "Security Fundamentals — Module 2",
  "textContent": "This module covers role-based..."
}

# 202 Accepted
# { "status": "extracting", "chunksCreated": 3,
#   "statusUrl": "/v1/ingest/.../status" }

The part nobody expects

The questions it cannot answer are a content roadmap.

Because refusal is a real outcome rather than a hallucination, the search history accumulates a list of questions your library genuinely does not cover — each one with the exact wording a learner used. That is a content roadmap that nobody had to run a survey to produce.

Corpus health adds the other half: how many concepts bridge two or more of your sources. A course library where nothing bridges is a set of silos with a search box on top, and that number tells you so.

FAQ

Frequently asked

Point it at one course and see.

Fourteen days on the graph tier with no card, and 2,500 documents — more than enough to put a real library section through it.

no card required
first workspace is free
one POST to ingest

Talk to us Start free