diff --git a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki
index bc603f89..d9edb63f 100644
--- a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki
+++ b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki
@@ -38,7 +38,7 @@ In addition to preconditions and postconditions, contract clauses include '''cla
==Expressing assertions==
-Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see [[ET: Other Mechanisms#Instructions|"Instructions"]] ): loop invariants and variants, check instructions.
+Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see "[[ET: Instructions|Instructions]]" ): loop invariants and variants, check instructions.
Here is a partial update of class ACCOUNT with more assertions:
@@ -135,7 +135,7 @@ Note in this respect that guaranteeing a precondition does not necessarily mean,
possibly with an else part. But if the context of the call, in the client's code, implies that n is positive -- perhaps because some preceding call set it to the sum of two squares -- then there is no need for an if or similar construct.
-{{note|In such a case, a check instruction as introduced later ( [[ET: Other Mechanisms#Instructions|"Instructions"]] ) is recommended if the reason for omitting the test is non-trivial. }}
+{{note|In such a case, a check instruction as introduced later ( "[[ET: Instructions|Instructions]]" ) is recommended if the reason for omitting the test is non-trivial. }}
==Using contracts for built-in reliability==