Closure Generation Workflow¶
Constructive procedure — instantiates Generated Span Closure Design
Repeatedly applies the admissible operations to generators and their products until no new element appears, constructing the closed reachable set.
An inventory tells you the generators and the operations; it does not tell you the world they imply. Closure Generation Workflow is the procedure that runs that world into existence: start from the generators, apply every admissible operation to everything you have, add whatever new elements appear, and repeat — until a full pass produces nothing new. That "nothing new" moment is the closure: the smallest set that contains the generators and is stable under the operations. Its defining commitment is completeness by construction — it does not stop at a convenient depth or a sampled subset; it chases the fixed point until the set is genuinely closed, and only then reports the reachable set as done. When the closure is infinite or intractable, this workflow's honest answer is "cannot be completed here," which hands the job to a mechanism that truncates on purpose.
Example¶
You want to know every position a standard Rubik's cube can reach from solved, using only quarter-turns of the six faces. The generators are the solved state plus the twelve quarter-turn moves; the admissible operation is "apply a move to a reachable state." Closure Generation Workflow builds the reachable set breadth-first: from solved, the twelve moves yield 12 new states; from each of those, twelve more moves yield fresh states (minus the ones already seen); and so on. Each pass adds a shrinking frontier of genuinely new positions. The workflow keeps going — pass after pass, deduplicating against what it has already recorded — until a pass discovers no state it hasn't seen. At that point the set is closed: every move from every reachable state lands back inside it.
The output is a recorded set of reachable positions together with the certified fact that applying any admissible move to any member stays inside — the closure boundary holds. The team now knows not a sample of positions but the whole reachable space, and can hand that record to anyone asking "is this scramble solvable?"
How it works¶
- Seed with the generators. The initial set is exactly the declared generators from the inventory.
- Saturate. Apply every admissible operation to every applicable tuple of current members; collect the results as candidate new members via the expression template.
- Deduplicate and add. Discard candidates already present; add the genuinely new ones to the set and to the reachability record.
- Test the fixed point. Repeat saturation until a full pass adds nothing — the closure boundary invariant now holds: no admissible operation escapes the set.
- Certify or bail. If the fixed point is reached, report the closed set; if the frontier keeps growing without bound, declare the closure non-terminating here and defer to a bounded procedure.
The distinguishing move is the fixed-point test: the workflow is finished only when it can prove stability, not when it runs out of patience.
Tuning parameters¶
- Traversal order — breadth-first versus depth-first saturation. Breadth-first gives a clean frontier and early coverage estimates; depth-first can find far members sooner but complicates the fixed-point check.
- Deduplication strength — exact-match versus equivalence-aware merging of candidates. Stronger dedup keeps the set minimal but leans on an equivalence policy this workflow does not itself own.
- Termination guard — the frontier-size or wall-clock ceiling past which the workflow declares "non-terminating." Set high to insist on true closure; set low to fail fast and hand off.
- Record granularity — whether the reachability log stores every element or just counts and a frontier. Full storage enables later membership lookups; summary storage saves space but weakens downstream use.
When it helps, and when it misleads¶
Its strength is that it produces a constructed answer rather than an asserted one: the reachable set exists as an artifact, and its closedness is a checked property, not a hope. This is exactly what turns "the primitives are expressive enough" into a demonstrable fact for finite, well-behaved spaces.
Its failure mode is structural: many interesting spans are infinite or combinatorially explosive, and a naïve saturation loop will run forever or exhaust memory chasing a fixed point that formally exists but cannot be reached in practice.[n1] Worse is the silent version — a workflow stopped by a timeout that then reports its partial set as if closed, which is a completeness lie. The guarding discipline is to make termination explicit: either prove the fixed point was reached or label the result incomplete and route it to a bounded-depth procedure. Never let an interrupted saturation masquerade as a closed set.
How it implements the components¶
Closure Generation Workflow realizes the construction-side machinery:
admissible_operation_algebra— it executes the operations, applying them exhaustively rather than merely declaring them.combination_expression_template— each candidate member is instantiated in the template's form as it is generated.closure_boundary_invariant— the fixed-point test is precisely the proof that the boundary holds: no admissible operation leaves the set.coverage_or_reachability_record— the accumulating set of generated elements is the reachability record it emits.
It does NOT cap generation at a depth and label the result approximate (truncation_depth_policy) — that is Bounded Depth Generation Template, its nearest twin: this workflow chases the closed fixed point, the template accepts a labeled truncation. Nor does it declare the generators (generator_set_specification) — it consumes them from Generator Inventory.
Related¶
- Instantiates: Generated Span Closure Design — this workflow constructs the closed reachable set the appraisal is about.
- Consumes: Generator Inventory supplies the generators, operation algebra, and expression template it runs.
- Sibling mechanisms: Generator Inventory · 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: Analysis, Modeling & Optimization
Rationale: Repeatedly applies the admissible operations to generators and their products until no new element appears, constructing the closed reachable set, making its operative form a computation, comparison, model, or analytic representation used to infer, estimate, or choose.
Independent corroboration: The frozen evidence defines Closure Generation Workflow as 'Repeatedly applies the admissible operations to generators and their products until no new element appears, constructing the closed reachable set', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Algebra and discrete mathematics established repeatedly applying admissible operations to generators until reaching the smallest closed set.
Related originating lineages:
- Computer Science & Software Engineering — Fixed-point and reachability algorithms supply executable closure construction.
Review resolution: Both reviewers agree on mathematics as primary. The source mechanism's defining operation supports that lineage; the reconciled record retains computer_science only where it materially contributes the mechanism, and treats later application breadth separately from origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A least fixed point is the smallest set stable under a set of operations, and fixed-point iteration reaches it by repeated application until nothing changes. For monotone operations on a finite lattice the iteration is guaranteed to terminate; on infinite domains the fixed point may exist mathematically yet be unreachable by any finite run — which is exactly when this workflow must defer to truncation. ↩