diff --git a/Makefile b/Makefile
index 37f6689..a4e3729 100644
--- a/Makefile
+++ b/Makefile
@@ -1,2 +1,3 @@
 frap.pdf: frap.tex
 	pdflatex frap
+	pdflatex frap
diff --git a/frap.tex b/frap.tex
index bf39c25..59eadae 100644
--- a/frap.tex
+++ b/frap.tex
@@ -71,6 +71,20 @@ The license text is available at:
 
 \mainmatter
 
+\chapter{Why Prove the Correctness of Programs?}
+
+The classic engineering disciplines all have their standard mathematical techniques that are applied to the design of any artifact, before it is deployed, to gain confidence abouts its safety, suitability for some purpose, and so on.
+The engineers in a discipline more or less agree on what are ``the rules'' to be followed in vetting a design.
+Those rules are specified with a high degree of rigor, so that it isn't a matter of opinion whether a design is safe.
+Why doesn't software engineering have a corresponding agreed-upon standard, whereby programmers convince themselves that their systems are safe, secure, and correct?
+The concepts and tools may not quite be ready yet for broad adoption, but they have been under deveopment for decades.
+This book introduces one particular tool and a body of ideas for how to apply it to different tasks in program proof.
+
+As this document is in a very early draft stage, no more will be said here, in favor of jumping right into the technical material.
+Eventually, there will no doubt be some sort of historical overview here, as part of a general placing-in-context of the particular approach that will come next.
+There will also be plenty of scholarly citations (here and throughout the book).
+In this early version, you get to take the author's word for it that we are about to learn a promising approach!
+
 \appendix
 
 \backmatter