diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..1fecb68
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,5 @@
+###############################################################################
+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto
+
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..45c1505
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+_site
+.sass-cache
+.jekyll-metadata
diff --git a/Gemfile b/Gemfile
new file mode 100644
index 0000000..dc7be24
--- /dev/null
+++ b/Gemfile
@@ -0,0 +1,31 @@
+source "https://rubygems.org"
+ruby RUBY_VERSION
+
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+#     bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+gem "jekyll", "3.4.2"
+
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.0"
+
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+   gem 'jekyll-optional-front-matter'
+   gem 'jekyll-readme-index'
+   gem 'jekyll-default-layout'
+   gem 'jekyll-titles-from-headings'
+   gem 'jekyll-relative-links'
+end
+
+# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
+gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
diff --git a/LICENSE b/LICENSE
index c091b69..1883941 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,4 +1,190 @@
-   Open Recipe Format
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "{}"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
 
    Copyright 2013 - 2014 Joseph Hall
 
@@ -12,4 +198,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..ca0dca4
--- /dev/null
+++ b/README.md
@@ -0,0 +1,41 @@
+---
+layout: default
+title: Home
+permalink: /index.html
+---
+
+# Open Recipe Format
+
+> **Attribution:** This is a fork of the [Open Recipe Format repository by Joseph Hall](https://github.com/techhat/openrecipeformat) converted to be a web site for easier access.
+
+In the beginning, there was food. And then there were dishes. And somewhere down the line, people started writing down how to make the dishes. And most of them weren't very good at it. And then they got computers, and they still weren't very good at it.
+
+The Open Recipe Format has been designed to solve some basic needs: accurate and flexible storage of recipes. While there have been attempts in the past to create standardized computer recipe formats, they have so far met with failure. This stems from several problems, all of which stem from a lack of understanding of the tasks at hand (and in most cases, ignorance of which tasks actually need to be addressed).
+
+A significant portion of the population cooks at home, and so most solutions target home cooks. Commercial solutions exist, and address a host of new considerations that are not thought to relate to home cooks. The Open Recipe Format was initially created by a software engineer with a cooking degree and professional kitchen experience. Few, if any, other attempts at writing food software, much less standardized recipe data modeling, can make this claim.
+
+At the heart of the Open Recipe Format is an established file format called YAML. This format was chosen for a variety of reasons:
+
+-   It is text-based, and therefore human readable.
+-   It mimics the internal data structures of several high-level programming languages.
+-   It can easily be converted to and from other formats, such as the more popular JSON (in fact, JSON is syntactically-correct YAML).
+-   It is more human readable than JSON.
+-   It is far more light-weight than other chatty formats, like XML.
+-   It is far more flexible than legacy formats like EDI.
+-   As a text-based format, it can be easily managed by revision control software, such as git.
+
+This repository is intended more for programmers than anyone else. As human-readable as the format is, it is likely to be confusing to many in its raw format. The job of the programmer is to use this spec in the development of their own software packages, websites, etc., and provide a friendly interface to the end-user.
+
+Many of the files in this repository are intended to document the Open Recipe Format. Others are examples, to help programmers understand how to best use the format. And finally, sample source code will be provided to give programmers a jump-start in their coding efforts.
+
+Getting Started
+===============
+
+This walkthrough is made to help individuals get started quickly and gain a foundational knowledge of the Open Recipe Format: [Getting Started - A Basic Recipe](tutorials/walkthrough.md)
+
+[Examples](examples.md)
+
+In addition to an Open Recipe Format, an Open Nutrition Format is being established. These two formats are described in more detail here:
+
+-   [Open Recipe Format Reference](reference/orf.md)
+-   [Open Nutrition Format Reference](reference/onf.md)
\ No newline at end of file
diff --git a/README.rst b/README.rst
deleted file mode 100644
index 1bedf54..0000000
--- a/README.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-Open Recipe Format
-==================
-
-In the beginning, there was food. And then there were dishes. And somewhere down
-the line, people started writing down how to make the dishes. And most of them
-weren't very good at it. And then they got computers, and they still weren't
-very good at it.
-
-The Open Recipe Format has been designed to solve some basic needs: accurate and 
-flexible storage of recipes. While there have been attempts in the past to
-create standardized computer recipe formats, they have so far met with failure.
-This stems from several problems, all of which stem from a lack of understanding
-of the tasks at hand (and in most cases, ignorance of which tasks actually need
-to be addressed).
-
-A significant portion of the population cooks at home, and so most solutions
-target home cooks. Commercial solutions exist, and address a host of new
-considerations that are not thought to relate to home cooks. The Open Recipe
-Format was initially created by a software engineer with a cooking degree and
-professional kitchen experience. Few, if any, other attempts at writing food
-software, much less standardized recipe data modeling, can make this claim. 
-
-At the heart of the Open Recipe Format is an established file format called
-YAML. This format was chosen for a variety of reasons:
-
-* It is text-based, and therefore human readable.
-* It mimics the internal data structures of several high-level programming
-  languages.
-* It can easily be converted to and from other formats, such as the more
-  popular JSON (in fact, JSON is syntactically-correct YAML).
-* It is more human readable than JSON.
-* It is far more light-weight than other chatty formats, like XML.
-* It is far more flexible than legacy formats like EDI.
-* As a text-based format, it can be easily managed by revision control software,
-  such as git.
-
-This repository is intended more for programmers than anyone else. As human-
-readable as the format is, it is likely to be confusing to many in its raw
-format. The job of the programmer is to use this spec in the development of
-their own software packages, websites, etc., and provide a friendly interface
-to the end-user. 
-
-Many of the files in this repository are intended to document the Open Recipe 
-Format. Others are examples, to help programmers understand how to best use the 
-format. And finally, sample source code will be provided to give programmers a
-jump-start in their coding efforts.
-
diff --git a/TODO.md b/TODO.md
new file mode 100644
index 0000000..5f0581c
--- /dev/null
+++ b/TODO.md
@@ -0,0 +1,9 @@
+# To Do
+
+This is a list of features that need to be considered for future addition to the Open Recipe Format repository.
+
+-   Add more example recipes
+-   Add a syntax checker
+-   Add a reference parser
+-   Clarify integration with USDA Standard Reference
+
diff --git a/TODO.rst b/TODO.rst
deleted file mode 100644
index f77996d..0000000
--- a/TODO.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-To Do
-=====
-
-This is a list of features that need to be considered for future addition to the
-Open Recipe Format repository.
-
-- Add more example recipes
-- Add a syntax checker
-- Add a reference parser
-- Clarify integration with USDA Standard Reference
diff --git a/_config.yml b/_config.yml
new file mode 100644
index 0000000..71e989a
--- /dev/null
+++ b/_config.yml
@@ -0,0 +1,14 @@
+title: Open Recipe Format
+
+# Build settings
+markdown: kramdown
+theme: minima
+gems:
+  - jekyll-optional-front-matter
+  - jekyll-readme-index
+  - jekyll-default-layout
+  - jekyll-titles-from-headings
+  - jekyll-relative-links
+exclude:
+  - Gemfile
+  - Gemfile.lock
diff --git a/doc/index.rst b/doc/index.rst
deleted file mode 100644
index ab33846..0000000
--- a/doc/index.rst
+++ /dev/null
@@ -1,67 +0,0 @@
-:orphan:
-
-.. _contents:
-
-Open Recipe Format
-==================
-
-In the beginning, there was food. And then there were dishes. And somewhere down
-the line, people started writing down how to make the dishes. And most of them
-weren't very good at it. And then they got computers, and they still weren't
-very good at it.
-
-The Open Recipe Format has been designed to solve some basic needs: accurate and 
-flexible storage of recipes. While there have been attempts in the past to
-create standardized computer recipe formats, they have so far met with failure.
-This stems from several problems, all of which stem from a lack of understanding
-of the tasks at hand (and in most cases, ignorance of which tasks actually need
-to be addressed).
-
-A significant portion of the population cooks at home, and so most solutions
-target home cooks. Commercial solutions exist, and address a host of new
-considerations that are not thought to relate to home cooks. The Open Recipe
-Format was initially created by a software engineer with a cooking degree and
-professional kitchen experience. Few, if any, other attempts at writing food
-software, much less standardized recipe data modeling, can make this claim. 
-
-At the heart of the Open Recipe Format is an established file format called
-YAML. This format was chosen for a variety of reasons:
-
-* It is text-based, and therefore human readable.
-* It mimics the internal data structures of several high-level programming
-  languages.
-* It can easily be converted to and from other formats, such as the more
-  popular JSON (in fact, JSON is syntactically-correct YAML).
-* It is more human readable than JSON.
-* It is far more light-weight than other chatty formats, like XML.
-* It is far more flexible than legacy formats like EDI.
-* As a text-based format, it can be easily managed by revision control software,
-  such as git.
-
-This repository is intended more for programmers than anyone else. As human-
-readable as the format is, it is likely to be confusing to many in its raw
-format. The job of the programmer is to use this spec in the development of
-their own software packages, websites, etc., and provide a friendly interface
-to the end-user. 
-
-Many of the files in this repository are intended to document the Open Recipe 
-Format. Others are examples, to help programmers understand how to best use the 
-format. And finally, sample source code is provided to give programmers a jump 
-start in their coding efforts.
-
-
-Getting Started
-===============
-
-This walkthrough is made to help individuals get started quickly and gain a
-foundational knowledge of the Open Recipe Format:
-
-:doc:`A Basic Recipe</topics/tutorials/walkthrough>`
-
-In addition to an Open Recipe Format, an Open Nutrition Format is being
-established. These two formats are described in more detail here:
-
-Developers References:
-    - :doc:`Open Recipe Format Reference<topics/reference/orf>`
-    - :doc:`Open Nutrition Format Reference<topics/reference/onf>`
-
diff --git a/doc/topics/reference/onf.rst b/doc/topics/reference/onf.rst
deleted file mode 100644
index da0222b..0000000
--- a/doc/topics/reference/onf.rst
+++ /dev/null
@@ -1,381 +0,0 @@
-Open Nutrition Format Reference
-===============================
-
-
-usda_num
---------
-Official record number matching an item in the USDA Standard Reference.
-
-usda_name
----------
-If ``usda_num`` is specified, this name may or may not match the actual name in
-the database.
-
-amount
-------
-
-unit
-----
-
-
-proximates
-----------
-
-water
-~~~~~
-nutrient_no: 255
-
-energy
-~~~~~~
-nutrient_no: 208
-
-protein
-~~~~~~~
-nutrient_no: 203
-
-lipid_total
-~~~~~~~~~~~
-nutrient_no: 204
-
-ash
-~~~
-nutrient_no: 207
-
-carbohydrate
-~~~~~~~~~~~~
-nutrient_no: 205
-
-fiber_total
-~~~~~~~~~~~
-nutrient_no: 291
-
-sugars_total
-~~~~~~~~~~~~
-nutrient_no: 269
-
-sucrose
-~~~~~~~
-nutrient_no: 210
-
-glucose
-~~~~~~~
-nutrient_no: 211
-
-fructose
-~~~~~~~~
-nutrient_no: 212
-
-lactose
-~~~~~~~
-nutrient_no: 213
-
-maltose
-~~~~~~~
-nutrient_no: 214
-
-galactose
-~~~~~~~~~
-nutrient_no: 287
-
-starch
-~~~~~~
-nutrient_no: 209
-
-
-minerals
---------
-
-calcium
-~~~~~~~
-nutrient_no: 301
-
-iron
-~~~~
-nutrient_no: 303
-
-magnesium
-~~~~~~~~~
-nutrient_no: 304
-
-phosphorus
-~~~~~~~~~~~
-nutrient_no: 305
-
-potassium
-~~~~~~~~~
-nutrient_no: 306
-
-sodium
-~~~~~~
-nutrient_no: 307
-
-zinc
-~~~~
-nutrient_no: 309
-
-copper
-~~~~~~
-nutrient_no: 312
-
-manganese
-~~~~~~~~~
-nutrient_no: 315
-
-selenium
-~~~~~~~~
-nutrient_no: 317
-
-flouride
-~~~~~~~~
-nutrient_no: 313
-
-
-vitamins
---------
-
-vitamin_c
-~~~~~~~~~
-nutrient_no: 401
-
-thiamin
-~~~~~~~
-nutrient_no: 404
-
-riboflavin
-~~~~~~~~~~
-nutrient_no: 405
-
-niacin
-~~~~~~
-nutrient_no: 406
-
-pantothenic_acid
-~~~~~~~~~~~~~~~~
-nutrient_no: 410
-
-vitamin_b6
-~~~~~~~~~~
-nutrient_no: 415
-
-folate_total
-~~~~~~~~~~~~
-nutrient_no: 417
-
-folic_acid
-~~~~~~~~~~
-nutrient_no: 431
-
-folate_food
-~~~~~~~~~~~
-nutrient_no: 432
-
-folate_dfe
-~~~~~~~~~~
-nutrient_no: 435
-
-choline_total
-~~~~~~~~~~~~~
-nutrient_no: 421
-
-betaine
-~~~~~~~
-nutrient_no:454
-
-vitamin_b12
-~~~~~~~~~~~
-nutrient_no:418
-
-vitamin_b12_added
-~~~~~~~~~~~~~~~~~
-nutrient_no: 578
-
-vitamin_a_rae
-~~~~~~~~~~~~~
-nutrient_no: 320
-
-retinol
-~~~~~~~
-nutrient_no: 319
-
-carotene_beta
-~~~~~~~~~~~~~
-nutrient_no: 321
-
-carotene_alpha
-~~~~~~~~~~~~~~
-nutrient_no: 322
-
-cryptoxanthin_beta
-~~~~~~~~~~~~~~~~~~
-nutrient_no: 334
-
-vitamin_a_iu
-~~~~~~~~~~~~
-nutrient_no: 318
-
-lycopene
-~~~~~~~~
-nutrient_no: 337
-
-lutein_zeaxanthin
-~~~~~~~~~~~~~~~~~
-nutrient_no: 338
-
-vitamin_e_alpha_tocopherol
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-nutrient_no: 323
-
-vitamin_e_added
-~~~~~~~~~~~~~~~
-nutrient_no: 573
-
-tocopherol_beta
-~~~~~~~~~~~~~~~
-nutrient_no: 341
-
-tocopherol_gamma
-~~~~~~~~~~~~~~~~
-nutrient_no: 342
-
-tocopherol_delta
-~~~~~~~~~~~~~~~~
-nutrient_no: 343
-
-vitamin_d2_d3
-~~~~~~~~~~~~~
-nutrient_no: 328
-
-vitamin_d_ergocalciferol
-~~~~~~~~~~~~~~~~~~~~~~~~
-nutrient_no: 325
-
-vitamin_d_cholecalciferol
-~~~~~~~~~~~~~~~~~~~~~~~~~
-nutrient_no: 326
-
-vitamin_d
-~~~~~~~~~
-nutrient_no: 324
-
-vitamin_k
-~~~~~~~~~
-nutrient_no: 430
-
-menaquinone_4
-~~~~~~~~~~~~~
-nutrient_no: 428
-
-
-lipids
-------
-
-total_saturated
-~~~~~~~~~~~~~~~
-nutrient_no: 606
-
-4:0
-nutrient_no: 607
-
-6:0
-nutrient_no: 608
-
-8:0
-nutrient_no: 609
-
-10:0
-nutrient_no: 610
-
-12:0
-nutrient_no: 611
-
-13:0
-nutrient_no: 696
-
-14:0
-nutrient_no: 612
-
-15:0
-nutrient_no: 652
-
-16:0
-nutrient_no: 613
-
-17:0
-nutrient_no: 653
-
-18:0
-nutrient_no: 614
-
-20:0
-nutrient_no: 615
-
-22:0
-nutrient_no: 624
-
-24:0
-nutrient_no: 654
-
-total_monounsaturated
-~~~~~~~~~~~~~~~~~~~~~
-nutrient_no: 645
-
-14:1
-nutrient_no: 625
-
-15:1
-nutrient_no: 697
-
-16:1 undifferentiated
-nutrient_no: 626
-
-16:1
-nutrient_no: 673
-
-17:1
-nutrient_no: 662
-
-18:1 undifferentiated
-nutrient_no: 617
-
-18:1 c
-nutrient_no: 674
-
-18:1 1
-nutrient_no: 663
-
-18:1-11t (18:1t n-7)
-nutrient_no: 859
-
-20:1
-nutrient_no: 628
-
-22:1 undifferentiated
-nutrient_no: 630
-
-22:1 c
-nutrient_no: 676
-
-22:1 t
-nutrient_no: 664
-
-24:1 c
-nutrient_no: 671
-
-
-total_polyunsaturated
-~~~~~~~~~~~~~~~~~~~~~
-nutrient_no: 646
-
-cholesterol
-~~~~~~~~~~~
-nutrient_no: 601
-
-
-other
------
-
-caffeine
-~~~~~~~~
-nutrient_no: 262
-
-
diff --git a/doc/topics/reference/orf.rst b/doc/topics/reference/orf.rst
deleted file mode 100644
index c0eed89..0000000
--- a/doc/topics/reference/orf.rst
+++ /dev/null
@@ -1,197 +0,0 @@
-Open Recipe Format Reference
-============================
-
-
-oven_fan
---------
-Setting to be used with convection oven. Possible values are "Off", "Low" and
-"High". If not specified, it is assumed to be "Off". If specified, all software
-should display and print this value. If not specified, it is up to the software
-whether or not it is displayed and/or printed, but it should be consistent.
-
-oven_temp
----------
-Starting oven temperature, if the oven is used.
-
-amount
-~~~~~~
-The number of degrees.
-
-unit
-~~~~
-Should be C or F.
-
-oven_time
----------
-How long the dish should spend in the oven. This is an overall value, which
-refers to the recipe as a whole. If multiple oven times are used, they should
-be specified in the recipe.
-
-ingredients
------------
-A list of dicts, defining which food items are to be added to the recipe. These
-items should be listed in the order in which they are to be used. Bearing this
-in mind, a particular item may be listed multiple times, if it is to be used
-multiple times and/or at different quantities in a recipe.
-
-To be clear, it is preferable to list "1 1/2 cups of sugar" and then "1/2 cup
-of sugar" (as specified below) than to list "2 cups sugar, divided".
-
-ingredient
-~~~~~~~~~~
-A dict of items, describing an ingredient, and how much of that ingredient to
-use.
-
-amounts
-```````
-A list of dicts which describe the amounts to use. Normally, the list will only
-contain one dict. In cases where multiple yields need to be stored (i.e. 50
-cookies vs 100 cookes vs 250 cookies), each yield will have its own dict in this
-list, in the same order as the recipe's yield field.
-
-amount
-******
-The amount of the ``unit`` to use.
-
-unit
-****
-The unit, relevant to the ``amount``.
-
-processing
-``````````
-A list of tags which describe the processing of this item. For instance,
-"whole", "large dice", "minced", "raw", "steamed", etc.
-
-notes
-`````
-Any notes specific to this ingredient.
-
-substitutions
-`````````````
-This field is a list of ingredients, in exactly the same format as a regular
-ingredient list item, minus the ``substitutions`` field. For instance, it must
-contain ``amounts``, and may also contain ``processing``, ``usda_num``,
-``notes``, etc.
-
-usda_num
-````````
-This corresponds with the index keys in the USDA Standard Reference. It is
-generally used for easy lookup of nutritional data. If possible, this should
-be used, and USDA data, when available, is preferable to any other nutritional
-data source.
-
-notes
------
-This is a field that will appear in several locations. The recipe itself may
-have noted, each ingredient may have notes, and each step may have notes.
-
-recipe_name
------------
-The name of this recipe.
-
-recipe_uuid
------------
-This functions somewhat like a network MAC address. It needs to contain an
-identifier for the company or the software package, and then a unique identifier
-for the recipe itself. This is easiest to handle when a recipe is managed either
-by a website (which likely has its own internal primary keys) or a piece of
-commerciak software that has been registered to a user, using a registration
-key.
-
-Ideally, a central source should be set up for companies to register their
-unique company identifier, to avoid UUID collisions.
-
-source_book
------------
-If this recipe was originally pulled from a book, then the book information
-should go here. Recipe software should make an intelligent effort to include
-correct information in the correct fields, rather than just dumping everything
-into a generic notes field.
-
-authors
-~~~~~~~
-This is a list. Refers to the author(s) of this recipe. Can be the same as
-``source_authors``, if appropriate. If there was only one author, then they
-would be the only item in the list.
-
-title
-~~~~~
-Title of the book. This is a single value, not a list.
-
-isbn
-~~~~
-International Standard Book Number, if available.
-
-notes
-~~~~~
-Any information about the book that does not fit into another field.
-
-X-<field>
-~~~~~~~~~
-A lot of different information about a book can be stored. Until a field has
-been officially accepted into the spec, it should start with a capital X,
-followed by a dash.
-
-source_authors
---------------
-Does not refer to the person who entered the recipe; only refers to the original
-author of the recipe. If this recipe was based on another recipe by another
-person, then this field should contain the name of the original author.
-
-source_url
-----------
-The URL that this recipe was copied from, if applicable. In the case of a
-recipe-hosting website, this may refer to the official URL at which the recipe
-is hosted.
-
-steps
------
-A list, in order, of steps to be performed on the recipe. Each item in the list
-is a dict, as specified below.
-
-step
-~~~~
-The only item in the dict that is absolutely required.
-
-haccp
-~~~~~
-A dict, which can contain either a ``control_point`` or a
-``critical_control_point``. Should not contain both.
-
-control_point
-`````````````
-Refers to specific HACCP guidelines relevant to this step.
-
-critical_control_point
-``````````````````````
-Refers to specific HACCP guidelines relevant to this step, which are critical
-to the safety outcome of this recipe. For instance, "Cook until the food
-reaches an internal temperature of 165F."
-
-notes
-~~~~~
-A list of notes relevant to this step. Often known as "bench notes" to
-professionals.
-
-yields
-------
-Refers to how much food the recipe makes. This is a list, which will normally
-contain one dict. In cases where multiple yields need to be stored (i.e. 50
-cookies vs 100 cookes vs 250 cookies), each yield will have its own dict in this
-list.
-
-amount
-~~~~~~
-The amount, relevant to the ``unit``.
-
-unit
-~~~~
-Generally "servings", but up to the user. Can be "packages", "cups", "glasses",
-etc.
-
-X-<field>
----------
-A lot of different information about a recipe can be stored. Until a field has
-been officially accepted into the spec, it should start with a capital X,
-followed by a dash.
-
diff --git a/doc/topics/tutorials/git.rst b/doc/topics/tutorials/git.rst
deleted file mode 100644
index 5ae6d88..0000000
--- a/doc/topics/tutorials/git.rst
+++ /dev/null
@@ -1,228 +0,0 @@
-Introduction to Git
-===================
-
-Using a text-based format, especially YAML, provides a powerful platform for
-recipe management. Recipes are essentially source code, using a human compiler
-rather than a machine compiler. As such, they can benefit from many of the same
-tools as computer programming languages. One of these tools that can be
-especially powerful in kitchen lab environments and recipe development is
-version control. Unfortunately, most cooks are not used to using version
-control, especially git.
-
-This document is currently targeted at developers and other technical
-professionals who are more used to using command line-based software. It assumes
-that the user has not previously used git, but can follow along with command
-line instructions. It was written for the Linux environment, but other Unices
-should not differ too terribly. Another guide, targeted at graphical
-environments such as Gnome, KDE and Windows, is planned.
-
-
-Distributed Revision Control
-============================
-Classical revision control systems used a centralized repository server, from
-which a user could check out files, modify them, and check them back in. Some
-older systems, such as CVS, would maintain version numbers of the repository
-as a whole; even checking in changes to a single file would update the version
-of every file in the repository. Some newer systems such as Subversion would
-maintain individual version numbers on each file. In either case, the central
-repository server would manage the version numbers, and was the final word on
-conflicting versions of files that were checked in.
-
-This scenerio was common in the software industry, and tended to work well for
-small software projects. However, it posed several limitations in larger
-organizations, which needed to handle multiple, disparate branches of a project
-in multiple, disparate locations. A distributed solution was needed. Several of
-these now exist, each with their own strengths. This guide focuses on git,
-partly because of its current popularity, and partly because of the author's
-own persional experience.
-
-Git was written by Linus Torvalds, creator of the Linux operating system kernel.
-It does not inherently assume a central repository, which controls all other
-checkouts of a project. Each user maintains their own repository, and with it
-the ability to send patches to another copy of the repository, and merge
-patches sent from another copy of the repository.
-
-When a repository is copied from another source, it is known as a fork. The
-process of forking a repository in git uses the `clone` command. Forked
-repositories can `pull` changes from other forks, or from the repository that
-they were cloned from. Forks can also send changes upstream to the initial
-repository using, among other options, a "pull request", in which the initial
-repository pulls changes from a fork.
-
-Confused yet? Don't worry, we'll take it step by step.
-
-
-Initializing a Repo
-===================
-This guide assumes the use of GitHub, a popular site which maintains Git
-repositories (known as "repos"), using both free and paid models. There are
-other stellar hosting options available, but by and large the usage will be the
-same.
-
-If you haven't already, go to https://github.com/ and create an account. Once
-you have signed up, you need to create a new repo. In GitHub, the icon to create
-a new repo is located in the top-right corner of the page, and looks like a book
-with a plus sign on it. Call your repo "myrecipes", and go ahead and make it
-public.
-
-Once the repo has been created on GitHub, you need to initialize it on your
-local machine. 
-
-.. code-block:: bash
-
-    localhost> mkdir -p ~/git/myrecipes
-    localhost> cd ~/git/myrecipes
-    localhost> git init
-    Initialized empty Git repository in /home/larry/git/myrecipes/.git/
-
-TODO: Push the repository to origin
-
-
-Creating a Recipe
-=================
-We'll create a simple recipe, using your favorite text editor. This recipe will
-be saved as ~/git/myrecipes/apple.yaml:
-
-.. code-block:: yaml
-
-    recipe_name: Giving an Apple to a Friend
-    ingredients:
-        - apple:
-            amounts:
-                - amount: 1
-                  unit: each
-    steps:
-        - step: Give an apple to a fiend.
-
-You may notice that this recipe contains an inconsistency. Don't worry about it,
-we'll fix it up in just a moment. For now, we'll save the recipe, and then see
-what git has to say about it.
-
-.. code-block:: bash
-
-    localhost> git status
-    # On branch master
-    #
-    # Initial commit
-    #
-    # Untracked files:
-    #   (use "git add <file>..." to include in what will be committed)
-    #
-    #   apple.yaml
-    nothing added to commit but untracked files present (use "git add" to track)
-
-Git can see that the file is there, but it's not currently tracking any changes
-to it. Let's add it, and see what git thinks about it.
-
-.. code-block:: bash
-
-    localhost> git add apple.yaml 
-    localhost> git status
-    # On branch master
-    #
-    # Initial commit
-    #
-    # Changes to be committed:
-    #   (use "git rm --cached <file>..." to unstage)
-    #
-    #   new file:   apple.yaml
-    #
-
-Git has now been notifed that `apple.yaml` is available to be added to the repo.
-However, it has not yet been checked in (or "committed", as git calls it), and
-so git is still not technically tracking changes to it. Let's go ahead and
-commit it.
-
-.. code-block:: bash
-
-    localhost> git commit -m 'This is my first commit'
-    [master (root-commit) 1617167] This is my first commit
-     1 file changed, 8 insertions(+)
-     create mode 100644 apple.yaml
-    localhost> git status
-    # On branch master
-    nothing to commit, working directory clean
-
-The `-m` option designates a commit message. This is usually a quick, one-line
-message giving a brief overview of what changes have occurred between this
-version and the previous version. With the first commit, it is usually
-reasonable to just say, "First commit". Any changes after that should be
-detailed enough that somebody in the future (who may be you) can easily identify
-when certain changes were made. One way to remind yourself to do this, is to
-assume that the next person to look at your work is a homocidal axe murderer
-who knows who you are and where you live.
-
-Git is now officially tracking changes to this file. But as you may have
-noticed before, there is an error in the recipe. The title of the recipe is,
-"Giving an Apple to a Friend", but the recipe itself states that the apple is to
-be given to a fiend. After this typo has been corrected, we can check Git to see
-how it is tracking our change.
-
-.. code-block:: bash
-
-    localhost> git diff
-    diff --git a/apple.yaml b/apple.yaml
-    index 72cd1a1..0ec3011 100644
-    --- a/apple.yaml
-    +++ b/apple.yaml
-    @@ -5,4 +5,4 @@ ingredients:
-                 - amount: 1
-                   unit: each
-     steps:
-    -    - step: Give an apple to a fiend.
-    +    - step: Give an apple to a friend.
-
-The `git diff` command shows us the difference between the old version of the
-file (`a/apple.yaml`) and the new version of the file (`b/apple.yaml`). The
-format that it uses tells us that any line starting with `-` shows a line that
-has been removed from the old version, and any line starting with `+` is a line
-that was added to the old version. In this case, the following line:
-
-.. code-block:: bash
-
-    - step: Give an apple to a fiend.
-
-Has been changed to this in the new version:
-
-.. code-block:: bash
-
-    - step: Give an apple to a friend.
-
-With the change in place, we may now add and commit a new version of this file.
-
-.. code-block:: bash
-
-    localhost> git add apple.yaml 
-    localhost> git commit -m 'Correcting typo: friend, not fiend'
-    [master 4f59a41] Correcting typo: friend, not fiend
-     1 file changed, 1 insertion(+), 1 deletion(-)
-
-At this point, two different versions of the file exist in the git repo. This is
-the important part of revision control: we can go back and look at old versions,
-and compare how something is done now with how it was done before. This can be
-especially important when doing recipe testing; somethings it helps to see how
-a recipe has evolved over time.
-
-Since we've left reasonable commit messages in git, we can go back and see, at a
-glace, where certain changes were made.
-
-.. code-block:: bash
-
-    localhost> git log
-    commit 4f59a41a9bc0e06f2858302ce3332d336140ca7f
-    Author: Larry Fine <larry@stooges.com>
-    Date:   Sat Jun 22 14:33:29 2013 -0600
-    
-        Correcting typo: friend, not fiend
-    
-    commit 824ba5bc2aa4cb07f33a82c9f1f833debb5fd055
-    Author: Larry Fine <larry@stooges.com>
-    Date:   Sat Jun 22 14:22:57 2013 -0600
-    
-        This is my first commit
-
-You can see that log messages are displayed in reverse order (most recent
-first). If we had enough entries that this output took up more than a single
-screen, git would have automatically displayed it using the default paging
-program on your system.
-
diff --git a/doc/topics/tutorials/using-alerts.rst b/doc/topics/tutorials/using-alerts.rst
deleted file mode 100644
index 0eb6647..0000000
--- a/doc/topics/tutorials/using-alerts.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-Using Alerts
-============
-The Open Recipe Format allows each step of a recipe to include extra, computer-
-readable information about that step. For instance, a duration may be stored,
-such as `25M` (25 minutes). Durations are based on the Unix `date` command, and
-include:
-
-* S: Seconds
-* M: Minutes
-* H: Hours
-* d: Days
-* W: Weeks
-* m: Months
-* Y: Years
-
-Please note that as with the `date` command, these abbreviations are case-
-sensitive; `M` refers to minutes, while `m` refers to months.
-
-Long-Term Durations
-===================
-The first question in many cooks' minds will be, why worry about anything longer
-than hours? Bear in mind that this format is intended to be usable in any
-situation where food is to be prepared. The following are all valid use cases:
-
-* Curing a duck breast prosciutto for several days.
-* Dry-curing an Italian sausage for several weeks.
-* Allowing vanilla beans to soak in vodka for several months.
-* Allowing whiskey to age in barrels for several years.
-
-Software-Based Alerts
-=====================
-With these considerations in mind, software can be written that helps the cook
-manage recipes, and alert the cook when an action needs to be taken.
-
-For instance, mobile recipe software can not only display the steps of a recipe,
-but also allow a cook to press a button when putting a tray of cookies into the
-oven, which will trigger an alarm 12 minutes later to remove them from the oven.
-Software designed for cheesemakers can be set up to add an item to a person's
-calendar, or send an email, when a particular batch of cheese needs to be
-checked. Such software should assume that multiple batches are being processed
-at once, and allow the food producer to store their own internal storage
-information (bin codes, batch dates, etc) within the software.
-
-Examples
-========
-.. include:: <duck-prosciutto.yaml>
-
diff --git a/doc/topics/tutorials/walkthrough.rst b/doc/topics/tutorials/walkthrough.rst
deleted file mode 100644
index c682d39..0000000
--- a/doc/topics/tutorials/walkthrough.rst
+++ /dev/null
@@ -1,200 +0,0 @@
-Getting Started
-===============
-
-The Open Recipe Format was designed to be as simple as possible for basic
-applications, while also being flexible enough to handle various complexities
-that may be encountered in production environments. This guide outlines the
-basic file format, what needs to be defined at a bare minimum, and how to put it
-all together.
-
-At its heart, the Open Recipe Format (ORF) uses an established file format
-called YAML. It's not a difficult format to get used to, but using a syntax
-checker will save you from a lot of headaches. An excellent online resource can
-be found at `http://yaml-online-parser.appspot.com/`.
-
-At its most basic level, a recipe consists of a name, a list of ingredients, and
-a list of steps to put those ingredients together. At this point, the most
-complex of these is the ingredient list. Each item in the list consists of an
-amount, a unit (which is often implied, in traditional recipes), and a
-corresponding ingredient.
-
-Let's put together a very basic recipe for giving an apple to a friend. In a
-non-computer parsable format, we might say, "Give an apple to a friend." To make
-this easier for the computer to use, we need to be more specific:
-
-.. code-block:: yaml
-
-    recipe_name: Giving an Apple to a Friend
-    ingredients:
-        - apple:
-            amounts:
-                - amount: 1
-                  unit: each
-    steps:
-        - step: Give an apple to a friend.
-
-This is as basic as a recipe gets. Because we are striving to be specific, there
-is nothing implied in this recipe; if we were writing it out traditionally, we
-would say `1 each apple` instead of `1 apple`. This may feel awkward to some,
-and developers may choose to allow their users to say `1 apple` in their
-software, but when they save it to an ORF file, it needs to be more specific.
-
-Let's expand this recipe, to include more fruit, and more steps for handling the
-fruit. This recipe is for a very basic fruit salad, which is unlikely to win any
-awards, but will still feed your friends.
-
-.. code-block:: yaml
-
-    recipe_name: Basic Fruit Salad
-    yields:
-        - servings: 6
-    ingredients:
-        - apple:
-            amounts:
-                - amount: 1
-                  unit: each
-        - banana:
-            amounts:
-                - amount: 1
-                  unit: each
-        - orange:
-            amounts:
-                - amount: 1
-                  unit: each
-        - grapes:
-            amounts:
-                - amount: 1
-                  unit: cup
-    steps:
-        - step: Cut the apple into cubes.
-        - step: Cut the banana into slices.
-        - step: Peel the orange, and divide into segments.
-        - step: Combine all ingredients in a bowl.
-        - step: Mix to combine.
-
-This recipe is fine for 6 people, but what if you need to feed 18 people? An
-important consideration that most recipe software handles is scaling recipes.
-However, many commercial environments require multiple scalings to be available
-in a tidy, concise format. In our case, we would make the following changes to
-our recipe to handle both at the same time:
-
-.. code-block:: yaml
-
-    recipe_name: Basic Fruit Salad
-    yields:
-        - servings: 6
-        - servings: 18
-    ingredients:
-        - apple:
-            amounts:
-                - amount: 1
-                  unit: each
-                - amount: 3
-                  unit: each
-        - banana:
-            amounts:
-                - amount: 1
-                  unit: each
-                - amount: 3
-                  unit: each
-        - orange:
-            amounts:
-                - amount: 1
-                  unit: each
-                - amount: 3
-                  unit: each
-        - grapes:
-            amounts:
-                - amount: 1
-                  unit: cup
-                - amount: 3
-                  unit: cup
-
-A classic use case for this scenario is a bakery, which may need to bake batches
-of 50, 100, 250, or even more cookies at a time, depending on the occassion.
-Unfortunately, ingredients are the product of nature, and not all recipes scale
-as nicely as we would like. It may be that in the case of our bakery, 50 cookies
-call for 1/2 tablespoon of baking soda, but 250 cookies only calls for 2
-tablespoons. It is up to the baker to discover this, but when they do, it will
-be aggrivating to them to not be able to make note of that in their software.
-
-Speaking of notes, many professional cooks and bakers like to make bench notes
-when experimenting with recipes. These items of information do not necessarily
-fit into the classic "steps" format. Fortunately, ORF allows for "notes" to be
-saved, both alongside specific steps, and outside of the steps. Let's go back
-to our first recipe, and add some notes.
-
-.. code-block:: yaml
-
-    recipe_name: Giving an Apple to a Friend
-    ingredients:
-        - apple:
-            amounts:
-                - amount: 1
-                  unit: each
-            notes:
-                - Use whole apples
-                - Pears may be substituted, but produce a different flavor and mouthfeel
-    steps:
-        - step: Give an apple to a friend.
-          notes:
-            - You can also give an apple to an enemy.
-    notes:
-        - This is a friendly recipe; giving, rather than throwing, is recommended.
-
-This recipe contains notes for individual ingredients and steps, as well as
-for the recipe as a whole. While it is not expected that most cooks, even in the
-professional kitchen, will take advantage of this, it is fully expected that
-food scientists will have the opportunity to do so.
-
-Food scientists have a whole new set of information that they need to manage.
-Precision is key for these individuals, and ORF is designed to handle features
-that are key to their job success. Consider the following:
-
-
-.. code-block:: yaml
-
-    ingredients:
-        - apple:
-            usda_num: 09003
-            amounts:
-                - amount: 1
-                  unit: each
-            processing:
-                - whole
-                - raw
-            substitutions:
-                - pears:
-                    usda_num: 09252
-                    amounts:
-                        - amount: 1
-                          unit: each
-            notes:
-                - Use whole apples
-                - Pears may be substituted, but produce a different flavor and mouthfeel
-    steps:
-        - step:
-              Gather the apples.
-          haccp:
-              control_point: The apples must be clean
-          notes:
-              - Some people like green
-              - Some people like red
-        - step:
-              Hand out the apples.
-          haccp:
-              critical_control_point: Wash hands with soap and warm water before distributing.
-
-This set of ingredients and steps includes a scary amount of detail, for the
-average layperson. However, it paves the way for the industrialization and
-safety of this recipe, allowing the user to specify keywords related to
-processing, and 
-:doc:`HACCP (Hazard Analysis Critical Control Points)</topics/tutorials/haccp>`
-instructions to be declared. References to the
-:doc:`USDA Standard Reference</topics/tutorials/usda>`
-are also included, allowing the recipe to make use of nutritional data
-provided by the USDA.
-
-Now that you have been through a brief overview of the format and its
-capabilities, the other tutorials and references will make much more sense.
-
diff --git a/examples.md b/examples.md
new file mode 100644
index 0000000..1ea18db
--- /dev/null
+++ b/examples.md
@@ -0,0 +1,6 @@
+---
+title: Examples
+---
+
+* [Banana Bread](examples/banana-bread.yaml)
+* [Sample File](examples/orf-sample-1.yaml)
diff --git a/examples/banana-bread.yaml b/examples/banana-bread.yaml
index 8e0f08f..97bc8a1 100644
--- a/examples/banana-bread.yaml
+++ b/examples/banana-bread.yaml
@@ -10,101 +10,101 @@ yields:
   - loaves: 3
 ingredients:
   - All Purpose Flour:
-    usda_num: 20581
-    amounts:
-      - amount: 3 1/2
-        unit: cups
-    substitutions:
-      - Oat Flour:
-        usda_num: '08122'
-        amounts:
-          - amount: '3 1/2'
-            unit: cups
-        notes:
-          - Make oat flour by processing instant oats in food processor.
+      usda_num: 20581
+      amounts:
+        - amount: 3 1/2
+          unit: cups
+      substitutions:
+        - Oat Flour:
+          usda_num: '08122'
+          amounts:
+            - amount: '3 1/2'
+              unit: cups
+          notes:
+            - Make oat flour by processing instant oats in food processor.
   - Baking Soda:
-    usda_num: 18372
-    amounts:
-      - amount: 2
-        unit: tsp
+      usda_num: 18372
+      amounts:
+        - amount: 2
+          unit: tsp
   - Baking Powder:
-    usda_num: 18369
-    amounts:
-      - amount: 2
-        unit: tsp
+      usda_num: 18369
+      amounts:
+        - amount: 2
+          unit: tsp
   - Salt:
-    usda_num: '02047'
-    amounts:
-      - amount: 1
-        unit: tsp
+      usda_num: '02047'
+      amounts:
+        - amount: 1
+          unit: tsp
   - Cinnamon, Ground:
-    usda_num: '02010'
-    amounts:
-      - amount: 2
-        unit: tsp
+      usda_num: '02010'
+      amounts:
+        - amount: 2
+          unit: tsp
   - Cloves, Ground:
-    usda_num: '02011'
-    amounts:
-      - amount: 1
-        unit: tsp
+      usda_num: '02011'
+      amounts:
+        - amount: 1
+          unit: tsp
   - Nutmeg, Ground:
-    usda_num: '02025'
-    amounts:
-      - amount: 1
-        unit: tsp
+      usda_num: '02025'
+      amounts:
+        - amount: 1
+          unit: tsp
   - Butter, Unsalted:
-    usda_num: '01145'
-    amounts:
-      - amount: 1
-        unit: cup
-    notes:
-      - Melted
+      usda_num: '01145'
+      amounts:
+        - amount: 1
+          unit: cup
+      notes:
+        - Melted
   - Granulated Sugar:
-    usda_num: 19335
-    amounts:
-      - amount: '1 1/2'
-        unit: cups
+      usda_num: 19335
+      amounts:
+        - amount: '1 1/2'
+          unit: cups
   - Bananas:
-    usda_num: '09040'
-    amounts:
-      - amount: 6
-        unit: each
+      usda_num: '09040'
+      amounts:
+        - amount: 6
+          unit: each
   - Eggs, Large:
-    usda_num: '01123'
-    amounts:
-      - amount: 4
-        unit: cups
+      usda_num: '01123'
+      amounts:
+        - amount: 4
+          unit: cups
   - Vanilla Extract:
-    usda_num: '02050'
-    amounts:
-      - amount: 2
-        unit: tsp
+      usda_num: '02050'
+      amounts:
+        - amount: 2
+          unit: tsp
   - Chocolate Chips, Bittersweet:
-    usda_num: 19080
-    amounts:
-      - amount: 2
-        unit: cups
-    notes:
-      - Optional
+      usda_num: 19080
+      amounts:
+        - amount: 2
+          unit: cups
+      notes:
+        - Optional
 steps:
   - step:
-    Preheat oven to 350F.
+      Preheat oven to 350F.
   - step:
-    Whisk together the flour, baking soda, baking powder, salt, cinnamon, cloves and nutmeg.
+      Whisk together the flour, baking soda, baking powder, salt, cinnamon, cloves and nutmeg.
   - step:
-    Roughly mash the bananas with a potato masher.
+      Roughly mash the bananas with a potato masher.
   - step:
-    Mix the bananas, melted butter, sugar, eggs and vanilla extract.
+      Mix the bananas, melted butter, sugar, eggs and vanilla extract.
   - step:
-    Combine the wet ingredients with the dry ingredients.
+      Combine the wet ingredients with the dry ingredients.
   - step:
-    Mix with a rubber spatula, until just combined. Be careful not to overmix.
+      Mix with a rubber spatula, until just combined. Be careful not to overmix.
   - step:
-    Gently fold in the chocolate chips.
+      Gently fold in the chocolate chips.
   - step:
-    Pour into prepared bread pans.
+      Pour into prepared bread pans.
   - step:
-    Bake at 350F until a toothpick inserted in the center comes out clean.
+      Bake at 350F until a toothpick inserted in the center comes out clean.
 notes:
   - This recipe is designed for high altitude (~4500 ft) baking.
   - Other than the chocolate chips, this recipe may serve as a reference recipe for banana bread. Other ingredients may be used in addition to or instead of the chocolate chips, or they may be ommitted entirely.
diff --git a/examples/orf-sample-1.yaml b/examples/orf-sample-1.yaml
index 22f380f..5890c2d 100644
--- a/examples/orf-sample-1.yaml
+++ b/examples/orf-sample-1.yaml
@@ -8,53 +8,53 @@ oven_fan: none
 bake_time: none
 yields:
   - servings:
-    4
+      4
   - servings:
-    10
+      10
 ingredients:
   - apple:
-    usda_num: 09003
-    amounts:
-      - amount: 4
-        unit: each
-      - amount: 10
-        unit: each
-    processing:
-      - whole
-      - raw
-    substitutions:
-      - pears:
-        usda_num: 09252
-        amounts:
-          - amount: 4
-            unit: each
-          - amount: 10
-            unit: each
-    notes:
-      - Use whole apples
-      - Pears may be substituted, but produce a different flavor and mouthfeel
+      usda_num: 09003
+      amounts:
+        - amount: 4
+          unit: each
+        - amount: 10
+          unit: each
+      processing:
+        - whole
+        - raw
+      substitutions:
+        - pears:
+          usda_num: 09252
+          amounts:
+            - amount: 4
+              unit: each
+            - amount: 10
+              unit: each
+      notes:
+        - Use whole apples
+        - Pears may be substituted, but produce a different flavor and mouthfeel
   - banana:
-    usda_num: 09040
-    amounts:
-      - amount: 4
-        unit: each
-      - amount: 10
-        unit: each
+      usda_num: 09040
+      amounts:
+        - amount: 4
+          unit: each
+        - amount: 10
+          unit: each
 steps:
   - step:
-    Hand out the apples
+      Hand out the apples
     haccp: The apples must be clean
     notes:
     - Some people like green
     - Some people like red
   - step:
-    Hand out the bananas
+      Hand out the bananas
     haccp: The bananas must be clean
     notes:
     - Some people like green
     - Most people don't like black 
   - step:
-    Enjoy
+      Enjoy
 notes:
   - This is a note
   - This is another note
diff --git a/reference/onf.md b/reference/onf.md
new file mode 100644
index 0000000..d3ca2c4
--- /dev/null
+++ b/reference/onf.md
@@ -0,0 +1,347 @@
+# Open Nutrition Format Reference
+
+* TOC
+{:toc}
+
+usda\_num
+---------
+
+Official record number matching an item in the USDA Standard Reference.
+
+usda\_name
+----------
+
+If `usda_num` is specified, this name may or may not match the actual name in the database.
+
+amount
+------
+
+unit
+----
+
+proximates
+----------
+
+### water
+
+nutrient\_no: 255
+
+### energy
+
+nutrient\_no: 208
+
+### protein
+
+nutrient\_no: 203
+
+### lipid\_total
+
+nutrient\_no: 204
+
+### ash
+
+nutrient\_no: 207
+
+### carbohydrate
+
+nutrient\_no: 205
+
+### fiber\_total
+
+nutrient\_no: 291
+
+### sugars\_total
+
+nutrient\_no: 269
+
+### sucrose
+
+nutrient\_no: 210
+
+### glucose
+
+nutrient\_no: 211
+
+### fructose
+
+nutrient\_no: 212
+
+### lactose
+
+nutrient\_no: 213
+
+### maltose
+
+nutrient\_no: 214
+
+### galactose
+
+nutrient\_no: 287
+
+### starch
+
+nutrient\_no: 209
+
+minerals
+--------
+
+### calcium
+
+nutrient\_no: 301
+
+### iron
+
+nutrient\_no: 303
+
+### magnesium
+
+nutrient\_no: 304
+
+### phosphorus
+
+nutrient\_no: 305
+
+### potassium
+
+nutrient\_no: 306
+
+### sodium
+
+nutrient\_no: 307
+
+### zinc
+
+nutrient\_no: 309
+
+### copper
+
+nutrient\_no: 312
+
+### manganese
+
+nutrient\_no: 315
+
+### selenium
+
+nutrient\_no: 317
+
+### flouride
+
+nutrient\_no: 313
+
+vitamins
+--------
+
+### vitamin\_c
+
+nutrient\_no: 401
+
+### thiamin
+
+nutrient\_no: 404
+
+### riboflavin
+
+nutrient\_no: 405
+
+### niacin
+
+nutrient\_no: 406
+
+### pantothenic\_acid
+
+nutrient\_no: 410
+
+### vitamin\_b6
+
+nutrient\_no: 415
+
+### folate\_total
+
+nutrient\_no: 417
+
+### folic\_acid
+
+nutrient\_no: 431
+
+### folate\_food
+
+nutrient\_no: 432
+
+### folate\_dfe
+
+nutrient\_no: 435
+
+### choline\_total
+
+nutrient\_no: 421
+
+### betaine
+
+nutrient\_no:454
+
+### vitamin\_b12
+
+nutrient\_no:418
+
+### vitamin\_b12\_added
+
+nutrient\_no: 578
+
+### vitamin\_a\_rae
+
+nutrient\_no: 320
+
+### retinol
+
+nutrient\_no: 319
+
+### carotene\_beta
+
+nutrient\_no: 321
+
+### carotene\_alpha
+
+nutrient\_no: 322
+
+### cryptoxanthin\_beta
+
+nutrient\_no: 334
+
+### vitamin\_a\_iu
+
+nutrient\_no: 318
+
+### lycopene
+
+nutrient\_no: 337
+
+### lutein\_zeaxanthin
+
+nutrient\_no: 338
+
+### vitamin\_e\_alpha\_tocopherol
+
+nutrient\_no: 323
+
+### vitamin\_e\_added
+
+nutrient\_no: 573
+
+### tocopherol\_beta
+
+nutrient\_no: 341
+
+### tocopherol\_gamma
+
+nutrient\_no: 342
+
+### tocopherol\_delta
+
+nutrient\_no: 343
+
+### vitamin\_d2\_d3
+
+nutrient\_no: 328
+
+### vitamin\_d\_ergocalciferol
+
+nutrient\_no: 325
+
+### vitamin\_d\_cholecalciferol
+
+nutrient\_no: 326
+
+### vitamin\_d
+
+nutrient\_no: 324
+
+### vitamin\_k
+
+nutrient\_no: 430
+
+### menaquinone\_4
+
+nutrient\_no: 428
+
+lipids
+------
+
+### total\_saturated
+
+nutrient\_no: 606
+
+4:0 nutrient\_no: 607
+
+6:0 nutrient\_no: 608
+
+8:0 nutrient\_no: 609
+
+10:0 nutrient\_no: 610
+
+12:0 nutrient\_no: 611
+
+13:0 nutrient\_no: 696
+
+14:0 nutrient\_no: 612
+
+15:0 nutrient\_no: 652
+
+16:0 nutrient\_no: 613
+
+17:0 nutrient\_no: 653
+
+18:0 nutrient\_no: 614
+
+20:0 nutrient\_no: 615
+
+22:0 nutrient\_no: 624
+
+24:0 nutrient\_no: 654
+
+### total\_monounsaturated
+
+nutrient\_no: 645
+
+14:1 nutrient\_no: 625
+
+15:1 nutrient\_no: 697
+
+16:1 undifferentiated nutrient\_no: 626
+
+16:1 nutrient\_no: 673
+
+17:1 nutrient\_no: 662
+
+18:1 undifferentiated nutrient\_no: 617
+
+18:1 c nutrient\_no: 674
+
+18:1 1 nutrient\_no: 663
+
+18:1-11t (18:1t n-7) nutrient\_no: 859
+
+20:1 nutrient\_no: 628
+
+22:1 undifferentiated nutrient\_no: 630
+
+22:1 c nutrient\_no: 676
+
+22:1 t nutrient\_no: 664
+
+24:1 c nutrient\_no: 671
+
+### total\_polyunsaturated
+
+nutrient\_no: 646
+
+### cholesterol
+
+nutrient\_no: 601
+
+other
+-----
+
+### caffeine
+
+nutrient\_no: 262
diff --git a/reference/orf.md b/reference/orf.md
new file mode 100644
index 0000000..4d560b1
--- /dev/null
+++ b/reference/orf.md
@@ -0,0 +1,161 @@
+# Open Recipe Format Reference
+
+* TOC
+{:toc}
+
+oven\_fan
+---------
+
+Setting to be used with convection oven. Possible values are "Off", "Low" and "High". If not specified, it is assumed to be "Off". If specified, all software should display and print this value. If not specified, it is up to the software whether or not it is displayed and/or printed, but it should be consistent.
+
+oven\_temp
+----------
+
+Starting oven temperature, if the oven is used.
+
+### amount
+
+The number of degrees.
+
+### unit
+
+Should be C or F.
+
+oven\_time
+----------
+
+How long the dish should spend in the oven. This is an overall value, which refers to the recipe as a whole. If multiple oven times are used, they should be specified in the recipe.
+
+ingredients
+-----------
+
+A list of dicts, defining which food items are to be added to the recipe. These items should be listed in the order in which they are to be used. Bearing this in mind, a particular item may be listed multiple times, if it is to be used multiple times and/or at different quantities in a recipe.
+
+To be clear, it is preferable to list "1 1/2 cups of sugar" and then "1/2 cup of sugar" (as specified below) than to list "2 cups sugar, divided".
+
+### ingredient
+
+A dict of items, describing an ingredient, and how much of that ingredient to use.
+
+#### amounts
+
+A list of dicts which describe the amounts to use. Normally, the list will only contain one dict. In cases where multiple yields need to be stored (i.e. 50 cookies vs 100 cookes vs 250 cookies), each yield will have its own dict in this list, in the same order as the recipe's yield field.
+
+##### amount
+
+The amount of the `unit` to use.
+
+##### unit
+
+The unit, relevant to the `amount`.
+
+#### processing
+
+A list of tags which describe the processing of this item. For instance, "whole", "large dice", "minced", "raw", "steamed", etc.
+
+#### notes
+
+Any notes specific to this ingredient.
+
+#### substitutions
+
+This field is a list of ingredients, in exactly the same format as a regular ingredient list item, minus the `substitutions` field. For instance, it must contain `amounts`, and may also contain `processing`, `usda_num`, `notes`, etc.
+
+#### usda\_num
+
+This corresponds with the index keys in the USDA Standard Reference. It is generally used for easy lookup of nutritional data. If possible, this should be used, and USDA data, when available, is preferable to any other nutritional data source.
+
+notes
+-----
+
+This is a field that will appear in several locations. The recipe itself may have noted, each ingredient may have notes, and each step may have notes.
+
+recipe\_name
+------------
+
+The name of this recipe.
+
+recipe\_uuid
+------------
+
+This functions somewhat like a network MAC address. It needs to contain an identifier for the company or the software package, and then a unique identifier for the recipe itself. This is easiest to handle when a recipe is managed either by a website (which likely has its own internal primary keys) or a piece of commerciak software that has been registered to a user, using a registration key.
+
+Ideally, a central source should be set up for companies to register their unique company identifier, to avoid UUID collisions.
+
+source\_book
+------------
+
+If this recipe was originally pulled from a book, then the book information should go here. Recipe software should make an intelligent effort to include correct information in the correct fields, rather than just dumping everything into a generic notes field.
+
+### authors
+
+This is a list. Refers to the author(s) of this recipe. Can be the same as `source_authors`, if appropriate. If there was only one author, then they would be the only item in the list.
+
+### title
+
+Title of the book. This is a single value, not a list.
+
+### isbn
+
+International Standard Book Number, if available.
+
+### notes
+
+Any information about the book that does not fit into another field.
+
+### X-&lt;field&gt;
+
+A lot of different information about a book can be stored. Until a field has been officially accepted into the spec, it should start with a capital X, followed by a dash.
+
+source\_authors
+---------------
+
+Does not refer to the person who entered the recipe; only refers to the original author of the recipe. If this recipe was based on another recipe by another person, then this field should contain the name of the original author.
+
+source\_url
+-----------
+
+The URL that this recipe was copied from, if applicable. In the case of a recipe-hosting website, this may refer to the official URL at which the recipe is hosted.
+
+steps
+-----
+
+A list, in order, of steps to be performed on the recipe. Each item in the list is a dict, as specified below.
+
+### step
+
+The only item in the dict that is absolutely required.
+
+### haccp
+
+A dict, which can contain either a `control_point` or a `critical_control_point`. Should not contain both.
+
+#### control\_point
+
+Refers to specific HACCP guidelines relevant to this step.
+
+#### critical\_control\_point
+
+Refers to specific HACCP guidelines relevant to this step, which are critical to the safety outcome of this recipe. For instance, "Cook until the food reaches an internal temperature of 165F."
+
+### notes
+
+A list of notes relevant to this step. Often known as "bench notes" to professionals.
+
+yields
+------
+
+Refers to how much food the recipe makes. This is a list, which will normally contain one dict. In cases where multiple yields need to be stored (i.e. 50 cookies vs 100 cookes vs 250 cookies), each yield will have its own dict in this list.
+
+### amount
+
+The amount, relevant to the `unit`.
+
+### unit
+
+Generally "servings", but up to the user. Can be "packages", "cups", "glasses", etc.
+
+X-&lt;field&gt;
+---------------
+
+A lot of different information about a recipe can be stored. Until a field has been officially accepted into the spec, it should start with a capital X, followed by a dash.
diff --git a/tutorials/git.md b/tutorials/git.md
new file mode 100644
index 0000000..a8ca65e
--- /dev/null
+++ b/tutorials/git.md
@@ -0,0 +1,155 @@
+# Introduction to Git
+
+Using a text-based format, especially YAML, provides a powerful platform for recipe management. Recipes are essentially source code, using a human compiler rather than a machine compiler. As such, they can benefit from many of the same tools as computer programming languages. One of these tools that can be especially powerful in kitchen lab environments and recipe development is version control. Unfortunately, most cooks are not used to using version control, especially git.
+
+This document is currently targeted at developers and other technical professionals who are more used to using command line-based software. It assumes that the user has not previously used git, but can follow along with command line instructions. It was written for the Linux environment, but other Unices should not differ too terribly. Another guide, targeted at graphical environments such as Gnome, KDE and Windows, is planned.
+
+Distributed Revision Control
+============================
+
+Classical revision control systems used a centralized repository server, from which a user could check out files, modify them, and check them back in. Some older systems, such as CVS, would maintain version numbers of the repository as a whole; even checking in changes to a single file would update the version of every file in the repository. Some newer systems such as Subversion would maintain individual version numbers on each file. In either case, the central repository server would manage the version numbers, and was the final word on conflicting versions of files that were checked in.
+
+This scenerio was common in the software industry, and tended to work well for small software projects. However, it posed several limitations in larger organizations, which needed to handle multiple, disparate branches of a project in multiple, disparate locations. A distributed solution was needed. Several of these now exist, each with their own strengths. This guide focuses on git, partly because of its current popularity, and partly because of the author's own persional experience.
+
+Git was written by Linus Torvalds, creator of the Linux operating system kernel. It does not inherently assume a central repository, which controls all other checkouts of a project. Each user maintains their own repository, and with it the ability to send patches to another copy of the repository, and merge patches sent from another copy of the repository.
+
+When a repository is copied from another source, it is known as a fork. The process of forking a repository in git uses the clone command. Forked repositories can pull changes from other forks, or from the repository that they were cloned from. Forks can also send changes upstream to the initial repository using, among other options, a "pull request", in which the initial repository pulls changes from a fork.
+
+Confused yet? Don't worry, we'll take it step by step.
+
+Initializing a Repo
+===================
+
+This guide assumes the use of GitHub, a popular site which maintains Git repositories (known as "repos"), using both free and paid models. There are other stellar hosting options available, but by and large the usage will be the same.
+
+If you haven't already, go to <https://github.com/> and create an account. Once you have signed up, you need to create a new repo. In GitHub, the icon to create a new repo is located in the top-right corner of the page, and looks like a book with a plus sign on it. Call your repo "myrecipes", and go ahead and make it public.
+
+Once the repo has been created on GitHub, you need to initialize it on your local machine.
+
+``` shell
+localhost> mkdir -p ~/git/myrecipes
+localhost> cd ~/git/myrecipes
+localhost> git init
+Initialized empty Git repository in /home/larry/git/myrecipes/.git/
+```
+
+TODO: Push the repository to origin
+
+Creating a Recipe
+=================
+
+We'll create a simple recipe, using your favorite text editor. This recipe will be saved as ~/git/myrecipes/apple.yaml:
+
+``` shell
+recipe_name: Giving an Apple to a Friend
+ingredients:
+    - apple:
+        amounts:
+            - amount: 1
+              unit: each
+steps:
+    - step: Give an apple to a fiend.
+```
+
+You may notice that this recipe contains an inconsistency. Don't worry about it, we'll fix it up in just a moment. For now, we'll save the recipe, and then see what git has to say about it.
+
+``` shell
+localhost> git status
+# On branch master
+#
+# Initial commit
+#
+# Untracked files:
+#   (use "git add <file>..." to include in what will be committed)
+#
+#   apple.yaml
+nothing added to commit but untracked files present (use "git add" to track)
+```
+
+Git can see that the file is there, but it's not currently tracking any changes to it. Let's add it, and see what git thinks about it.
+
+``` shell
+localhost> git add apple.yaml 
+localhost> git status
+# On branch master
+#
+# Initial commit
+#
+# Changes to be committed:
+#   (use "git rm --cached <file>..." to unstage)
+#
+#   new file:   apple.yaml
+#
+```
+
+Git has now been notifed that apple.yaml is available to be added to the repo. However, it has not yet been checked in (or "committed", as git calls it), and so git is still not technically tracking changes to it. Let's go ahead and commit it.
+
+``` shell
+localhost> git commit -m 'This is my first commit'
+[master (root-commit) 1617167] This is my first commit
+ 1 file changed, 8 insertions(+)
+ create mode 100644 apple.yaml
+localhost> git status
+# On branch master
+nothing to commit, working directory clean
+```
+
+The -m option designates a commit message. This is usually a quick, one-line message giving a brief overview of what changes have occurred between this version and the previous version. With the first commit, it is usually reasonable to just say, "First commit". Any changes after that should be detailed enough that somebody in the future (who may be you) can easily identify when certain changes were made. One way to remind yourself to do this, is to assume that the next person to look at your work is a homocidal axe murderer who knows who you are and where you live.
+
+Git is now officially tracking changes to this file. But as you may have noticed before, there is an error in the recipe. The title of the recipe is, "Giving an Apple to a Friend", but the recipe itself states that the apple is to be given to a fiend. After this typo has been corrected, we can check Git to see how it is tracking our change.
+
+``` diff
+localhost> git diff
+diff --git a/apple.yaml b/apple.yaml
+index 72cd1a1..0ec3011 100644
+--- a/apple.yaml
++++ b/apple.yaml
+@@ -5,4 +5,4 @@ ingredients:
+             - amount: 1
+               unit: each
+ steps:
+-    - step: Give an apple to a fiend.
++    - step: Give an apple to a friend.
+```
+
+The git diff command shows us the difference between the old version of the file (a/apple.yaml) and the new version of the file (b/apple.yaml). The format that it uses tells us that any line starting with - shows a line that has been removed from the old version, and any line starting with + is a line that was added to the old version. In this case, the following line:
+
+``` yaml
+- step: Give an apple to a fiend.
+```
+
+Has been changed to this in the new version:
+
+``` yaml
+- step: Give an apple to a friend.
+```
+
+With the change in place, we may now add and commit a new version of this file.
+
+``` shell
+localhost> git add apple.yaml 
+localhost> git commit -m 'Correcting typo: friend, not fiend'
+[master 4f59a41] Correcting typo: friend, not fiend
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+```
+
+At this point, two different versions of the file exist in the git repo. This is the important part of revision control: we can go back and look at old versions, and compare how something is done now with how it was done before. This can be especially important when doing recipe testing; somethings it helps to see how a recipe has evolved over time.
+
+Since we've left reasonable commit messages in git, we can go back and see, at a glace, where certain changes were made.
+
+``` shell
+localhost> git log
+commit 4f59a41a9bc0e06f2858302ce3332d336140ca7f
+Author: Larry Fine <larry@stooges.com>
+Date:   Sat Jun 22 14:33:29 2013 -0600
+
+    Correcting typo: friend, not fiend
+
+commit 824ba5bc2aa4cb07f33a82c9f1f833debb5fd055
+Author: Larry Fine <larry@stooges.com>
+Date:   Sat Jun 22 14:22:57 2013 -0600
+
+    This is my first commit
+```
+
+You can see that log messages are displayed in reverse order (most recent first). If we had enough entries that this output took up more than a single screen, git would have automatically displayed it using the default paging program on your system.
diff --git a/tutorials/using-alerts.md b/tutorials/using-alerts.md
new file mode 100644
index 0000000..2e9871b
--- /dev/null
+++ b/tutorials/using-alerts.md
@@ -0,0 +1,33 @@
+# Using Alerts
+
+The Open Recipe Format allows each step of a recipe to include extra, computer-readable information about that step. For instance, a duration may be stored, such as 25M (25 minutes). Durations are based on the Unix date command, and include:
+
+-   S: Seconds
+-   M: Minutes
+-   H: Hours
+-   d: Days
+-   W: Weeks
+-   m: Months
+-   Y: Years
+
+Please note that as with the date command, these abbreviations are case-sensitive; M refers to minutes, while m refers to months.
+
+Long-Term Durations
+===================
+
+The first question in many cooks' minds will be, why worry about anything longer than hours? Bear in mind that this format is intended to be usable in any situation where food is to be prepared. The following are all valid use cases:
+
+-   Curing a duck breast prosciutto for several days.
+-   Dry-curing an Italian sausage for several weeks.
+-   Allowing vanilla beans to soak in vodka for several months.
+-   Allowing whiskey to age in barrels for several years.
+
+Software-Based Alerts
+=====================
+
+With these considerations in mind, software can be written that helps the cook manage recipes, and alert the cook when an action needs to be taken.
+
+For instance, mobile recipe software can not only display the steps of a recipe, but also allow a cook to press a button when putting a tray of cookies into the oven, which will trigger an alarm 12 minutes later to remove them from the oven. Software designed for cheesemakers can be set up to add an item to a person's calendar, or send an email, when a particular batch of cheese needs to be checked. Such software should assume that multiple batches are being processed at once, and allow the food producer to store their own internal storage information (bin codes, batch dates, etc) within the software.
+
+Examples
+========
diff --git a/tutorials/walkthrough.md b/tutorials/walkthrough.md
new file mode 100644
index 0000000..b077182
--- /dev/null
+++ b/tutorials/walkthrough.md
@@ -0,0 +1,150 @@
+# Getting Started
+
+The Open Recipe Format was designed to be as simple as possible for basic applications, while also being flexible enough to handle various complexities that may be encountered in production environments. This guide outlines the basic file format, what needs to be defined at a bare minimum, and how to put it all together.
+
+At its heart, the Open Recipe Format (ORF) uses an established file format called YAML. It's not a difficult format to get used to, but using a syntax checker will save you from a lot of headaches. An excellent online resource can be found at http://yaml-online-parser.appspot.com/.
+
+At its most basic level, a recipe consists of a name, a list of ingredients, and a list of steps to put those ingredients together. At this point, the most complex of these is the ingredient list. Each item in the list consists of an amount, a unit (which is often implied, in traditional recipes), and a corresponding ingredient.
+
+Let's put together a very basic recipe for giving an apple to a friend. In a non-computer parsable format, we might say, "Give an apple to a friend." To make this easier for the computer to use, we need to be more specific:
+
+``` yaml
+recipe_name: Giving an Apple to a Friend
+ingredients:
+    - apple:
+        amounts:
+            - amount: 1
+              unit: each
+steps:
+    - step: Give an apple to a friend.
+```
+
+This is as basic as a recipe gets. Because we are striving to be specific, there is nothing implied in this recipe; if we were writing it out traditionally, we would say 1 each apple instead of 1 apple. This may feel awkward to some, and developers may choose to allow their users to say 1 apple in their software, but when they save it to an ORF file, it needs to be more specific.
+
+Let's expand this recipe, to include more fruit, and more steps for handling the fruit. This recipe is for a very basic fruit salad, which is unlikely to win any awards, but will still feed your friends.
+
+``` yaml
+recipe_name: Basic Fruit Salad
+yields:
+    - servings: 6
+ingredients:
+    - apple:
+        amounts:
+            - amount: 1
+              unit: each
+    - banana:
+        amounts:
+            - amount: 1
+              unit: each
+    - orange:
+        amounts:
+            - amount: 1
+              unit: each
+    - grapes:
+        amounts:
+            - amount: 1
+              unit: cup
+steps:
+    - step: Cut the apple into cubes.
+    - step: Cut the banana into slices.
+    - step: Peel the orange, and divide into segments.
+    - step: Combine all ingredients in a bowl.
+    - step: Mix to combine.
+```
+
+This recipe is fine for 6 people, but what if you need to feed 18 people? An important consideration that most recipe software handles is scaling recipes. However, many commercial environments require multiple scalings to be available in a tidy, concise format. In our case, we would make the following changes to our recipe to handle both at the same time:
+
+``` yaml
+recipe_name: Basic Fruit Salad
+yields:
+    - servings: 6
+    - servings: 18
+ingredients:
+    - apple:
+        amounts:
+            - amount: 1
+              unit: each
+            - amount: 3
+              unit: each
+    - banana:
+        amounts:
+            - amount: 1
+              unit: each
+            - amount: 3
+              unit: each
+    - orange:
+        amounts:
+            - amount: 1
+              unit: each
+            - amount: 3
+              unit: each
+    - grapes:
+        amounts:
+            - amount: 1
+              unit: cup
+            - amount: 3
+              unit: cup
+```
+
+A classic use case for this scenario is a bakery, which may need to bake batches of 50, 100, 250, or even more cookies at a time, depending on the occassion. Unfortunately, ingredients are the product of nature, and not all recipes scale as nicely as we would like. It may be that in the case of our bakery, 50 cookies call for 1/2 tablespoon of baking soda, but 250 cookies only calls for 2 tablespoons. It is up to the baker to discover this, but when they do, it will be aggrivating to them to not be able to make note of that in their software.
+
+Speaking of notes, many professional cooks and bakers like to make bench notes when experimenting with recipes. These items of information do not necessarily fit into the classic "steps" format. Fortunately, ORF allows for "notes" to be saved, both alongside specific steps, and outside of the steps. Let's go back to our first recipe, and add some notes.
+
+``` yaml
+recipe_name: Giving an Apple to a Friend
+ingredients:
+    - apple:
+        amounts:
+            - amount: 1
+              unit: each
+        notes:
+            - Use whole apples
+            - Pears may be substituted, but produce a different flavor and mouthfeel
+steps:
+    - step: Give an apple to a friend.
+      notes:
+        - You can also give an apple to an enemy.
+notes:
+    - This is a friendly recipe; giving, rather than throwing, is recommended.
+```
+
+This recipe contains notes for individual ingredients and steps, as well as for the recipe as a whole. While it is not expected that most cooks, even in the professional kitchen, will take advantage of this, it is fully expected that food scientists will have the opportunity to do so.
+
+Food scientists have a whole new set of information that they need to manage. Precision is key for these individuals, and ORF is designed to handle features that are key to their job success. Consider the following:
+
+``` yaml
+ingredients:
+    - apple:
+        usda_num: 09003
+        amounts:
+            - amount: 1
+              unit: each
+        processing:
+            - whole
+            - raw
+        substitutions:
+            - pears:
+                usda_num: 09252
+                amounts:
+                    - amount: 1
+                      unit: each
+        notes:
+            - Use whole apples
+            - Pears may be substituted, but produce a different flavor and mouthfeel
+steps:
+    - step:
+          Gather the apples.
+      haccp:
+          control_point: The apples must be clean
+      notes:
+          - Some people like green
+          - Some people like red
+    - step:
+          Hand out the apples.
+      haccp:
+          critical_control_point: Wash hands with soap and warm water before distributing.
+```
+
+This set of ingredients and steps includes a scary amount of detail, for the average layperson. However, it paves the way for the industrialization and safety of this recipe, allowing the user to specify keywords related to processing, and HACCP (Hazard Analysis Critical Control Points)&lt;/topics/tutorials/haccp&gt; instructions to be declared. References to the USDA Standard Reference&lt;/topics/tutorials/usda&gt; are also included, allowing the recipe to make use of nutritional data provided by the USDA.
+
+Now that you have been through a brief overview of the format and its capabilities, the other tutorials and references will make much more sense.