diff --git a/public/docs/ts/latest/guide/architecture.jade b/public/docs/ts/latest/guide/architecture.jade
index 5168a84d3b..891ddf59f5 100644
--- a/public/docs/ts/latest/guide/architecture.jade
+++ b/public/docs/ts/latest/guide/architecture.jade
@@ -458,7 +458,7 @@ figure
   * dependency injection is wired into the framework and used everywhere.<br><br>
   * the `Injector` is the main mechanism.
     * an injector maintains a *container* of service instances that it created.
-    * an injector can create a new service instance from a *provider*.
+    * an injector can create a new service instance using a *provider*.
   * a *provider* is a recipe for creating a service.
  
   * we register *providers* with injectors.
diff --git a/public/docs/ts/latest/guide/glossary.jade b/public/docs/ts/latest/guide/glossary.jade
index 3f7e5d8af7..e96fcdd683 100644
--- a/public/docs/ts/latest/guide/glossary.jade
+++ b/public/docs/ts/latest/guide/glossary.jade
@@ -355,24 +355,26 @@
 <a id="L"></a>
 :marked
   ## Lifecycle Hooks
-  [Directives](#directive) and [Components](#component) have a lifecycle
-  managed by Angular as it creates, updates and destroys them.
-  
-  Developers can tap into key moments in that lifecycle by implementing
-  one or more of the "Lifecycle Hook" interfaces. 
-  
-  Each interface has a single hook method whose name is the interface name prefixed with `ng`.
-  For example, the `OnInit` interface has a hook method names `ngOnInit`.
-  
-  Angular calls these hook methods in the following order:
-  * `ngOnChanges` - called when an [input](#input)/[output](#output) binding values change
-  * `ngOnInit` - after the first `ngOnChanges`
-  * `ngDoCheck` - developer's custom change detection
-  * `ngAfterContentInit` - after component content initialized
-  * `ngAfterContentChecked` - after every check of component content
-  * `ngAfterViewInit` - after component's view(s) are initialized
-  * `ngAfterViewChecked` - after every check of a component's view(s)
-  * `ngOnDestroy` - just before the directive is destroyed.
+.l-sub-section
+  :marked
+    [Directives](#directive) and [Components](#component) have a lifecycle
+    managed by Angular as it creates, updates and destroys them.
+    
+    Developers can tap into key moments in that lifecycle by implementing
+    one or more of the "Lifecycle Hook" interfaces. 
+    
+    Each interface has a single hook method whose name is the interface name prefixed with `ng`.
+    For example, the `OnInit` interface has a hook method names `ngOnInit`.
+    
+    Angular calls these hook methods in the following order:
+    * `ngOnChanges` - called when an [input](#input)/[output](#output) binding values change
+    * `ngOnInit` - after the first `ngOnChanges`
+    * `ngDoCheck` - developer's custom change detection
+    * `ngAfterContentInit` - after component content initialized
+    * `ngAfterContentChecked` - after every check of component content
+    * `ngAfterViewInit` - after component's view(s) are initialized
+    * `ngAfterViewChecked` - after every check of a component's view(s)
+    * `ngOnDestroy` - just before the directive is destroyed.
 
 .l-main-section
 <a id="M"></a>
@@ -382,20 +384,32 @@
   :marked
     Angular apps are modular.
 
-    In general we assemble our application from many modules both the ones we write ourselves
+    In general, we assemble our application from many modules, both the ones we write ourselves
     and the ones we acquire from others.
 
     A typical module is a cohesive block of code dedicated to a single purpose.
     
-    A module exports something of value in that code, typically one thing such as a class.
+    A module **exports** something of value in that code, typically one thing such as a class.
+    A module that needs that thing, **imports** it.
+
+    The structure of Angular modules and the import/export syntax 
+    is based on the [ES2015](#es2015) module standard 
+    described [here](http://www.2ality.com/2014/09/es6-modules-final.html).
+    
+    An application that adheres to this standard requires a module loader to
+    load modules on request and resolve inter-module dependencies. 
+    Angular does not ship with a module loader and does not have a preference
+    for any particular 3rd party library (although most samples use SystemJS).
+    Application developers may pick any module library that conforms to the standard
+    
     Modules are typically named after the file in which the exported thing is defined.
-    
     The Angular [DatePipe](https://github.com/angular/angular/blob/master/modules/angular2/src/common/pipes/date_pipe.ts)
-    class belongs to a module named `date_pipe` in the file `date_pipe.ts`.
+    class belongs to a feature module named `date_pipe` in the file `date_pipe.ts`.
     
-    In general, Angular feature modules such as the `data_pipe` are not exposed directly. 
-    Rather they are grouped together with logically related modules in public-facing **library modules**
-    called [**barrels**](#barrel).
+    Developers rarely access Angular feature modules directly. 
+    We usually import them from public-facing **library modules**
+    called [**barrels**](#barrel). Barrels are groups of logically related modules.
+    The `angular2/core` barrel is a good example. 
     
     Learn more in "[Modules, barrels and bundles](https://github.com/angular/angular/blob/master/modules/angular2/docs/bundles/overview.md)".
 
diff --git a/public/resources/images/devguide/architecture/library-module.png b/public/resources/images/devguide/architecture/library-module.png
index 91463cc051..1d6bf23f22 100644
Binary files a/public/resources/images/devguide/architecture/library-module.png and b/public/resources/images/devguide/architecture/library-module.png differ
diff --git a/public/resources/images/devguide/architecture/modules.png b/public/resources/images/devguide/architecture/modules.png
index de9b3345d2..0a8c24f20a 100644
Binary files a/public/resources/images/devguide/architecture/modules.png and b/public/resources/images/devguide/architecture/modules.png differ