What the Atlas Can Prove—and Where It Stops
Human Atlas has many ways to look trustworthy: its catalogue returns names, its scene responds to gestures, and its geometry arrives as a carefully packaged browser asset. This chapter asks a narrower and more useful question: which claims are supported by the repository's checks, and which claims remain outside them? The answer separates internal data integrity, interaction reliability, source scope, and clinical or device-level conclusions.
Correctness is layered
The atlas validation script begins with the manifest's own structure. It checks the expected number of parts and concepts, confirms that part IDs are unique, rejects empty or placeholder names, requires a system assignment, and verifies that each concept points to an existing part. It then examines the binary buffers through the offsets and counts recorded in the manifest. Positions must be finite, indices must remain within the part's vertex range, and the computed triangle total must agree with the manifest.
Those checks establish something concrete. They support the claim that the released catalogue is internally coherent in the ways the script enumerates: the named records point to real modeled elements, the binary ranges stay within the received buffers, the index data does not point beyond its local vertices, and the reported triangle count matches the data inspected. They do not establish that the source anatomy is complete, that every mesh is clinically correct, or that a valid index range represents a medically appropriate surface.
The distinction can be stated plainly: a valid graph is not the same as a true anatomy. The concept-to-part relationship can be complete relative to the manifest while the reference itself remains bounded. A count of 2,234 modeled parts confirms the release's internal inventory; it does not mean human anatomy has only 2,234 meaningful structures. A count of 3,432 named concepts confirms the catalogue's semantic records; it does not turn those records into an exhaustive clinical ontology.
The geometry checks have a similar scope. Finite positions and valid indices protect the runtime from malformed numeric data. Agreement between computed and declared triangle totals protects the manifest's accounting. These are necessary conditions for a usable model, but they are not perceptual or medical measures. A surface can be finite, indexed, and renderable while still being simplified, incomplete for a particular question, or unsuitable for a clinical decision.
The checks also establish ownership of failure more clearly. If a concept points to an ID that is not in the part set, the semantic graph is broken. If an index points outside a part's vertices, the geometry record is broken. If the manifest's triangle total disagrees with the buffers, the release's accounting is broken. Those failures can be distinguished because the validation follows the same boundaries that the runtime uses. It does not merely ask whether a JSON file parses; it tests whether the pieces can still be related in the way the viewer needs.
That makes the exact counts useful but not magical. A count is a checksum-like assertion about the release's expected inventory, not a census of the human body. The concept graph tells us that the stored names and elements connect; it does not tell us that the naming hierarchy is complete for every educational or clinical purpose. The validator protects the release's stated data contract, and the source scope determines what that contract is about.
Why interaction tests belong beside buffer tests
A viewer can pass every binary check and still fail as an atlas. If cells overlap in the exploded inventory, a reader cannot tell which piece they are selecting. If a drag is classified as a tap, the details panel may change while the reader is trying to orbit.