> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shumi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Decision record: pre-registration

> The rules the public decision record runs on, fixed on 2026-10-14 before the first entry: how the coin is picked, what Shumi is asked, how each plan is scored, and the bar it has to clear.

These rules were registered on 2026-10-14, before day one of [the decision record](/evidence/decision-record.md) (2026-10-16). This page is frozen. A change is a new version with its own page and date, and entries already published keep being scored under the version they were published under. Nothing on this page may change after the first outcome has been looked at. The pass mark (section 10) is a first version: it is re-set from live data through exactly that process.

**About this copy.** The founders wrote and registered these rules in an internal repository. This page publishes them with these edits only: names of people, internal repositories, internal links, code and database identifiers, data vendors and internal study codes are replaced by plain descriptions; the selection query is described instead of printed; the drafting status notes are replaced by this introduction; the draft's "proposed" markers are dropped; and points the registered text left for a founder to confirm are marked "(open at registration)". A few sentences that only explained a reference or an internal system are reworded. The prompt template Shumi is sent is printed verbatim. No rule, threshold or schedule differs from the registered text.

The founders agreed on 2026-10-09, on one condition: the take states, in plain words, the exit rule it is scored on. That line is in the template (section 2). A take is scored as the trade plan Shumi publishes, exits follow the rules of CR v2.2, CoinRotator's trend-following strategy, and nothing runs on a fixed clock. Facts cited below come from the production code as of 2026-10-09, from the CR v2.2 baseline study and from internal studies, each given with its date. Every study figure is a dated reading of the market it was measured in, not a permanent property.

**Research behind the scoring, in short.** These are readings, each dated:

* Exits do most of the work. On every tradable Binance pair 2021-01 to 2026-08, CR v2.2's exits earned +1.49 % a trade net of fees, against −0.37 % for the older take-profit exit on the same entries (the CR v2.2 baseline study).
* A fixed take-profit or a price-level target cut off the large winners that pay for a trend book (internal study, 2026-10-06).
* Stops trigger on a daily close, with no maximum distance (internal studies, 2026-10-07; the founders' rule).
* Sizing by risk is where the stop rule earns its keep (internal study, 2026-10-06).
* Which build of the CR trend is used matters less than the exits. Under CR v2.2's rules every trend build tested made money before and after July 2024 (internal study, 2026-10-09).
* Fast invalidations earn the most per trade at a lower hit rate. Users prefer to stay with a trade longer. The scored plan is the steady version, and the faster versions run beside it as shadow lines, so live data shows the trade-off (section 7).

## 1. Selection rule

The day's coin is picked by a query, not by a person:

1. At the **selection time** (section 3), build the eligible set from the universe rules in section 4.

2. For each eligible coin, count Shumi's hourly sentiment summaries for it (matched by the coin's upper-case symbol) in the 24 hours ending at the selection time. These are the same summaries the production "hottest coins" list reads. An hourly summary is written only for coins mentioned in Shumi's curated sentiment feed (about 56 coins a day), so the count measures how much the curated feed is talking about a coin. Only the hourly summaries count: daily, weekly and monthly roll-ups are also stored, written whenever anyone asks Shumi about a coin, and counting those would let usage steer the pick (on test data for 2026-10-12, ZEC's 3 hourly summaries became 5, level with SOL).

3. Remove any coin selected on one of the previous 7 scheduled days.

4. Select the coin with the highest count. Ties, including a day on which every eligible count is zero, go to the better (lower) market-cap rank.

5. If two eligible coins share a symbol, the count belongs to the one with the better market-cap rank; the other gets zero.

6. If the eligible set is empty, the day publishes a `no eligible coin` entry. It is a published attempt with no take.

7. **One open plan per coin.** A coin whose earlier plan in this record is still open (section 7) is skipped, and the next coin by count is selected. The earlier plan stays scored on its own.

