Foundry Workflow: Author, Test, Publish

Every ladder goes through the same cycle:

1. Author — write the YAML config (in the visual editor or raw YAML).
2. Validate — Foundry checks the config at save time. Structural errors (bad references, missing fields, malformed schemas) are caught before any LLM call runs.
3. Test run — execute the ladder with a real prompt. Foundry renders a live timeline showing every step, node, gate evaluation, and slate write.
4. Inspect — read the trace. Identify where the ladder produced good output and where it failed. Adjust prompts, gates, or node counts.
5. Publish — when the ladder is producing consistent results, publish it to the library at a chosen visibility tier.
6. Iterate — publish new versions as you improve the strategy. Callers pin to a version for reproducibility.

This article walks through each phase with a concrete example.

Foundry provides two editing modes that produce the same YAML:

Visual editor. Drag steps onto the canvas, click to add fields, type system prompts into text areas, select gate conditions from dropdowns. Useful for getting started and for visualizing ladder structure. The editor validates field references as you type.

Raw YAML. Click the YAML tab to edit the config directly. Useful for experienced authors, for copy-pasting from examples, and for features the visual editor does not expose (e.g., retrieve: blocks, checkpoint: labels).

Both modes produce the same output. You can switch between them at any time; changes in one are reflected in the other.

name: Research Briefing
allowedTargets: { strategy: universal }
exit: synthesize
knobs:
  branches:
    name: Analysts
    type: nodes
    input: slider
    steps:
      - { title: Fast, value: 3 }
      - { title: Standard, value: 5, default: true }
      - { title: Deep, value: 8 }

steps:
  - id: analyze
    nodes: branches
    fields:
      - { name: Question, type: text, from: input.context }
    systemPrompt: "You are an independent analyst. Produce a structured analysis."

  - id: score
    fields:
      - { name: Analysis, type: multi_ingest, from: [{ stepId: analyze, loopRef: current, nodeRef: accumulate }] }
    systemPrompt: 'Score each analysis 1-5. Output the integer alone.'
    if:
      integerRange: [4, 5]
      then: continue
      else: { jump: { stepId: analyze } }

  - id: synthesize
    fields:
      - { name: Analyses, type: multi_ingest, from: [{ stepId: score, loopRef: current, nodeRef: accumulate }] }
    systemPrompt: "Synthesize the surviving analyses into one briefing."

This ladder drafts N independent analyses in parallel, scores them, prunes anything below 4, and synthesizes the survivors. The caller controls N via the branches knob.

When you click Save, Foundry runs a three-phase validation pass:

1. Parse. The YAML is parsed as a LADR config. Unknown top-level keys, malformed YAML, and missing required fields fail here.
2. Static validation. Field references are resolved (does stepId: analyze exist?), gate conditions are checked (integerRange: [5, 3] has min > max), JSON Schemas are parsed, recursion depth is valid, exit step exists.
3. Aggregation. All errors are collected and displayed together. The config is rejected if any error is found.

If validation passes, you see a green Saved badge and the ladder is stored as a new version. If it fails, each error includes the step ID and the offending field so you can locate the problem.

Common validation errors:

Validation errors do not cost LLM calls. You can iterate on config structure for free.

Once the config validates, test it with a real prompt.

In Foundry: Click Test run. Enter a prompt in the input field. Select knob values (e.g., branches: 3 for a fast test run). Select a model (e.g., gpt-4o). Click Run.

Foundry dispatches the ladder execution and renders a live timeline as it progresses:

• Each step appears as a section in the timeline.
• For multi-node steps, each node is a dot. Pruned nodes (failed the gate) are visually marked.
• Gate evaluations are shown inline: the condition, the number of survivors, and which action fired.
• Slate writes are shown as annotations on the step that triggered them.
• Token cost and latency are shown per step and in aggregate.

Via curl: You can also test via the API. Private ladders are callable with your API key:

curl https://api.redeo.ai/v1/<your-username>/research-briefing/chat/completions \
  -H "Authorization: Bearer $REDEO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Analyze the trade-offs of microservices vs monoliths for a 20-person startup."}],
    "knobs": { "branches": 5 }
  }'

