Organize docs: front and back end; custom predicates. (#96)

* Organize docs: front and back end; custom predicates.

* Whoops forgot to hit save before git commit last time -- delete stuff moved out of values.md

* Update book/src/values.md

---------

Co-authored-by: Ahmad Afuni <root@ahmadafuni.com>

book/src/custom.md

@@ -10,9 +10,33 @@ At the backend level, every definition of a predicate is either a conjunction or
 
 On the backend, custom predicates are defined in _groups_.  A group can contain one or more custom predicates and their associated sub-predicates.  Recursive definition is only possible within a group: the definition of a predicate in a group can only depend on previously existing predicates, itself, and other predicates in the same group.
 
-## Custom predicates and their IDs
+## Arguments of custom predicates
+
+The definition of a custom predicate might also be called an _operation_ or _deduction rule_.  It includes two (or, potentially, say, five) statement templates as conditions.  The arguments to the statement templates are decomposed as (origin, key) pairs: if statements are allowed to have arity at most 4, then the statement templates in a deduction rule will have at most 8 arguments (4 origins and 4 keys).  The same holds for the output statement.
+
+Each argument (origin or key) to an statement template is either a wildcard or a literal.  In the backend, the wildcard arguments will be identified as *1, *2, *3, ....
+
+## Examples
+
+See [examples](./customexample.md)
+
+## Hashing and predicate IDs
+
+Each custom predicate is defined as part of a _group_ of predicates. The definitions of all statements in the group are laid out consecutively (see [examples](./customexample.md)) and hashed.  For more details, see the pages on [hashing custom statements](./customhash.md) and [custom predicates](./custompred.md).
+
+## How to prove an application of an operation
+
+The POD proof format is inspired by "two-column proofs" (for an example, see [Wikipedia](https://en.wikipedia.org/wiki/Mathematical_proof)).  A POD contains a "tabular proof", in which each row includes a "statement" and an "operation".  The "operation" is the "reason" that justifies the statement: it is everything the circuit needs as a witness to verify the statement.
+
+For a custom statement, the "reason" includes the following witnesses and verifications:
+- the definition of the statement, serialized (see [examples](./customexample.md))
+  - if the statement is part of a group, the definition of the full group, serialized
+- verify that the hash of the definition is the statement ID
+- the definition will have some number of "wildcards" (*1, *2, ...) as arguments to statement templates; a value for each wildcard must be provided as a witness (each will be either an origin ID or key)
+- the circuit must substitute the claimed values for the wildcards, and the resulting statements (true statements with origins and keys) will appear as witnesses
+- the circuit must verify that all the input statement templates (with origins and keys) appear in the previous statements (in higher rows of the table)
+- the circuit also substitutes the claimed values for the wildcards in the output statement, and verifies that it matches the claimed output statement
 
-A custom predicate, like a built-in predicate, is identified by a _name_ on the front end and an _identifier_ on the back end.  The identifier is a cryptographic hash of the definition of the group.
 
 
 [^inherit]: What to call this?  One POD "inherits" from another?