No study has measured the following days of the most-talked-about coin. The record is the first reading of its own selection rule, and the always-long plan on the same coin (section 8) keeps the pick itself from being scored as Shumi's choice.

Each entry publishes the five highest counts next to the chosen coin, so anyone with access to the data can re-run the count and anyone else can see the ranking it produced.

Why this shape: it picks the coin people are talking about, which is the one most worth distributing into its community. The baseline in section 8 is built on the same coin, so the pick itself is never scored as Shumi's choice.

The count reads one day of hourly summaries and keeps the 50 highest. Matching them to the eligible set and steps 3 to 5 happen in the selection script.

## 2. Prompt, surface and model

**Surface:** the Shumi web chat engine, driven by a **scheduled job** instead of a person. At the prompt time (section 3) the job sends the template with only `{NAME}` and `{SYMBOL}` filled in, as one dedicated house account, in a **new chat** with no earlier messages, general mode, no lens: the same request a person typing on shumi.ai would make. It sends once, sends no follow-up and does not regenerate. The chat is stored under the house account like any web chat, and the job makes the public share link from that chat (`shumi.ai/s/<id>`). The job records "asked at", the final model and provider, and the prompt versions from the turn itself. No person picks, edits or re-sends anything. A scheduled job removes the most likely way to break the 14-day run (nobody at a keyboard at 13:15) and is what lets the founders stop touching the record once it passes. A founder changed this from a human operator on 2026-10-13, before registration.

**Why the question asks for a reading, not a call.** Shumi's production system prompt (live 2026-10-08) never answers "should I buy or sell", and a founders' rule of 2026-10-09 keeps it that way: a reading that shows its inputs and their age is allowed; an order to trade is not. So the record asks which plan the data favours. It never asks what to buy.

**Prompt template (verbatim, one message):**

```text theme={"dark"}
{NAME} ({SYMBOL}): which plan does the data favour today: long, short or neither?
Start your answer with one line in exactly this form: "Data favours: LONG", "Data favours: SHORT" or "Data favours: NEITHER".
Then give the trade plan for BOTH sides, each as ONE line in exactly this format, copied from this turn's plan_long and plan_short: "${SYMBOL} | long | entryLow-entryHigh | stop | target | X/10" and "${SYMBOL} | short | entryLow-entryHigh | stop | target | X/10". Write n/a in a slot the plan does not have.
Then add this line exactly as written: "Exit: the plan ends on a daily close beyond its stop, when the trend turns against it, or on a reversal signal once it is 3% in profit. The target is not an exit."
Then give: the single biggest risk, and the venue you would act on it at.
For every input you used, show its source time in plain words, with no tool or field names. Write a time as its full date and UTC time, for example "price 2026-10-13 12:06 UTC"; write an input dated by day only as its date, for example "trend as of 2026-10-13". Do not mention inputs you did not use. If an input is older than its limit, say it is stale and do not base the reading on it.
```

**Dry run before day one, required.** The exact template is sent once by the scheduled job, through its own path (house account, new chat, share link), before day one; that run is not part of the record. A founder's dry runs of 2026-10-13 used the same engine through `shumi ask` and settled the template's format; this run tests the surface the record publishes from. It passes only if the first line, both plan lines and the `Exit:` line come back in the exact format. If the first line is refused or reworded, the template is changed and the dry run repeated; the frozen template is the one that passed.

**Exit line:** the founders' condition of 2026-10-09: the published take states the exit rule it is scored on, in plain words, so a reader can follow the same trade from the take alone. The `Exit:` line is the section 7 rule, fixed in the template so it cannot drift from what is scored: the stop is a daily close beyond it, the trend change is the site's trend turning to the opposite side, and the reversal exit applies only at 3 % profit or more. A take whose `Exit:` line is missing or reworded is published with the label `exit line missing` and still scored; the record's entry prints the rule either way.

**Stance parsing:** the stance is the token on the first line that matches `^Data favours: (LONG|SHORT|NEITHER)$`. Anything else is `unparsed`. Nobody reads a stance out of prose. NEITHER is a full answer, scored as staying out (section 10).

