graph LR
family["Reproducible Research"]
program["Deep Dive Make"]
section["Build Architecture Layered Includes Apis"]
page["Glossary"]
capstone["Capstone evidence"]
family --> program --> section --> page
page -.applies in.-> capstone
flowchart LR
orient["Orient on the page map"] --> read["Read the main claim and examples"]
read --> inspect["Inspect the related code, proof, or capstone surface"]
inspect --> verify["Run or review the verification path"]
verify --> apply["Apply the idea back to the module and capstone"]
Use this glossary to keep the language of Module 07 stable while you move between the core
lessons, worked example, and exercises.
The goal is not more jargon. The goal is to make sure the same architectural fact keeps the
same name whenever you explain a public target, an include boundary, or a macro reuse
decision.
If a build-architecture discussion starts drifting into vague phrases like "the Makefiles
are kind of modular" or "this target is sort of public," stop and look up the term doing
the most work in the argument. Module 07 becomes much clearer when the team agrees on the
right nouns.
The intentionally supported combination of public targets, parameters, results, side effects, and failure meaning. It is larger than a target-name list.
human help, machine-readable contract, accepted and rejected calls
public target
A stable invocation route promised to humans or automation. Reachability alone does not make a target public.
declared interface plus caller and result evidence
implementation target
A graph node used behind a public route without a compatibility promise to external callers.
absent from interface views; reached through a public target
target contract
The promise for one public target: invocation, supported inputs, results, side effects, and failure behavior.
a contract row and tests for every field
parameter API
A documented variable or argument that callers may set, including its accepted values and default.
validation, help, parent/child trace, rejection case
promised result
The artifact, report, or verified state a successful public invocation commits to produce.
path and content assertion
failure meaning
What nonzero status guarantees about final artifacts and evidence. “The recipe stopped” is not enough.
rejected input or failed producer with state inspection
callable surface
Every target an external caller can name, including accidental generated targets. It can be larger than the supported API.
parsed database compared with public contract
interface drift
An unreviewed change in target names, parameters, results, or failure meaning.
caller audit and before/after contract
recursive boundary
A new Make invocation that must receive supported parameters explicitly and parse one coherent graph.
parent command trace and child evidence
ambient input
An environment or inherited value that affects a build without being declared as a supported parameter.
origin trace and environment rejection case
flowchart LR
caller["human, CI, or script"] --> target["public target"]
caller --> parameter["supported parameter"]
target --> result["promised result"]
parameter --> result
rejected["unsupported input"] --> failure["documented failure meaning"]
Prefer statements that name both ownership and proof:
“CI calls the private internal-build target and misses verification evidence.”
“Discovery consumes policy-owned roots; it must not interpret public goal names.”
“The forward map is injective but not yet proved total because unsupported extensions
were never enumerated.”
“The macro preserves the explicit prerequisite map, but its parse-time writer crosses
the publication boundary.”
“The shared prerequisite has policy-dependent bytes, so release needs a distinct output
identity.”
Avoid conclusions such as “the Makefiles are messy,” “the macro is advanced,” or “the
folders look modular.” They do not identify an owner, a violated promise, or evidence
capable of changing the decision.