Brummel/Aura
1
0
Fork 0
Code Issues 31 Pull Requests Actions Packages Projects Releases Wiki Activity

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

New Issue
Closed
opened 2026-06-22 11:08:15 +02:00 by Brummel · 2 comments
Brummel commented 2026-06-22 11:08:15 +02:00
Owner
Copy Link
Copy Source

Status: discussion / focus-keeper — NOT for automatic dispatch. This records a
design direction the user wants kept in focus; it is deliberately not being tackled
yet. Decide direction (the open fork below) before any cycle.

Why this issue exists

aura's differentiator is the meta-level (C21 — the World is the product): not
the single backtest, but dynamically constructing and orchestrating families of
harnesses. The big late layers that realize it currently live only as ledger
direction with no tracker presence — exactly how a load-bearing layer slips
out of focus. This issue is the durable home for it until it becomes a milestone.

The vision (user, 2026-06-22)

Every project is fully Rust-based (C16: a project is a Rust crate; C17: all
logic — nodes, strategies, experiments — is native Rust via builder APIs, no DSL).
The low-level nodes are written in Rust. On the future meta-level, however,
"developing a strategy" is no longer writing new node code — it is:

  1. wiring existing nodes into strategies / harnesses (composition, C9), and
  2. defining the analysis framework — the orchestration of families
    (sweep / Monte-Carlo / walk-forward / compare) as composable tools a user
    wires into an analysis workflow, rather than today's hard-wired CLI verbs (C21).

The user wants this meta-level driven entirely via the CLI, and later also
via the interactive server / playground (C14 two faces; C22 playground).

The load-bearing open fork (resolve in a future brainstorm)

"Driven via the CLI / playground" hides a line that must be drawn, because two
activities are being conflated:

  • Authoring the wiring/topology + the analysis framework — today C17/C22/C9 put
    this firmly in Rust: C22 forbids constructing/wiring topology in the UI
    ("topology is Rust + hot-reload; the UI tunes runtime params"), C17 forbids an
    experiment/strategy DSL (the RustAst trap), and C9/#60 forbid a by-name runtime
    node registry.
  • Running / param-tuning / comparing the authored thing — this is the CLI +
    playground's job (C12 runtime-param tuning, C22 trace explorer).

So the fork: does "wiring via the CLI" mean (a) running a Rust-authored
experiment via the CLI / playground (compatible with C16/C17/C22), or (b)
composing/wiring nodes through the CLI itself (which tensions with C17's no-DSL,
C22's no-UI-topology, and C9's no-node-registry)? If the intent is (b), it is a
deliberate amendment to those contracts and needs that case made; if (a), it is the
project-env + composable-orchestration design with no contract change. This is the
first thing the brainstorm must settle.

