diff --git a/course/en/25-final-project.md b/course/en/25-final-project.md
new file mode 100644
index 0000000..e6d1c95
--- /dev/null
+++ b/course/en/25-final-project.md
@@ -0,0 +1,75 @@
+# Final project: analyze an unknown byte buffer
+
+This project combines the ideas from EduNumbers. You will use representation, byte order, signedness, bit fields, text and structure to explain a synthetic unknown buffer.
+
+## The task
+
+```text
+0000: 45 4E 55 4D 01 A5 0C 00 34 12 FE FF 50 4C 4F 4F
+0010: 53 00 00 00 78 56 34 12
+```
+
+You initially know only that the format was created for this exercise, every field starts on a byte boundary, and the buffer is complete.
+
+## PREDICT
+
+Before calculating, identify regions that look like text, flags or possible little-endian integers. Record hypotheses first.
+
+## STEP — build evidence
+
+The first four bytes decode as ASCII `ENUM`, making them a strong signature candidate.
+
+Byte `0x01` at offset `0x04` is plausible as a version. Byte `0xA5` at `0x05` is `10100101₂`, with bits 7, 5, 2 and 0 set.
+
+Bytes `0C 00` become 12 as little-endian 16-bit, while `34 12` becomes `0x1234 = 4660`.
+
+Bytes `FE FF` become 65534 unsigned or -2 as signed 16-bit two's complement. The bits alone do not specify signedness.
+
+Bytes `50 4C 4F 4F 53 00 00 00` resemble an eight-byte null-padded ASCII field containing `PLOOS`.
+
+Finally, `78 56 34 12` becomes `0x12345678` as little-endian. Multiple consistent fields strengthen the little-endian hypothesis.
+
+## A consistent structure
+
+| Offset | Size | Possible field | Interpretation |
+|---|---:|---|---|
+| 0x00 | 4 | magic | ASCII `ENUM` |
+| 0x04 | 1 | version | 1 |
+| 0x05 | 1 | flags | `0xA5` |
+| 0x06 | 2 | length | 12, little-endian |
+| 0x08 | 2 | id | `0x1234` |
+| 0x0A | 2 | delta | -2 signed |
+| 0x0C | 8 | name | `PLOOS`, null-padded |
+| 0x14 | 4 | value | `0x12345678` |
+
+For this synthetic exercise that is the intended structure. In real reverse engineering, more samples or documentation would be required before treating such a model as established fact.
+
+## Verify with code
+
+```python
+data = bytes.fromhex(
+    "45 4E 55 4D 01 A5 0C 00 34 12 FE FF "
+    "50 4C 4F 4F 53 00 00 00 78 56 34 12"
+)
+
+length = int.from_bytes(data[6:8], "little")
+ident = int.from_bytes(data[8:10], "little")
+delta = int.from_bytes(data[10:12], "little", signed=True)
+value = int.from_bytes(data[20:24], "little")
+
+print(length, ident, delta, hex(value))
+```
+
+Expected output is `12 4660 -2 0x12345678`.
+
+## OBSERVE
+
+The bytes never changed. What changed was the interpretation attached to them.
+
+## EXPLAIN
+
+Numbers and bytes provide values and bit patterns. Radix, signedness, byte order, text encoding and field structure are representation rules that give those patterns meaning.
+
+## Deliverable
+
+Produce an annotated dump, field map, integer calculations, decoded flag bits, signed interpretation, text interpretation, byte-order argument, at least one rejected alternative hypothesis and a small verification program.
diff --git a/course/no/25-sluttprosjekt.md b/course/no/25-sluttprosjekt.md
new file mode 100644
index 0000000..2caa1f3
--- /dev/null
+++ b/course/no/25-sluttprosjekt.md
@@ -0,0 +1,163 @@
+# Sluttprosjekt: analyser en ukjent bytebuffer
+
+Dette prosjektet samler hele EduNumbers. Du skal ikke bare konvertere tall; du skal bruke representasjon, byteorden, signedness, bitfelt, tekst og struktur for å forklare en ukjent buffer.
+
+## Oppgaven
+
+Du får denne syntetiske hex-dumpen:
+
+```text
+0000: 45 4E 55 4D 01 A5 0C 00 34 12 FE FF 50 4C 4F 4F
+0010: 53 00 00 00 78 56 34 12
+```
+
+Du får bare tre sikre opplysninger:
+
+1. formatet er laget for denne oppgaven
+2. alle felt begynner på hele bytegrenser
+3. bufferen er komplett
+
+Resten skal utledes og begrunnes.
+
+## PREDICT
+
+Se på dumpen uten å regne først.
+
+Hvilke områder ser ut som tekst? Hvilke byte kan være flagg? Ser du verdier som kan være little-endian heltall?
+
+Skriv hypotesene før du leser videre.
+
+## STEP 1 — offsets
+
+Dumpen har 24 byte, med offsets `0x00` til `0x17`.
+
+Marker hvert byte med offset. Dette gjør senere hypoteser presise.
+
+## STEP 2 — signatur
+
+De første fire bytene er:
+
+`45 4E 55 4D`
+
+Som ASCII blir dette `ENUM`.
+
+Det er en sterk kandidat til en magic/signatur, men merk ordet **kandidat**: mønsteret alene er ikke matematisk bevis.
+
+## STEP 3 — små felt
+
+Ved offset `0x04` finner vi `01`. Det kan passe som en versjon.
+
+Ved `0x05` finner vi `A5`:
+
+`1010 0101₂`
+
+Hvis dette er et flaggfelt, er bit 7, 5, 2 og 0 satt.
+
+## STEP 4 — lengde
+
+Offset `0x06–0x07` inneholder:
+
+`0C 00`
+
+Som little-endian 16-bit blir dette `0x000C = 12`.
+
+Som big-endian blir det `0x0C00 = 3072`.
+
+Siden bufferen bare er 24 byte, kan 12 være en mer plausibel lokal lengde — men plausibilitet er fortsatt ikke det samme som dokumentasjon.
+
+## STEP 5 — heltall og signedness
+
+Offset `0x08–0x09`:
+
+`34 12`
+
+Little-endian gir `0x1234 = 4660`.
+
+Offset `0x0A–0x0B`:
+
+`FE FF`
+
+Little-endian unsigned gir `65534`. Tolket som signed 16-bit two's complement blir samme bitmønster `-2`.
+
+Dette demonstrerer hvorfor signedness må være del av formatbeskrivelsen.
+
+## STEP 6 — tekst
+
+Offset `0x0C–0x13` er:
+
+`50 4C 4F 4F 53 00 00 00`
+
+ASCII gir `PLOOS` etterfulgt av tre nullbyte. En mulig modell er et fast 8-byte tekstfelt med null-padding.
+
+## STEP 7 — 32-bit verdi
+
+De siste fire bytene:
+
+`78 56 34 12`
+
+Little-endian gir:
+
+`0x12345678`
+
+Nå har vi flere felt som passer samme byteorden. Det styrker hypotesen om little-endian format.
+
+## En mulig struktur
+
+En konsistent modell er:
+
+| Offset | Størrelse | Mulig felt | Tolkning |
+|---|---:|---|---|
+| 0x00 | 4 | magic | ASCII `ENUM` |
+| 0x04 | 1 | version | 1 |
+| 0x05 | 1 | flags | `0xA5` |
+| 0x06 | 2 | length | 12, little-endian |
+| 0x08 | 2 | id | `0x1234` |
+| 0x0A | 2 | delta | -2 signed |
+| 0x0C | 8 | name | `PLOOS`, null-padded |
+| 0x14 | 4 | value | `0x12345678` |
+
+Denne strukturen er fasiten for den syntetiske oppgaven. I ekte reverse engineering ville vi krevd flere observasjoner eller dokumentasjon før vi kalte modellen sikker.
+
+## STEP 8 — verifiser med kode
+
+I Python kan deler av bufferen undersøkes eksplisitt:
+
+```python
+data = bytes.fromhex(
+    "45 4E 55 4D 01 A5 0C 00 34 12 FE FF "
+    "50 4C 4F 4F 53 00 00 00 78 56 34 12"
+)
+
+length = int.from_bytes(data[6:8], "little")
+ident = int.from_bytes(data[8:10], "little")
+delta = int.from_bytes(data[10:12], "little", signed=True)
+value = int.from_bytes(data[20:24], "little")
+
+print(length, ident, delta, hex(value))
+```
+
+Forventet resultat er `12 4660 -2 0x12345678`.
+
+## OBSERVE
+
+Ingen av de viktigste bytefølgene endret seg under analysen. Det som endret seg var **tolkningen** vår.
+
+## EXPLAIN
+
+Kursets hovedidé er nettopp dette: tall og byte er verdier og bitmønstre; base, signedness, byteorden, tekstkoding og feltstruktur er representasjonsregler som gir mønstrene mening.
+
+## Leveranse
+
+Lag en kort analyserapport som inneholder:
+
+- annotert hex-dump
+- foreslått feltkart
+- beregninger for alle heltall
+- flaggbits for `0xA5`
+- forklaring av signed `FE FF`
+- teksttolkning
+- begrunnelse for byteorden
+- minst én alternativ hypotese du vurderte og forkastet
+- et lite program som verifiserer modellen
+
+Når du kan forklare **hvorfor** hver tolkning er rimelig, har du brukt hele EduNumbers som et verktøy.
diff --git a/exercises/no/14-sluttprosjekt.md b/exercises/no/14-sluttprosjekt.md
new file mode 100644
index 0000000..4161fe7
--- /dev/null
+++ b/exercises/no/14-sluttprosjekt.md
@@ -0,0 +1,14 @@
+# Sluttprosjekt — arbeidsark
+
+Bruk bufferen fra kapittel 25 uten å se på feltkartet først.
+
+1. Nummerer alle 24 byte med offset.
+2. Finn alle sammenhengende byte som kan leses som ASCII.
+3. Skriv `0xA5` i binær og list bitene som er satt.
+4. Tolk `0C 00` både little- og big-endian.
+5. Tolk `34 12` som little-endian 16-bit.
+6. Tolk `FE FF` både unsigned og signed 16-bit little-endian.
+7. Tolk `78 56 34 12` som little-endian 32-bit.
+8. Foreslå et feltkart før du sammenligner med kapitlets modell.
+9. Skriv ned minst én alternativ hypotese og hva som taler mot den.
+10. Lag et Python-program som verifiserer minst fire av feltene.
diff --git a/solutions/no/14-sluttprosjekt.md b/solutions/no/14-sluttprosjekt.md
new file mode 100644
index 0000000..135a52e
--- /dev/null
+++ b/solutions/no/14-sluttprosjekt.md
@@ -0,0 +1,12 @@
+# Sluttprosjekt — kontrollpunkter
+
+1. Bufferen dekker offset `0x00` til `0x17`.
+2. `45 4E 55 4D` gir `ENUM`; `50 4C 4F 4F 53` gir `PLOOS`.
+3. `0xA5 = 10100101₂`; bit 7, 5, 2 og 0 er satt.
+4. Little-endian: `0x000C = 12`. Big-endian: `0x0C00 = 3072`.
+5. `0x1234 = 4660`.
+6. Unsigned: 65534. Signed two's complement: -2.
+7. `0x12345678 = 305419896`.
+8. Sammenlign med feltkartet i kapittel 25. Viktigere enn identisk navnsetting er at offset, bredde, byteorden og tolkning er begrunnet.
+9. Et eksempel er å tolke `0C 00` som big-endian 3072. Det passer dårlig som en lokal lengde i en komplett buffer på 24 byte og er mindre konsistent med de andre flerbytefeltene.
+10. Programmet bør bruke eksplisitt byteorden og eksplisitt signedness der det er relevant, slik at representasjonsvalgene er synlige i koden.