+@node OOD
+@unnumbered Out-of-date determination
+
+The main task for build system is deciding if the target is out-of-date
+and needs rebuilding. The single most reliable way to do that is to
+compare file's content with previously recorded one. But that is too
+expensive.
+
+So direct content storage/comparison can be replaced with
+collision-resistant hash function of enough length. @command{goredo}
+uses @url{https://github.com/BLAKE3-team/BLAKE3, BLAKE3} with 256-bit
+output for that purpose.
+
+Also it stores file's size. Obviously if size differs, then file's
+content too and there is no need to read and hash it.
+
+But still it could be relatively expensive. So there are additional
+possible checks that can skip need of hash checking, based on some trust
+to the underlying filesystem and operating system behaviour, controlled
+by @env{$REDO_INODE_TRUST} environment variable value:
+
+@table @env
+
+@item $REDO_INODE_TRUST=none
+Do not trust filesystem at all, except for file's size knowledge.
+Most reliable mode.
+
+@item $REDO_INODE_TRUST=ctime
+Trust @code{ctime} value of file's inode. It should change every time
+inode is updated. If nothing is touched and @code{ctime} is the same,
+then assume that file was not modified and we do not try to read its
+content. Unfortunately @code{ctime} also changes if link count is
+updated and ownership, that could give false positive decision and force
+file's rereading.
+
+@item $REDO_INODE_TRUST=mtime
+Trust @code{mtime} value of file's inode. It should change every time
+file's content is updated. But unfortunately there are
+@url{https://apenwarr.ca/log/20181113, many reasons} it won't.
+
+@end table
+
+Pay attention that although @code{mtime} is considered harmful (link
+above), and is hardly acceptable in build system like Make, because it
+compares timestamps of two files, redo is satisfied only with the fact
+of its changing, so badly jumping clocks are not so devastating. Modern
+filesystem and operating systems with micro- and nano-seconds resolution
+timestamps should be pretty good choice for @env{$REDO_INODE_TRUST=mtime}.
+However GNU/Linux with @code{ext4} filesystem can easily have pretty big
+granularity of 10ms.
+
+@command{goredo} uses @env{$REDO_INODE_TRUST=ctime} by default.