@@ -35,8 +35,9 @@ caps:
   # than the exposure/concentration caps below. Left at their non-binding default here so
   # risk-sized rule orders ($400-24k typical) aren't silently rejected.
   # max_exposure_usd caps total open notional for RULE-trading buys only; DCA buys are exempt
-  # (#841) and bounded by rail 14's attested monthly buy cap instead. max_per_asset_pct (a
-  # fraction of max_exposure_usd) binds both.
+  # (#841) and bounded by rail 14's attested monthly buy cap and available cash instead.
+  # max_per_asset_pct (a fraction of max_exposure_usd) is likewise RULE-trading only -- DCA is
+  # exempt from it too (#853), for the same reason.
   max_exposure_usd: 5000
   max_per_asset_pct: 0.50
 
 
@@ -992,10 +992,12 @@ fourth does not, which is most of why they drift apart.
   monthly, and every position size below grows with it.
 - **`caps.max_exposure_usd`** — has **two jobs at once**. It caps rule-trading entries' total
   notional held at any one moment (rail 4; rail 6's concentration cap is a percentage of it).
-  DCA buys are exempt from rail 4 (#841), bounded instead by rail 14's monthly buy cap and by
-  rail 6's per-asset cap — but DCA holdings still count toward the total, so a growing DCA sleeve
-  can consume the room rule-trading entries have left under it (`docs/rails/rail-4-total-exposure.md`).
-  *And* it is the **equity proxy that sizes orders** on the live path
+  DCA buys are exempt from both rail 4 and rail 6 (#841/#853), bounded instead by rail 14's
+  monthly buy cap and available cash (rail 13) — but DCA holdings still count toward the total
+  and the per-asset figure, so a growing DCA sleeve can consume the room rule-trading entries
+  have left under it (`docs/rails/rail-4-total-exposure.md`,
+  `docs/rails/rail-6-per-asset-concentration.md`). *And* it is the **equity proxy that sizes
+  orders** on the live path
   (`keel/execution/executor.py::_build_intent`). So live `risk_pct` is a fraction of THIS number,
   not of real account equity — raising the cap raises the real dollars risked per trade. Set above
   actual equity it stops binding before available cash does, and the refusal comes later and less
 
@@ -11,10 +11,12 @@ month, from the orders audit log, plus the order being placed — at the venue's
 The cap is a limit keel puts on its **own** buying. It is not a fee waiver, and nothing inside
 it is free: keel places its orders through **Coinbase Advanced Trade**, which charges its
 maker/taker schedule on every order whatever the cap says (#836). DCA is **not** exempt —
-recurring buys are exactly the spend this rail exists to cap. Since #841 this is the rail that
-**bounds DCA**: DCA BUYs are exempt from the total-exposure cap (rail 4,
-[rail-4-total-exposure.md](rail-4-total-exposure.md)), so the monthly buy cap here, together
-with per-asset concentration (rail 6), is what limits accumulation.
+recurring buys are exactly the spend this rail exists to cap. Since #841/#853 this is the rail
+that **bounds DCA's aggregate spend**: DCA BUYs are exempt from both the total-exposure cap
+(rail 4, [rail-4-total-exposure.md](rail-4-total-exposure.md)) and the per-asset concentration
+cap (rail 6, [rail-6-per-asset-concentration.md](rail-6-per-asset-concentration.md)), so the
+monthly buy cap here — together with available cash (rail 13's USDC-funding floor) — is what
+limits accumulation.
 
 > **Correction (2026-09-27, #836).** This page used to describe the cap as volume the venue
 > waives the taker fee on, and as *"the profitability boundary"*. That was wrong for keel's
 
@@ -23,7 +23,7 @@ What the exemption does and does not change:
 | Rail | Rule-trading BUY | DCA BUY |
 |---|---|---|
 | 4 — total open exposure (`total_exposure_cap`) | binds | **exempt** (#841) |
-| 6 — per-asset concentration (`per_asset_concentration_cap`) | binds | binds |
+| 6 — per-asset concentration (`per_asset_concentration_cap`) | binds | **exempt** (#853, [rail-6-per-asset-concentration.md](rail-6-per-asset-concentration.md)) |
 | 14 — monthly buy cap (`monthly_subscription_allowance`) | binds | binds — the limit that bounds DCA |
 | 8 — no averaging into losers | binds | exempt (§8/§12.1) |
 | 11 — account-drawdown breaker | binds | exempt (§12.6) |
@@ -35,9 +35,11 @@ Two consequences worth knowing:
 - **DCA holdings still count toward the total.** A rule-trading entry sees the whole book,
   DCA lots included, so a growing DCA sleeve shrinks the room rule trades have under
   `max_exposure_usd`.
-- **Rail 6 still uses `max_exposure_usd`.** The per-asset limit is
-  `max_per_asset_pct × max_exposure_usd`, so `max_exposure_usd` still bounds DCA per asset,
-  just not in total.
+- **Rail 6 is exempt too, since #853.** A fixed per-asset ceiling would halt a single-asset
+  accumulation sleeve the same way a fixed total ceiling would (#841's reasoning, applied to the
+  per-asset case) — see [rail-6-per-asset-concentration.md](rail-6-per-asset-concentration.md).
+  Rail 14 (the venue plan's attested monthly buy cap) and available cash (rail 13) are DCA's
+  aggregate bounds now.
 
 `keel simulate` applies the same exemption (`SimAccount.can_open`), so a backtest models what
 live does.
 
@@ -0,0 +1,58 @@
+# Rail 6 — the per-asset concentration cap
+
+Rail 6 is one of keel's hard rails: checks in `keel/execution/guards.py` that run before every
+order, in every mode, and cannot be switched off or widened from outside that module. This one
+caps the **summed open notional in one asset** — everything bought and not yet sold, from the
+orders audit log — plus the order being placed, at `max_per_asset_pct × caps.max_exposure_usd`
+in config.yaml. keel has no equity oracle, so the configured total-exposure ceiling stands in for
+funded trading capital, and `max_per_asset_pct` is a fraction of it (§10.3).
+
+Like rail 4, it is a **notional** cap, not an at-risk cap.
+
+## Who it binds: rule-trading BUYs, not DCA
+
+Since #853 (the operator's decision, 2026-09-28), **DCA BUYs are exempt from this rail too**,
+mirroring rail 4's #841 exemption:
+
+> DCA is bounded by the venue plan's cap (rail 14, the attested monthly buy cap) and available
+> cash, not by `max_per_asset_pct` (a fraction of `max_exposure_usd`).
+
+A fixed per-asset ceiling stops a single-asset accumulation sleeve within weeks whatever the plan
+is, for the same reason a fixed total-holdings ceiling does (#841): live BTC DCA was on track to
+be refused by this rail from around end October 2026.
+
+What the exemption does and does not change:
+
+| Rail | Rule-trading BUY | DCA BUY |
+|---|---|---|
+| 4 — total open exposure (`total_exposure_cap`) | binds | **exempt** (#841, [rail-4-total-exposure.md](rail-4-total-exposure.md)) |
+| 6 — per-asset concentration (`per_asset_concentration_cap`) | binds | **exempt** (#853) |
+| 14 — monthly buy cap (`monthly_subscription_allowance`) | binds | binds — the limit that bounds DCA |
+| 13 — USDC-funding (cash floor) | binds | binds |
+| 2/3 — per-order / per-day caps | binds | binds |
+| 5 — correlation-adjusted sizing | binds | binds |
+| 8 — no averaging into losers | binds | exempt (§8/§12.1) |
+| 11 — account-drawdown breaker | binds | exempt (§12.6) |
+| 16 — consecutive-loss breaker | binds | exempt (§12.6) |
+| every other rail | binds | binds |
+
+Two consequences worth knowing:
+
+- **DCA holdings still count toward the per-asset total.** A rule-trading entry in the same asset
+  sees the whole book, DCA lots included, so a growing DCA position in BTC shrinks the room a
+  rule-trading BTC entry has left under `max_per_asset_pct × max_exposure_usd`. The exemption is
+  from being *gated* by rail 6 as a DCA candidate, not a blind spot in what the rail measures.
+- **Rail 4 is exempt too, since #841.** DCA is bounded by rail 14 and available cash on both the
+  total and the per-asset axis now — see
+  [rail-4-total-exposure.md](rail-4-total-exposure.md).
+
+`keel simulate` applies the same exemption (`SimAccount.can_open`), so a backtest models what
+live does.
+
+## What happens when it is exceeded
+
+A rule-trading BUY is **vetoed** before it reaches the venue:
+
+- `per_asset_concentration_cap: <asset> exposure … exceeds … of max_exposure_usd (…)`
+
+SELLs are never checked by this rail — they reduce exposure.
@@ -66,6 +66,7 @@
   - Why: a warning that states something false about the money path is worse than none.
   - Cost if wrong: none.
 - Note (2026-09-28, after #842): rail 4 (`max_exposure_usd`) no longer vetoes DCA buys; rails 14 and 6 still bind them. The plan's output must not describe `max_exposure_usd` as a limit on DCA.
+  - **Amended 2026-09-28 (#853):** rail 6 (`per_asset_concentration_cap`, itself a fraction of `max_exposure_usd`) is now ALSO exempt from DCA, mirroring rail 4's #841 exemption -- the operator's decision was that a fixed per-asset ceiling would halt a single-asset accumulation sleeve the same way a fixed total ceiling would. Rail 14 (the venue plan's attested monthly buy cap) and available cash (rail 13) are DCA's aggregate bounds now; rails 2, 3, 5 and 13 still bind it. The plan's output must not describe `max_per_asset_pct`/`max_exposure_usd` as a limit on DCA either.
 - Ruling R10: `--buffer-pct` is **required**, not defaulted.
   - Why: the spec's signature names it. A silent default of 0 turns "budget" into "spend" without the operator saying so.
   - Cost if wrong: one extra flag to type.
@@ -97,6 +98,13 @@
   - Why: writing `candidate` rules is not a capability increase. `keel rules add` writes the same rows ungated and has no row there. A `candidate` rule cannot place an order until `rules promote` clears it.
   - Cost if wrong: `tests/test_capabilities.py` scans only `_require_interactive_confirmation` call sites, and this feature adds none, so no test would object. The only cost would be an inventory row the user wanted.
 
+- Ruling R21 (2026-09-28, #853): rail 3 (per-day cap) is a **blocker**. The plan computes the busiest single day as the sum of every planned per-buy plus every existing `live` DCA rule's own `budget_usd`. It compares that sum against `caps.max_per_day_usd`. `per_day_cap_text` builds the sentence, and both front-ends show it verbatim.
+  - Why: `Dca.detect` buys when `epoch_day % cadence_days == 0`, and no rule has a phase offset. So some day (a multiple of the lcm of every cadence) has every rule buying at once. If that total is over the cap, every such day would be vetoed partway through.
+  - Cost if wrong: if `Dca` ever gains a phase, the blocker overstates the risk. It would block conservatively, never let too much through.
+- Ruling R22 (2026-09-28, #853): rail 5 (correlated-size) is a **warning**. It fires when a planned per-buy for an asset outside `UNCORRELATED_ASSETS` exceeds `max_per_order_usd x CORRELATED_SIZE_SCALE`. Both constants are imported from `guards.py`. `correlated_size_text` builds the sentence.
+  - Why: the rail binds only while another correlated asset already has exposure open, and a plan cannot see that.
+  - Cost if wrong: buys vetoed that the plan approved. DCA never sells, so once another correlated asset is held (a live DCA rule, or a second planned correlated asset after its first cycle) rail 5 vetoes every buy above the cap. Whether that case should block instead of warn is held as an open question on #871.
+
 ## Review Focus
 
 1. **The per-buy amount rounds to $0.00** for a small budget or weight, for example `--budget 1` with a 1% weight. A person expects a named refusal ("BTC's per-buy rounds to $0.00"), not a traceback from `Dca.__init__` and not a silently dropped asset. Pinned in Task 3.
 
@@ -12,6 +12,14 @@
 exactly as `keel/execution/guards.py` rail 14 does; `tests/commands/test_dca_plan.py` drives
 `guards.check` itself to prove the two agree.
 
+**DCA's aggregate bounds are rail 14 and available cash, not `max_exposure_usd`/
+`max_per_asset_pct` (#841/#853).** Rails 2 (per order), 3 (per day), 5 (correlated) and 13 (cash)
+still bind a DCA buy, and this plan checks the two rails it CAN evaluate offline: rail 3 (a
+BLOCKER: the busiest day every rule's cadence can coincide on, since `Dca.detect`'s scheduling
+carries no per-rule phase) and rail 5 (a WARNING: a per-buy above the correlated-size cap, using
+`guards.py`'s own `CORRELATED_SIZE_SCALE`/`UNCORRELATED_ASSETS`). Neither text may describe
+`max_exposure_usd` or `max_per_asset_pct` as a limit on DCA.
+
 **What this module never does:** promote, touch a `paper`/`live` row, or modify any existing rule.
 It writes `candidate` rows through `keel.commands.rules.add_rule_row` and nothing else.
 """
@@ -37,7 +45,10 @@
 from keel.data.repository import Repository
 
 # Rail 1's own key function, as `keel/commands/rules.py` imports it: an existing rule's asset is
-# read the way the rails read it, so "already has a DCA rule" cannot disagree with them.
+# read the way the rails read it, so "already has a DCA rule" cannot disagree with them. Rail 5's
+# own constants (#853) so the correlated-size warning below computes the SAME cap the rail does,
+# never a re-typed copy that could drift from it.
+from keel.execution.guards import CORRELATED_SIZE_SCALE, UNCORRELATED_ASSETS
 from keel.execution.guards import _asset as _asset_of
 from keel.strategy.rules.dca import Dca
 
@@ -452,6 +463,22 @@ class DcaPlan:
     #: renderer reuses it verbatim rather than recomputing, so the display can never show a
     #: total larger than what was actually checked (R5's rule, extended to this figure by #847).
     worst_month_spend_usd: Decimal
+    #: R21 (#853): the busiest SINGLE DAY this plan's own buys can land on -- `Dca.detect`'s
+    #: scheduling rule (`epoch_day % cadence_days == 0`) has no per-rule phase/offset, so every
+    #: buy this plan schedules shares one cadence and therefore lands on the SAME days; the
+    #: worst single day for this plan alone is simply the sum of every planned `per_buy_usd`.
+    worst_day_cycle_usd: Decimal
+    #: R21: the total of every EXISTING `live` DCA rule's own per-buy amount (`budget_usd`, not
+    #: the average-month figure `existing_live_monthly_usd` shows). Because no rule's cadence
+    #: carries a phase either, a day exists where `epoch_day` is a multiple of every cadence
+    #: involved (e.g. their lcm) -- on it, this plan's rules AND every existing live rule buy at
+    #: once, whatever their individual cadences are.
+    existing_live_daily_usd: Decimal
+    #: `worst_day_cycle_usd + existing_live_daily_usd` -- the figure the rail 3 (per-day cap)
+    #: blocker (R21) compares against `caps.max_per_day_usd`. Rail 3 counts EVERY BUY placed
+    #: that day, not just DCA, but this plan only knows about DCA rules -- so this is a DCA-only
+    #: FLOOR on that day's total, and the blocker text says so rather than overclaiming.
+    worst_day_spend_usd: Decimal
     blockers: tuple[str, ...]
     warnings: tuple[str, ...]
 
@@ -486,6 +513,44 @@ def _worst_month_buy_days(cadence_days: int) -> int:
     return worst
 
 
+def per_day_cap_text(
+    *,
+    worst_day_spend_usd: Decimal,
+    worst_day_cycle_usd: Decimal,
+    existing_live_daily_usd: Decimal,
+    live_rule_count: int,
+    max_per_day_usd: Decimal,
+) -> str:
+    """Rail 3's blocker (R21, #853), as ONE sentence both front-ends show: the CLI prints
+    `plan.blockers` under "Cannot approve" and `/api/dca-plan` sends them as the card's
+    blockers, verbatim. Phrased as a DCA-only floor, because rail 3 counts every BUY placed that
+    day and the plan knows only DCA rules."""
+    return (
+        "the busiest day every rule's cadence can coincide on -- no cadence carries a "
+        "phase, so a day exists where every rule buys at once -- would spend "
+        f"{_usd(worst_day_spend_usd)} in DCA buys alone ({_usd(worst_day_cycle_usd)} from this "
+        f"plan's own buys plus {_usd(existing_live_daily_usd)} from {live_rule_count} existing "
+        f"live DCA rule(s)); that exceeds caps.max_per_day_usd "
+        f"{_usd(max_per_day_usd)} (rail 3), which counts every BUY placed that "
+        "day, not just DCA"
+    )
+
+
+def correlated_size_text(buy: PlannedBuy, correlated_cap: Decimal) -> str:
+    """Rail 5's warning (R22, #853) for one planned buy, as ONE sentence both front-ends show
+    (`plan.warnings`, verbatim). A warning, not a blocker: the rail binds only while another
+    correlated asset already has exposure open, which a plan cannot see. It must not say the
+    rail rarely binds: DCA never sells, so once any other correlated asset is held (a live DCA
+    rule's holding, or another planned buy after its first cycle) every buy this size is vetoed
+    (#871)."""
+    return (
+        f"{buy.asset}'s per-buy {_usd(buy.per_buy_usd)} exceeds the correlated-size cap "
+        f"{_usd(correlated_cap)} (rail 5: max_per_order_usd x {CORRELATED_SIZE_SCALE}) -- "
+        "rail 5 vetoes a buy this size whenever another correlated asset has exposure open, "
+        "and DCA never sells, so once another correlated asset is held every such buy is vetoed"
+    )
+
+
 def build_dca_plan(
     repo: Repository,
     config: Config,
@@ -582,6 +647,30 @@ def build_dca_plan(
             )
 
     live_rules = [rule for rule in universe.existing if rule.status == "live"]
+
+    # R21 (#853): rail 3 (`guards.py`'s per-day cap) counts EVERY BUY placed that day, and
+    # `Dca.detect`'s scheduling rule (`epoch_day % cadence_days == 0`) carries no per-rule phase
+    # or offset -- so a day exists where `epoch_day` is a multiple of every cadence involved (at
+    # worst, their lcm), and on it EVERY rule -- this plan's own buys and every existing LIVE DCA
+    # rule -- lands at once, regardless of how their individual cadences differ. The worst single
+    # day is therefore simply the sum of every planned per-buy plus every live rule's own per-buy
+    # (`budget_usd`, its per-hit amount -- not the average-month figure `live_monthly` computes
+    # below). This plan only knows about DCA rules, so the blocker is phrased as a DCA-only floor
+    # on that day's total, never a claim about the whole day's spend.
+    worst_day_cycle = sum((b.per_buy_usd for b in buys), Decimal("0"))
+    existing_live_daily = sum((rule.budget_usd for rule in live_rules), Decimal("0"))
+    worst_day_spend = worst_day_cycle + existing_live_daily
+    if worst_day_spend > config.caps.max_per_day_usd:
+        blockers.append(
+            per_day_cap_text(
+                worst_day_spend_usd=worst_day_spend,
+                worst_day_cycle_usd=worst_day_cycle,
+                existing_live_daily_usd=existing_live_daily,
+                live_rule_count=len(live_rules),
+                max_per_day_usd=config.caps.max_per_day_usd,
+            )
+        )
+
     live_monthly = sum(
         (_cents_down(rule.budget_usd * MONTH_DAYS / rule.cadence_days) for rule in live_rules),
         Decimal("0"),
@@ -626,6 +715,17 @@ def build_dca_plan(
             "month buy can be vetoed below the full-month figure shown"
         )
 
+    # R22 (#853): rail 5 (correlation-adjusted sizing) halves the per-order cap for a correlated
+    # asset WHILE another correlated asset already has exposure open (`guards.py`'s
+    # `CORRELATED_SIZE_SCALE`/`UNCORRELATED_ASSETS` -- imported, never re-typed, so this cannot
+    # drift from the rail). A plan has no live exposure to check, so a per-buy above that cap is
+    # a WARNING, not a blocker: it only ever binds conditionally, and names the asset(s) it would
+    # bind for.
+    correlated_cap = config.caps.max_per_order_usd * CORRELATED_SIZE_SCALE
+    for buy in buys:
+        if buy.asset not in UNCORRELATED_ASSETS and buy.per_buy_usd > correlated_cap:
+            warnings.append(correlated_size_text(buy, correlated_cap))
+
     return DcaPlan(
         inputs=inputs,
         spend_usd=spend,
@@ -644,6 +744,9 @@ def build_dca_plan(
         worst_month_buy_days=worst_days,
         worst_month_cycle_usd=worst_month_cycle,
         worst_month_spend_usd=worst_month_spend,
+        worst_day_cycle_usd=worst_day_cycle,
+        existing_live_daily_usd=existing_live_daily,
+        worst_day_spend_usd=worst_day_spend,
         blockers=tuple(blockers),
         warnings=tuple(warnings),
     )