Using Structure Synthesis

Using Structure Synthesis

Overview

A structure generator that also judges its own output is not a generator — it is a policy wearing a generator's clothes.

This pack is for the class of system where a model's output is not a number or a label but an object with topology: a candidate neural-network subgraph, a program in a typed intermediate representation, a molecule graph, a circuit netlist, a level layout graph — anything a generator emits as a small directed graph over a constrained vocabulary of typed operators. The generation problem and the verification problem look similar (both touch the same graph) but they answer different questions, and collapsing them is the single most common failure mode this pack exists to prevent:

• Generation answers "what structures are plausible." A generator proposes. It may propose badly. It may mode-collapse. It may hallucinate topology that violates the grammar. None of that is fatal on its own.
• Structural verification answers "is this candidate legal." Shape-correct, cycle-free, contract-respecting, within budget. This is checkable by rule, not by taste, and it must not consume any signal about whether the candidate is useful.
• Utility judgement answers "does this candidate help." That question belongs to whatever evaluates the candidate against real outcomes — a counterfactual trial, a benchmark, a downstream reward. This pack does not answer it and does not ship the machinery to answer it.

The failure this pack is built around: a generator that filters its own best-of-K pool by predicted task performance is grading its own examination. A verifier that rejects a legal candidate because it looks unpromising has let policy leak into what should be a rule-driven gate. Both failures are invisible in a demo and catastrophic at scale, because they silently narrow the search space to whatever the current model already believes is good — which is exactly the thing generation was supposed to explore past.

Key tensions this pack resolves, sheet by sheet: expressiveness vs. verifiability (bigger grammars generate more, cost more to check), validity-by-construction vs. generate-then-verify (cheaper to decode legally, but you still need a verifier), raw diversity vs. functional diversity (a pool that looks different byte-for-byte may be one candidate after canonicalisation), simple generator vs. simple in the wrong sense (start deterministic/latent-conditioned; escalate to flows or diffusion only when that demonstrably fails).

When to Use

Use this pack when:

• A model or search process must emit a graph, program, or structured artifact — not a scalar, not free text — and that artifact has to satisfy typing, shape, or resource constraints.
• You are designing the grammar a generator may emit from: operator whitelist, node/edge/parameter ceilings, staged expressiveness levels.
• You need to canonicalise generated structures to a normal form so that "same structure, different serialization" collapses to one identity.
• You need to detect whether two generated structures are equivalent (isomorphic under the grammar's semantics), or assign a semantic hash that is stable across serialization order and generator/library versions.
• You suspect mode collapse: a best-of-K pool that looks diverse in raw syntax but is one candidate after canonicalisation.
• You are choosing a generation strategy: deterministic direct generation, latent-conditioned sampling, stochastic best-of-K, mutation/recombination of an archived lineage, or (last resort) a flow/diffusion model.
• You are designing the learning objective for the generator itself: reconstruction, functional-effect matching, ranking, contrastive learning from failures — and you need the generator/judge boundary to survive that training.
• You are auditing an existing generator+verifier pipeline for generator/judge conflation, canonicalisation that silently changes semantics, or a hash that is not actually stable.

Do not use this pack when:

• You are selecting among existing, human-authored architecture families (ResNet vs. Transformer vs. Mamba) rather than generating novel topology → yzmir-neural-architectures.
• You are building the growable network substrate itself — FSM lifecycle, gradient isolation, alpha blending mechanics for a structure once it has been chosen → yzmir-dynamic-architectures. This pack produces the candidate structure; that pack embodies it.
• You are designing the controller that decides WHEN and WHERE to request a new structure, and how to score the causal effect of admitting it → yzmir-morphogenetic-rl. That pack owns the request and the admission decision; this pack owns only what happens between "a request was issued" and "a canonical, verified candidate exists."
• You need the statistics of comparing a generated candidate's pool against a no-op baseline (independent unit, paired tests, winner's curse, abstention calibration) → yzmir-counterfactual-statistics.
• You are decomposing a staged human/LLM procedure (a wizard, a curriculum, an approval pipeline) into stages and decision points → axiom-procedural-architecture. That pack's "graph" is a control-flow decomposition of expert work; this pack's graph is a typed computational structure a model emits as output.
• You are analyzing or writing rules for an existing static analyzer over already-written programs → axiom-static-analysis-engineering. That pack verifies code humans wrote; this pack verifies candidates a generator proposed, before anything is compiled or run.

