diff --git a/meetings/2024-11-19.md b/meetings/2024-11-19.md
index fc1377c54be3a03a7f8ea9bc3f43616d3da8ef6e..b74b17dfc9bad316ab4e575f303173b543fa79bb 100644
--- a/meetings/2024-11-19.md
+++ b/meetings/2024-11-19.md
@@ -41,17 +41,17 @@ A combination of various strategies is probable:
 * Break compatibility and rely on existing language tags.
 * Provide tool for automatic conversion.
 
-# Coding style
+## Coding style
 
 We should extend the ruleset for coding style of TTCN-3 examples (and conformance tests).
 
-# Templates
+### Templates
 
 Refining templates pose a big challenge for backward compatibility, but also
 many opportunities for simplification. We discussed several ideas without going
 too much into detail during this session:
 
-## Template Evaluation
+#### Template Evaluation
 
 Various evaluation strategies for templates are required. However, the current
 approach of lazy, fuzzy, var, const or parameterized templates is neither
@@ -96,14 +96,14 @@ template Point t := function (integer p) return Point {
 Details need to be worked out in future discussions.
 
 
-## Special Template Symbols
+#### Special Template Symbols
 
 `all from`, `permutation`, `complement`, `subset`, `superset`, ..., do not need
 to be part of the core language. They could be implemented as library
 functions, as language extensions or even by user-defined dynamic matching.
 
 
-## Inline Templates
+#### Inline Templates
 
 Inline templates consist of an optional type annotation part and a template literal.
 A dedicated notion for inline templates is not necessary, as they type
@@ -111,17 +111,17 @@ annotations could be promoted to a type-conversion operator and template
 literals are already part of the language.
 
 
-## Modified Templates
+#### Modified Templates
 
 Modified template and modified inline template syntax might be unified and simplified.
 
 
-## List Templates
+#### List Templates
 
 See [List Types](#list-types).
 
 
-## Differentiation of Values and template values
+#### Differentiation of Values and template values
 
 Differencing between value and template value complicates the language and its specification.
 
@@ -141,7 +141,7 @@ This could also improve on compiler-pleasing through `valueof` and on
 operations such as `omit`, `present`, ...
 
 
-# Type System
+### Type System
 
 We discussed several aspects of the type system to identify opportunities for
 simplification:
@@ -164,7 +164,7 @@ simplification:
   variables, ...).
 
 
-## List Types
+#### List Types
 
 Semantics of list types need harmonization and simplification.
 
@@ -223,7 +223,7 @@ c := c & {3,4};                     // lengthof(c) == ?
 ```
 
 
-## Language Features
+### Language Features
 
 Procedure based communication might be moved to an extension document.
 
@@ -253,7 +253,7 @@ Attributes might be simplified:
   * multiple encodings is complicated and could be removed
 
 
-## Module organization
+### Module organization
 
 `import` will be simplified if possible.  
 This would make `group` superfluous. However groups are used to structure
@@ -265,14 +265,14 @@ seldom. It's used primarily by framework developers. Possible improvements need
 further discussion.
 
 
-## TCI/TRI/xTRI
+### TCI/TRI/xTRI
 
 Might be merged into a single document. Language mappings for C and Java will
 become non-normative, the other language mappings will be removed.
 
 The future for mappings of XML to TLI needs further discussion.
 
-## Extensions
+### Extensions
 
 Language features that were neither removed nor moved into the core, will
 probably be merged into a common extensions document.