**Plan parsing:** each plan line is parsed with
`^\$(\S+) \| (long|short) \| ([0-9.]+)-([0-9.]+) \| ([0-9.]+|n/a) \| ([0-9.]+|n/a) \| (\d+|n/a)/10$`
into entry low, entry high, stop, target and **data score**. The **scored plan** is the line whose side matches the stance. The record scores the numbers as Shumi published them, so anyone can check a score from the entry and public prices. Shumi copies them from its price-levels data. When the stance is LONG or SHORT and its line is missing, does not parse, or lacks entry or stop, the entry is labelled `no plan` and is not scored. The X/10 figure is called the **data score** everywhere in the record, never "conviction".

**Model:** no model is pinned. The final model and provider come from the configuration layer at runtime. The record tests Shumi as shipped, so model and prompt changes during the record are allowed, but every entry records the final-model id, provider and the versions of the system prompt, classification prompt and tool definitions that served it.

**Retries:** if the request fails with no answer, the job retries once after 10 minutes. Both attempts are published; the retry's answer is the take of record.

## 3. Cadence

Every day, including weekends, all times UTC.

| Step | Time (UTC) |
| - | - |
| Selection query runs | 12:15 |
| Daily coin is registered for the on-chain data pre-fetch | by 12:20 |
| Prompt is sent by the scheduled job | 13:15 |
| Entry is published on the canonical record, X and Telegram | by 19:15 |
| Posted into the coin's community | same UTC day |

Why these times: they stay clear of the database's busy windows for scheduled data jobs, of the 00:00–03:00 window in which coin lookups still serve yesterday's trend, and of the hourly futures-data update at :00. The pre-fetch runs every 30 minutes and refreshes anything older than 30 minutes, so the hour between registration and prompt guarantees at least one pass.

The 12:15 selection job registers the day's coin for the pre-fetch.

**Founders read before publication (first days), changed 2026-10-14 before day one.** The day's entries are opened as a pull request on the record page around 13:40 and go live when a founder lands it, by 19:15. This is a reading step only: nothing in a take is edited, re-asked or withheld, and a take that looks wrong is published as it came back. While this step is on, an entry's time row says "Prepared at"; its publication time `T` is the time of the merge commit that landed the day's record PR on the canonical record (not the entry commit's own \~13:40 time), and scoring (section 7) counts from that `T`. Because `T` is not known when the entry is written, it is stated in the first line appended to the entry, its first daily line or its outcome (section 11), so the score can still be rebuilt from the record alone. A record PR landed after 19:15 is published late with its real `T`; one not landed by 00:00 UTC is a day with no published entry (section 12). When the founders stop reading first, entries publish at about 13:40 with the time row "Published at".

A day counts as scheduled whether or not anyone is at a keyboard. A missed prompt is still a day with no published entry and resets the 14-day count (section 11).

## 4. Universe

A coin is eligible at selection time when all of these hold:

1. Market-cap rank between 1 and 500. This is the live sentiment read's coverage: a live read of X runs only for the top 500 by market cap.
2. A crypto asset, not a real-world-asset row (stocks, commodities). Those rows have no market-cap rank, so rule 1 already excludes them; this rule makes it explicit.
3. Not a stablecoin, using the category rule already in production: a category ending in "stablecoin", excluding "Stablecoin Issuer".
4. Not a wrapped, bridged or liquid-staking derivative of another asset: no CoinGecko category matching `wrapped`, `bridged` or `liquid staking` (case-insensitive) among the coin's CoinGecko categories.
5. A current trend exists: the site shows a trend for the coin, computed from complete data.

A stored sentiment summary no older than 5 hours is not required. Since 2026-10-06, a missing or stale stored read triggers a live read of the last 6 hours of X posts for any top-500 coin, so a stored summary is no longer a coverage condition.

## 5. Maximum age per input

