diff --git a/documentation/src/main/asciidoc/introduction/Advanced.adoc b/documentation/src/main/asciidoc/introduction/Advanced.adoc
index db28b95d28..4472fc8764 100644
--- a/documentation/src/main/asciidoc/introduction/Advanced.adoc
+++ b/documentation/src/main/asciidoc/introduction/Advanced.adoc
@@ -53,7 +53,7 @@ Any entity or collection which is affected by a filter must be annotated `@Filte
 [source,java]
 ----
 @Entity
-@Filter(name = "ByRegion")
+@Filter(name = example_.BY_REGION)
 class User {
 
     @Id String username;
@@ -64,13 +64,15 @@ class User {
 }
 ----
 
+Here, as usual, `example_.BY_REGION` is generated by the Metamodel Generator, and is just a constant with the value `"ByRegion"`.
+
 If the `@Filter` annotation does not explicitly specify a restriction, the default restriction given by the `@FilterDef` will be applied to the entity.
 But an entity is free to override the default condition.
 
 [source,java]
 ----
 @Entity
-@Filter(name = "ByRegion", condition = "name = :region")
+@Filter(name = example_.FILTER_BY_REGION, condition = "name = :region")
 class Region {
 
     @Id String name;
@@ -97,7 +99,7 @@ You should do this right at the _start_ of the session.
 [source,java]
 ----
 sessionFactory.inTransaction(session -> {
-    session.enableFilter("ByRegion")
+    session.enableFilter(example_.FILTER_BY_REGION)
         .setParameter("region", "es")
         .validate();
 
@@ -812,11 +814,11 @@ class Book {
     ...
 
     @ManyToOne(fetch = LAZY)
-    @FetchProfileOverride(profile = "EagerBook", mode = JOIN)
+    @FetchProfileOverride(profile = Book_.PROFILE_EAGER_BOOK, mode = JOIN)
     Publisher publisher;
 
     @ManyToMany
-    @FetchProfileOverride(profile = "EagerBook", mode = JOIN)
+    @FetchProfileOverride(profile = Book_.PROFILE_EAGER_BOOK, mode = JOIN)
     Set<Author> authors;
 
 	...
@@ -829,13 +831,15 @@ class Author {
     ...
 
     @OneToOne
-    @FetchProfileOverride(profile = "EagerBook", mode = JOIN)
+    @FetchProfileOverride(profile = Book_.PROFILE_EAGER_BOOK, mode = JOIN)
     Person person;
 
     ...
 }
 ----
 
+Here, once again, `Book_.PROFILE_EAGER_BOOK` is generated by the Metamodel Generator, and is just a constant with the value `"EagerBook"`.
+
 For collections, we may even request subselect fetching:
 
 [source,java]
@@ -847,12 +851,13 @@ class Book {
     ...
 
     @OneToOne
-    @FetchProfileOverride(profile = "EagerBook", mode = JOIN)
+    @FetchProfileOverride(profile = Book_.PROFILE_EAGER_BOOK, mode = JOIN)
     Person person;
 
     @ManyToMany
-    @FetchProfileOverride(profile = "EagerBook", mode = JOIN)
-    @FetchProfileOverride(profile = "BookWithAuthorsBySubselect", mode = SUBSELECT)
+    @FetchProfileOverride(profile = Book_.PROFILE_EAGER_BOOK, mode = JOIN)
+    @FetchProfileOverride(profile = Book_.BOOK_WITH_AUTHORS_BY_SUBSELECT,
+                          mode = SUBSELECT)
     Set<Author> authors;
 
 	...
@@ -879,8 +884,6 @@ session.enableFetchProfile(Book_.PROFILE_EAGER_BOOK);
 Book eagerBook = session.find(Book.class, bookId);
 ----
 
-Here, once again, `BookQueries_.PROFILE_EAGER_BOOK` is generated by the Metamodel Generator, and is just a constant with the value `"EagerBook"`.
-
 So why or when might we prefer named fetch profiles to entity graphs?
 Well, it's really hard to say.
 It's nice that this feature _exists_, and if you love it, that's great.