diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
index 3a6e48b0..03f49e01 100644
--- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
+++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
@@ -229,7 +229,7 @@ Postcondition semantics are characterized as follows:
 
 ===Class invariants===
 
-TThe '''separate argument rule''' above tells us that separate calls are valid only on targets which are formal arguments of their enclosing routines. Because class invariants are not routines and therefore have no arguments, separate calls are not allowed in class invariants. 
+The '''separate argument rule''' above tells us that separate calls are valid only on targets which are formal arguments of their enclosing routines. Because class invariants are not routines and therefore have no arguments, separate calls are not allowed in class invariants. 
 
 The semantics of class invariants will be the same as in sequential Eiffel, precisely because invariants must include only non-spearate calls. To put it the terms of SCOOP, the class invariant ensuring the validity of any particular object will be evaluated entirely by the processor handling that object.
 
diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/index.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/index.wiki
new file mode 100644
index 00000000..1fa9c2f9
--- /dev/null
+++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|SCOOP examples]]
+[[Property:weight|0]]
+[[Property:uuid|75ddd9e0-3baf-655a-748f-ea8765a1d06d]]
+The examples for SCOOP that are distributed with EiffelStudio are solutions to classic and not-so-classic concurrency problems.
+
+
+
+