Publishing and Visibility

A ladder is data, but it's also a product. Authors have different goals:

• Some want maximum distribution (a free ladder that establishes research credibility).
• Some want revenue (a paid ladder that earns per call).
• Some want IP protection (a flagship ladder that's callable via API but never disclosed).
• Some want self-hosting only (internal tooling that never touches the directory).

One publishing model cannot serve all of these. LADR's visibility tier system lets each author pick the right model per ladder. Five tiers cover the space.

The tiers also serve the platform's commercial logic. The directory is two-sided: it needs supply (ladders) and demand (callers). Free ladders seed supply; paid ladders create a marketplace; private ladders let Redeo itself (and enterprise customers) keep IP internal while still using the runtime. Local ladders cost the platform nothing but expand the user base.

Each tier is a different combination of (1) where the ladder's config is visible, (2) where it runs, and (3) how it's priced.

Config disclosure. Public tiers disclose the full YAML. The whole point of publishing is that callers can see what they're running. Private tiers do not disclose config; callers trust the publisher.

Listing. Only public ladders appear in the directory. Private and local ladders are addressable (via @author/name for hosted-private, via local/name for local — see Ladder Addressing) but not listed.

Pricing. Only public-paid ladders have a price callers pay. The others are either free (public-free), priced via custom contracts (hosted-private, enterprise-local-licensed), or self-hosted at the caller's own cost (local).

public-free ladders are the directory's foundation. Anyone can invoke them; the full YAML is disclosed; no cost to the caller beyond their normal API usage.

visibility: public-free
license: AGPL-3.0

Why publish for free.

• Research credibility. A published SOTA-beating ladder with measured benchmark outcomes is a research artifact. Free publication is how the result gets verified, cited, and built on.
• Seed supply for the marketplace. A directory with no free ladders is dead. Free ladders from Redeo and early creators bootstrap the supply.
• Network effects. A free ladder that gets forked and remixed contributes to the corpus thesis: every call generates training data that benefits future models.
• Funnel to paid offerings. A free basic ladder can drive callers toward a paid advanced ladder by the same author.

License. Public-free ladders are AGPL-3.0 by default (matching the platform license). Callers who self-host must comply with AGPL. Alternative licenses (MIT, Apache-2.0) are configurable per ladder; some authors may prefer permissive licensing for broader adoption.

No cost ceiling. public-free doesn't mean cheap to run; it means no per-call price. A free ladder can still declare a generous executionBudget and consume significant tokens. The caller pays for token usage through their normal Redeo or provider billing.

public-paid ladders are listed on the directory with a price the caller pays per invocation. The author sets the price; the platform takes a cut (default 15%, configurable per deployment).

visibility: public-paid
pricing:
  model: per_call | per_1k_calls | subscription
  amount: 0.05        # USD

Three pricing models.

• Per call. Caller pays a fixed amount every time they invoke the ladder. Simple, predictable. Best for ladders with bounded cost.
• Per 1,000 calls. Lower per-call price for high-volume callers. Useful for production integrations.
• Subscription. Caller pays a monthly fee for unlimited (or capped) calls. Useful for ladders that callers use frequently.

The default 15% platform cut is a deliberate choice. Below App Store parity (30%); competitive with Substack (10%); signals creator-friendliness. Configurable per deployment; self-hosted deployments can set it to 0.

Revenue share mechanics.

• Caller pays price + platform cut at invocation time.
• Platform records the transaction.
• Payouts to creators via Stripe Connect (recommended). Handles KYC, international tax, refunds.

Verified-benchmark badges. A "Redeo Verified" tier rewards ladders that pass curated benchmark suites. The badge is a trust signal (this ladder really does what it claims) and feeds the corpus thesis (measured outcomes are research data). Both directory ranking and payout bonuses may apply.

Ranking. Directory ranking weights measured outcomes more than popularity. A ladder that actually beats benchmarks ranks above one that's merely well-marketed. This is the alignment between marketplace incentives and the research mission: being good is the same as being successful.

hosted-private ladders are callable via the Redeo API but never disclosed. The full YAML is kept internal to the publisher. The ladder does not appear in the directory.

visibility: hosted-private

Why host privately.

• Flagship IP. Publishers may keep proprietary ladders private — the config is never disclosed, protecting trade secrets.
• Provider-gated. Hosted-private ladders can be configured to use managed providers exclusively. Even if the config leaks, running it elsewhere is constrained.
• Custom pricing. Hosted-private ladders can have custom pricing via enterprise contracts, not per-call public pricing.

Callable via standard API. Despite being private, the ladder is invoked via the same OpenAI-compatible endpoint:

POST /v1/{author}/{ladder}/chat/completions

To the caller, it looks like a normal ladder invocation. The config is never exposed in the response.

Trust model. Callers trust the publisher's reputation and service-level commitments. The directory's trust signals (verified benchmarks, fork lineage) don't apply because the config isn't public.

Enterprise-local-licensed (planned) extends this to customer infrastructure. The ladder runs on the customer's hardware under license, encrypted to prevent inspection. Used for data-residency and compliance scenarios.

local ladders never leave the user's machine. They are not uploaded; they are not listed; they are callable only from the local runtime.

visibility: local
name: my-experiment

Addressed via the local/ namespace: local/my-experiment. See Ladder Addressing for the full reference.

Use cases.

• Development. Iterating on a ladder before publishing. Local lets you test without committing to a visibility tier.
• Internal tools. A ladder that wraps your company's internal APIs. Not for the public.
• Personal workflows. A ladder you run for yourself, customized to your preferences. Never intended for distribution.
• Privacy-sensitive. Ladders that process data you don't want to leave your machine.

No publish step. A local ladder is just a YAML file on disk in the runtime's search path. No upload, no version pinning, no listing. The ladder is always "the current file on disk."

Local ladders cannot be referenced from published ladders. A public ladder that jumps to local/X fails when someone else runs it (their environment doesn't have local/X). Keep local/ references inside the local environment only.

A ladder's visibility tier can change after publication, with caveats.

public-free to public-paid. Allowed. Existing callers continue to work; new callers pay the new price. Existing pinned references to old free versions remain free.

public-paid to public-free. Allowed. Existing paid subscribers stop being charged; new callers pay nothing. Useful for sunsetting a paid ladder while keeping it accessible.

public-* to hosted-private. Allowed but breaks existing public references. Callers who pinned to a public version continue to work; callers using latest silently fail. Don't do this without notice.

hosted-private to public-*. Allowed. The config is disclosed for the first time. Existing private references continue to work.

* to local. Effectively unpublishing. The ladder disappears from the directory. Existing pinned references continue to resolve (versions are immutable); latest references silently fail.

Version immutability applies. Even when a ladder's tier changes, already-published versions don't change. A caller who pinned to @alice/helper@v3 when it was public continues to get the same config even if Alice later moves the ladder to hosted-private. Tier changes apply to new versions only.

Can I publish the same ladder under multiple visibility tiers? Yes, via forking. Publish the free version; fork it to a paid version with extras; fork it to a private version for enterprise customers. Each fork is a first-class ladder with its own tier.

What's the difference between unpublishing and deleting? Unpublishing (moving to local) removes the ladder from the directory but preserves existing pinned references. Deleting (which the platform discourages) would break all existing references. Prefer unpublishing.

Can I set different prices per version? Yes. Each version can have its own pricing. v1 might be free; v2 might be paid; v3 might raise the price. Existing pinned references keep the price at the time of pinning.

What if a free ladder costs the caller money to run? It does, in token costs. public-free means no per-call price to the publisher; the caller still pays their normal provider costs. Make sure your ladder's executionBudget is bounded so callers know what to expect.

Can hosted-private ladders be forked? No. Forking requires config disclosure; private configs cannot be forked. The publisher can publish a separate public version if they want to allow forking.

How are paid ladders discovered? Via the directory, same as free ladders. Paid ladders appear in search and ranking alongside free ones. The price is shown prominently. Verified-benchmark badges apply equally to paid and free ladders.

Do local ladders support cross-ladder jumps? Yes, but only to other local ladders in the same runtime. A local ladder cannot jump to a published ladder without network access; a published ladder cannot jump to a local ladder (the reference would fail when anyone else runs it).