Builders As Descriptions

The central move in metaBuilder is to treat a builder as a description before it is treated as an executable artifact.

A description is typed data. Parameters, sources, dependencies, tools, operations, outputs, evidence, and runtime declarations are all generated datatypes with named constructors and fields. A builder spec is an inhabitant of the base description type, and it is checked against that type before anything is built. A spec that is missing a required field or carries the wrong shape is rejected at description time, not at build time.

Because the builder is data, its parts are available to inspect and reinterpret. A description says which parts exist and how they relate without committing to the single thing that could be done with them. That separation is what makes multiple views possible.

Functions And Descriptions

A function gives an answer when it is called. It can hide everything that happened on the way to the answer.

A description can be read before any answer is produced. It can be checked, summarized, documented, or interpreted into a build. The description is not less precise than a function. It is precise in a form that supports more than one use.

Typed All The Way Down

The types are not decoration. They are the same descriptions the views read and the same descriptions the documentation and schemas are generated from. A field added to a description becomes visible to validation, to dependency analysis, to the rendered docs, and to materialization at once, because all of them read the one typed source.

Structure Before Execution

When a builder is described structurally, its components become available to generic interpretations. Validation inspects the shape. Dependency analysis inspects tools and operations. Dry-run summarizes intent. Plan-view renders an executable plan. Materialization produces the artifact.

The build still happens. metaBuilder adds the structure around it that makes the builder inspectable before it runs.