The response is a standard OpenAI chat completion. The model field is set to <your-username>/research-briefing. The usage field shows total tokens across all LLM calls in the execution.

The execution trace is the primary debugging surface. Read it top to bottom:

1. Step order. Confirm the steps ran in the expected order. A backward jump creates a visible loop in the timeline.

2. Node outputs. Click any node dot to see the raw LLM output. For the analyze step, read each analyst's output. Are they meaningfully different? If all 5 nodes produce the same analysis, the system prompt may need to encourage diverse approaches.

3. Gate results. The score step's gate shows which nodes passed and which were pruned. If the gate pruned everything (else: fired), the scoring prompt may be too strict. If the gate passed everything, it may be too lenient.

4. Synthesis quality. Read the synthesize step's output. Does it incorporate the surviving analyses? Does it drop information? The synthesis system prompt is usually the highest-leverage tuning point.

5. Cost breakdown. The aggregate token count tells you the per-call cost. A 5-branch ladder with 3 surviving nodes typically uses 8-12 LLM calls (5 analyze + 5 score + 1 synthesize, minus pruned). At GPT-4o pricing, that is roughly $0.05-0.10 per call.

What to look for:

When the ladder is producing consistent results, publish it.

To publish: Click Publish in Foundry. Choose a visibility tier:

See Publishing and Visibility for full details on each tier.

Once published, the ladder is available at library.redeo.io/@{your-username}/{ladder-slug}. External callers invoke it via:

curl https://api.redeo.ai/v1/{your-username}/{ladder-slug}/chat/completions \
  -H "Authorization: Bearer $REDEO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "..."}]
  }'

Before you publish, verify:

• The executionBudget is set. A published ladder without a spend cap is a liability.
• The system prompts do not contain internal jargon or proprietary references.
• The knobs have sensible defaults. Most callers will not override them.
• The allowedTargets strategy is correct. universal accepts any model; constrained limits to specific providers/models.
• The ladder works with at least two different models (e.g., GPT-4o and Claude). If it only works with one model, constrain allowedTargets to that model.

Published versions are immutable. Once version 1 is public, callers can pin to it and expect reproducible behavior. You cannot modify version 1; you publish version 2.

Publishing a new version: Edit the ladder in Foundry, test it, then click Publish new version. The new version becomes the default for new callers. Callers who pinned to version 1 continue to get version 1 until they explicitly upgrade.

Versioning discipline:

• Incremental changes (prompt tuning, threshold adjustment): publish a new version, document the change in the description.
• Structural changes (new steps, changed fields, removed steps): this is a breaking change. Consider publishing as a new ladder instead of a new version. Callers who ingest the output schema may break.
• Forking: if another author wants to take the ladder in a different direction, they can fork it. The fork starts as a copy and evolves independently. See Ladder Addressing for fork semantics.

What to track between versions:

• Which system prompts changed and why.
• Which gates were tightened or loosened.
• Whether node counts or knobs changed.
• Whether the exit step changed (this changes the response format).

Foundry shows a diff between versions when you publish, so callers can see what changed.

Before publishing a ladder, run through this checklist:

Config quality:

• Every step has a clear id and name (not step1, step2).
• System prompts are specific and self-contained (no references to internal tools or proprietary data shapes).
• Gates use the most specific predicate that works (integerRange over contains over equals).
• No continueIf: — use the typed if: form.
• checkpoint: labels on long ladders (helps callers read the trace).

Safety:

• executionBudget.maxSpend is set (default $5 is generous; tighten for public-free).
• executionBudget.maxHops is set (tight enough to catch runaway loops).
• No nodes: above 20 (runtime cap).

Usability:

• Knobs have sensible defaults. Most callers will not override them.
• Knob steps (for slider input) are meaningfully different (not [3, 4, 5]).
• allowedTargets is correct. If the ladder only works with GPT-4o, constrain it.
• The ladder works with at least two models from different providers.

Testing:

• Run the ladder with at least 5 different prompts.
• Check that the gate prunes meaningfully (not all-pass or all-fail).
• Verify the exit step output is the final answer (not an intermediate step).
• Check token cost per call is within your budget.