Each input carries its own source time. "Asked at" (the moment the prompt was sent) is shown separately and never stands in for an input's age.

| Input | Source time | Maximum age at "asked at" | Source of the limit |
| - | - | - | - |
| Trend | the trend's as-of date | the as-of date is the selection day, and the trend is computed from complete data. The trend is dated by the 00:00 UTC close it was computed from, so at 13:15 UTC on Oct 13 a current trend reads "as of 2026-10-13"; the price levels read 2026-10-12 for the same close, because they date a daily bar by its open. | the site's trend; dry run 2026-10-13 |
| Social sentiment | stored read: the hour it summarises; live read: the newest X post used | 6 hours | production: a stored hourly read, or a live read of the last 6h of X when the stored one is missing or older than 6h |
| On-chain: KOL traders | upstream fetch time | 60 minutes, because the selected coin is the registered daily coin (otherwise 10 minutes) | production on-chain data settings |
| On-chain: holders, wallet tags, largest-pool liquidity | upstream fetch time | 60 minutes, because the selected coin is the registered daily coin (otherwise 6 hours) | same |
| Price levels (swings, averages, ATR, stop) | the levels' as-of date (open of the newest daily bar; daily close = 00:00 UTC) | the previous UTC day's 00:00 close. The levels turn unavailable past 30h. | Shumi's price levels; spot-dependent fields are computed per request from the live price |

**On-chain coverage:** the on-chain data covers `eth`, `bsc`, `base`, `robinhood` and `sol` (Solana added 2026-10-06; its inclusion in coverage was open at registration). For a coin with no contract on one of these chains (BTC, for one), the take lists the inputs it used and says nothing about on-chain; the entry shows no on-chain field. That is not staleness and does not affect a clean day. On-chain data is never called sentiment or depth near spot.

**Sentiment freshness, what is and is not built:** the live rule is age only (6h). The fuller rule that was proposed, which would also invalidate a reading after an abnormal price move or new coin news since it was taken, is **not built**; the production code has a hook for it and nothing more. This page freezes the 6h age limit only. If the invalidation rule ships during the record, it is a Shumi change, logged per entry like a prompt change, and the limit here stays 6h.

**Live-read limits that can produce a stale input:** live reads are capped at 300 a day across all coins, regenerated at most once per 3h per coin, and skipped when the cache is down. In each case the stale stored row is served with its true age, or no read. The record publishes that as `stale input` or `no current sentiment read`, never hides it.

**`stale input` rule:** if any input Shumi used is past its limit, the entry is published with the label `stale input` and the input's actual age. The day is clean only when Shumi's own output already disclosed that input as stale (and so did not base the stance on it). An input shown with no source time at all makes the day not clean. A `stale input` entry with a LONG or SHORT stance is still scored in section 6, and is also reported as its own subgroup.

## 6. Venue

From the founders' product bar: every entry names the venue Shumi said it would act on. Pool TVL, including the on-chain largest-pool liquidity, is never presented as executable depth near spot; that is checked when the entry is reviewed, not printed in the take. The venue is published verbatim and does not change the score.

## 7. Outcome: scoring a plan

A take is scored as the plan it states, not as a trade opened at publication. Markets keep no fixed timetable, so neither does the record: a plan fills when price reaches its zone, and ends when the market invalidates it or a reversal signal takes profit. NEITHER is a full answer.

### Price data

Daily bars in USD for the coin's CoinGecko id, built from CoinGecko's 4h OHLC (`/coins/{id}/ohlc`), one bar per UTC day (open = first 4h open, high = max, low = min, close = the 4h bar closing at 00:00 UTC). This is how CoinRotator builds the daily bars the levels come from.

