Generator Inventory¶
Specification catalog — instantiates Generated Span Closure Design
Declares the primitive generators, the operations allowed on them, and the template that combines them — the frozen input catalog everything downstream builds on.
Before you can argue about what a set of primitives can produce, you have to pin down exactly what the primitives are, what you're allowed to do with them, and how a legal combination is even written. Generator Inventory is that declaration: a named, frozen catalog of the generator set, the algebra of admissible operations, and the expression template that says how generators compose into candidate members — plus a short contract for who is allowed to rely on it. It builds nothing and reaches nowhere on its own; its whole value is that it turns an implicit "these building blocks are enough" into an explicit list that every other mechanism in the family can point at. If two people disagree about whether some target is reachable, the inventory is what tells them whether they're even arguing about the same primitives.
Example¶
A team stands up a new UI design system and wants to promise product teams that "you can build any screen we ship from the kit." Generator Inventory is where that promise gets its terms. The catalog names the generators — the design tokens (a fixed palette of colors, a type scale, a spacing ramp) and the base components (button, field, card, list row). It names the admissible operations: components may be nested, placed in a row/column layout, and bound to a token, but a component may not invent a new color outside the palette or hard-code a pixel value off the spacing ramp. It gives the combination template: every screen is written as a tree of components, each slot filled by another component or a token, nothing else. And it states the use contract: teams may compose freely within these rules, and any screen that needs a primitive not in the kit must file a request rather than fork one in.
The inventory ships as a single versioned document. It has not yet said which screens are buildable — that comes later — but now the claim "the kit is expressive enough" has a fixed referent instead of a vibe.
How it works¶
The catalog is assembled in one pass and then frozen under version control:
- Enumerate the generators. List every primitive and, crucially, mark which candidate items are not generators because they are already composites — this is where a would-be primitive gets demoted to "derivable later."
- State the operation algebra. Spell out each admissible operation with its arity, allowed coefficients or arguments, and the constraints that keep a combination legal and in-domain.
- Fix the expression template. Give the exact syntactic shape a candidate member takes, so "a combination" is a well-formed object a machine or a reviewer can check.
- Attach the use contract. Name who may rely on the span this induces and what obligation a change to the generators or operations triggers downstream.
The output is deliberately inert: a specification, not a computation. Everything that runs — closure, membership, coverage — consumes this file.
Tuning parameters¶
- Grain of the generator set — coarse, powerful primitives versus many small ones. Coarser generators shrink the catalog but hide structure; finer ones make composition explicit at the cost of a longer list.
- Operation permissiveness — how many operations you admit and how loosely constrained they are. More operations enlarge the reachable span but raise the odds of invalid or out-of-domain combinations.
- Template strictness — how rigidly a legal expression is shaped. A strict template makes downstream checking cheap; a loose one is friendlier to author but pushes validation work onto every consumer.
- Freeze cadence — how often the inventory is allowed to change. Frequent edits keep it current but break every downstream claim pinned to the old version.
When it helps, and when it misleads¶
Its strength is that it gives the whole family a shared object of analysis: closure, basis, independence, and coverage conversations all resolve to the same named generators and operations instead of talking past each other. It is also the natural place to resist catalog bloat — the discipline of asking "is this really primitive, or already derivable?" belongs here.
Its characteristic failure is the leaky primitive: an item listed as a generator that is actually a composite in disguise, so the inventory quietly overstates what is irreducible.[n1] The opposite error is just as common — omitting an operation everyone assumes is allowed, so the declared span is smaller than the one people actually use. Because the inventory is inert, both errors survive review easily; nothing here fails, it just misdescribes. The guarding discipline is to treat the inventory as a claim to be tested by the mechanisms that consume it, and to demote any "generator" the redundancy test later shows is reachable from the others.
How it implements the components¶
Generator Inventory fills exactly the declaration-side machinery of the archetype:
generator_set_specification— its core content: the enumerated, frozen list of primitives and excluded non-primitives.admissible_operation_algebra— the stated operations, arities, coefficients, and legality constraints.combination_expression_template— the fixed syntactic form a candidate member must take.downstream_use_contract— the scope-of-reliance clause and the change-triggers-review obligation.
It does NOT construct the closed set (closure_boundary_invariant) or record what is reachable (coverage_or_reachability_record) — that is Closure Generation Workflow, its nearest twin: the inventory is the frozen input list, the workflow is the process that expands it. Nor does it certify any single element (span_membership_criterion) — that is Span Membership Certificate.
Related¶
- Instantiates: Generated Span Closure Design — Generator Inventory supplies the declared inputs the rest of the appraisal runs on.
- Sibling mechanisms: Closure Generation Workflow · Span Membership Certificate · Dependency Elimination Test · Normal Form Reduction Procedure · Reachability Matrix or Table · Bounded Depth Generation Template · Basis Sensitivity Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Generator Inventory operates as a non-executable information artifact that externalizes static or prospective structure because it declares the primitive generators, the operations allowed on them, and the template that combines them — the frozen input catalog everything downstream builds on.
Independent corroboration: The frozen evidence defines Generator Inventory as 'Declares the primitive generators, the operations allowed on them, and the template that combines them — the frozen input catalog everything downstream builds on', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Algebraic generators and closure operations supply the primitive-set conception.
Related originating lineages:
- Computer Science & Software Engineering — Language and API design materially contribute frozen primitive catalogs and composition templates.
Review resolution: Both reviewers agree that mathematics is primary: Algebraic generators and closure operations supply the primitive-set conception. I retain computer_science only as formative lineage, not as a list of later applications. I resolve origin_mode as cross_disciplinary_synthesis because the artifact joins distinct disciplinary contributions. I resolve domain_reach as universal because it is broadly applicable across essentially all domains. Encyclopedia synthesis is true because the exact generalized packaging is an encyclopedia-authored combination or refinement.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The inventory is upstream of everything else in the family, which is why keeping it inert matters: the moment it starts asserting reachability, it stops being a stable referent and every consumer inherits its guesses. Let it declare; let the other mechanisms compute.
[n1] Joel Spolsky's Law of Leaky Abstractions — a supposedly self-contained building block that exposes the details it was meant to hide. In inventory terms, a "generator" that is really a composite leaks: it behaves like a primitive until a combination reveals it was derivable all along. ↩