diff --git a/documentation/src/main/paradox/deployer.md b/documentation/src/main/paradox/deployer.md
index 832521d..e1d416c 100644
--- a/documentation/src/main/paradox/deployer.md
+++ b/documentation/src/main/paradox/deployer.md
@@ -21,7 +21,7 @@ trait Deployer {
 
  - `F[_]`: abstract effectful context `F` encapsulating all values, e.g. `IO[*]`
  - `Alg[_[_]]`: algebra allowing interaction with the entity, e.g. @github[BookingAlg\[IO\[*\]\]](/example/src/main/scala/endless/example/algebra/BookingAlg.scala)
- - `RepositoryAlg[_[_]]`: repository algebra, e.g. @github[BookingRepositoryAlg\[IO\[*\]\]](/example/src/main/scala/endless/example/repository/BookingRepositoryAlg.scala)
+ - `RepositoryAlg[_[_]]`: repository algebra, e.g. @github[BookingsAlg\[IO\[*\]\]](/example/src/main/scala/endless/example/algebra/BookingsAlg.scala)
  - `ID`: entity ID, e.g.  `final case class BookingID(id: UUID) extends AnyVal`
  - `S`: entity state, e.g. @github[Booking](/example/src/main/scala/endless/example/data/Booking.scala)
  - `E`: entity event, e.g. @github[BookingEvent](/example/src/main/scala/endless/example/data/BookingEvent.scala)
diff --git a/documentation/src/main/paradox/effector.md b/documentation/src/main/paradox/effector.md
index 02bf5b5..760aad3 100644
--- a/documentation/src/main/paradox/effector.md
+++ b/documentation/src/main/paradox/effector.md
@@ -32,7 +32,7 @@ An effective alternative to using a projection is to track process completion in
 
 By enabling [*remember-entities*](https://pekko.apache.org/docs/pekko/current/typed/cluster-sharding.html#remembering-entities), we can achieve guaranteed *at-least-once* completion of asynchronous processes thanks to effector running right after recovery (thus withstanding node crash or shard rebalancing).
 
-*endless* makes it easy to implement this pattern with `Self`. Here's the recipe, as illustrated in the example application @github[example](/example/src/main/scala/endless/example/logic/BookingEffector.scala):
+*endless* makes it easy to implement this pattern with `Self`. Here's the recipe, as illustrated in the example application @github[example](/example/src/main/scala/endless/example/logic/BookingSideEffect.scala):
 
 1. `BookingPlaced` event gets persisted. At this point, entity state represents pending acceptation of the booking `Booking(..., status = Pending)`
 2. Effector function inspects the state, and in case of `Pending` status, asks a third-party service for availability and notifies the entity of the result:
diff --git a/documentation/src/main/paradox/entity.md b/documentation/src/main/paradox/entity.md
index 5001992..9217784 100644
--- a/documentation/src/main/paradox/entity.md
+++ b/documentation/src/main/paradox/entity.md
@@ -10,7 +10,7 @@ trait EventWriter[F[_], E] {
 trait Entity[F[_], S, E] extends StateReader[F, S] with EventWriter[F, E]
 ```
 
-@scaladoc[Entity](endless.core.entity.Entity) is parametrized with entity state `S` and events `E`. It is a typeclass which represents reader-writer capabilities for `F` with event-sourcing semantics, i.e. the abilities to read current entity state from the context and persist events. `Entity` is used to describe entity behavior (e.g. @github[BookingEntity](/example/src/main/scala/endless/example/logic/BookingEntity.scala)). 
+@scaladoc[Entity](endless.core.entity.Entity) is parametrized with entity state `S` and events `E`. It is a typeclass which represents reader-writer capabilities for `F` with event-sourcing semantics, i.e. the abilities to read current entity state from the context and persist events. `Entity` is used to describe entity behavior (e.g. @github[BookingEntityBehavior](/example/src/main/scala/endless/example/logic/BookingEntityBehavior.scala)). 
 
 ## Functional event sourcing
 *Reader-writer* is a natural fit for describing event sourcing behavior: the monadic chain represents event sequencing and corresponding evolution of the state (see also [here](https://pavkin.ru/aecor-part-2/) and [here](https://www.youtube.com/watch?v=kDkRRkkVlxQ)).