From c2424f10ef2028f862b7a721b633097670c8cf90 Mon Sep 17 00:00:00 2001 From: Elmehdi Aitbrahim Date: Sat, 15 Aug 2026 19:00:21 -0400 Subject: [PATCH 1/3] docs: move the status review to docs/presentations/, named title-date Establishes `docs/presentations/` with a `-<date>.html` convention, at the operator's request. The review moves there from `docs/reports/`, which had held it only because `docs/superpowers/reports/` set the precedent for a rendered HTML report in-tree. Recorded as a `git mv` rather than a copy: two copies of a deck drift, and the one in the wrong place is the one someone eventually presents from. Verified no file in the repo referenced the old path. The date in the filename is the date it was saved (2026-08-15). The masthead inside carries 16 August 2026, the date it is presented. That is deliberate and not a discrepancy to "fix" -- a deck is written the day before the room. Content is unchanged: same 29,781 bytes, still parses, and the withheld account figures are still withheld (re-grepped; zero hits). Only the path changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --- .../keel-status-review-2026-08-15.html} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/{reports/2026-08-16-status-review.html => presentations/keel-status-review-2026-08-15.html} (100%) diff --git a/docs/reports/2026-08-16-status-review.html b/docs/presentations/keel-status-review-2026-08-15.html similarity index 100% rename from docs/reports/2026-08-16-status-review.html rename to docs/presentations/keel-status-review-2026-08-15.html From 5129b52398e3960176557bf6eeaac38c847a4b8c Mon Sep 17 00:00:00 2001 From: Elmehdi Aitbrahim <eaitbrahim@gmail.com> Date: Sat, 15 Aug 2026 19:04:27 -0400 Subject: [PATCH 2/3] docs: give the paper deployment and the promotion gate their own section The review mentioned paper in one clause -- "a wider universe, exists to accumulate evidence" -- which undersold both what it is and why it matters. It now has a section, because the paper-to-live path is the mechanism that decides whether a rule may ever touch real money, and its current state is a finding rather than a footnote. WHAT PAPER ACTUALLY IS: separate database, separate config, synthetic cash ($500 start, $550 high-water mark), 19 allowlisted assets against live's six, 20 attested. 22 rules on the books but only 19 load -- status is not a label, it decides whether the agent reads the rule at all, so the one `candidate` turtle and the two `disabled` DCA rules are inert. Zero signals, zero orders, zero positions, zero outcomes to date. WHAT IT IS FOR: `candidate` -> `paper` -> `live`, with a deterministic gate between the last two rungs. Promotion needs n>=100 trades, positive expectancy, RR >= 1.5, a win rate over the class floor, and a PBO result. The floors were deliberately not relaxed together: when the win-rate axis was loosened to 0.30 for trend-following, min_trades was held at 100 on the grounds that the axes are independent and only one had a justification. WHY IT CANNOT WORK, and this is the point of the section: min_trades is checked per rule and per product, and it does not pool. Measured daily turtle rates are 1.19 to 3.20 trades per year, which puts n=100 between 31 and 84 years away. Adding assets does not help -- a new asset is a new rule with its own ~14 trades, not a pooled 114. Waiting for the gate is not a slower path to the same place; it is no path. WHAT FOLLOWS, said plainly rather than left for a reader to discover: five of the seven live rules carry promoted_at = NULL. They were seeded straight to `live` and left there, deliberately and on the record. Only the BTC dca rule and the DOGE turtle went through the normal path. So what bounds the risk is not the promotion gate, which never ran -- it is the caps, the nineteen rails and the allowlist, which are separate mechanisms that did. The bypass is of the evidence gate, not the safety rails, and the section says so in those words. Stacked on the move commit rather than branched from main, because main still carries the file at its old path and editing it there would guarantee a conflict with that rename. Account figures remain withheld; re-verified. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --- .../keel-status-review-2026-08-15.html | 56 ++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/docs/presentations/keel-status-review-2026-08-15.html b/docs/presentations/keel-status-review-2026-08-15.html index 490095b6..5024ff20 100644 --- a/docs/presentations/keel-status-review-2026-08-15.html +++ b/docs/presentations/keel-status-review-2026-08-15.html @@ -236,7 +236,61 @@ <h2>Deployed, autonomous, and deliberately tiny</h2> </table> </div> - <p>A parallel paper deployment carries a wider universe — <span class="num">19</span> allowlisted assets, <span class="num">20</span> attested, <span class="num">22</span> rules — and exists purely to accumulate evidence without risking funds.</p> + <p>Alongside it runs a <strong>paper deployment</strong> — separate database, separate config, synthetic cash. It is not a toy: it is the evidence pipeline that is supposed to feed live. The next section is about why it currently does not.</p> +</section> + +<section> + <p class="eyebrow">Paper → live</p> + <h2>The promotion path exists, is enforced, and is unreachable</h2> + <p class="lead">A rule is not supposed to touch real money until it has earned it. keel encodes that as a status ladder with a deterministic gate between the last two rungs — and the gate is doing its job, which is how we know the strategy cannot clear it.</p> + + <div class="scroll"> + <table> + <caption>Paper deployment · synthetic cash, wider universe</caption> + <thead><tr><th>Item</th><th>Detail</th><th class="n">Figure</th></tr></thead> + <tbody> + <tr><td>Mode</td><td>Paper — synthetic equity, no venue orders</td><td class="n">$500 → $550</td></tr> + <tr><td>Allowlist</td><td>The live six plus SOL, LTC, LINK, ZEC, NEAR, AVAX, UNI, FET, ICP, DOT, CRV, ALGO, BCH</td><td class="n">19</td></tr> + <tr><td>Attested assets</td><td>Human-classified, each with a source</td><td class="n">20</td></tr> + <tr><td>Rules on the books</td><td>19 × <code>turtle_breakout</code> at <code>paper</code>, 1 at <code>candidate</code>, 2 × <code>dca</code> <code>disabled</code></td><td class="n">22</td></tr> + <tr><td>Rules that actually load</td><td class="dim">Only <code>status=paper</code> loads in paper mode — the other three are inert</td><td class="n">19</td></tr> + <tr><td>Signals produced</td><td class="dim">To date</td><td class="n bad">0</td></tr> + <tr><td>Orders, positions, outcomes</td><td class="dim">To date</td><td class="n bad">0</td></tr> + </tbody> + </table> + </div> + + <h3>The ladder, and the gate between paper and live</h3> + <p>A rule moves <code>candidate</code> → <code>paper</code> → <code>live</code>. Status is not a label: it decides whether the agent loads the rule at all. Promotion to live requires clearing every floor below, and the floors were deliberately <em>not</em> relaxed together — when the win-rate axis was loosened for trend-following, <code>min_trades</code> was held at its canonical value on the grounds that the two axes are independent and only one had a justification.</p> + + <div class="scroll"> + <table> + <caption>Promotion floors · <code>strategy/promotion.py</code></caption> + <thead><tr><th>Floor</th><th class="n">Required</th><th>Status against measurement</th></tr></thead> + <tbody> + <tr><td><code>min_trades</code></td><td class="n">100</td><td class="bad">Unreachable — see below</td></tr> + <tr><td><code>min_expectancy</code></td><td class="n">> 0</td><td class="dim">Untested at scale</td></tr> + <tr><td><code>min_rr</code></td><td class="n">1.5</td><td class="dim">Untested at scale</td></tr> + <tr><td><code>min_win_rate</code> (trend class)</td><td class="n">0.30</td><td class="dim">Relaxed from 0.55, deliberately and alone</td></tr> + <tr><td>PBO / overfitting gate</td><td class="n">required</td><td class="bad">Blocks while unset</td></tr> + </tbody> + </table> + </div> + + <div class="finding"> + <h3>The floor and the timeframe are arithmetically incompatible</h3> + <p><code>min_trades = 100</code> is checked <strong>per rule, per product</strong> — it does not pool across assets. Measured trade rates for the daily turtle:</p> + <ul> + <li>BTC <span class="num">2.59</span>/yr · ETH <span class="num">2.59</span>/yr · PAXG <span class="num">3.20</span>/yr · XLM <span class="num">1.59</span>/yr · ADA <span class="num">1.19</span>/yr</li> + <li>Years to reach <span class="num">n=100</span> from scratch: <strong>31 to 84</strong>.</li> + </ul> + <p><strong>Waiting for the gate is not a slower path to the same place; it is no path.</strong> And adding assets does not help — the floor is per rule, so a new asset yields a new rule with its own ~14 trades, not a pooled 114.</p> + </div> + + <h3>What follows, stated plainly</h3> + <p><strong>Five of the seven live rules carry <code>promoted_at = NULL</code>.</strong> They were seeded straight to <code>live</code> and have been left there. That is a recorded decision, not an oversight — the reasoning sits in the live config, reviewed and dated. Only the BTC <code>dca</code> rule and the DOGE turtle were promoted through the normal path.</p> + <p>What bounds the risk is therefore <em>not</em> the promotion gate, which never ran. It is the position caps, the nineteen rails, and the allowlist — and those are separate mechanisms that all did run. The bypass is of the <strong>evidence</strong> gate, not the <strong>safety</strong> rails.</p> + <p>This is also why paper matters more than its zero signals suggest. It is the only apparatus that could ever produce the evidence the gate demands, and the honest reading of <span class="num">0</span> signals is not that paper is broken — it is that a rule firing twice a year cannot generate a hundred trades inside a human attention span.</p> </section> <section> From 6b9d7ba3431793ad73c2b79aeb18c35a03f0ea14 Mon Sep 17 00:00:00 2001 From: Elmehdi Aitbrahim <eaitbrahim@gmail.com> Date: Sat, 15 Aug 2026 19:10:29 -0400 Subject: [PATCH 3/3] docs: list the Shariah rules and their sources, and add Robinhood to venues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two gaps a reader would have hit. THE SHARIAH BASIS WAS UNCITED. The deck described the rails but never said what the compliance criteria rest on, so the screen read as a curated list of approved coins rather than a set of named juristic tests. It now carries both tables: each criterion mapped to what it tests and its reference, and the sources themselves. attestation / haram_sector / riba_yield §28.4 backing 'ayn vs dayn §65.5, §67.2 gold & silver -> stricter bay' al-sarf §65.5 (this is PAXG) instrument_wrapper, naming the CONTRACT §71.4a qabd / withdrawal capability, rail 17 §65.4 settlement, USD spot only rails 18/19 Sources: Jobst (IMF WP 07/117, 2007) as the original foundation; Ayub, *Understanding Islamic Finance* (Wiley, 2007) which displaced it and derives the prohibitions from primary texts while citing OIC Fiqh Academy and AAOIFI; four trading-specific papers on bay' al-sarf and qabd including Najeeb (INCEIF); Al-Jarhi/Abuzaid/Oweida's *Handbook of Islamic Finance* (2022) for 'ayn/dayn; IIFA Resolution 237 with the SRB and IIUM material; and four academic papers on the māl/thaman question. The section also states the gap rather than smoothing it, because it is the most important thing on the page: IIFA Resolution 237 carries a heading reading "Second: Shariah Ruling" with NO RULING UNDER IT. The Academy has ruled on electronic possession -- which is exactly why the qabd test behind rail 17 is well-grounded -- and has expressly declined to rule on whether crypto is Shariah-recognised property. An earlier note in the record puts it plainly: not one compliance source addressed crypto directly, and silence is not permission. So keel does not claim the question is settled; it enforces what is settled and records the operator's attribution for what is not. Worth noting only ONE criterion in the screen is waivable, and it is `history` -- the one that is not a religious question. The code never consults the waiver map for the others and the CLI will not accept them. ROBINHOOD WAS MISSING FROM VENUES. Four venues have been assessed, not three, and Robinhood's status is unlike any of the others: not refused on the instrument (cTrader, Trade Nation), not waiting on data (equities), but BUILT AND DELIBERATELY UNWIRED. `keel-broker-robinhood` ships translate, transport and adapter layers behind the port with its own tests, and is unreachable from live by design. The blocker is a venue capability, not our code: Robinhood's market orders accept only `asset_quantity`, with no quote-amount variant, and keel opens every position with MarketIOCByQuote. Under the current entry model Robinhood cannot open a position at all, and the adapter declares the capability unsupported and raises rather than approximating it. Account figures remain withheld; re-verified. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --- .../keel-status-review-2026-08-15.html | 58 ++++++++++++++++++- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/docs/presentations/keel-status-review-2026-08-15.html b/docs/presentations/keel-status-review-2026-08-15.html index 5024ff20..8cbb4ea2 100644 --- a/docs/presentations/keel-status-review-2026-08-15.html +++ b/docs/presentations/keel-status-review-2026-08-15.html @@ -395,6 +395,55 @@ <h3>The governing asymmetry</h3> </div> </section> +<section> + <p class="eyebrow">Shariah basis</p> + <h2>Which rulings are encoded, and what they rest on</h2> + <p class="lead">The compliance screen is not a curated list of "approved coins". It is a set of named juristic tests, each traceable to a source, each enforced in code that fails closed.</p> + + <div class="scroll"> + <table> + <caption>The encoded rules · <code>compliance/screen.py</code> and <code>execution/guards.py</code></caption> + <thead><tr><th>Criterion</th><th>What it tests</th><th>Source</th><th>Waivable?</th></tr></thead> + <tbody> + <tr><td><code>attestation</code></td><td>Sector, backing and yield are human-attested with a source. Nothing is derived from price data, so an unclassified asset is <em>unknown</em> — and unknown is a rejection</td><td class="num">§28.4</td><td class="bad">Never</td></tr> + <tr><td><code>haram_sector</code></td><td>The token's core business line is not an excluded one</td><td class="num">§28.4</td><td class="bad">Never</td></tr> + <tr><td><code>riba_yield</code></td><td>Holding it carries no guaranteed or expected return — that is riba-like, and not a bare spot position</td><td class="num">§28.4</td><td class="bad">Never</td></tr> + <tr><td><code>backing</code></td><td><em>'ayn</em> (a tangible, owned thing) versus <em>dayn</em> (a debt claim on an issuer). A pure claim is refused</td><td class="num">§65.5 · §67.2</td><td class="bad">Never</td></tr> + <tr><td class="dim">└ gold & silver</td><td class="dim">If the backing is gold or silver, the stricter <em>bay' al-sarf</em> treatment applies — relevant to PAXG</td><td class="num">§65.5</td><td class="bad">Never</td></tr> + <tr><td><code>instrument_wrapper</code></td><td>Admission must name the <strong>contract</strong>, not just the asset: the allowlist is not juristically homogeneous, and a CFD can spell itself exactly like spot</td><td class="num">§71.4a</td><td class="bad">Never</td></tr> + <tr><td><code>withdrawal_capability</code></td><td><em>Qabd</em> — possession holds only while nothing prevents withdrawal on demand. Rail 17 halts new entries when it cannot be shown</td><td class="num">§65.4</td><td class="bad">Never</td></tr> + <tr><td><code>settlement</code></td><td>USD-settled spot only; every other contract class is refused mechanically</td><td class="num">rails 18/19</td><td class="bad">Never</td></tr> + <tr><td><code>history</code></td><td>Four years of daily bars before a rule can be validated</td><td class="dim">evidence, not fiqh</td><td class="good">Yes, documented</td></tr> + </tbody> + </table> + </div> + + <p><strong>Only one criterion in the whole screen can be waived, and it is the one that is not a religious question.</strong> The code does not consult the waiver map for any of the others, and the CLI will not accept them — expanding that set is a deliberate decision, not something a passing test can quietly do.</p> + + <h3>The sources</h3> + <div class="scroll"> + <table> + <caption>Compliance references, in the order they entered the record</caption> + <thead><tr><th>Ref</th><th>Source</th><th>Role</th></tr></thead> + <tbody> + <tr><td class="num">§28</td><td>Andreas Jobst, <em>The Economics of Islamic Finance and Securitization</em> — IMF Working Paper 07/117 (2007)</td><td>The original compliance foundation; its §II definition grounded the first screen</td></tr> + <tr><td class="num">§65</td><td>Muhammad Ayub, <em>Understanding Islamic Finance</em> — Wiley Finance (2007, 544pp)</td><td><strong>The foundation source</strong>, displacing §28. Derives the prohibitions from primary texts, names the juristic tests, and cites OIC Fiqh Academy and AAOIFI resolutions</td></tr> + <tr><td class="num">§66</td><td>Four trading-specific papers on <em>bay' al-sarf</em>, <em>qabd</em> and forex fiqh — including Syed Faiq Najeeb (INCEIF)</td><td>Exchange-specific rather than banking-specific; the sharpest-focused material in the base</td></tr> + <tr><td class="num">§67</td><td>Al-Jarhi, Abuzaid & Oweida, <em>Handbook of Islamic Finance</em> — Ankara Social Sciences University (2022, 322pp)</td><td>The <em>'ayn</em>/<em>dayn</em> distinction the backing axis rests on</td></tr> + <tr><td class="num">§71</td><td>IIFA Resolution 237, the SRB material, and the IIUM literature review</td><td>Sought specifically to close the crypto gap below</td></tr> + <tr><td class="num">§72</td><td>Four academic papers on cryptocurrency and Shariah — the <em>māl</em>/<em>thaman</em> question</td><td>The first direct engagement with whether crypto is Shariah-recognised property</td></tr> + </tbody> + </table> + </div> + + <div class="finding"> + <h3>⚠️ The honest gap, and why it is stated rather than papered over</h3> + <p><strong>The field's highest authority has expressly declined to rule on the central question.</strong> IIFA Resolution 237 carries a heading reading <em>"Second: Shariah Ruling"</em> — and there is no ruling under it. The Academy identified the foundational questions as unresolved. It <em>has</em> ruled on electronic possession, which is precisely why the <em>qabd</em> test behind rail 17 is well-grounded; it has not ruled on whether crypto is Shariah-recognised property. The IIUM piece is a literature review and issues no ruling of its own.</p> + <p>An earlier note in the record puts it more bluntly: at the time, <strong>not one compliance source addressed crypto directly — and silence is not permission.</strong> §71 and §72 were sought specifically to close that, and they narrowed it rather than closing it.</p> + <p><strong>So keel does not claim the question is settled.</strong> It enforces what <em>is</em> settled — possession, riba, sector, backing, contract class — and records the operator's own attestation, attributed and sourced, for what is not. That is the whole design: keel is an enforcement engine for a ruling you supply, not a source of rulings.</p> + </div> +</section> + <section> <p class="eyebrow">Asset sweep</p> <h2>The scout found more bugs in itself than assets to trade</h2> @@ -418,7 +467,7 @@ <h2>The scout found more bugs in itself than assets to trade</h2> <section> <p class="eyebrow">Venues</p> <h2>Coinbase spot only — and the refusals are structural</h2> - <p>Three venue expansions were studied and three answered no. Two are permanent; one is "not yet".</p> + <p>Four venues have been assessed beyond Coinbase spot. None is live, and the reasons are not interchangeable — two are permanent refusals on the instrument, one waits on data, and one is <em>built and deliberately unwired</em>.</p> <div class="scroll"> <table> @@ -429,11 +478,16 @@ <h2>Coinbase spot only — and the refusals are structural</h2> <tr><td>Trade Nation</td><td><span class="chip chip-ref">Refused</span></td><td>Nothing in the product range is spot ownership — CFDs and spread bets throughout.</td></tr> <tr><td>US equities</td><td><span class="chip chip-open">Not yet</span></td><td>Coinbase <em>does</em> have an equities order path — the brief was wrong. But market data is absent: <span class="num">n=0</span> candles across 21 trading days, preview refused 403, three conflicts with our execution model.</td></tr> <tr><td>Coinbase futures / perps</td><td><span class="chip chip-ref">Refused</span></td><td>Rails 18/19 reject any non-USD-settled-spot contract mechanically, regardless of narrative.</td></tr> + <tr><td><strong>Robinhood</strong></td><td><span class="chip chip-open">Built, unwired</span></td><td>The <em>only</em> venue with a working adapter — <code>keel-broker-robinhood</code> ships translate, transport and adapter layers behind the broker port, with its own test suite. It is deliberately unreachable from live: the executor still calls Coinbase's signature directly, <code>_common.py</code> constructs a <code>CoinbaseClient</code>, and nothing calls <code>load_broker()</code>.</td></tr> </tbody> </table> </div> - <p>The distinction matters for planning: a CFD venue is <strong>never</strong>, because the instrument conflicts with the charter. Equities are <strong>not yet</strong>, because the blocker is data and execution capability, both of which can change.</p> + <h3>Robinhood is blocked by the venue, not by us</h3> + <p>The gap is a property of the venue rather than a bug to fix: <strong>Robinhood's market orders accept only <code>asset_quantity</code> — there is no quote-amount market order.</strong> keel opens every position with <code>MarketIOCByQuote</code>, sizing in dollars rather than coins, so under the current entry model <strong>Robinhood cannot open a position at all</strong>. The adapter is honest about it: it declares <code>market_ioc_quote</code> unsupported and raises rather than approximating.</p> + <p>That is why the port work is finished and the wiring is not. Issue <span class="num">#198</span> exists so the migration trips over this deliberately, on the bench, rather than discovering it with real money.</p> + + <p>The distinction matters for planning. A CFD venue is <strong>never</strong> — the instrument conflicts with the charter. Equities are <strong>not yet</strong> — the blocker is data and execution capability, both of which can change. Robinhood is <strong>not like this</strong> — it needs either a different entry model or a venue-side capability that does not exist today.</p> </section> <section>