added appendix explaining how the list of methods was constructed.

doc/src/core-transmutation.md

@@ -133,3 +133,11 @@ For the safe functions, you do not need to provide a full-functional correctness
 
 
 * All solutions to verification challenges need to satisfy the criteria established in the challenge book (TODO: Add link) in addition to the ones listed below
+
+## Appendix A: The list construction
+
+The list of methods and intrinsics was gathered by surveying the call-graph (solely within the libcore source) of function bodies that could eventually invoke `transmute` or `transmute_unchecked`. For each caller: if the caller was itself `unsafe`, then its callers were then surveyed; if the caller was not `unsafe`, then it was treated as an end point for the survey.
+
+As mentioned in the assumptions, some (large) classes of methods were omitted from the challenge, either because 1. they encompassed a large API surface (e.g. `core::num`) that deserved separate treatment, 2. they had an enormous number of callers that would deserve separate treatment (e.g. `core::str::from_utf8_unchecked`), or 3. they interact with aspects of the Rust memory model that still need to be better understood by reasoning tools (e.g. the provenance APIs).
+
+You can see the [call graph produced by the survey here](https://hackmd.io/PYQNIL_aTxK0N6-AltxfbQ)