Skip to content
Fito

Knowledge components

The Knowledge area at /knowledge is Fito’s vocabulary: every technology it knows about, and the pieces of knowledge that hang off each one. This page is for anyone who has opened that screen and wants to read it — what the three labels under a technology mean, what a component holds, and what any of it has to do with the score a case gives you.

It doesn’t cover authoring the vocabulary, and it doesn’t cover playing a case. For a case end to end, see Play your first case.

What a knowledge component is

Section titled “What a knowledge component is”

Fito doesn’t model a technology as one block. It splits each one into small, separately addressed pieces called knowledge components, and those components are the vocabulary everything else in the product speaks: a case declares what it teaches as components, the tutor is scoped to the components its case references, and your proficiency is recorded per component.

Every component carries a canonical reference id built from its type, its technology’s slug, and its own slug — concept:javalin.handler, execution-fact:javalin.ctx-json-sets-result-and-content-type, usage-scenario:javalin.serving-a-json-rest-endpoint. That id is what a case pins, what the web app routes on, and what the terminal prints back at you. It appears in code font under the component’s name on its own page.

A published id never changes. Where two components would derive the same slug, the second gets a -2 suffix.

Reads under /knowledge are public, so the whole vocabulary is browsable without an account.

The three component types

Section titled “The three component types”

A technology’s components come in three types. The following table lists them in the order the type tabs use:

Type What it captures Example
Concept Domain vocabulary and the conceptual model. “Idempotence in HTTP”
Usage scenario A goal-oriented pattern for applying the technology. “Implementing an idempotent payment endpoint”
Execution fact A behavioral fact about how the technology works at runtime. “PUT must be idempotent”

The split isn’t cosmetic: it is the distinction between knowing what a term means, knowing how the thing behaves when it runs, and knowing how to reach for it on purpose. A technology page carries a badge and a count per type, and the type tabs — All, Concepts, Usage Scenarios, Execution Facts — narrow the list to one type at a time.

What a component hangs off

Section titled “What a component hangs off”

A component does not attach to a technology directly. It applies to one or more of that technology’s major lines, and every line it applies to belongs to the same technology — which is what lets a single technology slug sit inside the reference id.

Two pages carry that structure:

What a component holds

Section titled “What a component holds”

A component’s content is field-structured, not free prose. A template declares the fields a component of that type must fill — their keys, labels, order, and whether each is a single value or a list — and the component records which template version it was written against. The backend’s seed script loads the templates; there is no editing interface for them.

Each field value is a markdown fragment: paragraphs, emphasis, inline code, lists, blockquotes, tables, and fenced code with a language tag. Raw HTML isn’t allowed, and neither is an H1 — the component’s name holds that level. A heading written inside a field renders demoted, so it nests under the field it sits in.

The fields are what become the titled sections on the component’s page and the entries in its outline. The outline stays at field level: a heading inside a field never appears in it.

Content is generated and community-curated, so the web app sanitizes every fragment before rendering it, and highlights fenced code by the language on the fence.

From a case score to your proficiency

Section titled “From a case score to your proficiency”

This is the part that makes the vocabulary matter rather than decorate.

A case’s rubric is a list of criteria, and each criterion names one knowledge component and the Bloom level it targets for that component. When your work is scored, each criterion gets a score from 0 to 3. A score of 2 or 3 records the criterion’s Bloom level as the proficiency for its component, and a score of 0 or 1 records NOT_ACHIEVED. Proficiency is recorded per knowledge component, never per competence.

The full rule, what NOT_ACHIEVED means beside an unassessed component, and how those records roll up into a competence are all on Bloom levels and proficiency.

What points back at a component

Section titled “What points back at a component”

Two structures reference components, and they are not the same thing. A competence is a standing capability whose elements are each defined by one component. A learning objective is one edge a single case declares about itself.

The Used in cases panel on a component’s page reads the second kind: it lists the published cases that reference the component as a learning objective or as a prerequisite. For the difference, and the test that settles it, see Competences and learning objectives.

What’s next

Section titled “What’s next”