Navigation
ManualIntroductionGetting StartedBuilder SpecsOperationsPrograms And ViewsDesigning Builder SurfacesOutputs, Evidence, And Runtime ArtifactsMaterialization ModelAuthoring Production Builders
TheoryBuilders As DescriptionsInternalized ProgramsOrnaments And Domain SurfacesInterpretation And ViewsEvidence, Descriptors, And Runtime Structure
ExamplesNode service exampleSource filesNode service builder moduleserver.jsC code generation exampleSource filesC codegen builder modulemessages.defmain.cBridge exampleSource filesBridge proof moduleIDL exampleSource filesIDL builder moduleschema.protoOCI image exampleSource filesOCI image example module
API Reference
Core APIDescriptionsOperations
ProgramValidateDepsDry-runPlan-viewDescribeIntrospectMaterializeBackendsFormerPlan-export
ReferenceSchemasDatatypes
OrnamentsProject-builderDependenciesImplementationsToolEnvTestingVendoringCode-genIdlCapabilitiesProtocolServiceReplServerSandboxTransformOci-image
Library HelpersTool-envToolchainPassthruBundledDashboardContentAddress

Theory

The theory section explains the ideas behind metaBuilder. It is a companion to the manual and not a prerequisite for using the library.

The practical claim is short. A build can be written as typed data, that data can be read as a program, and the program can be interpreted in more than one way. The theory chapters make each part of that claim precise.

A builder is a typed description rather than a function. The description becomes a program over a fixed signature of build-time and runtime operations. Domain builders refine the description with extra data through ornaments, and a typed forget map projects them back to the shared shape without losing the program. Every view is an interpretation of that one program.

Read this section when you want to understand why metaBuilder can support one build with many views.

backmetaBuilder