# This page is derived > This section covers what the rest of the page is made of. Page: Anatomy · Reading Canonical: https://banes-lab.com/anatomy#this-page-is-derived This section covers what the rest of the page is made of. This tab is the one part of the page I wrote, and everything else, every panel, every number and the whole tree tab, comes out of the build, which parsed every source file of the site's client, built the call graph, ran the diagnoses and laid every syntax node on a grid. The page renders that output by shape, as described in [derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md) on the methodology page. The module's totals are shown in the measurements, and the edges between its containers in [A1·b the import graph](https://banes-lab.com/anatomy#this-page-is-derived-panel-b). ### What the reader is seeing A page that describes a codebase is prose about the codebase, and prose has no mechanism that makes it wrong when the codebase changes. An architecture page names three containers and the tree holds four, the fourth added the week after the page was written, and every reader of the page reasons about a tree that no longer exists. A description written by hand is a second copy of the tree, and a second copy disagrees with the first from the day one of them moves. For this reason a page about a system is derived from the system in the same build that renders it, since otherwise it is only a claim. The derivation is published rather than a description of it, so the page can only be as wrong as the build that produced it. In practice, every number on this page is a measurement taken at build time. The tree tab shows the source as it sits on disk, and each file there shows its walk, its definitions and its source. Where a number here disagrees with the tree on disk, the tree is right and this page is stale. To check this, pick any file on the tree tab and open the same file on disk. The definitions, the line count and the imports on the page match the file, or the page was not derived from it. The page describes the client source the reader is looking at and nothing behind it. The tooling that produced it, the documents that govern it and the checks that gate it are not on this tree, so they are not on this page. The measurements are the same ones the quality tooling reads, namely how many definitions the parser found, how many call edges it resolved between them, how many calls it could not resolve, and the diagnoses it ran. A call the parser cannot resolve is counted and never guessed, so the resolution rate is a measured fraction and not a hope. The import graph folds every import a file makes to the container that owns the imported file, so an edge is a container reaching into another container, counted. Which way those edges may run is described in [the direction axis](https://banes-lab.com/software-architecture/model/the-direction-axis.md) on the architecture page, and this graph shows which way they do run. A1·a the measurements Files 450 Lines of code 30237 Definitions 4443 Exported 2601 Callable 978 Call edges 1369 Unresolved calls 78 Resolution rate 0.95 Highest in-degree 196 Highest out-degree 18 isolated flow 3621 relay flow 323 entry flow 254 leaf flow 245 Findings no anomalies A1·b the import graph ```mermaid flowchart LR n_assets["assets"] n_configuration["configuration"] n_core["core"] n_domain["domain"] n_presentation["presentation"] n_runtime["runtime"] n_types["types"] n_configuration -- 28 imports --> n_assets n_configuration -- 149 imports --> n_core n_configuration -- 28 imports --> n_domain n_configuration -- 104 imports --> n_types n_core -- 4 imports --> n_assets n_core -- 40 imports --> n_configuration n_core -- 50 imports --> n_types n_domain -- 11 imports --> n_assets n_domain -- 77 imports --> n_configuration n_domain -- 44 imports --> n_core n_domain -- 71 imports --> n_types n_presentation -- 37 imports --> n_assets n_presentation -- 220 imports --> n_configuration n_presentation -- 150 imports --> n_core n_presentation -- 32 imports --> n_domain n_presentation -- 113 imports --> n_types n_runtime -- 1 import --> n_assets n_runtime -- 7 imports --> n_core n_runtime -- 1 import --> n_domain n_runtime -- 7 imports --> n_presentation n_runtime -- 2 imports --> n_types ``` ## Links to - [Derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md) - [The direction axis](https://banes-lab.com/software-architecture/model/the-direction-axis.md)