Ladder Addressing

Most platforms split a content item's identity from its URL: a video has a YouTube ID and a separate URL; a repo has a GitHub ID and a separate URL. Two things to remember, two things to share, two things that can drift.

LADR collapses them. The canonical identifier for a ladder is its public URL: @author/name renders at library.redeo.io/@author/name. One thing to remember, type, share, index, and crawl.

What this buys:

• Memorable and shareable. People can type @alice/researcher from memory. They can paste the URL into Slack, email, a paper bibliography.
• Indexable by search. Every published ladder is a real public page. Search engines crawl it. People find ladders via Google.
• Crawlable by future training corpora. Publishing measured reasoning strategies to a crawlable directory means future LLMs train on "which strategies work." This is the long-game corpus thesis.
• One thing, not two. No ID-to-URL mapping. No "permalink" concept. The identifier IS the shareable URL.

The convention is borrowed from GitHub (@user/repo) and NPM (@scope/package). Users already know it.

Four forms are accepted.

# Public ladder, latest version.
"@alice/helper"

# Public ladder, pinned to a specific version.
"@alice/helper@v3"

# Org-namespaced ladder (no leading @).
"redeo-labs/tot"

# Local (unpublished, self-hosted only).
"local/my-experiment"

Cross-ladder jumps use these forms in the ladderId field:

then: { jump: { ladderId: "@alice/helper" } }
then: { jump: { ladderId: "@alice/helper@v3" } }
then: { jump: { ladderId: "redeo-labs/tot" } }
then: { jump: { ladderId: "local/my-experiment" } }

Versions are immutable. Once published, a version of a ladder never changes. @alice/helper@v3 always resolves to the same config, the same YAML, the same behavior, forever.

@alice/helper (no version) resolves to the latest published version. As the author publishes v4, v5, v6, the unversioned reference silently moves forward. This is the right default for casual use; it's the wrong default for reproducibility.

When to pin a version:

• Benchmarks and papers. A published result must be reproducible. Pin to the exact version that produced the number.
• Production integrations. If your application depends on a ladder's behavior, pin to avoid surprise breakage when the author publishes a new version.
• Compliance and audit. Regulated environments need to know exactly what code ran. Pinning makes the answer deterministic.

When to use latest:

• Development and exploration. While you're figuring out what ladder to use, latest gives you the author's most recent improvements.
• Casual use. If a new version breaks something, you can always pin after the fact.

Publishing a new version does not break old versions. Existing pinned references continue to work unchanged. Existing callers using latest silently get the new version on their next call. Authors can publish breaking changes; callers who pinned are insulated; callers on latest adapt or pin after the fact.

Users can rename their accounts. @alice becomes @aliceprime. References must keep working forever.

The platform implements this via permanent redirects (HTTP 301, GitHub model). @alice/old-name continues to resolve after the rename; it transparently redirects to @aliceprime/old-name. Old references in published ladders, old URLs in papers, old API calls in production code — all keep working.

This is non-negotiable. The alternative (breaking old references on rename) would silently corrupt the entire published-ladder ecosystem every time anyone changed their username. References must be permanent; renames must be transparent.

Org renames work the same way. redeo-labs/tot → redeo/tot redirects transparently.

What this means for authors. Don't worry about choosing the perfect username before publishing. You can rename later without breaking anyone who references your ladders. The platform handles the indirection.

GitHub-style forking with preserved lineage. Any published ladder can be forked by any user. The fork is a first-class ladder with its own identifier, its own versions, its own (optional) price.

@bob/tot
  forkedFrom: @alice/tot@v3
  forkedAt: 2026-04-15

The fork's directory page shows the lineage: "Forked from @alice/tot@v3." Visitors can trace any fork back to its origin.

Why lineage matters.

• Credit. The original author gets attribution on every fork's page.
• Auditing. A caller using @bob/tot can see it derives from @alice/tot and decide whether to trust the derivation.
• Evolution tracking. The directory can show "this strategy has been forked N times," which is a useful signal of usefulness.
• Research reproduction. A paper citing @bob/tot can note the derivation and readers can compare the fork to the original.

Forks are independent. Once forked, the fork evolves independently of the original. @alice/tot publishes v4; @bob/tot does not automatically update. Bob can manually pull changes from Alice's v4 if he wants, but it's a deliberate act, not automatic.

Forks compete on the directory. If Alice's original is paid and Bob's fork is free, both appear in search results. The market decides. This is by design: it incentivizes authors to keep their ladders useful, and it lets the corpus evolve via selection.

local/name is for unpublished, self-hosted ladders. They never appear in the directory. They're callable only from the environment where they're declared. See Publishing and Visibility for the full tier system.

then: { jump: { ladderId: "local/my-experiment" } }

Use cases:

• Development. Building a new ladder before publishing. Test it locally; iterate; publish when ready.
• Internal tools. A ladder that's specific to your team or company. Not for the public directory.
• Experiments. Trying variations on a published ladder without polluting the directory with forks.
• Private ladders. Publishers may deploy proprietary ladders locally without publishing to the directory.

Local ladders don't have version suffixes. local/my-experiment is always "the current version on disk." No @vN pinning, because there's no publish step.

Local ladders are not portable. A reference to local/X in a published ladder config fails when someone else tries to run that ladder (their environment doesn't have local/X). Don't reference local/ ladders from published ladders. Use local/ only for ladders you run yourself, not for ladders you intend to publish.

Cross-ladder jump targets are validated at config load time. The grammar:

• @author/name: requires non-empty author and name. author cannot contain /. name cannot contain /.
• @author/name@vN: requires N to be a positive integer (after the v).
• org/name: requires non-empty org and name. Same character restrictions.
• local/name: requires non-empty name. No further slashes.

Malformed identifiers fail validation:

Step "delegate": then jump has invalid ladderId "@alice": expected @author/name, got "@alice"
Step "delegate": then jump has invalid ladderId "@alice/helper/v2": ladderId: invalid local name "@alice/helper/v2"
Step "delegate": then jump has invalid ladderId "local/a/b": ladderId: invalid local name "local/a/b"

The validator checks the format of the identifier. It does not check whether the referenced ladder actually exists at validation time — that's a runtime check against the directory.