S-Curve Evaluation Lens

One-line summary: An evaluation layer over this project's causal chains — once a chain is judged true (evidence per step), the S-curve lens asks how much of the move is left, how fast it arrives, and when the knee dates — using a technology's position on its adoption curve, the curve's steepness, and the underlying Wright's-Law cost tipping point.

The insight

The conviction model scores whether a mechanism is true; it does not score whether the move is still ahead or imminent. Those are orthogonal: a confirmed chain can be near saturation (little upside left) while a partial chain can sit right at the inflection (large upside if it confirms). The S-curve supplies that missing timing-and-magnitude layer. The full theory lives in the technology-adoption-s-curves thread; this page is its operational form for evaluating a stock-market signal.

Three inputs, mapping to the three intended encodings:

1. Remaining-runway (position). Where does the beneficiary technology sit on its adoption curve — penetration % against an honest range for the ceiling L (see technology-adoption-s-curve)? Near the inflection = most of the move ahead; near ~80% = mostly gone. The asset-pricing evidence backs the direction: adoption lags convert "growth options" into "assets in place," so the risk premium and expected return are structurally higher earlier on the curve.
2. Velocity (steepness). How steep is the curve (k)? Steepness is set by feedback — learning rate, scale, network effects, lock-in (see curve-steepness-and-adoption-velocity) — and modern curves are getting steeper (time-to-50% compressing). Steeper ⇒ nearer horizon + larger, more violent re-rate; shallow ⇒ you are early and bleeding time-decay.
3. Cost tipping point (catalyst). Is there a datable Wright's-Law cost/performance crossing that triggers the knee (see wrights-law)? A parity date is a forcing function, not a vibe — it belongs in the chain as a catalyst.

The non-negotiable caveat

Cost curves are forecastable; adoption timing and the ceiling are not (see forecastability-of-technological-progress). So:

• Weight cost-curve evidence heavily; treat the adoption date as a range with explicit falsifiers, never as confirmed.
• Read the regime per-segment, never per-theme — in 2026, solar/storage are beating forecasts while EV battery demand and robotaxi adoption are undershooting.
• Consensus is structurally biased against steep cost curves over the long run (IEA's repeated solar underestimation) while near-term timing is routinely over-hyped (Amara's Law). The edge is buying structural underestimation; the trap is buying near a hype peak (see adoption-underestimated-or-overhyped).

How to apply it to a mechanism

When scoring a technology-driven chain in DAILY.md step 4c, add three reads alongside chain-strength:

• Position — penetration % and a ceiling range; is the beneficiary pre-knee, at the knee, or post-knee?
• Velocity — qualitative steepness (steep / moderate / shallow) and what feedback drives it.
• Cost trigger — the next datable cost-parity milestone, if any, as a catalyst.

These do not change whether the chain is true; they qualify upside magnitude, horizon, and sizing. Encoding is shipped (2026-06/07): optional mechanism adoption: frontmatter + ## Adoption read, Signal contract v3 adoption block (brain + trader mirrors), DAILY 4c/7 + signal-emit mapping. Design question s-curve-position-in-stock-evaluation is resolved (2026-07-09). First operational backfill covers GLP-1, HBM/CoWoS, agentic seat SaaS, nuclear-for-AI, 800VDC, CUDA-erosion, and wafer-scale inference.

Evidence

• From 2026-06-16-distill-technology-adoption-s-curves: "the S-curve adds an orthogonal evaluation layer the current conviction model omits: how much of the move is left (curve position), how fast it arrives (steepness), and what dates the knee (the cost/performance tipping point)."
• From 2026-06-16-distill-technology-adoption-s-curves: "weight the cost curve heavily (it's the forecastable part), but never treat an adoption date as confirmed"; apply per-segment.
• Schema + contract: docs/s-curve-evaluation-proposal.md; RESEARCH.md Adoption read; brain PR #76 + trader PR #31 (merged 2026-07-09).

Design implications

• This lens is a filter on already-true chains, not a chain-generation engine — it changes sizing/horizon/upside, not whether to file the thesis.
• Maps to Signal v3: adoption.* (primary) plus informed siblings classification.horizon, valuation.base_case_upside_pct, catalysts[]. Never moves conviction.score.
• Prefer unknown / null over fabricated penetration_pct or hard parity_dates (see first backfill — only GLP-1 carries a citable penetration %).

Contradictions / tensions

• The lens is only as good as the inflection read, which is the least forecastable part (see detecting-s-curve-inflection-in-real-time). Over-trusting a "we're at the knee" call is the main failure mode.

Open questions

• detecting-s-curve-inflection-in-real-time — still open (how to know the knee in real time).
• s-curve-position-in-stock-evaluation — resolved 2026-07-09 (encoding + trader mirror + first backfill).

Related

• technology-adoption-s-curve
• wrights-law
• curve-steepness-and-adoption-velocity
• forecastability-of-technological-progress
• cost-curve-tipping-point-to-s-curve-adoption
• 2026-06-16-distill-technology-adoption-s-curves