sd/C05/From SRS to Detailed Designs - Data and Logic.md ..
@@ 44,14 44,14 @@
Before the big table, meet two **complete, small** ones. The real data dictionary opens with these — each just two rows, but already carrying the full six-column format (Field / Data type / Format / Description / Example / Validation). The column set itself is the teaching point: every field, however small, gets a type, a format, an example *and* a validation rule. Both tables verbatim:
-
> ## 1. Criteria (`CRITERIA`)
+
> #### 1. Criteria (`CRITERIA`)
| Field | Data type | Format / range | Description | Example | Validation |
| --- | --- | --- | --- | --- | --- |
| `cid` | str | `C` + 2 digits, `C01`–`C10` | Criterion identifier; also keys the rubric filename | `C03` | Must have a matching `data/rubrics/<cid>-rubric.md` |
| `name` | str | ≤ 80 chars | Criterion title from the VCAA rubric heading | `Skills in documenting a software requirements specification` | Non-empty |
-
> ## 2. Band scale (`BANDS`, `BAND_LABELS`)
+
> #### 2. Band scale (`BANDS`, `BAND_LABELS`)
| Field | Data type | Format / range | Description | Example | Validation |
| --- | --- | --- | --- | --- | --- |
@@ 60,7 60,7 @@
That is a complete data dictionary in miniature — you can read it end to end in thirty seconds. Now you are ready for the real thing: §4, the **student record**, the shape that becomes one markdown file per student in Sprint 2. Here is an abbreviated cut — four rows chosen to show the variety the format can carry, each verbatim:
-
> ## 4. Student record (`MOCK_STUDENTS` → one markdown file per student in Sprint 2)
+
> #### 4. Student record (`MOCK_STUDENTS` → one markdown file per student in Sprint 2)
| Field | Data type | Format / range | Description | Example | Validation |
| --- | --- | --- | --- | --- | --- |
@@ 75,7 75,7 @@
So §§1–4 document everything **stored**. The punchline is what comes next: a separate §5 for **derived values** — the things the dictionary deliberately does *not* let you store. The heading is exact:
