# Evidence, Descriptors, And Runtime Structure


Build systems often treat metadata as something outside the build. metaBuilder
treats important metadata as part of the description, because a builder's meaning
is not exhausted by its store path.

## Evidence

Evidence gives checks and claims a place in the description. A smoke test, an
expected behavior, or an invariant can be represented as data that views surface.
Evidence does not replace tests. It gives the builder a typed place to say why a
produced artifact should be trusted.

## Descriptors

Descriptors carry structured facts about an artifact. Compiler identity, runtime
version, protocol, generated files, and artifact kind are facts a builder should
state directly rather than hide in path names or shell scripts. Because a
descriptor is part of the program's data, downstream tools and documentation can
read it without parsing conventions.

## Runtime Structure

Some artifacts are meant to run. Runtime services, protocols, capabilities, and
units describe that operational shape. These come from the runtime half of the
operation signature, so a builder declares its runtime structure with the same
program it uses to build.

The runtime declarations are kept structure, not forgotten bookkeeping. They
survive into the materialized result, which is why the same program can produce a
store artifact and a runtime description together.

## Why They Belong Together

Evidence, descriptors, and runtime declarations all answer questions about the
artifact beyond whether it built. They belong in the same descriptive model
because users need them to evaluate, compose, and operate builders.