Start Here

If you are designing a structure-synthesis pipeline from scratch:

1. Read typed-graph-grammars.md — define the operator whitelist, ceilings, and staged expressiveness levels before choosing how to generate within them. Foundation; every other sheet assumes a grammar exists.
2. Read graph-representations-for-generation.md — pick the encoding the generator actually emits (op sequence, edge list, latent code) and know what it buys and costs in validity.
3. Read validity-by-construction-vs-post-hoc.md — decide how much illegality you prevent by construction vs. catch after the fact. Either way, a verifier is mandatory; this sheet tells you what it must still check.
4. Read canonicalisation-and-normal-forms.md and equivalence-detection-and-semantic-hashing.md together — these are the technical core. Get the canonical form and the hash right before anything downstream depends on candidate identity.
5. Read structural-verification.md — the full legality gate: shapes, cycles, contracts, trainability, forbidden operations.
6. Read generation-strategies.md — now choose deterministic, latent-conditioned, best-of-K, or mutation/recombination, informed by what the grammar and verifier can actually support.
7. Use the Routing table below for the rest (diversity, objectives, lineage, explosion control) as they become relevant.

Steps 1–5 are the spine: grammar, representation, validity discipline, canonical identity, verification. Skipping to generation strategy before the spine exists produces a generator with no stable notion of what it produced.

How to Access Reference Sheets

All reference sheets are in the same directory as this SKILL.md. When you see a link like [canonicalisation-and-normal-forms.md](canonicalisation-and-normal-forms.md), read the file from the same directory.

Pipeline Position

This pack sits between "something decided a new structure is worth requesting" and "something will compile, execute, or judge the result." It owns generation and structural verification. It does not own the request, the compilation, or the judgement.

Upstream: whatever decides WHEN/WHERE a structure is needed
  (a NAS search loop, a morphogenetic RL controller, a program-
   synthesis driver, a molecule-design campaign)
        │
        │  a typed request: operator budget + interface contract
        │  ── NEVER a blueprint naming the answer ──
        ▼
┌───────────────────────────────────────────────────────────────┐
│                yzmir-structure-synthesis                        │
│                                                                  │
│  GENERATE ("imagines")            VERIFY & CANONICALISE          │
│  grammar · representation    →    ("permits")                    │
│  generation strategy ·            validity · canonical form ·    │
│  conditioning · diversity ·       equivalence class ·            │
│  lineage/mutation                 semantic hash                  │
│                                                                  │
│  A generator that filters its own pool by predicted utility     │
│  has crossed into the next box without permission.              │
└───────────────────────────────────────────────────────────────┘
        │
        │  a canonical, verified candidate (or ranked-by-nothing pool)
        ▼
Downstream: compiles/lowers, executes, and judges
  (a compiler or lowering pass; a counterfactual trial whose
   statistics are yzmir-counterfactual-statistics's job; an
   admission authority this pack must never become)

Specialist Skills Catalog

Grammar and representation (define the space before generating in it):

Generation:

Validity, canonical identity, verification (the technical core):

Diversity, learning, and lineage:

Scaling the search space:

Catalogue:

Routing

Specialist Agents

• agent: structure-synthesis-architect — Forward-design SME: grammar, representation, generation strategy, and learning-objective selection for a given synthesis problem. Invoked via the Agent tool.
• agent: synthesis-integrity-reviewer — Critic SME: hunts generator/judge conflation, canonicalisation semantic drift, syntax-space diversity claims, and hash instability in a design or codebase. A zero-findings run is treated as an audit defect, not a clean bill of health. Invoked via the Agent tool.

Specialist Commands

