The concept map — what this folder must explain
A note on PDSCH cannot stop to explain HARQ, and a note on sounding cannot stop to explain CSI. So every note leans on ideas it does not define — and until they are written down somewhere, that debt is invisible.
This page is the ledger. It lists every concept the notes use, says whether it has actually been explained and where, gives the specification clause it comes from, and — for the ones still owed — says what a note on it would have to cover and which file it belongs in.
In one line. Nothing on this page is typed by hand except the judgements. The widget scans every note for every term on every page load, so the mention counts, the "used in" column and the disagreement warnings are always current.
terms.jsonholds only what a scan cannot work out.
The three states, and what they mean for a reader.
explained — there is a section of its own, in a note that exists, and the link in the table goes straight to it. You can follow it and come back.
partial — it is used and partly explained, but inside another subject's note and from that note's angle only. Good enough to keep reading; not good enough to learn the concept from.
not yet — the notes use it and nothing here defines it. If you hit one of these and are lost, that is the folder's fault, not yours.
There are no not yet entries left, and every concept has a file of its own — true since
26 August 2026, and still true after the core and device layers were added on 28 August 2026,
which brought 46 concepts and three themes with their own pages and reference notes. Each row below
links to term-<name>.md: the definition, the clause, what must be learned first, what it unlocks,
and which notes use it.
The eleven group notes remain as the narrative — they read a group as one argument and link out to the pages. Six on the radio: modulation, the stack, channels, signals, space and system. Five on the rest of the system: the core, sessions, identity, device state and mobility.
That is a floor, not a ceiling. A reference section explains a concept well enough to keep reading; a deep note explains it well enough to work with, the way PDSCH does for the downlink shared channel. The deep notes still to come are on the track page, and when one is written the entry here simply re-points at it.
This page is a map. If you want a road, it is the route.
A map shows the whole shape at once, which is the right thing once you know where you are — but it never says you are here, and it never says now this one. The route takes exactly these concepts, flattens the hierarchy below into one numbered order, and links each entry straight at its own page. Every concept's page then carries its own step number, the two concepts either side of it, and the ones it unlocks a level up, so the walk continues from wherever you happen to be.
Same data, same ordering function — the route is this page's hierarchy read left to right, not a second opinion about it.
What is on this page, in the order it is useful.
1 · The themes — the eleven subjects the folder is made of, each with the concept to start from and the note that develops it.
2 · The hierarchy — what to learn before what, by level, split by theme inside each level.
3 · Worked paths — before X, learn these, for any concept.
4 · Index — A to Z of every concept and every other name it goes by, so a word met in a note can be looked up.
5 · Everything tracked — the full registry: clause, state, level, prerequisites, where it is explained, how often it is used.
6 · What each note assumes — the other direction: given a note, which concepts it leans on.
7 · How this is kept honest — the checks, and how to add a concept.
Everything here has an address, and the addresses are stable. Link at any of them from a note, from the tracker, or from outside the folder:
| To link at | Write |
|---|---|
| one concept's own page | term-pdsch.md#top |
| its row in the registry | terms.md#pdsch — the key from terms.json |
| one level of the hierarchy | terms.md#level-7 |
| one level of the route | learn.md#level-7 — the walkable view of the same level |
| one theme | terms.md#group-signal — grid, stack, channel, signal, coding, mimo, procedure, rf, core, session, ue |
| a letter of the index | terms.md#index-h |
| a section of this page | terms.md#terms-tree, #terms-groups, #terms-paths, #terms-index, #terms-all |
The # beside a level, a theme or a term row is that link, ready to copy. Every concept badge
in the hierarchy, every entry in the index and every prerequisite in a path is itself a link to the
concept's page — nothing on this page is a dead end.
The themes — the eleven subjects
A hierarchy answers what before what. It does not say what the folder is about. Every concept belongs to exactly one theme, and a theme is the unit worth reading in one sitting — which is why the eleven group notes are organised this way too.
The last column is measured, not declared. Whichever note mentions a theme's concepts most is where that theme is really developed, whatever anyone intended.
Where the debt is heaviest
The ordering is the whole point. A concept used ninety times without a definition costs a reader far more than one used twice, so the backlog is sorted by how hard the existing notes already lean on it. The top of this list is what to write next, and it is computed, not chosen.
It is currently empty, which is the intended state — but the widget stays on the page, because the
moment a note starts using a concept that is not in terms.json, or one is added as planned, it
reappears here at the position its usage earns.
The hierarchy — what to learn before what
A list of concepts does not say which to read first. terms.json gives each term its direct
prerequisites, and the widget turns those into a graph: a term's level is the number of ideas
that must be understood in sequence before it.
How to read a level. Level 0 needs nothing — those are the places to start. Level 5 means five ideas stacked one on another come first. Nothing on a level depends on anything else on the same level, so a level can be read in any order; but no level before the one above it.
Inside a level, the concepts are split by theme and ordered by how heavily the
notes already use them. A level is otherwise a bag of unrelated ideas that happen to be equally
deep — level 4 holds a resource block, a modulation scheme and a random-access channel, and reading
them as one line teaches nothing. Each level is linkable as terms.md#level-4, and every term
page's card links straight at its own level.
The level is the longest chain, not the count. PDSCH is level 12 and has 30 prerequisites in total — 12 is how deep the deepest strand goes, 30 is how many concepts it touches.
The graph is checked, not trusted. The widget reports a cycle, a prerequisite naming a term
that does not exist, a term with no needs list at all, and — the pedagogical one — a concept
better explained than something it depends on, which is a hole a reader would fall into while
following the chain downwards.
Worked paths — before X, learn these
The path mode answers the question directly for any term, and takes either a name or a key —
the row in the modes table above shows the syntax. Three worked examples follow; the same
call works for all 118 concepts.
Index — every name, A to Z
A reader does not meet a concept by its registry name. They meet BCCH, or hybrid ARQ, or
BG2, in the middle of a note, and need to know which idea owns that word. This index lists every
concept and every alias the registry knows — the other spellings, and the named members a
concept enumerates — each pointing at the page that explains it.
Everything tracked
The same ideas, in code
The concept map has a second half, and it is not prose. 5G Simulation/ is a from-scratch
NR simulator written from the same specification snapshot as these notes: the notes say what
the standard requires, the simulator says it in code and checks that the arithmetic closes.
The two are joined on the 3GPP clause, and on nothing else. Every concept below carries a clause; every module of the simulator cites the clauses it implements. Neither side declares anything about the other, so neither can go stale — and no edit is needed anywhere when a module starts citing a new clause. It simply appears here, and on that concept's own page, on the next page load.
Two relations are reported and they are not the same claim: exact means a module cites
precisely the clause the concept names, within that it cites a subclause of it. A module
citing a parent clause is deliberately not counted — the step it names is broader than the
concept, and counting it would let a chain that merely walks past a clause claim to implement
everything beneath it. That rule was written after the join caught the simulator's own
chain.py claiming TS 38.211 §7.3.1.4, which is precoding, from a step that only counts
resource elements.
How this is kept honest
The same discipline as the rest of the folder: the widget scans, the JSON judges. Nothing that
can be counted is ever typed into terms.json.
What the widget checks on every page load, and reports in red if it fails:
- A term marked explained or partial must give a
whereof the formfile.md#anchor— and that file must exist and really carry that anchor. Rename a section and the map says so. - A term marked not yet must not give a location.
- Every term in
terms.jsonmust be mentioned by at least one note. A term nothing uses is either a mistake or a concept the folder has quietly dropped. - The reverse direction too: any acronym the notes use three or more times that is not in
terms.jsonis listed as a candidate. The registry cannot fall behind the writing, because the writing reports itself.
Adding a concept
When a note starts using a new idea, add it to terms.json in the same pass — name, full,
group, state, spec, why, and note if it deserves a file of its own. Then declare its other
names, and mind which of the three keys they belong in: aka for another spelling of the same
idea (hybrid ARQ for HARQ), covers for the named members it enumerates (QPSK and 256QAM
are two of the six modulations, not two ways of writing the word), and scan for a word that merely
proves the idea is in play. All three count as a mention; aka and covers are printed on the
concept's card and listed in the index, under labels that say which they are.
When a concept finally gets its section, change state to explained and set where to the
anchor. The link on this page starts working; the backlog gets shorter by one.
When the candidate list shows something that is not a concept — a surname printed in capitals
inside a citation, a node label from a diagram — add it to NOT_CONCEPTS in
../widgets/fiveg_terms.py rather than inventing a term for it.
The modes, if you want this box elsewhere
| Placeholder | Renders |
|---|---|
fiveg_terms |
the whole registry, grouped, with totals and warnings |
fiveg_terms: summary |
one line — counts, and the heaviest unexplained terms |
fiveg_terms: next |
the top six of the backlog, as a card |
fiveg_terms: todo |
the full backlog, with what each note must explain |
fiveg_terms: candidates |
acronyms the notes use that the registry lacks |
fiveg_terms: tree |
the whole hierarchy, by level, split by theme inside each level |
fiveg_terms: route |
the same order, flattened and numbered — the walk on learn.md |
fiveg_terms: step <term> |
one concept's place in that walk — prev, next, progress, and what it unlocks a level up |
fiveg_terms: groups |
the eleven themes — concepts, level span, and the note each is developed in |
fiveg_terms: index |
A to Z of every concept and alias, each linking to its page |
fiveg_terms: path <term> |
before this term, learn these — the full chain in learning order |
fiveg_terms: grid |
one group — also stack, channel, signal, coding, mimo, procedure, rf |
fiveg_terms: used nr-pdsch.md |
the concepts one note leans on, heaviest first — capped at twelve |
fiveg_terms: used nr-pdsch.md all |
the same, uncapped |
What each note assumes
The other direction: given a note, which concepts does it lean on, and how many of them are still undefined? This is the honest reading-difficulty measure — a note that leans on six unexplained ideas is harder than its word count suggests.
Each of these was written to define a group of concepts rather than to explain one subject, so the right measure for them is coverage: how many of the terms they name they also define.
Modulation — the mapper, Gray mapping, normalisation, EVM, polar coding.
The stack — physical layer, MAC, RLC, PDCP, SDAP, RRC, and the seams between them.
Channels — PDCCH, CORESET, search space, RNTI, PBCH, initial access, PRACH, PUCCH, PUSCH.
The backlog in full
Everything not yet explained, with what a note on it has to cover and where it goes.