diff --git a/docs/src/main/asciidoc/spring-cloud-config.adoc b/docs/src/main/asciidoc/spring-cloud-config.adoc
index a1412846..b5f98c03 100644
--- a/docs/src/main/asciidoc/spring-cloud-config.adoc
+++ b/docs/src/main/asciidoc/spring-cloud-config.adoc
@@ -267,7 +267,8 @@ For a Spring Boot Actuator application there are some additional management endp
 
 === Locating Remote Configuration Resources
 
-The Config Service serves property sources from `/{name}/{env}/{label}`, where the default bindings are
+The Config Service serves property sources from `/{name}/{env}/{label}`, where the default bindings in the
+client app are
 
 * "name" = `${spring.application.name}`
 * "env" = `${spring.profiles.active}` (actually `Environment.getActiveProfiles()`)
@@ -349,18 +350,24 @@ to set defaults.
 You can extend the context hierarchy by simply setting the parent
 context of any `ApplicationContext` you create, e.g. using its own
 interface, or with the `SpringApplicationBuilder` convenience methods
-(`parent()`, `child()` and `sibling()`). Note that the
-`SpringApplicationBuilder` allows you to share an `Environment`
-amongst the whole hierarchy, but that is not the default. Thus,
-sibling contexts in particular do not need to have the same profiles
-or property sources, even though they will share common things with
-their parent. Every context in the hierarchy will have its own
-"bootstrap" property source (possibly empty) to avoid promoting values
-inadvertently from parents down to their descendants. Every context in
-the hierarchy can also (in principle) have a different
-`spring.application.name` and hence a different remote property source
-if there is a Config Server. Remember that properties from a child
-context override those in the parent.
+(`parent()`, `child()` and `sibling()`). The bootstrap context will be
+the parent of the most senior ancestor that you create yourself.
+Every context in the hierarchy will have its own "bootstrap" property
+source (possibly empty) to avoid promoting values inadvertently from
+parents down to their descendants.  Every context in the hierarchy can
+also (in principle) have a different `spring.application.name` and
+hence a different remote property source if there is a Config
+Server. Normal Spring application context behaviour rules apply to
+property resolution: properties from a child context override those in
+the parent, by name and also by property source name (if the child has
+a property source with the same name as the parent, the one from the
+parent is not included in the child).
+
+Note that the `SpringApplicationBuilder` allows you to share an
+`Environment` amongst the whole hierarchy, but that is not the
+default. Thus, sibling contexts in particular do not need to have the
+same profiles or property sources, even though they will share common
+things with their parent. 
 
 [[customizing-bootstrap-properties]]
 === Changing the Location of Bootstrap Properties