What this layer is made of (all currently unbuilt, ledger-direction only)

  • Project-as-crate authoring — aura new scaffolder, the experiment-builder API
    (harness wiring, structural axes, sweep combinators), the Aura.toml static-context
    schema, cdylib project loading. Ledger: "not yet designed" (INDEX.md open threads;
    C16/C17/C20). Code recon (#28 comments): zero cdylib / Aura.toml / project-loader
    machinery in the repo.
  • Composable orchestration — sweep / MC / walk-forward become composable
    meta-level tools instead of hard-wired CLI verbs (sweep_family /
    walkforward_family in aura-cli). Ledger names it "the orchestration-composability
    rebuild … its own later cycle, deliberately deferred" (C22 amendment, #107).
  • The interaction surfaces — CLI first, then the interactive server / web
    playground (#72 is the discussion-only web-frontend idea; the families-comparison
    view #107 is the first read-side step on the playground track).

Relation to existing items

  • #107 — families-comparison view: the first read-side step toward this meta-level
    (decoupled "set of runs" consumer); does NOT build the orchestration layer.
  • #60 — export a named frozen strategy: part of the strategy-authoring surface
    (Rust module of blueprint values, C9-ok), a sibling fork.
  • #61 — parameter ganging; #100 — Cell/Scalar param-authoring ergonomics: small
    facets of the experiment-authoring surface.
  • #72 — web frontend driving the CLI (discussion idea): the later interaction face.
  • Sibling unqueued big-rock: the realistic broker (C10 A-side) — also ledger-only.

Sequencing

Per the ledger sequencing note + the project-env memory: the runnable single-harness
substrate first (done), then the World/meta layer (C21) and the playground (C22) as
the differentiating follow-on; the project-as-crate authoring comes late, after the
World layer + experiment API harden. When picked up, this becomes a milestone
container seeded by a brainstorm that first resolves the open fork above.

context: captured from a design conversation (2026-06-22) so the meta-level does not
slip out of focus; not for auto-dispatch.

**Status: discussion / focus-keeper — NOT for automatic dispatch.** This records a design direction the user wants kept in focus; it is deliberately not being tackled yet. Decide direction (the open fork below) before any cycle. ## Why this issue exists aura's differentiator is the **meta-level** (C21 — the World is the product): not the single backtest, but dynamically constructing and orchestrating *families* of harnesses. The big late layers that realize it currently live only as ledger *direction* with **no tracker presence** — exactly how a load-bearing layer slips out of focus. This issue is the durable home for it until it becomes a milestone. ## The vision (user, 2026-06-22) Every project is **fully Rust-based** (C16: a project *is* a Rust crate; C17: all logic — nodes, strategies, experiments — is native Rust via builder APIs, no DSL). The low-level **nodes** are written in Rust. On the future **meta-level**, however, "developing a strategy" is no longer writing new node code — it is: 1. **wiring existing nodes** into strategies / harnesses (composition, C9), and 2. **defining the analysis framework** — the orchestration of families (sweep / Monte-Carlo / walk-forward / compare) as *composable tools* a user wires into an analysis workflow, rather than today's hard-wired CLI verbs (C21). The user wants this meta-level driven **entirely via the CLI**, and **later also via the interactive server / playground** (C14 two faces; C22 playground). ## The load-bearing open fork (resolve in a future brainstorm) "Driven via the CLI / playground" hides a line that must be drawn, because two activities are being conflated: - **Authoring** the wiring/topology + the analysis framework — today C17/C22/C9 put this firmly in **Rust**: C22 forbids constructing/wiring topology in the UI ("topology is Rust + hot-reload; the UI tunes runtime params"), C17 forbids an experiment/strategy DSL (the RustAst trap), and C9/#60 forbid a by-name runtime node registry. - **Running / param-tuning / comparing** the authored thing — this *is* the CLI + playground's job (C12 runtime-param tuning, C22 trace explorer). So the fork: does "wiring via the CLI" mean **(a)** *running* a Rust-authored experiment via the CLI / playground (compatible with C16/C17/C22), or **(b)** *composing/wiring nodes through the CLI itself* (which tensions with C17's no-DSL, C22's no-UI-topology, and C9's no-node-registry)? If the intent is (b), it is a deliberate amendment to those contracts and needs that case made; if (a), it is the project-env + composable-orchestration design with no contract change. **This is the first thing the brainstorm must settle.** ## What this layer is made of (all currently unbuilt, ledger-direction only) - **Project-as-crate authoring** — `aura new` scaffolder, the experiment-builder API (harness wiring, structural axes, sweep combinators), the `Aura.toml` static-context schema, cdylib project loading. Ledger: "not yet designed" (INDEX.md open threads; C16/C17/C20). Code recon (#28 comments): zero cdylib / Aura.toml / project-loader machinery in the repo. - **Composable orchestration** — sweep / MC / walk-forward become composable meta-level tools instead of hard-wired CLI verbs (`sweep_family` / `walkforward_family` in aura-cli). Ledger names it "the orchestration-composability rebuild … its own later cycle, deliberately deferred" (C22 amendment, #107). - **The interaction surfaces** — CLI first, then the interactive server / web playground (#72 is the discussion-only web-frontend idea; the families-comparison view #107 is the first read-side step on the playground track). ## Relation to existing items - #107 — families-comparison view: the first read-side step toward this meta-level (decoupled "set of runs" consumer); does NOT build the orchestration layer. - #60 — export a named frozen strategy: part of the strategy-authoring surface (Rust module of blueprint values, C9-ok), a sibling fork. - #61 — parameter ganging; #100 — Cell/Scalar param-authoring ergonomics: small facets of the experiment-authoring surface. - #72 — web frontend driving the CLI (discussion idea): the later interaction face. - Sibling unqueued big-rock: the realistic broker (C10 A-side) — also ledger-only. ## Sequencing Per the ledger sequencing note + the project-env memory: the runnable single-harness substrate first (done), then the World/meta layer (C21) and the playground (C22) as the differentiating follow-on; the project-as-crate authoring comes late, after the World layer + experiment API harden. When picked up, this becomes a **milestone container** seeded by a brainstorm that first resolves the open fork above. context: captured from a design conversation (2026-06-22) so the meta-level does not slip out of focus; not for auto-dispatch.
Brummel added the idea label 2026-06-22 11:08:15 +02:00
Brummel commented 2026-06-28 12:33:46 +02:00
Author
Owner
Copy Link
Copy Source

Requirement-spec for the composable-analysis half (strategy-research vision)

Recorded from a 2026-06-28 design discussion (the same one that reworked C10, commit 29cdc8c). This is the why the analysis meta-level must be composable rather than a fixed scalar-metric list.

The research unit is not "a profitable signal" but "a conditionally predictive signal + the orthogonal context that selects its regime."

  • A strategy is a composition of orthogonal components. A signal (e.g. an oscillator "oversold") means nothing alone; it needs orthogonal signals that confirm and — above all — refute it (higher-timeframe trend, news event, session-open). The edge is in the combination.
  • Individual signals are not profitable (E[R]≈0); a lone equity curve is uninteresting. So it is not about whether a signal's performance level rises — it is about how the performance curve looks: is the signal, under certain circumstances, able to predict a market inefficiency, and which orthogonal signals confirm/filter it?
  • The question is therefore conditional: evaluate a signal's R-distribution sliced by other signals' states (trend regime, session, news, vol) — does conditioning separate the distribution? conviction_terciles_r is the seed; the general capability is unbuilt.
  • "Refute" is its own evaluation primitive. A filter has no meaningful standalone curve — it removes bad regimes. Its value = how it reshapes another signal's curve (E[R] of A with the filter vs without), never its own E[R]. Structural home: the Veto seam (stop-rule → [Veto] → position-management).

What this demands of the meta-level (#109):

  • conditional / sliced R analysis (slice a signal's R by other signals' states; see the shape, not a scalar);
  • measuring orthogonality (does B add information independent of A?), not assuming it;
  • composing confirm/refute and reading each component's marginal contribution.

Caution (load-bearing): conditional slicing = degrees of freedom = false discovery. This capability MUST ride on the already-built anti-false-discovery machinery (deflation, cross-instrument generalization, aura generalize); orthogonality is the antidote only if measured, not assumed.

Fit with the C10 rework: gross R (cost optional) gives the cheap brutto-testing of non-profitable blocks; removing compounding makes the curve's shape signal-faithful; R + feed-forward + C9 is the clean composable substrate this analysis sits on. The rework cleared the ground; this is the house that #109 must build.

## Requirement-spec for the composable-analysis half (strategy-research vision) Recorded from a 2026-06-28 design discussion (the same one that reworked C10, commit `29cdc8c`). This is the *why* the analysis meta-level must be composable rather than a fixed scalar-metric list. **The research unit is not "a profitable signal" but "a *conditionally* predictive signal + the orthogonal context that selects its regime."** - A strategy is a composition of **orthogonal components**. A signal (e.g. an oscillator "oversold") means nothing alone; it needs orthogonal signals that **confirm** and — above all — **refute** it (higher-timeframe trend, news event, session-open). The edge is in the combination. - Individual signals are **not profitable** (E[R]≈0); a lone equity curve is uninteresting. So it is **not** about whether a signal's performance *level* rises — it is about **how the performance curve *looks***: is the signal, *under certain circumstances*, able to predict a market inefficiency, and which orthogonal signals confirm/filter it? - The question is therefore **conditional**: evaluate a signal's R-distribution **sliced by other signals' states** (trend regime, session, news, vol) — does conditioning *separate* the distribution? `conviction_terciles_r` is the seed; the general capability is unbuilt. - **"Refute" is its own evaluation primitive.** A filter has no meaningful standalone curve — it removes bad regimes. Its value = how it **reshapes another signal's curve** (E[R] of A *with* the filter vs *without*), never its own E[R]. Structural home: the **Veto seam** (`stop-rule → [Veto] → position-management`). **What this demands of the meta-level (#109):** - conditional / sliced R analysis (slice a signal's R by other signals' states; see the *shape*, not a scalar); - **measuring** orthogonality (does B add information independent of A?), not assuming it; - composing confirm/refute and reading each component's *marginal* contribution. **Caution (load-bearing):** conditional slicing = degrees of freedom = false discovery. This capability MUST ride on the already-built anti-false-discovery machinery (deflation, cross-instrument generalization, `aura generalize`); orthogonality is the antidote *only if measured*, not assumed. Fit with the C10 rework: gross R (cost optional) gives the cheap brutto-testing of non-profitable blocks; removing compounding makes the curve's *shape* signal-faithful; R + feed-forward + C9 is the clean composable substrate this analysis sits on. The rework cleared the ground; this is the house that #109 must build.
Brummel commented 2026-07-03 11:56:19 +02:00
Author
Owner
Copy Link
Copy Source

The meta-level question this issue holds open now has a broader anchor: issues/188 records the ratified role model (nine user roles cut by artifact + surface + iteration cost), the diagnosis that the methodology and campaign layers lack artifact types entirely, and the resolved fork that both become closed-vocabulary data documents (the op-script pattern one level up) — never a Rust builder API, never an open DSL. The (a)-vs-(b) fork recorded here resolves toward (a) generalized: experiments are Rust-free data artifacts referencing strategies by content/identity id; node logic stays Rust. This issue remains the home of the composable-orchestration substrate question; the artifact-vocabulary design pass is anchored on issues/188.

The meta-level question this issue holds open now has a broader anchor: issues/188 records the ratified role model (nine user roles cut by artifact + surface + iteration cost), the diagnosis that the methodology and campaign layers lack artifact types entirely, and the resolved fork that both become closed-vocabulary data documents (the op-script pattern one level up) — never a Rust builder API, never an open DSL. The (a)-vs-(b) fork recorded here resolves toward (a) generalized: experiments are Rust-free data artifacts referencing strategies by content/identity id; node logic stays Rust. This issue remains the home of the composable-orchestration substrate question; the artifact-vocabulary design pass is anchored on issues/188.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BLOCKER
Core functionality blocked; preempts other selection
 bug
Observable misbehaviour
 feature
Substantial extension; no full spec required
 idea
Droppable; no commitment
No Label idea
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Aura#109
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?