• /design-graph-grammar — From requirements (operator set, budgets, interface contract) to a typed grammar spec with ceilings, validity rules, and a staged expansion plan.
• /scaffold-structure-generator — Scaffold a generator + verifier + canonicaliser skeleton with failing-first tests: round-trip, canonicalisation idempotence, equivalent-graph hash equality, non-equivalent-graph hash separation.
• /audit-canonicalisation — Adversarially review a canonicaliser/hasher for semantic drift, non-idempotence, hash instability, and equivalence false positives/negatives, with severity-rated findings.

Agents vs. skills: Skills design the grammar, generator, and verifier. Agents audit or critique an existing design or implementation. Load a skill when designing; dispatch an agent when reviewing.

Common Multi-Skill Scenarios

Scenario: Greenfield structure-synthesis pipeline

1. typed-graph-grammars — Operator whitelist and ceilings first
2. graph-representations-for-generation — Pick the emission format
3. validity-by-construction-vs-post-hoc — Decide the validity strategy
4. canonicalisation-and-normal-forms + equivalence-detection-and-semantic-hashing — Canonical identity and hashing, together
5. structural-verification — The full legality gate
6. generation-strategies — Now choose how the generator actually samples
7. learning-objectives-for-generators — Train it, keeping generator/judge separate

Scenario: Best-of-K pool looks suspiciously uniform

1. diversity-and-mode-collapse — Measure duplicate rate after canonicalisation, not before
2. equivalence-detection-and-semantic-hashing — Confirm the hash/canonicalisation pipeline is actually distinguishing distinct structures
3. learning-objectives-for-generators — Audit for a collapsed objective (no explicit latent, no min-over-K term)

Scenario: Auditing an existing generator + verifier

1. synthesis-anti-patterns — Run the eight-pattern checklist first
2. canonicalisation-and-normal-forms — Idempotence test: does canon(canon(x)) == canon(x)?
3. equivalence-detection-and-semantic-hashing — Equal-semantics-same-hash and distinct-semantics-different-hash, both directions
4. structural-verification — Does the verifier consume any utility/reward/provenance signal? It must not.
5. → dispatch synthesis-integrity-reviewer for a full pass with severity ratings

Scenario: Grammar keeps growing, verification is getting slow / unreliable

1. search-space-evolution-and-explosion-control — Is there a reliability gate before each expansion?
2. structural-verification — Measure the verification-cost curve against grammar size
3. typed-graph-grammars — Consider staged levels instead of one flat grammar

Scenario: Choosing a generation strategy for a new domain

1. generation-strategies — Start at the bottom of the escalation ladder: deterministic or latent-conditioned
2. conditioning-on-context-and-contracts — What must the request constrain vs. leave open?
3. lineage-mutation-and-recombination — If an archive of past candidates exists, consider mutation/recombination before a from-scratch generator

Decision Tree

Designing the pipeline from scratch?
├─ Yes → typed-graph-grammars → graph-representations-for-generation
│        → validity-by-construction-vs-post-hoc
│        → canonicalisation-and-normal-forms + equivalence-detection-and-semantic-hashing
│        → structural-verification → generation-strategies
│        → learning-objectives-for-generators
└─ No  → continue

Best-of-K pool looks uniform / duplicated?        → diversity-and-mode-collapse
Two candidates that should match don't (or        → equivalence-detection-and-semantic-hashing
  vice versa)?
Hash changed after a reorder / library upgrade?   → equivalence-detection-and-semantic-hashing
Canonicaliser deleted something it shouldn't have? → canonicalisation-and-normal-forms
Generator filtering its own pool by predicted     → learning-objectives-for-generators,
  score?                                             synthesis-anti-patterns
Grammar growing without a reliability gate?       → search-space-evolution-and-explosion-control
Need mutation/recombination over an archive?      → lineage-mutation-and-recombination
Auditing an existing pipeline end-to-end?         → synthesis-anti-patterns
                                                      → dispatch synthesis-integrity-reviewer
Need the request format itself designed?          → conditioning-on-context-and-contracts
Comparing a candidate's measured effect to a       → yzmir-counterfactual-statistics
  no-op baseline?
Deciding WHEN/WHERE to request a structure?       → yzmir-morphogenetic-rl
Embodying an accepted candidate in a live network? → yzmir-dynamic-architectures

Rationalization Resistance

