Export a named frozen strategy (blueprint-as-values collection) — #55 export fork #60

New Issue

2026-06-12T16:26:59+02:00

Brummel commented

2026-06-12 16:26:59 +02:00

Deferred from #55 (the third fork, explicitly out of scope for the bind-overlay
cycle 0034). #55 shipped PrimitiveBuilder::bind — a node param can now be fixed
as a structural constant, removed from param_space. The remaining open question:

How is a named frozen strategy exported? Once a blueprint has its
structural constants bound (e.g. "SMA2-entry" = an SMA blueprint with length
bound to 2 + its surrounding topology), it is a distinct, reusable strategy
value — not a point in another strategy's sweep space. The export fork is how
such a frozen, named blueprint becomes a first-class value a future
blueprint-as-values collection can hold and a researcher can pull by name.

Constraints (from #55's C9 boundary)

A future "blueprint registry" must stay a Rust module of blueprint values
(cargo-native reuse, C9-ok) — NOT a by-name runtime node resolution
("SMA" -> constructor), which is the node-registry C9 forbids and the RustAst/DSL
trap C10 forbids. Blueprints are already first-class values
(Composite / param_space / compile_with_params); "create a node from a
blueprint dynamically" already IS compile_with_params. This fork adds only the
export/naming surface, no registry layer.

Open forks (needs its own brainstorm)

.bind() ergonomics for a fully-frozen strategy (all knobs bound vs a mix).
Where the named frozen strategy lives as a value and how it is addressed.
Relationship to the blueprint-as-values collection (the eventual home).

depends on: nothing blocking (#55 bind overlay shipped, cycle 0034)
context: design fork — needs brainstorm when picked up; not blocking

Deferred from #55 (the third fork, explicitly out of scope for the bind-overlay cycle 0034). #55 shipped `PrimitiveBuilder::bind` — a node param can now be fixed as a structural constant, removed from `param_space`. The remaining open question: **How is a *named frozen strategy* exported?** Once a blueprint has its structural constants bound (e.g. "SMA2-entry" = an SMA blueprint with `length` bound to 2 + its surrounding topology), it is a distinct, reusable strategy *value* — not a point in another strategy's sweep space. The export fork is how such a frozen, named blueprint becomes a first-class value a future **blueprint-as-values collection** can hold and a researcher can pull by name. ## Constraints (from #55's C9 boundary) A future "blueprint registry" must stay a **Rust module of blueprint values** (cargo-native reuse, C9-ok) — NOT a by-name runtime node resolution ("SMA" -> constructor), which is the node-registry C9 forbids and the RustAst/DSL trap C10 forbids. Blueprints are already first-class values (`Composite` / `param_space` / `compile_with_params`); "create a node from a blueprint dynamically" already IS `compile_with_params`. This fork adds only the *export/naming* surface, no registry layer. ## Open forks (needs its own brainstorm) - `.bind()` ergonomics for a fully-frozen strategy (all knobs bound vs a mix). - Where the named frozen strategy lives as a value and how it is addressed. - Relationship to the blueprint-as-values collection (the eventual home). depends on: nothing blocking (#55 bind overlay shipped, cycle 0034) context: design fork — needs brainstorm when picked up; not blocking

Brummel added the idea label 2026-06-12 16:26:59 +02:00

Brummel referenced this issue from a commit

2026-06-12 17:37:21 +02:00

audit: cycle 0034 (#55) — record structural-constant bind in the ledger; drift-clean otherwise

Brummel referenced this issue

2026-06-22 11:08:15 +02:00

Meta-level (composable analysis + project-as-crate authoring): keep in focus, resolve the CLI-vs-Rust authoring line #109

Brummel commented

2026-07-09 17:31:52 +02:00

Triage 2026-07-09 (tree at 68317ec) — assessed superseded; every fork this issue kept open has since been resolved by shipped design:

The export fork resolved the data way: the C24 design card (topology as serializable, World-owned data; #155/#157) gives blueprint_to_json/blueprint_from_json with bind-order-independent structural constants (crates/aura-engine/src/blueprint_serde.rs:81-82/:183-188).
The issue's literal example ships as data: crates/aura-cli/examples/r_sma.json is a named blueprint ("sma_signal") with the SMA length bound to 2 (demo retirement, #159).
The "collection" exists as the content-addressed registry blueprint store (put_blueprint/get_blueprint, aura graph register); pull-by-reference exists via content id / identity id, and campaign documents reference strategies exactly that way.
The body's "must stay a Rust module of values, not a registry" constraint was the pre-C24 framing; C24 honors the C9/C10 invariants via type-identity resolution through the closed roster instead.
Residual polish is tracked elsewhere: #191 (identity-ref resolution cost), #183 (bound-param authoring docs).
One stale ledger clause to fix on close: the C19 realization note still says export "is deferred (#60)" (docs/design/INDEX.md:1660).

Triage 2026-07-09 (tree at 68317ec) — assessed superseded; every fork this issue kept open has since been resolved by shipped design: - The export fork resolved the data way: the C24 design card (topology as serializable, World-owned data; #155/#157) gives blueprint_to_json/blueprint_from_json with bind-order-independent structural constants (crates/aura-engine/src/blueprint_serde.rs:81-82/:183-188). - The issue's literal example ships as data: crates/aura-cli/examples/r_sma.json is a named blueprint ("sma_signal") with the SMA length bound to 2 (demo retirement, #159). - The "collection" exists as the content-addressed registry blueprint store (put_blueprint/get_blueprint, `aura graph register`); pull-by-reference exists via content id / identity id, and campaign documents reference strategies exactly that way. - The body's "must stay a Rust module of values, not a registry" constraint was the pre-C24 framing; C24 honors the C9/C10 invariants via type-identity resolution through the closed roster instead. - Residual polish is tracked elsewhere: #191 (identity-ref resolution cost), #183 (bound-param authoring docs). - One stale ledger clause to fix on close: the C19 realization note still says export "is deferred (#60)" (docs/design/INDEX.md:1660).

claude commented

2026-07-21 10:36:42 +02:00

Re-anchoring note, ahead of #60's still-pending own brainstorm.

This issue's opening framing predates two things that now bear directly on it and should seed its eventual brainstorm rather than be silently worked around:

Cycle 0090 (#155/#156/#157, 2026-06-30) shipped topology-as-data: a round-trippable JSON op-script format, a loader, and a construction service, proven end to end (author -> serialize -> load -> construct -> introspect -> reproduce) in fieldtests/milestone-topology-as-data/. Runtime construction of a blueprint from a serialized artifact is therefore already the shipped, sanctioned path — the issue's original constraint ("a future blueprint registry must stay a Rust module of blueprint values ... NOT a by-name runtime node resolution") needs to be read against this shipment, not assumed to rule out a data-artifact-shaped registry.
The C25 amendment landed with #295 (2026-07-20, docs/design/INDEX.md, C25 section) establishes the text-artifact vocabulary — "blueprints, process/campaign documents, registry records" — as the canonical layer that every control surface (CLI executor verbs, any future host, an MCP face, a World program) projects over, never a second home for intent. "Registry records" is now named vocabulary in the ledger for exactly the kind of artifact this issue's third open fork ("relationship to the blueprint-as-values collection, the eventual home") is asking about. Content-addressed blueprint identity (topology_hash, #158, cycle 0094) is also available as a building block for how such a named export would be addressed.

The owner's decided direction on #300 (document-first completion of the run quintet's flag vocabulary) is scoped narrower than this issue and doesn't resolve it directly, but it reinforces the same posture: new intent-bearing surfaces are text artifacts first, control-surface projections second.

No code changes are implicated (crates/aura-core/src/node.rs:226 PrimitiveBuilder::bind and crates/aura-engine/src/blueprint.rs's collect_params/param_space remain the accurate dock sites, unmoved by #295). This is a scope note for whenever #60's own brainstorm is picked up: start from "a named frozen strategy is a text artifact in the same family as blueprints/op-scripts/campaign documents, addressed like a registry record" rather than from the original "Rust module of blueprint values" framing, which is now the more constrained of the two options rather than the only C9-safe one.

Re-anchoring note, ahead of #60's still-pending own brainstorm. This issue's opening framing predates two things that now bear directly on it and should seed its eventual brainstorm rather than be silently worked around: 1. Cycle 0090 (#155/#156/#157, 2026-06-30) shipped topology-as-data: a round-trippable JSON op-script format, a loader, and a construction service, proven end to end (author -> serialize -> load -> construct -> introspect -> reproduce) in fieldtests/milestone-topology-as-data/. Runtime construction of a blueprint from a serialized artifact is therefore already the shipped, sanctioned path — the issue's original constraint ("a future blueprint registry must stay a Rust module of blueprint values ... NOT a by-name runtime node resolution") needs to be read against this shipment, not assumed to rule out a data-artifact-shaped registry. 2. The C25 amendment landed with #295 (2026-07-20, docs/design/INDEX.md, C25 section) establishes the text-artifact vocabulary — "blueprints, process/campaign documents, registry records" — as the canonical layer that every control surface (CLI executor verbs, any future host, an MCP face, a World program) projects over, never a second home for intent. "Registry records" is now named vocabulary in the ledger for exactly the kind of artifact this issue's third open fork ("relationship to the blueprint-as-values collection, the eventual home") is asking about. Content-addressed blueprint identity (topology_hash, #158, cycle 0094) is also available as a building block for how such a named export would be addressed. The owner's decided direction on #300 (document-first completion of the run quintet's flag vocabulary) is scoped narrower than this issue and doesn't resolve it directly, but it reinforces the same posture: new intent-bearing surfaces are text artifacts first, control-surface projections second. No code changes are implicated (crates/aura-core/src/node.rs:226 PrimitiveBuilder::bind and crates/aura-engine/src/blueprint.rs's collect_params/param_space remain the accurate dock sites, unmoved by #295). This is a scope note for whenever #60's own brainstorm is picked up: start from "a named frozen strategy is a text artifact in the same family as blueprints/op-scripts/campaign documents, addressed like a registry record" rather than from the original "Rust module of blueprint values" framing, which is now the more constrained of the two options rather than the only C9-safe one.

claude commented

2026-07-21 15:11:22 +02:00

Closed as ratified drop (owner decision, 2026-07-21, idea-cull round): topology-as-data (cycle 0090) undercut the original Rust-module-only constraint, and C25's registry-records vocabulary answers the remaining fork. On real export demand the ledger dictates the shape.

claude closed this issue

2026-07-21 15:11:22 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Aura#60