1. The close of UTC day D is used only from 00:00 UTC on D+1. No fill, stop or exit inside day D reads it. A same-day close once reversed an internal study's result.
2. On the publication day, only 4h bars opening at or after `T` count.
3. Every CoinGecko response is archived raw with its request range, and the bar width it returned is recorded. A response whose bars are not 4h wide is rejected and requested again, never mixed in.
4. While a plan is open, the record appends each day's bar and each day's trend state to the entry, so the score can be rebuilt from the record alone.
5. If no price exists for a day a plan needs, the outcome is `incomplete`. It is published, not scored, and never dropped.

### Trend state

The record reads the **CoinRotator trend the site shows** (the production state: SuperTrend 5 × 1.5 on the coin in USD, BTC and ETH; UP when all three are up, DOWN when all three are down, HODL otherwise), for the previous completed UTC day. The record never shows a trend the site contradicts.

Two other trend builds are published next to every entry as shadow lines and never scored:

* CR v2.2's own legs (slower; agrees with the site on about 65 % of days).
* The site's state with a 20/50 EMA tie-breaker on days the two builds disagree.

*Research:* under CR v2.2's rules on every tradable Binance pair 2021-01 to 2026-08, the site's state made +0.15 % / +1.26 % a trade before / after July 2024, the EMA tie-breaker +1.29 % / +1.34 %, and CR v2.2's legs +1.36 % / +1.67 % (internal study, 2026-10-09). Live data decides between them in a later version.

### Entry

Bars after `T` are checked in order:

1. A LONG fills on a bar whose low is at or below the entry high, at the entry high or at the open if the bar opens below it. A SHORT fills on a bar whose high is at or above the entry low, at the entry low or at the open if it opens above it.
2. Before a fill, the plan **lapses** on the first of these events, and is published with that reason:
   * `invalidated before entry`: a daily close beyond the stop;
   * `ran without entry`: price reaches the target;
   * `trend turned`: the site's trend turns against the side (DOWN for a LONG, UP for a SHORT).
3. A plan with no fill and no lapse after 30 daily closes is published as `not triggered`. This backstop only lets the record close the line.

For every plan that does not fill, the record publishes the coin's move from `T` to the lapse, and how close price came to the entry zone in ATR. Neither is scored. A pullback entry tends to miss the strongest moves (an internal study: on breakouts, the 14 % that never pulled back were the big moves), so the record shows them.

### Exit: CR v2.2's rules, with the founders' stop

After the fill, the scored plan ends at the first of:

1. **Stop:** a daily close (00:00 UTC) beyond the stop published at `T`, exiting at that close. The stop is volatility-based: the founders' rule (the nearest swing\_5 below price for a LONG, above for a SHORT, ∓ 0.5 ATR, at least 1.5 ATR from the entry midpoint, no maximum distance; "unbroken" was dropped from the wording on 2026-10-09), as Shumi's price levels print it. It is never moved, widened or trailed. A gap through the stop can cost more than 1R.
2. **Reversal signal, trend change:** the site's trend turns to the opposite side (DOWN for a LONG, UP for a SHORT), exiting at that day's close, at any profit or loss. HODL does not end the plan.
3. **Reversal signal, take profit:** an opposite mean reversion point (as defined in the CR v2.2 baseline study, including its "last 14 band re-entries" behaviour) while the plan is at least 3 % in profit at that close, exiting at that close.

There is **no time limit** on a filled plan. Plans still open at a checkpoint are marked at that day's close and labelled `open` (section 10).

The plan's printed target is not an exit. When price reaches it, the record publishes `reached target` with the date, and the plan stays open. CR v2.2 continuation re-entries are not scored. After a plan closes, the coin can be selected again (section 1).

Published labels name the exit kind, never the indicator: `exit (stop)`, `exit (trend change)`, `exit (reversal signal)`.

*Research:* CR v2.2's exits are the founders' current rule, and a founder is trading them live (2026-10-09). On every tradable Binance pair 2021-01 to 2026-08 they earned +1.49 % a trade net of a 0.2 % fee, +1.36 % before July 2024 and +1.67 % after (the CR v2.2 baseline study). A close-triggered stop beat the same stop triggered on a wick, on longs and shorts, and no stop cap beat the uncapped stop (internal studies, 2026-10-07).

