diff --git a/.markdownlint.yml b/.markdownlint.yml
index d2b7b5483335bfc0e0202e50934b9305fd510f84..865f20520620c71b0e67c7548fb53c390cc1e6a8 100644
--- a/.markdownlint.yml
+++ b/.markdownlint.yml
@@ -14,6 +14,12 @@ MD013:
   heading_line_length: 100
   # Number of characters for code blocks
   code_block_line_length: 100
-  # Line length requirement disabled for
-  code_blocks: false
+  # Exclude tables
   tables: false
+  # Exclude code blocks
+  code_blocks: false
+
+# MD033/no-inline-html - Inline HTML
+MD033:
+  # Allowed elements
+  allowed_elements: [ br, sup ]
diff --git a/docs/Developer-Basics.md b/docs/Developer-Basics.md
index 4f222768db9d945f2e603f9bbe7b92689360251a..51cf8c2cd7fbc357d0704d57e9afde3c02c9b4c2 100644
--- a/docs/Developer-Basics.md
+++ b/docs/Developer-Basics.md
@@ -56,5 +56,5 @@ Eclipse provides automatic compilation, syntax highlighting, and integration wit
 other useful features. To build or modify *nshmp-haz* using [Eclipse](http://www.eclipse.org/),
 install the [Eclipse IDE for Java Developers](https://www.eclipse.org/downloads/packages/) or
 [Eclipse IDE for Enterprise Java and Web Developers](https://www.eclipse.org/downloads/packages/),
-if you plan on developing web services. Import the project into Eclipse: `File > Import > 
+if you plan on developing web services. Import the project into Eclipse: `File > Import >
 Gradle > Existing Gradle Project`
diff --git a/docs/Functional-PSHA.md b/docs/Functional-PSHA.md
index 87d3897ffeb93e59ee4880727e4eac366ed2c550..726864a1de39589eabe9931a7021604ad2cbdf5d 100644
--- a/docs/Functional-PSHA.md
+++ b/docs/Functional-PSHA.md
@@ -1,4 +1,6 @@
-### Abstract
+# Functional PSHA
+
+## Abstract
 
 Probabilistic seismic hazard analysis (PSHA; Cornell, 1968) is elegant in its relative simplicity.
 However, in the more than 40-years since its publication, the methodology has come to be applied
@@ -18,7 +20,7 @@ intermediate results as immutable objects, making it easier to: chain actions to
 intermediate data or results that may still be relevant (e.g. as in a deaggregation); and leverage
 the concurrency supported by many modern programming languages.
 
-#### Traditional PSHA formulation (after Baker, 2013):
+## Traditional PSHA formulation (after Baker, 2013)
 
 ![image](images/psha-formula.png "PSHA formulation of Baker (2013)")
 Briefly, the rate, *λ*, of exceeding an intensity measure, *IM*, level may be computed as a
@@ -39,7 +41,7 @@ more than magnitude and distance, including, but not limited to:
 * __Fault geometry__ (e.g. dip, width, rupture depth, hypocentral depth)
 * __Site characteristics__ (e.g. basin depth terms, site type or Vs30 value)
 
-#### Simple, yes, but used for so much more…
+## Simple, yes, but used for so much more…
 
 While this formulation is relatively straightforward and is typically presented with examples for
 a single site, using a single GMM, and a nominal number of sources, modern PSHAs commonly include:
@@ -56,7 +58,7 @@ a single site, using a single GMM, and a nominal number of sources, modern PSHAs
 * Source models that do not adhere to the traditional formulation (e.g. cluster models of the NSHM).
 * Logic trees of ground motion models.
 
-#### And further extended to support…
+## And further extended to support…
 
 * Response Spectra, Conditional Mean Spectra – multiple intensity measure types (IMTs; e.g. PGA,
   PGD, PGV, multiple SAs)
@@ -65,11 +67,12 @@ a single site, using a single GMM, and a nominal number of sources, modern PSHAs
 * Maps – many thousands of sites
 * Uncertainty analyses
 
-#### How are such calculations managed?
+## How are such calculations managed?
 
 * PSHA codes typically compute hazard in a linear fashion, looping over all relevant sources for
   a site.
 * Adding additional GMMs, logic trees, IMT’s, and sites is addressed with more, outer loops:
+
 ```PHP
 foreach IMT {
     foreach Site {
@@ -83,10 +86,11 @@ foreach IMT {
     }
 }
 ```
+
 * Support for secondary analyses, such as deaggregation is supplied by a separate code or codes
   and can require repeating many of the steps performed to generate an initial hazard curve.
 
-#### What about scaleability, maintenance, and performance?
+## What about scaleability, maintenance, and performance?
 
 * Although scaleability can be addressed for secondary products, such as maps, by distributing
   individual site calculations over multiple processors and threads, it is often difficult to
@@ -98,9 +102,9 @@ foreach IMT {
 * Multiple codes repeating identical tasks invite error and complicate maintenance by multiple
   individuals.
 
-#### Enter functional programming…
+## Enter functional programming…
 
-* http://en.wikipedia.org/wiki/Functional_programming
+* <http://en.wikipedia.org/wiki/Functional_programming>
 * Functional programming languages have been around for some time (e.g. Haskell, Lisp, R), and
   fundamental aspects of functional programming/design are common in many languages. For example,
   a cornerstone of the functional paradigm is the anonymous (or lambda) function; in Matlab, one
@@ -110,7 +114,7 @@ foreach IMT {
   popularity of the functional style, Java 8 recently added constructs in the form of the function
   and streaming APIs, and libraries exists for other languages.
 
-#### How do PSHA and related calculations leverage such an approach?
+## How do PSHA and related calculations leverage such an approach?
 
 Break the traditional PSHA formulation down into discrete steps and preserve the data associated
 with each step:
@@ -132,7 +136,7 @@ The functional pipeline can be processed stepwise:
 
 **Need a response spectra?** Spawn more calculations, one for each IMT, at step 2.
 
-#### Benefits:
+## Benefits
 
 * It’s possible to build a single calculation pipeline that will handle a standard hazard curve
   calculation and all of its extensions without repetition.
@@ -141,12 +145,12 @@ The functional pipeline can be processed stepwise:
 * Can add or remove transforms or data at any point in the pipeline, or build new pipelines
   without adversely affecting existing code.
 
-#### Drawbacks:
+## Drawbacks
 
 * Greater memory requirements.
 * Additional (processor) work to manage the flow of calculation steps.
 
-#### References
+## References
 
 * Baker J.W. (2013). An Introduction to Probabilistic Seismic Hazard Analysis (PSHA), White Paper,
   Version 2.0, 79 pp.
diff --git a/docs/Ground-Motion-Models.md b/docs/Ground-Motion-Models.md
index 91aec294af263b0bf7f137a6b1121d2b6244ef62..82f109b620244bdb64d376606c9b01ddb01ecac8 100644
--- a/docs/Ground-Motion-Models.md
+++ b/docs/Ground-Motion-Models.md
@@ -97,11 +97,16 @@ TODO
 | [Tavakoli & Pezeshk, 2005](http://dx.doi.org/10.1785/0120050030) | TP_05<br>TP_05_AB<br>TP_05_J | not specified | Mean values clamped |
 | [Toro et al., 1997](http://dx.doi.org/10.1785/gssrl.68.1.41)<br>[Toro, 2002](http://www.ce.memphis.edu/7137/PDFs/attenuations/Toro_2001_(modification_1997).pdf) | TORO_97_MB<br>TORO_97_MW | not specified | Mean values clamped |
 
-<a id="one-nga-east-median-model-ids"></a>
-:one: NGA-East Median Model IDs: NGA_EAST_USGS_1, NGA_EAST_USGS_2, NGA_EAST_USGS_3, NGA_EAST_USGS_4, NGA_EAST_USGS_5, NGA_EAST_USGS_6, NGA_EAST_USGS_7, NGA_EAST_USGS_8, NGA_EAST_USGS_9, NGA_EAST_USGS_10, NGA_EAST_USGS_11, NGA_EAST_USGS_12, NGA_EAST_USGS_13, NGA_EAST_USGS_14, NGA_EAST_USGS_15, NGA_EAST_USGS_16, NGA_EAST_USGS_17
-
-<a id="one-nga-east-seed-model-ids"></a>
-:two: NGA-East Seed Model IDs: NGA_EAST_SEED_1CCSP, NGA_EAST_SEED_1CVSP, NGA_EAST_SEED_2CCSP, NGA_EAST_SEED_2CVSP, NGA_EAST_SEED_B_A04, NGA_EAST_SEED_B_AB14, NGA_EAST_SEED_B_AB95, NGA_EAST_SEED_B_BCA10D, NGA_EAST_SEED_B_BS11, NGA_EAST_SEED_B_SGD02, NGA_EAST_SEED_FRANKEL, NGA_EAST_SEED_GRAIZER, NGA_EAST_SEED_GRAIZER16, NGA_EAST_SEED_GRAIZER17, NGA_EAST_SEED_HA15, NGA_EAST_SEED_PEER_EX, NGA_EAST_SEED_PEER_GP, NGA_EAST_SEED_PZCT15_M1SS, NGA_EAST_SEED_PZCT15_M2ES, NGA_EAST_SEED_SP15, NGA_EAST_SEED_SP16, NGA_EAST_SEED_YA15
+1. NGA-East Median Model IDs: NGA_EAST_USGS_1, NGA_EAST_USGS_2, NGA_EAST_USGS_3, NGA_EAST_USGS_4,
+   NGA_EAST_USGS_5, NGA_EAST_USGS_6, NGA_EAST_USGS_7, NGA_EAST_USGS_8, NGA_EAST_USGS_9,
+   NGA_EAST_USGS_10, NGA_EAST_USGS_11, NGA_EAST_USGS_12, NGA_EAST_USGS_13, NGA_EAST_USGS_14,
+   NGA_EAST_USGS_15, NGA_EAST_USGS_16, NGA_EAST_USGS_17
+2. NGA-East Seed Model IDs: NGA_EAST_SEED_1CCSP, NGA_EAST_SEED_1CVSP, NGA_EAST_SEED_2CCSP,
+   NGA_EAST_SEED_2CVSP, NGA_EAST_SEED_B_A04, NGA_EAST_SEED_B_AB14, NGA_EAST_SEED_B_AB95,
+   NGA_EAST_SEED_B_BCA10D, NGA_EAST_SEED_B_BS11, NGA_EAST_SEED_B_SGD02, NGA_EAST_SEED_FRANKEL,
+   NGA_EAST_SEED_GRAIZER, NGA_EAST_SEED_GRAIZER16, NGA_EAST_SEED_GRAIZER17, NGA_EAST_SEED_HA15,
+   NGA_EAST_SEED_PEER_EX, NGA_EAST_SEED_PEER_GP, NGA_EAST_SEED_PZCT15_M1SS,
+   NGA_EAST_SEED_PZCT15_M2ES, NGA_EAST_SEED_SP15, NGA_EAST_SEED_SP16, NGA_EAST_SEED_YA15
 
 ## Subduction GMMs  
 
@@ -146,7 +151,8 @@ TODO
 
 ## Auxilliary Models
 
-Auxilliary models are not used directly, they can be used by concrete implementations of GMMs to modify model output.
+Auxilliary models are not used directly, they can be used by concrete implementations of GMMs to
+modify model output.
 
 | Reference | Purpose | Component | Notes |
 |:---------:|:-------:|:---------:|:------|
diff --git a/docs/Logic-Trees-&-Uncertainty.md b/docs/Logic-Trees-&-Uncertainty.md
index a49ec7032223bd7fd0fe1d558adcff6297e2b09f..5b51aaec28e62bc8dd34fa0f4491448115fb4877 100644
--- a/docs/Logic-Trees-&-Uncertainty.md
+++ b/docs/Logic-Trees-&-Uncertainty.md
@@ -1,8 +1,7 @@
 # USGS Models: Logic Trees & Uncertainty
 
 The following page details the logic trees of epistemic uncertainty considered in NSHMs supported
-by *nshmp-haz*. Logic trees are represented in a NSHM using files ending in `-tree.json`
-([example]()).
+by *nshmp-haz*. Logic trees are represented in a NSHM using files ending in `-tree.json`.
 
 [[_TOC_]]
 
diff --git a/docs/Magnitude-Frequency-Distributions.md b/docs/Magnitude-Frequency-Distributions.md
index c51b4d288d64834ee1852d48d8708e63825913c3..27afc47542a87b116f1791ce0ea17b2c20926f8a 100644
--- a/docs/Magnitude-Frequency-Distributions.md
+++ b/docs/Magnitude-Frequency-Distributions.md
@@ -8,10 +8,11 @@ members listed in the JSON examples below are required.
 [[_TOC_]]
 
 MFD types:
- * [Single](#single-magnitude-mfd)
- * [Gutenberg-Richter](#gutenberg-richter-mfd)
- * [Tapered Gutenberg-Richter](#tapered-gutenberg-richter-mfd)
- * [Incremental](#incremental-mfd)
+
+* [Single](#single-magnitude-mfd)
+* [Gutenberg-Richter](#gutenberg-richter-mfd)
+* [Tapered Gutenberg-Richter](#tapered-gutenberg-richter-mfd)
+* [Incremental](#incremental-mfd)
 
 ## Single
 
@@ -97,26 +98,37 @@ example:
 }
 ```
 
-**mfd-config.json:** 
-
+**mfd-config.json:**
 
 MFD confguration files:
- * mfd-map.json
- * mfd-config.json
- * rate-tree.json
- * Rate files (*.csv)
 
-For instance, the final MFDs used in a hazard may be modified by an epistemic or aleatory uncertainty model specified in `mfd-config.json`. Single and Gutenberg-Richter MFDs that do not have their `rate` or `a`-value members defined rely on the presence of a `rate-tree.json` file. A rate-tree defines a logic tree of rates or pointers to CSV rate files with spatially varying rate data.
+* mfd-map.json
+* mfd-config.json
+* rate-tree.json
+* Rate files (*.csv)
 
-#### `mfd-map.json`
-
-A mfd-map defines multiple mfd-trees common to multiple branches of a source-tree.
+For instance, the final MFDs used in a hazard may be modified by an epistemic or aleatory
+uncertainty model specified in `mfd-config.json`. Single and Gutenberg-Richter MFDs that do not
+have their `rate` or `a`-value members defined rely on the presence of a `rate-tree.json` file.
+A rate-tree defines a logic tree of rates or pointers to CSV rate files with spatially varying
+rate data.
 
+### `mfd-map.json`
 
+A mfd-map defines multiple mfd-trees common to multiple branches of a source-tree.
 
-#### `mfd-config.json`
+### `mfd-config.json`
 
-Additional uncertainty in MFDs is often considered when building hazard models and is defined in a `mfd-config.json` file. Application of uncertainty models is MFD type-dependent.  The `epistemic-tree` member, if non-null, is used to create 3-branches for single and Gutenberg-Richter MFDs. For a single MFD, a moment-balanced three-point distribution of magnitudes (± 0.2 magnitude units) is created. For a Gutenberg-Richter MFD, three maximum magnidue branches are created, also moment-balanced. The `aleatory-properties` member is only applicable to single MFDs and may be applied on top of an epistemic-tree. In the example below, `aleatory-properties` defines an eleven-point, moment-balanced normal distribution with a width of ±2σ of magnitudes about a central magnitude. If no additional uncertainty model is desired,  `epistemic-tree` and  `aleatory-properties` should be set to null.
+Additional uncertainty in MFDs is often considered when building hazard models and is defined
+in a `mfd-config.json` file. Application of uncertainty models is MFD type-dependent.  The
+`epistemic-tree` member, if non-null, is used to create 3-branches for single and Gutenberg-Richter
+MFDs. For a single MFD, a moment-balanced three-point distribution of magnitudes (± 0.2 magnitude
+units) is created. For a Gutenberg-Richter MFD, three maximum magnidue branches are created, also
+moment-balanced. The `aleatory-properties` member is only applicable to single MFDs and may be
+applied on top of an epistemic-tree. In the example below, `aleatory-properties` defines an
+eleven-point, moment-balanced normal distribution with a width of ±2σ of magnitudes about a
+central magnitude. If no additional uncertainty model is desired,  `epistemic-tree` and
+`aleatory-properties` should be set to null.
 
 TODO is aleatory uncertainty in MFD ALWAYS moment-balanced???
 
@@ -137,7 +149,7 @@ TODO is aleatory uncertainty in MFD ALWAYS moment-balanced???
 }
 ```
 
-#### `rate-tree.json`
+### `rate-tree.json`
 
 A rate-tree defines each branch `value` in years (recurrence or return period):
 
@@ -211,15 +223,17 @@ For example:
 ]
 ```
 
-
-
 From Model Files:
 
-#### Magnitude Frequency Distributions (MFDs)
+### Magnitude Frequency Distributions (MFDs)
 
 `mfd-tree`, `mfd-map.json`, `mfd-config.json`, and `rate-tree.json`
 
-A `mfd-tree` property is common to all source types and defines a logic tree of magnitude frequency distributions (MFDs). The `mfd-tree` element may be an array of mfd branches defined inline or a string reference to a top-level member of an `mfd-map.json` that contains one or more mfd-trees shared across a source-tree. The branches of a mfd-tree commonly have the generic ID's: `[M1, M2, M3, ...]` to support mfd-tree matching across source-tree branches.
+A `mfd-tree` property is common to all source types and defines a logic tree of magnitude
+frequency distributions (MFDs). The `mfd-tree` element may be an array of mfd branches defined
+inline or a string reference to a top-level member of an `mfd-map.json` that contains one or
+more mfd-trees shared across a source-tree. The branches of a mfd-tree commonly have the generic
+ID's: `[M1, M2, M3, ...]` to support mfd-tree matching across source-tree branches.
 
 ```json
 "mfd-tree": [
@@ -230,10 +244,13 @@ A `mfd-tree` property is common to all source types and defines a logic tree of
 ]
 ```
 
-How MFDs are actually built depends on the settings in a `mfd-config.json` file and rates For more details on MFDs and their configuration see the [magnitude frequency distributions](magnitude-frequency-distributions) section.
-
-An `mfd-config.json` is currently only required for finite fault sources. It can be located anywhere in the file heirarchy and may be overridden in nested directories. 
-
+How MFDs are actually built depends on the settings in a `mfd-config.json` file and rates. For more
+details on MFDs and their configuration see the
+[magnitude frequency distributions](magnitude-frequency-distributions) section.
 
-Depending on the types of MFDs being modeled, a rate file may contain Gutenberg-Richter a-values or magnitude-specific rates. The branches of a rate-tree commonly have the generic ID's: `[R1, R2, R3, ...]` to support matching rate-trees across source-tree branches. 
+An `mfd-config.json` is currently only required for finite fault sources. It can be located
+anywhere in the file heirarchy and may be overridden in nested directories.
 
+Depending on the types of MFDs being modeled, a rate file may contain Gutenberg-Richter a-values
+or magnitude-specific rates. The branches of a rate-tree commonly have the generic ID's:
+`[R1, R2, R3, ...]` to support matching rate-trees across source-tree branches.
diff --git a/docs/Model Editions.md b/docs/Model Editions.md
index 94cf0cdedacd9d0b274a914de49d02f41c4b7436..e4524a35cd4b794875e8006ba0cf361435d4d679 100644
--- a/docs/Model Editions.md	
+++ b/docs/Model Editions.md	
@@ -57,7 +57,7 @@ the Atkinson & Boore (2003) model does not support long periods (see the
 Moving forward, we will continue to include the original dynamic version of the 2014 model
 (v4.1.4) in the UHT. However, we recommend that users consider the updated model (4.2.0).
 
-### Static vs. Dynamic
+## Static vs. Dynamic
 
 Historically, the USGS NSHMP has produced static datasets of hazard curves that accompany the
 'official' release or update to a model. In the context of providing interactive web services,
@@ -89,7 +89,7 @@ Dynamic editions are supported through web-services provided by the `nshmp-haz-w
 (this repository). Static editions are supported via a separate set of services. Both are
 documented on the [web services](web-services) page.
 
-### Region specific changes
+## Region specific changes
 
 Changes between editions in model regions are documented in the release notes of the individual
 model repositories.
@@ -97,4 +97,3 @@ model repositories.
 * [Conterminous US (2014)](/usgs/nshmp-model-cous-2014/wiki)  
 * [Conterminous US (2008)](/usgs/nshmp-model-cous-2008/wiki)  
 * [Alaska (2007)](/usgs/nshmp-model-ak-2007/wiki)  
-
diff --git a/docs/Model-Files.md b/docs/Model-Files.md
index 267950cd96e0f70802e8c66edd66849bad0cf7f9..73d8400d221c8d00f0b6677cd4629e90dc7f9906 100644
--- a/docs/Model-Files.md
+++ b/docs/Model-Files.md
@@ -135,14 +135,12 @@ using the same MFDs on multiple branches of a source tree.
 How MFDs are intialized (or realized) depends on the presence and contents of `mfd-config.json` and
 `rate-tree.json` files. See the
 [magnitude frequency distributions](magnitude-frequency-distributions) page for details on these
-files and the types of MFDs supported in _nshmp-haz_. 
+files and the types of MFDs supported in _nshmp-haz_.
 
 ## Rupture Sets
 
-A `rupture-set` is the terminal file of a source-tree branch and defines the fault sections and
-MFD's required to intialize a source.
-
-**rupture-set.json**
+**rupture-set.json**: A `rupture-set` is the terminal file of a source-tree branch and defines the
+fault sections and MFD's required to intialize a source.
 
 ```json
 {
@@ -160,11 +158,10 @@ case, `mfd-tree` points to a named tree that will be present in an `mfd-map.json
 the source-tree. The `sections` member may be absent. In this case, the `id` of the rupture-set
 is the same as the single, associated fault section.
 
-**cluster-set.json**
-
-Fault sources also support cluster models where the total hazard is computed from the probability
-of exceeding some ground motion level is conditioned on the occurrence of 2 or more, roughly
-contemporaneous events. A cluster-set is composed of an array of rupture-sets.
+**cluster-set.json**: A specialized form of a rupture set. Fault sources also support cluster
+models where the total hazard is computed from the probability of exceeding some ground motion
+level is conditioned on the occurrence of 2 or more, roughly contemporaneous events. A cluster-set
+is composed of an array of rupture-sets.
 
 ```json
 {
diff --git a/docs/Model-Structure.md b/docs/Model-Structure.md
index 4ca92befd3d3955e42b26ce003561cbb25a2a619..c4fdfc6ca4b802f60716c0a1467f171207f5b421 100644
--- a/docs/Model-Structure.md
+++ b/docs/Model-Structure.md
@@ -99,7 +99,7 @@ See also: [Finite Fault Source Type](source-types#finite-fault-sources)
 
 ## Crustal Grid Sources
 
-*TODO this isn't quite right, needs conus-2018 refactor for verification*
+TODO this isn't quite right, needs conus-2018 refactor for verification
 
 Grid sources are based on smoothed seismicity or other spatially varying rate model and may be
 defined as either single source features, each within its own directory, or as more complex logic
diff --git a/docs/README.md b/docs/README.md
index 7cd65d8782bfd6ed3e4634bc8f0aa3544678d7bb..3df0badcbca381d9d8a4359193898fd1fffbb0c7 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -17,7 +17,7 @@ to use *nshmp-haz* as well as underlying model implementation details.
   * [Developer Basics](developer-basics)
   * [Calculation Configuration](calculation-configuration)
   * [Site Specification](site-specification)
-  * [Examples](/ghsc/nshmp/nshmp-haz-v2/-/tree/master/etc/examples)
+  * [Examples](/ghsc/nshmp/nshmp-haz/-/tree/master/etc/examples)
 * [Hazard Model](hazard-model)
   * [Model Structure](model-structure)
   * [Model Files](model-files)
@@ -31,8 +31,12 @@ to use *nshmp-haz* as well as underlying model implementation details.
 
 ## Other Pages & References
 
-  * [nshmp-lib](/ghsc/nshmp/nshmp-lib): USGS hazard modeling library
-  * [Functional PSHA](functional-psha)
-  * [Probabilistic Seismic Hazard Analysis, a Primer [PDF]](http://www.opensha.org/sites/opensha.org/files/PSHA_Primer_v2_0.pdf) by Edward Field  
-  * [An Introduction to Probabilistic Seismic Hazard Analysis [PDF]](http://web.stanford.edu/~bakerjw/Publications/Baker_(2015)_Intro_to_PSHA.pdf) by Jack Baker  
-  * [License](../LICENSE.md)
+* [nshmp-lib](/ghsc/nshmp/nshmp-lib): USGS hazard modeling library
+* [Functional PSHA](functional-psha)
+* [Probabilistic Seismic Hazard Analysis, a Primer
+  [PDF]](http://www.opensha.org/sites/opensha.org/files/PSHA_Primer_v2_0.pdf)
+  by Edward Field  
+* [An Introduction to Probabilistic Seismic Hazard Analysis
+  [PDF]](http://web.stanford.edu/~bakerjw/Publications/Baker_(2015)_Intro_to_PSHA.pdf)
+  by Jack Baker  
+* [License](../LICENSE.md)
diff --git a/docs/Rupture-Scaling-Relations.md b/docs/Rupture-Scaling-Relations.md
index 26864831598e05facf3df921f3c36b7eab8d93e2..0a79a5e4f6e0abdcd037bf2dfbdc8ce4521cd417 100644
--- a/docs/Rupture-Scaling-Relations.md
+++ b/docs/Rupture-Scaling-Relations.md
@@ -2,12 +2,12 @@
 
 Rupture scaling models describe relationships between rupture geometry and magnitude. Such models
 are used in a NSHM to:
+
 * Compute an expected magnitude from a rupture geometry.
 * Compute the size (length or area) of a rupture from a magnitude.
 * Compute point-source distance corrections (optimization for unknown strike)
 
-Rupture scaling model implementations typically impose restrictions on rupture aspect ratio. For
-more details see the [rupture scaling implementation]() reference.
+Rupture scaling model implementations typically impose restrictions on rupture aspect ratio.
 
 ## Magnitude-Scaling Relationships
 
@@ -25,7 +25,6 @@ more details see the [rupture scaling implementation]() reference.
 | Papazachos-04      | Papazachos et al. (2004)   | subduction   | magnitude-length |
 | Youngs-97          | Youngs et al. (1997)       | subduction   | magnitude-length |
 
-
 ¹ UCERF3 uses rupture scaling relationships to also balance slip rate when computing rupture
 rates. These models consider alternative slip-length scaling relations relative to the default
 computed from rupture area and moment; see Field et al. (2014) for details.
diff --git a/docs/Site-Specification.md b/docs/Site-Specification.md
index 04b002b8806875b98990f43454041f0d5be9137b..c2a27fa42b90f59556bd3498d6bca3d04009d293 100644
--- a/docs/Site-Specification.md
+++ b/docs/Site-Specification.md
@@ -36,13 +36,13 @@ it's 'default' basin depth scale factor.
 
 ## Comma-Delimited Format (\*.csv)
 
-* Header row must identify columns.  
-* Valid and [optional] column names are:  
+* Header row must identify columns.
+* Valid and [optional] column names are:
   `[name,] lon, lat [, vs30] [, vsInf] [, z1p0] [, z2p5]`  
-* At a minimum, `lon` and `lat` must be defined.  
-* Columns can be in any order and any missing fields will be populated with the default values 
-  listed above.  
-* If a site `name` is supplied, it is included in the first column of any output curve files.  
+* At a minimum, `lon` and `lat` must be defined.
+* Columns can be in any order and any missing fields will be populated with the default values
+  listed above.
+* If a site `name` is supplied, it is included in the first column of any output curve files.
 
 ## GeoJSON Format (\*.geojson)
 
@@ -91,7 +91,6 @@ GeoJSON is also used to define *nshmp-haz* map regions. For example, see the fil
 region commonly used when creating hazard and other maps for the
 [Los Angeles basin](/usgs/nshmp-haz/blob/master/etc/nshm/map-la-basin.geojson).
 
-
 A map region is expected as a `Polygon` `FeatureCollection`. Currently, *nshmp-haz* only supports
 a `FeatureCollection` with 1 or 2 polygons. When a single polygon is defined, it must consist of a
 single, simple closed loop. Additional arrays that define holes in the polygon (per the GeoJSON
diff --git a/docs/Source-Types.md b/docs/Source-Types.md
index 0b6dfa3cee9a827c0a00c2b34b23e8fbf5ce4bd7..03b47b1b9cdc69ac5b4d4b53f1b1367b1fe32752 100644
--- a/docs/Source-Types.md
+++ b/docs/Source-Types.md
@@ -17,15 +17,24 @@ configuration files are provided with each [source type](source-types) descripti
 files must be fully specified with `null` JSON member values used to specify 'do nothing' where
 appropriate.
 
-Source models for use with *nshmp-haz* are defined using [JSON](https://www.json.org) and [GeoJSON](https://geojson.org). *nshmp-haz* makes determinations about how to represent a source based on a GeoJSON geometry type in conjunction with supporting JSON configuration files.
+Source models for use with *nshmp-haz* are defined using [JSON](https://www.json.org) and
+[GeoJSON](https://geojson.org). *nshmp-haz* makes determinations about how to represent a source
+based on a GeoJSON geometry type in conjunction with supporting JSON configuration files.
 
-Values in source model files in ALL_CAPS generally map to enum types, [for example](http://usgs.github.io/nshmp-haz/javadoc/index.html?gov/usgs/earthquake/nshmp/gmm/Gmm.html).
+Values in source model files in ALL_CAPS generally map to enum types,
+[for example](http://usgs.github.io/nshmp-haz/javadoc/index.html?gov/usgs/earthquake/nshmp/gmm/Gmm.html).
 
-__Note on Coordinates:__ *nshmp-haz* supports longitude and latitude values in the closed ranges `[-360°‥360°]` and `[-90°‥90°]`. Note, however, that mixing site and/or source coordinates across the antimeridian (the -180° to 180° transition) will yield unexpected results. For Pacific models and calculations, always use positive or negative longitudes exclusively.
+__Note on Coordinates:__ *nshmp-haz* supports longitude and latitude values in the closed ranges
+`[-360°‥360°]` and `[-90°‥90°]`. Note, however, that mixing site and/or source coordinates across
+the antimeridian (the -180° to 180° transition) will yield unexpected results. For Pacific models
+and calculations, always use positive or negative longitudes exclusively.
 
-### Model Initialization Parameters
+## Model Initialization Parameters
 
-Model initialization parameters *must* be supplied; there are no default values. In addition, these parameters may *not* be overridden once a model has been initialized in memory. However, one can configure parts of a model differently, [for example](/usgs/nshmp-model-cous-2014/blob/master/Western%20US/Interface/config.json).
+Model initialization parameters *must* be supplied; there are no default values. In addition,
+these parameters may *not* be overridden once a model has been initialized in memory. However,
+one can configure parts of a model differently,
+[for example](/usgs/nshmp-model-cous-2014/blob/master/Western%20US/Interface/config.json).
 
 Parameter | Type | Notes |
 --------- | ---- | ----- |
@@ -37,8 +46,7 @@ __`model`__ |
 &nbsp;&nbsp;&nbsp;`.pointSourceType`    |`String`  |[PointSourceType](http://usgs.github.io/nshmp-haz/javadoc/index.html?gov/usgs/earthquake/nshmp/eq/model/PointSourceType.html)
 &nbsp;&nbsp;&nbsp;`.areaGridScaling`    |`String`  |[AreaSource.GridScaling](http://usgs.github.io/nshmp-haz/javadoc/index.html?gov/usgs/earthquake/nshmp/eq/model/AreaSource.GridScaling.html)
 
-
-### Outline
+## Outline
 
 * [Area Sources](#area-sources)
 * [Cluster Sources](#cluster-sources)
@@ -50,7 +58,8 @@ __`model`__ |
 
 * Basic source types
 * Fault Modeling Approaches
-  * cluster models are a source model specialization; currently used in both cratonic and active crustal environments.
+  * cluster models are a source model specialization; currently used in both cratonic and active
+    crustal environments.
   * system
 
 ### Zone Sources
@@ -155,7 +164,7 @@ smaller events) during earthquakes. Smaller events are modeled as 'floating'
 ruptures; they occur in multiple locations on the fault surface with
 appropriately scaled rates.
 
-Many fault-based earthquake sources are strightforward to model using a single geojson file that 
+Many fault-based earthquake sources are strightforward to model using a single geojson file that
 
 ```json
 {
@@ -181,7 +190,7 @@ MFDs associated with finite fault models may be explicitely defined or or derive
 ]
 ```
 
-##### Geodetic slip variants
+#### Geodetic slip variants
 
 ```json
 "rateModels": [
@@ -215,7 +224,7 @@ MFDs associated with finite fault models may be explicitely defined or or derive
 ]
 ```
 
-##### `fault-config.json`
+#### `fault-config.json`
 
 ```json
 {
@@ -230,7 +239,6 @@ MFDs associated with finite fault models may be explicitely defined or or derive
 }
 ```
 
-
 ### Fault Zone (Area) Sources
 
 ```json
@@ -347,7 +355,8 @@ It is not uncommon for rupture models to be defined by complex logic trees. In t
 
 expectation that all MFDs are some flavor of GR*
 
-Always floats when used for a fault source; never floats for grid sources. 'a' is the incremental log10(number of M=0 events).
+Always floats when used for a fault source; never floats for grid sources. 'a' is the incremental
+log10(number of M=0 events).
 
 grid polygons generally offset (expanded) due to includes() operations on grid nodes.
 
@@ -355,7 +364,8 @@ grid sources must define a rate-tree, even if it is a singleton.
 
 ANy grid sources/rates defined outside grid polygon are skipped.
 
-No `mfd-config` for grid, slab, or zone sources at this time. (implies we don't use epi or aleatory variability in grid-based source MFDs)
+No `mfd-config` for grid, slab, or zone sources at this time. (implies we don't use epi or
+aleatory variability in grid-based source MFDs)
 
 ...tapered GR  Currently only used for grid sources.
 
@@ -421,7 +431,7 @@ No `mfd-config` for grid, slab, or zone sources at this time. (implies we don't
 </GridSourceSet>
 ```
 
-##### `grid-config.json`
+#### `grid-config.json`
 
 ```json
 {
@@ -451,7 +461,10 @@ No `mfd-config` for grid, slab, or zone sources at this time. (implies we don't
 }
 ```
 
-A `grid-depth-map` defines a mapping of magnitude ranges to logic trees of depth distributions. The map can use arbitrary names as keys, but the magnitude ranges defined by each member must be non-overlapping. The magnitude ranges are interpreted as closed (inclusive) – open (exclusive), e.g. [mMin..mMax).
+A `grid-depth-map` defines a mapping of magnitude ranges to logic trees of depth distributions.
+The map can use arbitrary names as keys, but the magnitude ranges defined by each member must
+be non-overlapping. The magnitude ranges are interpreted as closed (inclusive) – open (exclusive),
+e.g. [mMin..mMax).
 
 ## Grid Data Files (*.csv)
 
@@ -462,7 +475,6 @@ then latitude (lower-left to upper-right). While most gridded rate files contain
 longitude, latitude, and rate, some may contain depth values (intraslab sources), maximum
 magnitude caps, or other values.
 
-
 ### Subduction Interface Sources
 
 ```xml
@@ -516,7 +528,7 @@ magnitude caps, or other values.
 </SubductionSourceSet>
 ```
 
-##### `interface-config.json`
+#### `interface-config.json`
 
 ```json
 {
@@ -530,7 +542,7 @@ magnitude caps, or other values.
 
 Subduction intraslab sources are currently specified the same way as [Grid Sources](#grid-sources).
 
-##### `slab-config.json`
+#### `slab-config.json`
 
 ```json
 {
@@ -551,7 +563,9 @@ Fault system source sets require three files:
 * `fault_ruptures.xml`
 * `grid_sources.xml`
 
-that are placed together within a _source group_ folder. Fault system source sets represent a single logic-tree branch or an average over a group of branches and has a gridded (or smoothed seismicity) source component that is coupled with the fault-based rates in the model.
+that are placed together within a _source group_ folder. Fault system source sets represent a
+single logic-tree branch or an average over a group of branches and has a gridded (or smoothed
+seismicity) source component that is coupled with the fault-based rates in the model.
 
 `fault_sections.xml` defines the geometry of a fault network as a set of indexed fault sections: