Public beta: join our Discord to share feedback and suggestions
Lightcone Stack

Paths

Address any element of an ASTRA analysis with one dot-separated path that mirrors astra.yaml.

A path is a dot-separated route through the analysis tree — the same structure as astra.yaml, and the same dotted spelling the spec itself uses for element references (when: decision.option, from: scope.id, recipe placeholders {inputs.id}). Dots address elements; slashes are reserved for files. A path is read left-to-right: leading segments step into sub-analyses, and the first collection keyword fixes the target. One grammar drives every surface: the {astra} role, the {astra} directive, and the {astra:*} variants.

outputs.hubble_diagram                  an output (figure / table / metric / …)
decisions.algorithm                     a decision
decisions.algorithm.gp                  a child — one option of a decision
findings.sig.fig1                       a child — one evidence record of a finding
prior_insights.recon_sharpens_bao       a prior insight
inputs.raw_catalog                      an input
reconstruction.outputs.xi               an output in the `reconstruction` sub-analysis
reconstruction                          the sub-analysis itself
outputs                                 a whole collection (a registry)

Collections

The recognised collections are exactly the astra.yaml keys:

CollectionContainsSingular kind
inputsDeclared input datasetsinput
outputsFigures, tables, metrics, data, reportsoutput
decisionsMethodological choices and their optionsdecision
findingsClaims with notes, scope, and evidencefinding
prior_insightsCited claims from the literatureprior_insight
analysesNested sub-analysesanalysis

Sub-analyses

A sub-analysis id may be written directly — the analyses. prefix is implied — and nests to any depth:

reconstruction.outputs.xi               shorthand
analyses.reconstruction.outputs.xi      the explicit long form
clustering.correlation.outputs.xi       two levels deep
reconstruction                          the sub-analysis itself (renders a summary card)

Each segment before the first collection keyword is a step into a sub-analysis; the first collection keyword fixes the target.

Children

Two element kinds have addressable children — decisions have options, findings and prior insights have evidence. Since each kind has exactly one child collection, the collection keyword is implied (just like analyses.):

decisions.<id>.<option-id>              one option of a decision
findings.<id>.<evidence-id>             one evidence record of a finding
prior_insights.<id>.<evidence-id>       one evidence record of a prior insight

decisions.<id>.options.<option-id>      … the explicit long forms
findings.<id>.evidence.<evidence-id>

Registries

A path that stops at a collection addresses the whole collection — in a block embed this renders a registry (a table of inputs or outputs, all findings, all decisions, …):

outputs                                 the outputs registry of the root analysis
reconstruction.inputs                   the inputs registry of a sub-analysis

Where paths resolve from

A path always resolves from the root analysis, so it means the same thing on every page. To address something inside a sub-analysis, spell the scope out: reconstruction.outputs.xi. Paths must use canonical collection names and exact dot-separated segments; leading slashes, empty segments, and trailing content are errors.

IDs and labels

The final path segments are the ids you declared in astra.yaml (snake_case by convention). When MySTRA needs a human-readable label — an inline reference with no display text, for instance — it prefers the element's label: (or name: for analyses) and falls back to the id with underscores replaced by spaces.