### Shadow exits, published, not scored

Each one runs on the same fill as the scored plan, so live data shows which works best. A later version can promote one.

| Shadow line | Rule |
| - | - |
| Reversal signal invalidates | an opposite mean reversion point ends the plan at any profit or loss |
| Stop beyond the reversal bar | the stop sits beyond the bar of the latest reversal signal on the plan's side, not the volatility stop |
| 2-bar reversal | after the plan is 3 % in profit, the second consecutive daily close against it ends the plan (CR v2.2 "second consecutive" mode) |
| Faster average on a mature trend | once the site's trend on the plan's side is at least 14 days old, a daily close beyond the 20-day EMA ends the plan (open at registration: the 14 days and the 20-day EMA) |
| Target as printed | exit when price reaches the plan's target |

*Research:* faster invalidations earn more per trade at a lower hit rate, while users prefer staying with a trade through deep pullbacks (a founder, 2026-10-09). The scored plan is the steady version. The shadows record the faster ones on the same trades.

### Size and result per plan

* **Size:** Shumi's price levels' size under the founders' rule: 1 % of the account ÷ stop distance, for longs and shorts alike. Longs are not halved when BTC is below its 200-day: on 2026-10-14 the founders replaced the halving with full size plus one line of history in the answer (an internal study found halving a preference, not an edge). The 200-day split is still published (section 10). The founders' other 2026-10-09 answers on the stop stand: the 1.5 ATR minimum is measured from the entry midpoint; 120 days means 120 daily candles. The plan is scored on a fill in its zone, so it uses the plan's size, not the stop-only size quoted for buying at market. A size above 100 % of the account carries `needs_leverage`.
* `risk = |entry − stop| / entry`; gross move `g = (exit − entry) / entry` for a LONG, `(entry − exit) / entry` for a SHORT.
* **Net R** `= (g − c) / risk`, with `c` from section 9. One R is the loss the plan stated up front.
* **Account result** `= net R × risk %`, where risk % is 1. The bar (section 10) uses the account result.
* Also published per plan: net % move, exit kind, days held, the best and worst close while open and the highest high and lowest low (in R and %), whether `reached target` happened, and the result of every shadow line.

**Not scored but counted as attempts:** NEITHER, `unparsed`, `no plan`, every lapse reason, `not triggered`, `incomplete`, `no short venue` (section 9), errors and `no eligible coin`.

**Resolution:** a plan resolves at its exit. The outcome is a **new line** appended to the record that references the entry id; the entry itself is never edited.

**The stop rule as written by the founders** (2026-10-07):

> **The rule, for every trade:**
>
> 1. **Where:** the nearest unbroken swing\_5 low within 120 days, minus 0.5 ATR. If that is closer than 1.5 ATR to entry, use 1.5 ATR. Shorts: the swing high, mirrored. (Unchanged from the spec.)
> 2. **Trigger:** a daily close beyond the level (00:00 UTC). An intraday wick does not trigger it.
> 3. **Size:** position = 1% of account ÷ stop distance (a 25% stop means a 4% position). Halve it when BTC is below its 200-day. *(Superseded 2026-10-14, before day one: no halving; see Size above.)*
> 4. **No maximum distance.** When the stop is far, show the smaller position. Do not drop or grey out the setup.

Production has carried this rule since 2026-10-08 00:15 UTC (the interim 3 ATR cap is gone). On 2026-10-09 the founders kept the built swing (a swing closed through and reclaimed still counts) and replaced "unbroken swing low" with "nearest swing low below price"; the quote above keeps the original words. Blind marking round 2 (2026-10-10, 60 entries) found Shumi's price levels' stop where a founder draws it (median 2.33 ATR against 2.45).

Before day one, confirm the deployed production build carries the rule and the founders' 2026-10-09 changes: no halving (deployed, longs at 1 % risk in every BTC regime), and the answer quoting the size that matches the entry.

