Outputs, Evidence, And Runtime Artifacts

Builders need to communicate more than the fact that a derivation exists. A user often needs to know what the artifact contains, how it was checked, and how it should run. metaBuilder gives those concerns explicit places in the build description.

Outputs

Outputs name the results a build promises. A generated source tree, a static library, a CLI binary, a JSON manifest, package metadata, or a service tree are typical examples. An output should have a name, a path, and a format, which lets views explain what the build returns without executing it.

Descriptors

Descriptors are structured metadata. Use them when a builder wants to report facts about the artifact, such as compiler identity, runtime version, protocol, generated files, package manager, or artifact kind. Descriptors are better than conventions hidden in filenames because they are part of the program's data.

Evidence

Evidence records checks or claims about the artifact. A syntax-check command, a smoke-test expectation, a generated-artifact invariant, or a compatibility assertion can each be recorded as evidence. Evidence does not replace tests. It gives the builder a typed place to report why a produced artifact should be trusted.

Runtime Artifacts

Some builders produce things that run as services. For those builders the runtime shape should be explicit, and it is expressed with the runtime operations for services, protocols, lifecycle capabilities, and runtime units. These runtime declarations are kept structure. They survive into the materialized result, so the same builder describes both build-time and runtime behavior and returns both from one program.