Red Flags Checklist

• Generator filters its own pool: any code path where the generator drops or re-ranks candidates using a predicted-utility signal
• Verifier reads reward, future utility, or candidate provenance in its accept/reject decision
• Canonicaliser changes non-equivalent semantics: a "simplification" that isn't provably identity-preserving
• Canonicaliser splits one structure into several identities: signature refinement that reads predecessors only, or a raw node ID breaking the ties that bidirectional refinement leaves — either way raw labels leak into the "canonical" form for branch-and-merge graphs
• Diversity measured on raw syntax: duplicate rate reported before canonicalisation
• Hash has no version field: no way to detect that a library upgrade silently changed hash values
• Equivalence check is bare, unlabeled isomorphism: nx.is_isomorphic() (or equivalent) with no node/edge attribute matching
• Grammar expanded with no reliability gate: new operators added without a staged-expressiveness review
• Validity left entirely post-hoc when cheap constrained decoding could have prevented most illegal candidates
• Mode collapse hidden behind syntactic variation: a pool that looks different but canonicalises to one structure

Integration with Other Skillpacks

Dynamic architectures (yzmir-dynamic-architectures)

That pack covers the growable network substrate an accepted candidate is embodied into — FSM lifecycle, gradient isolation, alpha blending. This pack covers everything upstream of that: inventing and legality-checking the candidate structure itself.

Morphogenetic RL (yzmir-morphogenetic-rl)

That pack's controller decides WHEN and WHERE a new structure should be requested, and judges the causal effect of admitting one. This pack answers what happens between "a request was issued" and "a canonical, verified candidate exists" — it never decides whether to admit anything.

Counterfactual statistics (yzmir-counterfactual-statistics)

Once a candidate (or pool) exists, deciding whether its measured effect is real — the independent unit, paired tests against a no-op anchor, the winner's curse in best-of-K screening — is that pack's job, not this one's.

Neural architectures (yzmir-neural-architectures)

That pack selects among existing, human-authored architecture families for a given modality and constraint set. This pack generates novel topology from a grammar as a model's own output.

Procedural architecture (axiom-procedural-architecture)

That pack decomposes staged human/LLM/team procedures into stages and decision points — a different sense of "graph" (control flow over expert work, not a typed computational structure a model emits).

Other packs

Quick Reference

The Bottom Line

Generation, structural verification, and utility judgement are three different questions, and the moment one component answers more than one of them, the search space silently narrows to whatever the system already believes is good. This pack designs the first two — a generator that may propose badly, and a verifier that checks legality by rule and consumes no utility signal — and gives them a stable shared vocabulary: a canonical normal form and a semantic hash that agree exactly when two structures mean the same thing. It deliberately does not answer whether a candidate is any good. That question, and the machinery to answer it safely, belongs downstream.

Reference Sheets

After routing, load the appropriate specialist sheet:

Grammar and representation:

1. typed-graph-grammars.md — Operator whitelist, typing/shape rules, ceilings, staged expressiveness levels
2. graph-representations-for-generation.md — Encodings a generator can emit; round-trip fidelity

Generation:

3. generation-strategies.md — Deterministic, latent-conditioned, best-of-K; escalation to flows/diffusion
4. conditioning-on-context-and-contracts.md — Conditioning on context, contracts, and budgets

Validity, canonical identity, verification:

5. validity-by-construction-vs-post-hoc.md — Constrained decoding vs. generate-then-verify
6. canonicalisation-and-normal-forms.md — Semantics-preserving normal form; idempotence
7. equivalence-detection-and-semantic-hashing.md — Isomorphism, equivalence classes, hash design
8. structural-verification.md — The full legality gate

Diversity, learning, lineage:

9. diversity-and-mode-collapse.md — Canonical/functional diversity; duplicate rate
10. learning-objectives-for-generators.md — Training objectives; generator/judge separation
11. lineage-mutation-and-recombination.md — Archive-driven mutation and crossover

Scaling the search space:

12. search-space-evolution-and-explosion-control.md — Growing the grammar safely

Catalogue:

13. synthesis-anti-patterns.md — The eight recurring failure patterns