Question Metadata

Every question carries a set of organizational properties, set when you save it and used by the Question Bank Navigator to filter, sort, and browse your library. They overlap in purpose — all help you find questions later — but each has a different underlying structure, and that structure is what makes it suited to a different job.

Why It Matters

A bank with 50 questions is easy to scroll through by eye. A bank with 5,000 isn't — and that's exactly when these properties start paying off:

• You find the right question in seconds, not minutes — combine a folder with a tag filter (e.g. Algebra folder + difficulty: hard) instead of scrolling through hundreds of unrelated questions.
• Multiple people can work in the same bank without stepping on each other — folders keep each contributor's area separate, while status (Draft/Review/Ready) makes it obvious what's safe to use in a live test and what's still being written.
• Nothing gets lost or duplicated as the bank grows — a clear folder tree plus consistent tags means nobody accidentally writes the same question twice because they couldn't find the existing one.
• You can run a multi-language program from one bank — language tagging lets you filter to just the questions for a given locale instead of maintaining separate banks per language.
• Reporting and audits become possible — tags and folders give you a consistent vocabulary to slice results by (e.g. "how did candidates do on hard Algebra questions specifically"), which a pile of untagged questions can't support.

Which One Should You Use?

Each property's structure isn't arbitrary — it's what makes it suited to a different job:

• Folder — the question's single, structural home. Because it's a tree, it's exclusive and hierarchical: a question lives in exactly one place, which makes bulk actions and scoping natural (export "everything under Math", hand a whole sub-folder to one contributor). Use it when a question belongs to one clear place in a hierarchy — no other property lets you act on a whole branch at once.
• Tags — structured key-value attributes a question can carry several of at once (difficulty: hard, topic: algebra). Because each tag has both a dimension and a value, the navigator can run precise multi-condition queries across dimensions that don't fit a single tree. Use tags when you need combinable filters, like difficulty and topic together.
• Labels — free-form, no-key markers (needs review, exam-ready). Because they're flat strings with no key, they're fast and frictionless — no taxonomy to design up front. Use labels for ad-hoc or temporary flags you want to add and remove without deciding what "dimension" they belong to.
• Language — a single ISO code marking what language the question is written in. Because it's one fixed value from a known list rather than free text, filters and integrations can rely on it without guessing at spelling. Use it only if your bank serves more than one language.
• Status — where a question sits in your team's review workflow (Draft / Review / Ready). Because it's a small ordered set, it models a workflow the way a plain label couldn't — Draft → Review → Ready mirrors how a team actually reviews work. Use it to track progress, not to restrict usage — a Draft question can still be added to a test.

Reach for a folder first when deciding how to organize a new bank — it is the one property every question must have, and getting the tree right early saves a lot of tag cleanup later. As your team grows, see Metadata Rules & Schema to lock folder and tag naming down and prevent drift.

Good to know