## 8. Baseline

(Open at registration.) Both baselines use the **same coin over the same dates**, the same section 7 rules, the same costs and the same sizing.

1. **Always-long plan (the bar's baseline):** on every published day, whatever the stance, the LONG plan line Shumi published is scored under section 7. This is what taking the long plan every day earns without Shumi's reading. Shumi's contribution is its choice of side and of when to stay out.
2. **Hold from publication (context):** buy at the first price after `T`, sell when the scored plan exits (or at its lapse). Reported next to every plan.

BTC over the same window is reported as market context.

*Research:* the house yardstick is always the same coin on the same dates. Holding over the plan's own window is nearly the same trade as the plan, so it serves as context only.

## 9. Costs and funding

**Round-trip cost `c` (open at registration):** 40 bps for coins ranked 1–100 at selection time, 100 bps for ranks 101–500, for fees on both legs plus slippage. The same `c` applies to the baselines. *Research:* the 2026 stop and exit studies used 0.4 % round trip; the 100 bps tier is a convention.

**Funding is shown, never assumed zero.** For every filled plan on a coin with a perp at the named venue (or, failing that, at Hyperliquid), the record publishes realised funding over the hold, signed (paid or received), and the account result including it. Where no funding data exists, the field reads `funding: not available`, never 0. SHORT plans are reported with and without funding. *Research:* funding moved shorts taken after crash days from +3.10 % to −2.40 % a trade in 2025–26 (internal study), and an internal short strategy's long-held shorts received +2.52 % a trade in 2023–25.

**Stop slippage, reported:** the mean result if every stop exit had filled 100 bps worse.

**Shorts that cannot be held:** a SHORT whose named venue lists no perp or borrow for the coin at `T` is published as `no short venue` and not scored.

## 10. The bar

A first version. The founders, 2026-10-09: the pass mark is work in progress, re-set from consolidated live data through a new version of this page. It is never adjusted against outcomes already seen.

**First reading:** checked once, on the first day on which **30 scored plans** (LONG or SHORT, filled, exited) have resolved **and** those plans were entered in at least **8 different UTC weeks**. If either is short, the check moves forward a week at a time.

**Confirmed reading:** checked once at **60 scored plans entered in at least 12 different weeks**, the same template as an earlier internal forward test.

At each reading the record passes only if all of these hold, net of costs, in account result (section 7):

1. The mean account result of the scored plans is above 0, and the mean of weekly means (each entry week counted once) is above 0.
2. **Ahead of the always-long plan, day by day.** Across every published day in the period, Shumi's total account result is above the always-long plan's total. On each day Shumi's result is its scored plan's, or 0 for NEITHER, `unparsed`, `no plan` and plans that did not fill. The always-long result is the published LONG line's, or 0 if it did not fill or is missing. Open plans on either side are marked at that day's close.
3. At least 40 % of the scored plans end with net R above 0. *Research:* trend exits in our studies keep their winners long, and their hit rates ran 31–44 % (internal studies, 2026-10). A plan with a 1.5R target breaks even near 40 % before costs.
4. No scheduled attempt in the period is missing from the record.

Condition 2 scores staying out directly: a NEITHER on a day the long plan lost counts for Shumi, and one on a day it won counts against. No separate cap on abstentions is needed.

Each reading is published as **"passed"**, **"not passed"**, or **"more plans needed"**. The last is used when the mean is closer to 0 than the smallest gap 30 plans can show, which the optional past-data check below states. Without that check, a reading is only "passed" or "not passed". Either way the result is published as a new dated decision. Until the first reading the record is "registered, unresolved".

**Reported alongside, never part of the bar:**

* median net R, and the mean without the single best plan;
* the busiest entry week's share of the total, and the most-repeated coin's share;
* splits by LONG / SHORT × BTC above / below its 200-day, by calendar month, by rank 1–100 / 101–500, and by data score (0–4, 5–7, 8–10, and the 8/10-and-above subset paying customers act on);
* the label `one-sided` if more than 85 % of scored plans are on one side;
* fill rate, lapse reasons, NEITHER share;
* every shadow exit and shadow trend line, scored the same way;
* the hold-from-publication baseline and BTC.

These are published as dated regime readings. No expected hit rate per regime is published.

**Optional before day one (open at registration):** run the full plan (zone entry, this stop, these exits, the site's trend) once on past data with the existing harness, to state the smallest gap 30 and 60 plans can show. No study has yet scored the plan as one rule.

## 11. Publication format

Each entry carries this field list. The record's own words are "take", "reading", "plan", "result". It never says "accurate", "win rate", "proven" or "profitable"; counts are published as counts with their sample size.

| Field | Content |
| - | - |
| Entry id | `R-YYYY-MM-DD` (retry: `R-YYYY-MM-DD-b`) |
| Asked at | UTC timestamp the prompt was sent |
| Published at (`T`) | UTC timestamp of publication, and the delay from "asked at". While founders read each day first (section 3), the entry carries "Prepared at" instead, and `T` (the landing merge commit's time) and the delay are stated in the first line appended to the entry |
| Coin | name, symbol, CoinGecko id, market-cap rank at selection |
| Selection | the five highest counts from section 1, and whether a tie-break or an open-plan skip decided it |
| Input ages | trend as-of; sentiment time, stored or live; on-chain fetch time per input, when the coin has on-chain data; price-levels as-of; each with its age at "asked at" |
| Context at `T` | site trend, its age and days since its last flip; CR v2.2 trend; EMA tie-break trend; whether the stance is with or against the coin's trend; BTC's trend, BTC vs its 200-day and vs its prior cycle high; funding rate |
| Labels | `stale input`, `exit line missing`, `no plan`, `no short venue`, `needs_leverage`, `incomplete`, `error`, `no eligible coin`, as applicable |
| Stance | LONG, SHORT, NEITHER or `unparsed` |
| Plans | both plan lines verbatim, parsed (entry zone, stop, target, data score), and the scored side |
| Size | the size as printed, and the account risk % |
| Exit rule | Shumi's `Exit:` line verbatim, and the section 7 rule in the same words |
| One risk | verbatim from Shumi |
| Venue | verbatim |
| Full take | Shumi's verbatim answer |
| Live Shumi link | the Send a Shumi share URL (`https://shumi.ai/s/<id>`) |
| Served by | final-model id, provider, prompt versions |
| Daily lines while open | that day's bar, site trend, and whether `reached target` occurred |
| Outcome (appended at exit or lapse) | fill price and date or lapse reason; exit kind, price and date; gross move, net R, account result, with and without funding; best and worst point; every shadow line's result; the always-long plan's result; hold-from-publication and BTC over the same window; pullback depth at fill in ATR |

Shumi's cycle-high price bet and its 25 / 50 / 75 % alert ladder are published verbatim if they appear, and never scored.

**Canonical record:** an append-only page on the public docs site (served at docs.shumi.ai), one git commit per entry and per outcome, so "never edited or removed" is checkable from git history. Distribution, from the product bar: Shumi's own X and Telegram, plus the coin's community, each post linking the entry and the live Shumi link.

## 12. The 14-day run and the clean day

The founders' success criterion for the record, quoted unchanged:

> the daily record described under *Product bar* is published on each of 14 consecutive scheduled days and distributed from Shumi's own X and Telegram plus the coin's community. A day with no published entry resets the 14-day count (an entry that says `error` or `stale input` is published, and does not reset it). A published day is *clean* when its data age is correct, its links work, and it was distributed the same day; the run passes when ≥ 90 % of the 14 days are clean. The founders run it until it passes, then QA owns the cadence and the founders stop touching it

The 14-day run measures whether the record is produced and distributed reliably. The bar in section 10 measures whether the takes are good enough to trade on. They are judged separately.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.