⚠ 14 past-due next actions

nothing is blocked by these — but each one is a promise with a missed date. Do it, re-date it, or kill the card.

Jul 14SalesPut the 4 invisible invoiced accounts into the CRM — 2026-07-27 audit: dropped 'incl. DMJX $42K' from the title, the figure came from the seat x list method retracted 2026-07-19 (F022/F024) and was never invoice-verified; sales 2026-30 found DMJX has NO subscription row in the app DB at all (bills outside the app, or the line was never real). Still zero crm_customers rows for the four as of 2026-07-26. Past due since 2026-07-14, left overdue for visibility. — next: Create the CRM records, verifying each account against actual Visma invoices, not seat x list price (F022) (Jul 14)

Jul 15CEOPricing Phase 2: the usage-ladder one-page proposal — 2026-07-27 audit: status reset building to planned, no draft, branch, or PR anywhere and the W30 CEO read treats it as not started. Date left overdue on purpose: this card blocks the ladder chain (I012, I018) and rock 0. Past due since 2026-07-15. — next: One-page ladder proposal for Erik (Jul 15)

Jul 22EngPromo admin: pick a percentage and dates, run the summer sale — Time-boxed by summer. 2026-07-27 audit: 4 days past due with the build verifiably not started (no Promotion model on main, no PR), left overdue, every slipped week shrinks E005's summer window. Prompt's closing steps corrected (they instructed hand-editing superseded queue.md/todo.md, rule 13) and the stale queue-3/queue-item-1 numbering fixed, the card had been queue position 2 since I001 closed; moved to queue position 1 on 2026-08-08 when I002 was killed. — next: Build Phase 1 (queue-1 session); summer 50%-off-yearly test vs 13% BF benchmark (Jul 22)

Jul 24MarketingTurn shared dashboards into an acquisition surface — A shared dashboard produced one of W28's fastest payers. 2026-07-27 audit: the 2026-07-24 date was missed with no note; left overdue for visibility. — next: Size the channel from public-dashboard tags, then propose the play (Jul 24)

Jul 24SalesEnterprise outbound and renewal machine, the 32 churned logos plus lookalikes — Both strategy takes rank this first: the only proven engine at $1M density; target 6 new logos in 12 months. 2026-07-27 audit: the 2026-07-24 ratification date was missed with no note (left overdue, the decision is Erik's). Before ratifying, re-read section 5 against F022/F023/F024: parts of the enterprise numbers the strategy review leans on were retracted 2026-07-19, two days after it was written. — next: Erik ratifies (strategy review section 5); then agents draft ~10 notes/wk, Erik sends (~2h/wk), 3-tier price sheet (Erik, Jul 24)

Jul 29ProductDecide what lapsing to free should actually cost — 2026-07-27 audit: the 2026-07-21 date was missed with no note and the E003 readout never ran; the W30 CEO read set 2026-07-29, applied here (rule 2). — next: Verify enforcement actually started Jul 14 (E003's premise was never independently checked), then read the natural experiment and propose the entitlement diff (Jul 29)

Jul 31MarketingFeed your AI: make /mcp the hub, list in agent directories — 2026-07-27 audit: date set from the plan, P06 Phase A time-boxes directory listings + the /mcp hub to July (company/plans/ai-data-wedge.md, ratified top priority 2026-07-04); the card had sat undated while its own plan carried the deadline. 2026-08-08: Erik reprioritized this direction ('the mcp is enough. maybe if we make an official connector to claude and chatgpt') after killing I002. How-to research for the Claude and ChatGPT directory submissions is in company/reports/marketing/2026-08-08-official-connector-listings.md (PR #339): both portals' requirements, Feeder's gaps (tool annotations missing on all MCP tools; plan-gate upgrade message links to checkout, which OpenAI prohibits), and prerequisites (Claude Team/Enterprise org for the claude.ai submission portal; verified business identity on the OpenAI Platform). Eng prep is ~1-2 days before either submission. — next: Directory placements + hub page (Jul 31)

Aug 1FinanceModel the usage-ladder cohorts: uptake, cannibalization, retention guardrails — 2026-07-25 (Erik): regional/PPP pricing is NOT part of this card. It was briefly routed here earlier the same day; Erik reversed that, PPP becomes a separate project (issue 17) and the ladder goes first. Reasoning on the record: PPP cannot be measured at any time (India is 295 plan-viewers per 180 days, F035 arithmetic), so there is no PPP learning to protect by sequencing; what sequencing protects is focus on the ladder, which is the larger prize, is already overdue, and CAN be measured on US/EU volume. The L003 cost of a second pricing event (one more grandfathered cohort) is small here because the PPP countries produce very few payers (IN 18/yr, BR 13/yr, geo report 2026-07-05). Evidence that shaped the split: F037 (IN/BR is price resistance, JP/KR/TW is not). CORRECTION 2026-07-25: an earlier version of this note called Japan 'the largest non-US signup geo'. Wrong. Japan is 3rd among non-US by signups (IN 5,025, FR 4,660, JP 4,066, geo report 2026-07-05); what is true is that it is the largest non-US market whose weak conversion is NOT explained by purchasing power. F037's own notes field carries the same slip and should be corrected next time that record is touched. — next: Cohort model for the ladder decision: uptake, cannibalization, retention guardrails. Ladder only, no regional/PPP prices in scope (Erik 2026-07-25 split PPP into its own project, sequenced after the ladder ships). (Aug 1)

Aug 1SupportMonthly voice-of-customer digest — next: First digest (Aug 1)

Aug 1CEOAugust retro: judge July by new-payer production per cohort — next: Run the retro (Aug 1)

Aug 5MarketingRead win-back results, then decide the churned-payer backlog campaign — 2026-08-11 (COO Level 10, W33): this card's premise is answered and the answer is "there is nothing to attribute". I028 exists to attribute the July reactivation line that W30/W31/W32 flagged three weeks running as the largest unexplained positive in the P&L. F062 settled it with one extra ChartMogul call for 2024: reactivation is in a three-year decline ($513.90 -> $364.33 -> $296.29 Jan-Jul monthly average) and July 2026's $385.66 sits below July 2025 and well below July 2024. It looked strong only against 2026's own weak start. So the dormant-nudge rock (rock 3, done as built) has no measurable win behind it, and the 30-day readout this card is waiting on (due 2026-08-05, now 6 days overdue) can be scoped much tighter or the card closed. The CEO's W33 read proposes rescope-or-close; that decision is Erik's or a reviewed CEO session's, so no status was changed here. Recording it because leaving the card reading "attribute the reactivation line" is a wrong memory (rule 1). — next: 30-day readout + framing proposal for Erik (Aug 5)

Aug 7MarketingFirst batch of AI landing pages at best-converting cohorts — 2026-08-25 marketing-channel-read (W35): card is 18 days past its 2026-08-07 date and still planned. RETRACTION FROM LAST WEEK, stated plainly because it was a stated condition: last week's note said 'leave cybersecurity out until it produces one payer' and it has now produced one. User 1005609 (US) signed up 2026-08-19 14:44 and paid by Chargebee at 15:47, 63 minutes later, inside the reporting week. Deduplicated table (273 users touching exactly one page, 2026 to Aug 23, F059): cybersecurity-teams 108/1, software-engineers 39/0, financial-services 39/2, marketing-professionals 28/2, competitor-monitoring 18/2, 12 others 41/1. The two highest-volume pages are now 147 signups / 1 payer against ~4.4 expected at the discover path's 30-day rate (3.00%, F072), so p is ~0.066, up from 0.014 last week and 0.02 the week before. That is no longer significant at any conventional threshold and three weeks of a hardening zero has reversed. F122. The ranking advice is unchanged in DIRECTION and weaker in strength: the three converting pages are 6 payers on 85 signups (7.1%) against the top two at 0.68%, a 10x gap in rate but on volumes too small to be certain of. Rank the next batch against financial-services, marketing-professionals and competitor-monitoring, but no longer exclude cybersecurity-teams. Method caveat that killed the earlier ranking still binds: page-use-case-* tags are re-applied per visit, so the table must be deduplicated to users carrying exactly one page tag (two further cybersecurity payers exist but touched several pages and are correctly excluded). Evidence: company/reports/marketing/2026-W35.md. No date proposed here, that is Erik's call on an overdue card. — next: Ship the first batch, early August (Aug 7)

Aug 10DataPost-release check-ins on the extension upgrade experience — Week-4 product readout delivered 2026-08-03 (company/reports/data/2026-08-03-extension-upgrade-checkpoint-w4.md, F053). Directional answer to the week-4 question: the funnel leaks at the offer step, not at checkout, which converts 1 in 3 once opened. Trial emails run 59.4% open / 19.4% click and have converted 0 of 40 recipients, so this is a page-and-price problem rather than an interest problem; the experiment doc's own fallback (free first feed, paid from the second) is the obvious A/B and does not need to wait for week 8. Floor check is already off pace without needing a closed window: 1 payer in 29 days annualizes to ~13/yr against a ~60/yr bar. Two defects found this run: the day-20 metric recommendation overcounts, and the design guarantee that nobody receives both a trial email and the day-3 reminder is broken for 18 users (4 of them an outright suppression failure). — next: Hold the week-4 redesign call on the offer page, not checkout: 156 verified users reached the offer, 3 opened checkout, 1 paid (F053). Do NOT ship the day-20 updated_at metric fix as written, it overcounts (scored a payer who never entered the funnel); use the funnel-entry query in the week-4 report and update the experiment doc's queries section. Then the week-5 run reports the first closed 30-day cohort (W27 closes 2026-08-04). (Aug 10)

Aug 18ProductAI onboarding A/B, ship or kill call — next: Recommendation from the data seat is now on the record: return the default to the reader and keep the agent behind ?onboarding=1 and the sidebar. The last argument for keeping the screen was that some identifiable group might be well served by it and should be routed in rather than switched off. F078 tests that on everything observable before the screen renders and finds no such group: seven segment cuts, seven negative for the AI arm, five regions out of five (sign test p=0.031), and the segments that engage the agent most carry the larger deficits. With F064 (shallower readers at equal feed count) and F066 (a perfect fallback tops out at parity), all three lines of evidence point the same way. Score the one-tap example chips as polish, not as the activation lever that rescues the arm: the 14.56% typers-beat-control number behind it is selection, and the segment evidence runs the other way. Product's call, unchanged in ownership. (Aug 18)

Jul 21ProductMissed readout: Rules-gating natural experiment: do paused rules convert holders to paid (E003) — experiments

Are we making money yet?

net new MRR vs what the board's sized bets could add on top

+$4/mo

net new MRR, August MTD through Aug 25 · July closed −$75

No sized bets on the board.

MRR · 14 months

$28,105+$6 vs Jul 26

Jul 25 → Aug 26 (MTD) · ChartMogul, as of 2026-08-25

Each bar is that bet's share of the combined upside; "up to" uses the high estimate from the bet's own doc. A bet only appears here when a committed doc states its number. Click a row for the full card and its sources.

Do this next

the execution stack — grab the top, copy the prompt into a fresh Claude Code session; the session sets its record to done in state/initiatives.json

1

Promo admin: pick a percentage and dates, run the summer sale Engdo by Jul 22

Time-boxed by summer. 2026-07-27 audit: 4 days past due with the build verifiably not started (no Promotion model on main, no PR), left overdue, every slipped week shrinks E005's summer window. Prompt's closing steps corrected (they instructed hand-editing superseded queue.md/todo.md, rule 13) and the stale queue-3/queue-item-1 numbering fixed, the card had been queue position 2 since I001 closed; moved to queue position 1 on 2026-08-08 when I002 was killed.

promotion automation · promo decision

You are engineering for Feeder. Read company/plans/promotion-automation.md (all phases; build Phase 1 only), company/reports/ceo/2026-07-09-promo-decision.md, and company/personas/company-context.md. Goal: an admin can run a promotion by picking a percentage and dates — no code deploy — and the summer 2026 50%-off-yearly test can run and be measured. Study the current seams first: backend/app/controllers/application_controller.rb (current_global_deal_id ~L580, is_current_deal_time?, current_global_sales_bundle, eligible_for_current_global_deal?), backend/app/lib/black_friday.rb, backend/app/helpers/deal_helper.rb, backend/app/models/sales_bundle.rb (exclude_logic — keep the black_friday_offer new/upgrade-only rule as the default audience). Existing pieces to reuse, not reinvent: the discount engine (SalesBundle/ProductBundle/Discount/ChargebeeCoupon), the site banner (app/views/products/_deal_banner.html.erb), the extension deal flag (is_global_deal in readers_controller), and the admin orchestration precedent in backend/app/controllers/admin/price_adjustments_controller.rb#switch_to_new. Build: (1) a Promotion model — percent, start/end datetime, headline copy, plus boolean lever switches (site_banner, extension, in_app_notification, email_blast, cms_landing) defaulting per the plan; (2) super-simple admin under Admin:: to create/schedule/flip a promo with just percent + dates (levers are checkboxes, sane defaults); (3) auto-provision the discount from the percentage so admin never touches bundles; (4) current_global_deal_id and is_current_deal_time? read the active Promotion; site banner + extension flag driven by it; (5) per-promo conversion tagging (reuse the plan-page cliff-fix instrumentation from I001, closed 2026-07-25) so the summer run is analyzable. Seed the current Black Friday behavior as the first Promotion row so an empty table reproduces today exactly — BF regression tests must stay green (backend/test/models/black_friday_test.rb, sales_bundle_black_friday_test.rb). Phase 1 wires ONLY the site-banner + extension levers to actually fire; the in-app-message (web), reader/extension notice, email-blast, and CMS-landing switches are persisted but their fan-out/teardown is Phase 2 — leave a clear TODO. Note for Phase 2: the web in-app-message lever reuses the existing surface — the Ember app already renders currentUser.uncheckedUserMessages via UserMessageModal (frontend/app/user-root/template.hbs, user-message model); the work is backend generation of one promo UserMessage per eligible web user (title/body/CTA to discounted pricing, gated by the same exclude_logic), one per user, cleared on promo end — like Admin::PriceAdjustmentsController#switch_to_new but driven by the Promotion, not by hand. Do NOT build Phase 3 (A/B arms). Do NOT weaken existing-customer protection (L003). Follow CLAUDE.md exception rules; tests per repo convention. Verify against a running app before the PR. Branch claude/promotion-automation-phase1; push with `git push origin HEAD:refs/heads/claude/promotion-automation-phase1`. In the same PR: update the plan's phase checklist, close I003 in the company DB via the company MCP (status done with done.date + done.pr, clear queue, renumber the queue dense), refresh company/state/initiatives.json from the export, delete company/state/prompts/I003.md, and run node company/bin/check-state.mjs.

Waiting on Erik

7each one is blocking somebody's next step — dated ones first

overdue · Jul 24Erik ratifies (strategy review section 5); then agents draft ~10 notes/wk, Erik sends (~2h/wk), 3-tier price sheet Sales · Enterprise outbound and renewal machine, the 32 churned logo

Enterprise outbound and renewal machine, the 32 churned logos plus lookalikes — Both strategy takes rank this first: the only proven engine at $1M density; target 6 new logos in 12 months. 2026-07-27 audit: the 2026-07-24 ratification date was missed with no note (left overdue, the decision is Erik's). Before ratifying, re-read section 5 against F022/F023/F024: parts of the enterprise numbers the strategy review leans on were retracted 2026-07-19, two days after it was written. — next: Erik ratifies (strategy review section 5); then agents draft ~10 notes/wk, Erik sends (~2h/wk), 3-tier price sheet (Erik, Jul 24) — 1m arr strategy review, enterprise arr reconciliation

Aug 31Phase 4, one item retired and one sharpened by F125. (1) A preflight auth check that verifies the Claude OAuth session before the 04:00 chain and pages while it can still be refreshed, since retry-once cannot clear an expired session. (2) RETIRED, the notifier path already works: notifyRun() is awaited before the stop-on-fail exit and the heartbeat posted the 529 to #fleet-log on 2026-08-24. Replaced by escalation: post to the page tier when any job in a run-due chain exits non-zero, since the runner already knows and only tells the wrong channel. (3) The .claude/settings.json tool allowlist for unattended runs. Ship issue 50's two smaller changes first, continue-on-fail and moving the API-heaviest job out of order 1, because they are what actually cost the company the 2026-08-24 read. COO · Build a laptop CLI that runs the recurring agent jobs on the

Build a laptop CLI that runs the recurring agent jobs on the Claude subscription — 2026-07-27 audit correction: the record said 'not yet running: needs merge', but company/fleet/ is merged to main and 8 of 9 chain jobs ran manually Jul 22-25, producing the W30 report set (agents.json last_run + artifacts verified on disk). The CLI is proven end to end on the subscription; what remains is launchd wiring on Erik's machine and Phase 4. data-explorer was the one chain job skipped in the catch-up runs (issue 22). Decision 2026-07-21 (Erik): laptop CLI on the subscription, not cloud routines. Build: P17, company/plans/agent-fleet-runner.md. 2026-08-11 (COO Level 10, W33): the laptop half is DONE. launchd fires on schedule and the chain has produced a full seat report set twice (2026-08-03 on the Monday slot, 2026-08-11 a day late). What is not done is Phase 4, and it is now measured rather than theoretical. Three weeks, three failure modes, all needing a human to recover: 2026-07-27 data-explorer crashed and stop-on-fail dropped five seats (issue 22, F061); 2026-08-10 the fire and its retry both died on 'OAuth session expired and could not be refreshed' and a Tuesday 04:14 attempt died on laptop sleep. F061's retry-once fix fired correctly on 2026-08-10 and bought nothing, because expired auth is not transient. The notifier failed both weeks, so the dead-man's switch that makes silence mean 'broken' is itself broken. An unattended fleet would still be dark today. Dated to 2026-08-17 by this run: this is the COO seat's own card and it is the one thing on the board this seat can date without asking anyone. 2026-08-17 (COO Level 10, W34): the date was missed and the card is re-dated to 2026-08-24, which is the next chain. Recorded plainly because this is this seat's own card and it dated itself. What happened instead: all eight Monday jobs fired in their own slots on the first attempt, no retry, no OAuth wall, no sleep abort. fleet.mjs has not changed a byte since 2026-08-11 09:46, so none of the three pieces exists and nothing about today is repeatable. One further measurement worth keeping, because it is the half people will assume today settled: the notifier was NOT exercised. No seat wrote a signal file (all eight declined on the notify-policy bar), so the '[notify] post failed: fetch failed' path that broke on two consecutive Mondays was never called today. Today is evidence about the OAuth coin toss only, and it came up heads. It is evidence about the dead-man's switch of exactly zero. 2026-08-25 (COO Level 10, W35): re-dated to 2026-08-31 and Phase 4 corrected. The 2026-08-24 date passed and that is the day the chain parked: the revenue digest failed twice (529, then timeout) and stop-on-fail took all 8 downstream seats with it (F105, issue 50). Fourth of the last five Mondays needing a human to recover. CORRECTION to the 2026-08-11 block above, which two weekly reads inherited without re-testing. 'The notifier failed both weeks, so the dead-man's switch is itself broken. An unattended fleet would still be dark today' is WRONG (F125). runList() awaits notifyRun() before the stop-on-fail exit (fleet.mjs:389), notify.json carries a live bot token with heartbeat_channel #fleet-log, and every Slack failure path logs to stderr. The 2026-08-24 block of launchd.err.log (lines 37-40) has the two digest failures, the retry and the stop-on-fail, and NO [notify] line. So Slack received 'Fleet 2026-08-24: 0 ok, 1 failed - weekly-revenue-digest: API Error: 529 Overloaded'. The single '[notify] post failed: fetch failed' in that file sits in the older working-tree-dirty block. Method caveat: inferred from the absence of a logged failure on a path where every failure logs, not from reading Slack. Second correction, same class: stale signal files ARE cleared. runJob() unlinks signals/<id>.json before the job runs (fleet.mjs:338). A signal outlives its week only when its own job does not run, which is exactly why coo-level10.json from 2026-08-17 was still on disk on 2026-08-25. What this changes: Phase 4 item 2 is retired as already built, and replaced by the rung above it. A parked chain is one line in a log channel, indistinguishable from a normal day, and the only tier that rings a phone requires a job to write its own signal file, which a job that died on a 529 cannot do. The runner already knows a job exited non-zero; it tells the wrong channel. Issue 50's two smaller changes (continue-on-fail, move the API-heaviest job out of order 1) are sequenced ahead of all of Phase 4, because they are what actually cost the company the 2026-08-24 read. — next: Phase 4, one item retired and one sharpened by F125. (1) A preflight auth check that verifies the Claude OAuth session before the 04:00 chain and pages while it can still be refreshed, since retry-once cannot clear an expired session. (2) RETIRED, the notifier path already works: notifyRun() is awaited before the stop-on-fail exit and the heartbeat posted the 529 to #fleet-log on 2026-08-24. Replaced by escalation: post to the page tier when any job in a run-due chain exits non-zero, since the runner already knows and only tells the wrong channel. (3) The .claude/settings.json tool allowlist for unattended runs. Ship issue 50's two smaller changes first, continue-on-fail and moving the API-heaviest job out of order 1, because they are what actually cost the company the 2026-08-24 read. (Erik, Aug 31) — status check

Sep 1TWO left, both past end date. DAGBLADET is now the bigger one: invoice 190 (86,400 SEK) went to Aller Media's scan-only inbox 2026-07-19 and its auto-reply states that an invoice missing any of six mandatory fields is 'not processed or returned' - so 37 days of silence may mean it was deleted on arrival, not that it is queued. Check Invoice190.pdf against those six (their reference, our company info, invoice date+number, payment terms, our VAT/org no., our payment details) BEFORE chasing; reissue if it fails, chase Trym Mogen (tmog@db.no) if it passes. CRM note 58 fell due 2026-08-20. Then trim subscription 1496668 from 90 seats to 20. IDMC: $1,620 (inv 184) now 72 days overdue, Lis Zandberg silent 36 days since promising a finance follow-up, and Intercom 215473594558152 has been open 62 days with the answer already written and unsent. Her email lis.zandberg@idmc.ch WORKS (the hard-bounce claim in the notes below is wrong). Drafts for both are in company/reports/sales/2026-35.md. Sales · Fix the enterprise CRM data, then chase or close the past-du

Fix the enterprise CRM data, then chase or close the past-due five — RESOLVED 2026-07-19 (Erik + assistant session, all five worked account by account against Visma invoices, both bank accounts, Gmail and Intercom). Verdict: none of the five needed cancelling. All five were real customers with invoices actually sent. The needs_cancellation flag was wrong on every row. PAID, confirmed against bank statements: - NTB inv 187, 64,800 SEK, paid 2026-06-10, bank ref CINV/187. Period 2026-05-19 to 2027-05-19, 8 seats x 12 months @ 900 SEK/seat/month less 25% loyalty. (Inv 183 was credited by 188 and replaced by 187; the CRM still has the superseded Faktura183.pdf attached.) - Regeringskansliet inv 179, 11,564 SEK, paid 2026-06-12 (11,563.75 via BG 5150-3894, 25-ore rounding). Period 2026-04-15 to 2027-04-15, 2 seats @ 35 USD/seat/month = 327 SEK, plus 150 USD invoicing fee, plus 25% moms. - Virginia Tech inv 182, USD 1,656, paid 2026-05-21, ref 2026052100174093 (USD account). Period 2026-05-01 to 2027-05-01, 2 seats @ 35 USD/seat/month less 10% educational, PLUS a Public Dashboard add-on at 1,000 USD/yr less 10%. UNPAID: - IDMC inv 184, USD 1,620, sent 2026-05-11 via Intercom (Lis confirmed 2026-05-19 she forwarded it to finance). Period 2026-05-17 to 2027-05-17, 10 seats @ 240 USD/seat/yr less 780 (20% public good + 300 custom). Chased 2026-07-19. Note Lis's email hard-bounces; reach her in Intercom or via ivana.hajzmanova@idmc.ch. [SUPERSEDED 2026-08-17, see the correction block below: the address works.] - Dagbladet inv 181, 86,400 SEK, superseded. Credited and reissued 2026-07-19 as 20 seats x 4,320 SEK/seat/yr, period 2026-04-25 to 2027-04-25, sent to Aller Media (Peppol 0192910119877 / Invoice.no.allermedia@aller.com, Referanse 1 'Trym Mogen, desksjef', Referanse 2 'product code: 40600'). Trym confirmed 20 seats on 2026-07-01. DATA FIXED: all four subscriptions rows had next_payment_due corrected to match invoice periods (1075599 NTB 2027-05-19, 885574 Regeringskansliet 2027-04-15, 881920 Virginia Tech 2027-05-01, was 2025-03-28 stale by 15 months, 1527119 IDMC 2027-05-17). CRM customer rows updated by Erik. PREMISE CORRECTION: the Jul 10 reconciliation's '$58.6K in limbo' does not survive (F023). Dagbladet was booked at $37.8K/yr (23% of the enterprise book) from annualising a stale 90-seat row at list price; the real contract is 86,400 SEK (~$9K). Enterprise ARR is overstated by roughly $29K (F022); the book total is retracted as method-unsafe (F024). Actual outstanding across the five as of 2026-07-19 is USD 1,620 plus the Dagbladet reissue. ROOT CAUSE, identified 2026-07-19 (since fixed): the needs_cancellation flip was the OLD CrmAutoTransitionStatusesJob overdue_payment.update_all (daily 05:00), which flipped confirm_payment -> needs_cancellation once invoice_sent_at was 60+ days old, skipping updated_at (the 'undated' flip and no system note) and never checking payment_confirmed_at, so it flipped three already-paid accounts too. The 2026-05-15 11:07 stamp was the invoice-SEND batch (7 accounts, incl. Leatherhead and Ilta-Sanomat), not the flip; the flip fired ~2026-07-14 (invoice_sent + 60d). Backend f527582f (main, 2026-07-19) removed that behavior: needs_cancellation is deleted from the CrmCustomer enum, unpaid invoices are no longer auto-transitioned, and overdue is derived from payment_due_by (payment_overdue?) with the row staying confirm_payment for a human to decide. So there is no re-flip risk and the eng half of issue 12 is done. See issue 12 (now resolved) and issue 13 (Visma bank feed not reconciling, why payment_confirmed_at stays null). ALSO FOUND: quantity x list variant price reproduces NO invoice, every enterprise account bills a negotiated rate the subscriptions table cannot express (VT has an add-on, Regeringskansliet has a fee and VAT, NTB and Dagbladet bill in SEK against a USD variant). Any ARR figure derived from subscriptions.quantity x variants.price is wrong by construction (F022). Visma's paid/unpaid flags are also unreliable: five invoices confirmed paid by bank still sat in 'Obetalda kundfakturor', so the bank feed is not reconciling (carded as issue 13). CORRECTION 2026-08-17 (sales-renewals W34, company/reports/sales/2026-34.md). Two claims above are wrong and were inherited by three weekly reports without anyone re-testing them. 1. Lis Zandberg's email does NOT hard-bounce. Erik emailed lis.zandberg@idmc.ch on 2026-07-19 (Gmail thread 19f7c13c8dd608ba) and she replied from that address on 2026-07-20: 'Absolutely, I will follow up with the responsible department immediately and get back to you as soon as possible.' The chase therefore went by email, not 'in Intercom' as the next action said. 28 days on, nothing has come back and inv 184 is 64 days past due. The class: a contact-channel fact recorded once under pressure and never re-checked. It expires like any other claim (rule 12a). 2. The Dagbladet seat trim is 90 to 20, not 40 to 20. subscriptions.quantity on 1496668 reads 90 against a 20-seat contract, with 32 active users on organization 5594. Whatever the admin screen showed when this card was written, the row is 70 seats over, not 20. STATUS 2026-08-17: neither half has moved. No CRM write since 2026-07-19 22:11 (29 days). No reply from db.no or aller.com since the reissue, and crm_visma_invoices is still empty (F020) so its state is not visible from the app. The CRM's own note 58 on Dagbladet ('New invoice sent with corected seat count') carries due_by 2026-08-20 and no resolved_at. IDMC's support conversation 215473594558152 is still open, waiting since 2026-06-24, 54 days, with a suggested answer sitting unsent in the thread since the day it arrived. — next: TWO left, both past end date. DAGBLADET is now the bigger one: invoice 190 (86,400 SEK) went to Aller Media's scan-only inbox 2026-07-19 and its auto-reply states that an invoice missing any of six mandatory fields is 'not processed or returned' - so 37 days of silence may mean it was deleted on arrival, not that it is queued. Check Invoice190.pdf against those six (their reference, our company info, invoice date+number, payment terms, our VAT/org no., our payment details) BEFORE chasing; reissue if it fails, chase Trym Mogen (tmog@db.no) if it passes. CRM note 58 fell due 2026-08-20. Then trim subscription 1496668 from 90 seats to 20. IDMC: $1,620 (inv 184) now 72 days overdue, Lis Zandberg silent 36 days since promising a finance follow-up, and Intercom 215473594558152 has been open 62 days with the answer already written and unsent. Her email lis.zandberg@idmc.ch WORKS (the hard-bounce claim in the notes below is wrong). Drafts for both are in company/reports/sales/2026-35.md. (Erik, Sep 1) — enterprise arr reconciliation, 2026 W29

Review PR #237 (on staging) Erik · Link bookmarking via an auto-created links feed — next: Revi

Link bookmarking via an auto-created links feed — next: Review PR #237 (on staging)

Apply the generated rulesets on statistics-db1 and bhs-rails-worker1 (a default-deny rewrite, follow the PR #241 checklist), then decide the remaining undeclared hosts: bhs-web-app1/2, analytics-frontend1, docker-metabase1, dev-db Erik · Firewall the undeclared data-service hosts (Redis incident f

Firewall the undeclared data-service hosts (Redis incident follow-up) — 2026-07-27 audit: PR #241 closed unmerged 2026-07-18 but its iptables config is on main (statistics-db1 in servers.json + hosts/db.json, hosts/rails-worker.json), so in_review pointed reviewers at a dead PR. Both live exposures were already closed by hand; what remains is applying the managed rulesets per host and the straggler decisions. — next: Apply the generated rulesets on statistics-db1 and bhs-rails-worker1 (a default-deny rewrite, follow the PR #241 checklist), then decide the remaining undeclared hosts: bhs-web-app1/2, analytics-frontend1, docker-metabase1, dev-db

Close or card #1 #2 #4 #7 #36 #37 #48 #68 #103 #156 (every open PR created before July) Erik · Triage or close the 10 stale open PRs — 2026-07-27 audit: th

Triage or close the 10 stale open PRs — 2026-07-27 audit: the old '7 stale pre-June PRs' list was wrong on both ends, #156 was opened Jun 21 (not pre-June) and genuinely old open PRs #1 #2 #4 (February) were missing. Current stale set is these 10, verified against the open-PR list 2026-07-26. — next: Close or card #1 #2 #4 #7 #36 #37 #48 #68 #103 #156 (every open PR created before July) — status check

Asks found in recent docs

Audit the Chargebee dunning settings (§5.1) — one sitting in the Chargebee admin UI. Check the retry schedule and duration, Smart Dunning on/off, the dunning email sequence, auto-cancel timing, and whether a network card updater is active on the gateway. None of it is API-readable, so nobody can do this but a human with admin access. Today's defaults recover 1 in 284 (§2); this audit decides what the retry engine should look like before the in-app fixes land on top of it. Involuntary (failed-payment) churn — measured (2026-07-04)

→ Read the full doc: Involuntary (failed-payment) churn — measured (2026-07-04)

The year

The turn: net new MRR durably above zero by December; trough ARR >= ~$310K · 10-year: Feeder alive and thriving as a side business, ~3x ARR (ratified 2026-07-10)

Measurable	Target	Now	As of
Net new MRR / mo	> $0 by Dec	-$2 July MTD through Jul 16 (June: -$556)	2026-07-17 source
Customer churn / mo	< 3.5%	~4.5%	2026-07-02 source
New payers / yr pace	~1,100	778 (2025 pace)	2026-07-02 source
New business MRR / mo	> $1,000	$789 pace July MTD	2026-07-17 source
Reactivation MRR / mo	> $400	$241 in 16 days (July)	2026-07-17 source

Rocks & issues

4 off trackthe quarter's commitments (done or not-done, no partial credit) · what's in the way, headed for IDS

Rocks — 2026-Q3 V/TO

ProductEntry-tier A/B live at day 0, plan-page cliff fix shipped first off track

ProductExtension revive: 8.0.29 shipped, listing worked, install-to-signup on the scorecard off track

DataPhase 3 gauges: cohorts to ChartMogul, payers-per-cohort in the weekly digest on track

MarketingWin-back and dormant nudges routed into the dormant flow done

SupportKind early-cancel play shipped, save rate on the scorecard off track

Sales90-day renewal worklist built and worked, 0 enterprise renewals lost off track

ProductAI onboarding ship/kill decision on week-1 activation on track

Issues — 51 open

#1 · New buyers cancel in first 60 days saying it didn't work (50% of early free texts)

#2 · Feed catalog lies: ~40% mislabeled ai_generated, 16% dead (L007)

#3 · Custom-feed/RSS-builder fails on real target sites (top early-cancel complaint)

EOS: the weekly Level 10 IDS's the top three issues to root cause — no symptom patches (L013). Rocks reset at the quarterly session.

The board

In progress 5 · Up next 28 · Done 0

Erik4

Aug 31Fix Chargebee's give-up-too-fast billing retries — Audit ran 2026-07-18 (Erik, Chargebee admin UI, config applied). System was already tuned: dunning emails on for years, Account Updater on via Stripe default, 39% recovery (F017). Only material change is the retry window 5 to 21 days, plus schedule spread 2/5/9/14/21 and skip-hard-failures on. Smart Dunning declined: plan-gated, negative ROI against the ~$374/mo residue. See F021 and the 2026-07-18 addendum on the kill report. Expect a ~3-week involuntary-churn trough that is deferral, not impact. — next: Re-run company/checks/dunning-recovery.rb and compare steady-state recovery to the 39% baseline (F017), discounting the transition trough (Data, Aug 31) — failed payment recovery task killed, involuntary churn

Link bookmarking via an auto-created links feed — next: Review PR #237 (on staging)

Firewall the undeclared data-service hosts (Redis incident follow-up) — 2026-07-27 audit: PR #241 closed unmerged 2026-07-18 but its iptables config is on main (statistics-db1 in servers.json + hosts/db.json, hosts/rails-worker.json), so in_review pointed reviewers at a dead PR. Both live exposures were already closed by hand; what remains is applying the managed rulesets per host and the straggler decisions. — next: Apply the generated rulesets on statistics-db1 and bhs-rails-worker1 (a default-deny rewrite, follow the PR #241 checklist), then decide the remaining undeclared hosts: bhs-web-app1/2, analytics-frontend1, docker-metabase1, dev-db

Triage or close the 10 stale open PRs — 2026-07-27 audit: the old '7 stale pre-June PRs' list was wrong on both ends, #156 was opened Jun 21 (not pre-June) and genuinely old open PRs #1 #2 #4 (February) were missing. Current stale set is these 10, verified against the open-PR list 2026-07-26. — next: Close or card #1 #2 #4 #7 #36 #37 #48 #68 #103 #156 (every open PR created before July) — status check

—

Product6

overdue · Aug 18AI onboarding A/B, ship or kill call — next: Recommendation from the data seat is now on the record: return the default to the reader and keep the agent behind ?onboarding=1 and the sidebar. The last argument for keeping the screen was that some identifiable group might be well served by it and should be routed in rather than switched off. F078 tests that on everything observable before the screen renders and finds no such group: seven segment cuts, seven negative for the AI arm, five regions out of five (sign test p=0.031), and the segments that engage the agent most carry the larger deficits. With F064 (shallower readers at equal feed count) and F066 (a perfect fallback tops out at parity), all three lines of evidence point the same way. Score the one-tap example chips as polish, not as the activation lever that rescues the arm: the 14.56% typers-beat-control number behind it is selection, and the segment evidence runs the other way. Product's call, unchanged in ownership. (Aug 18) — ai onboarding ab readout

overdue · Jul 29Decide what lapsing to free should actually cost — 2026-07-27 audit: the 2026-07-21 date was missed with no note and the E003 readout never ran; the W30 CEO read set 2026-07-29, applied here (rule 2). — next: Verify enforcement actually started Jul 14 (E003's premise was never independently checked), then read the natural experiment and propose the entitlement diff (Jul 29) — failed payment cohorts and premortem

One calm pricing moment at day 0, at the end of onboarding — 2026-07-27 audit: ungated, the next_action had waited on 'after the plan-page fix ships' and I001 closed 2026-07-25. — next: Design the day-0 pricing moment; the plan-page gate resolved 2026-07-25 (I001 closed: the cliff is real, currency ruled out as the fix, F031/F034/F035) — payment mechanisms

Ship extension 8.0.29 and investigate the 140k disabled installs — Data seat, 2026-08-25 (F107): extension 8.0.28 mislabels its platform. Clients flipped fromPlatform chrome->firefox from the week of 2026-03-09, complete by ~2026-04-06; clients still on 7.9.0 never flipped. Monthly extension readers went chrome 14,939 -> 1,637 and firefox 191 -> 12,233 with the union flat, and 45% of March's readers were counted under both labels. This blinds every chrome-vs-firefox cut in BigQuery, and it is why the 'phantom-install era faded in Apr-Jun' reading was wrong: the 6x multiple changed labels rather than going away. Ask for 8.0.29: one grep of the platform-detection code, fix ships with the build already planned here. Second item from the same run (F106): 96-98% of app:new_install_event clients are never seen again on any event and 3.1% ever attach to a userId, so the 140k disabled-installs question and any install-to-signup rate both rest on a clientId that may not mean one browser profile. Worth establishing what mints a clientId while the build is open. — next: Ship the instrumented post-install flow — L008 extension funnel broke at post install signup step

Monitoring feature audit and one-flow keyword setup — next: Audit, then the one-flow setup — monitoring experience

Root-cause the 4 bug reports mined from exit surveys — Issue 3 — next: Ticket each: folder-move data loss, signup feed-wipe, blocked Microsoft feeds, Firefox YouTube embeds — exit survey mining

—

Sales4

Sep 1Fix the enterprise CRM data, then chase or close the past-due five — RESOLVED 2026-07-19 (Erik + assistant session, all five worked account by account against Visma invoices, both bank accounts, Gmail and Intercom). Verdict: none of the five needed cancelling. All five were real customers with invoices actually sent. The needs_cancellation flag was wrong on every row. PAID, confirmed against bank statements: - NTB inv 187, 64,800 SEK, paid 2026-06-10, bank ref CINV/187. Period 2026-05-19 to 2027-05-19, 8 seats x 12 months @ 900 SEK/seat/month less 25% loyalty. (Inv 183 was credited by 188 and replaced by 187; the CRM still has the superseded Faktura183.pdf attached.) - Regeringskansliet inv 179, 11,564 SEK, paid 2026-06-12 (11,563.75 via BG 5150-3894, 25-ore rounding). Period 2026-04-15 to 2027-04-15, 2 seats @ 35 USD/seat/month = 327 SEK, plus 150 USD invoicing fee, plus 25% moms. - Virginia Tech inv 182, USD 1,656, paid 2026-05-21, ref 2026052100174093 (USD account). Period 2026-05-01 to 2027-05-01, 2 seats @ 35 USD/seat/month less 10% educational, PLUS a Public Dashboard add-on at 1,000 USD/yr less 10%. UNPAID: - IDMC inv 184, USD 1,620, sent 2026-05-11 via Intercom (Lis confirmed 2026-05-19 she forwarded it to finance). Period 2026-05-17 to 2027-05-17, 10 seats @ 240 USD/seat/yr less 780 (20% public good + 300 custom). Chased 2026-07-19. Note Lis's email hard-bounces; reach her in Intercom or via ivana.hajzmanova@idmc.ch. [SUPERSEDED 2026-08-17, see the correction block below: the address works.] - Dagbladet inv 181, 86,400 SEK, superseded. Credited and reissued 2026-07-19 as 20 seats x 4,320 SEK/seat/yr, period 2026-04-25 to 2027-04-25, sent to Aller Media (Peppol 0192910119877 / Invoice.no.allermedia@aller.com, Referanse 1 'Trym Mogen, desksjef', Referanse 2 'product code: 40600'). Trym confirmed 20 seats on 2026-07-01. DATA FIXED: all four subscriptions rows had next_payment_due corrected to match invoice periods (1075599 NTB 2027-05-19, 885574 Regeringskansliet 2027-04-15, 881920 Virginia Tech 2027-05-01, was 2025-03-28 stale by 15 months, 1527119 IDMC 2027-05-17). CRM customer rows updated by Erik. PREMISE CORRECTION: the Jul 10 reconciliation's '$58.6K in limbo' does not survive (F023). Dagbladet was booked at $37.8K/yr (23% of the enterprise book) from annualising a stale 90-seat row at list price; the real contract is 86,400 SEK (~$9K). Enterprise ARR is overstated by roughly $29K (F022); the book total is retracted as method-unsafe (F024). Actual outstanding across the five as of 2026-07-19 is USD 1,620 plus the Dagbladet reissue. ROOT CAUSE, identified 2026-07-19 (since fixed): the needs_cancellation flip was the OLD CrmAutoTransitionStatusesJob overdue_payment.update_all (daily 05:00), which flipped confirm_payment -> needs_cancellation once invoice_sent_at was 60+ days old, skipping updated_at (the 'undated' flip and no system note) and never checking payment_confirmed_at, so it flipped three already-paid accounts too. The 2026-05-15 11:07 stamp was the invoice-SEND batch (7 accounts, incl. Leatherhead and Ilta-Sanomat), not the flip; the flip fired ~2026-07-14 (invoice_sent + 60d). Backend f527582f (main, 2026-07-19) removed that behavior: needs_cancellation is deleted from the CrmCustomer enum, unpaid invoices are no longer auto-transitioned, and overdue is derived from payment_due_by (payment_overdue?) with the row staying confirm_payment for a human to decide. So there is no re-flip risk and the eng half of issue 12 is done. See issue 12 (now resolved) and issue 13 (Visma bank feed not reconciling, why payment_confirmed_at stays null). ALSO FOUND: quantity x list variant price reproduces NO invoice, every enterprise account bills a negotiated rate the subscriptions table cannot express (VT has an add-on, Regeringskansliet has a fee and VAT, NTB and Dagbladet bill in SEK against a USD variant). Any ARR figure derived from subscriptions.quantity x variants.price is wrong by construction (F022). Visma's paid/unpaid flags are also unreliable: five invoices confirmed paid by bank still sat in 'Obetalda kundfakturor', so the bank feed is not reconciling (carded as issue 13). CORRECTION 2026-08-17 (sales-renewals W34, company/reports/sales/2026-34.md). Two claims above are wrong and were inherited by three weekly reports without anyone re-testing them. 1. Lis Zandberg's email does NOT hard-bounce. Erik emailed lis.zandberg@idmc.ch on 2026-07-19 (Gmail thread 19f7c13c8dd608ba) and she replied from that address on 2026-07-20: 'Absolutely, I will follow up with the responsible department immediately and get back to you as soon as possible.' The chase therefore went by email, not 'in Intercom' as the next action said. 28 days on, nothing has come back and inv 184 is 64 days past due. The class: a contact-channel fact recorded once under pressure and never re-checked. It expires like any other claim (rule 12a). 2. The Dagbladet seat trim is 90 to 20, not 40 to 20. subscriptions.quantity on 1496668 reads 90 against a 20-seat contract, with 32 active users on organization 5594. Whatever the admin screen showed when this card was written, the row is 70 seats over, not 20. STATUS 2026-08-17: neither half has moved. No CRM write since 2026-07-19 22:11 (29 days). No reply from db.no or aller.com since the reissue, and crm_visma_invoices is still empty (F020) so its state is not visible from the app. The CRM's own note 58 on Dagbladet ('New invoice sent with corected seat count') carries due_by 2026-08-20 and no resolved_at. IDMC's support conversation 215473594558152 is still open, waiting since 2026-06-24, 54 days, with a suggested answer sitting unsent in the thread since the day it arrived. — next: TWO left, both past end date. DAGBLADET is now the bigger one: invoice 190 (86,400 SEK) went to Aller Media's scan-only inbox 2026-07-19 and its auto-reply states that an invoice missing any of six mandatory fields is 'not processed or returned' - so 37 days of silence may mean it was deleted on arrival, not that it is queued. Check Invoice190.pdf against those six (their reference, our company info, invoice date+number, payment terms, our VAT/org no., our payment details) BEFORE chasing; reissue if it fails, chase Trym Mogen (tmog@db.no) if it passes. CRM note 58 fell due 2026-08-20. Then trim subscription 1496668 from 90 seats to 20. IDMC: $1,620 (inv 184) now 72 days overdue, Lis Zandberg silent 36 days since promising a finance follow-up, and Intercom 215473594558152 has been open 62 days with the answer already written and unsent. Her email lis.zandberg@idmc.ch WORKS (the hard-bounce claim in the notes below is wrong). Drafts for both are in company/reports/sales/2026-35.md. (Erik, Sep 1) — enterprise arr reconciliation, 2026 W29

overdue · Jul 14Put the 4 invisible invoiced accounts into the CRM — 2026-07-27 audit: dropped 'incl. DMJX $42K' from the title, the figure came from the seat x list method retracted 2026-07-19 (F022/F024) and was never invoice-verified; sales 2026-30 found DMJX has NO subscription row in the app DB at all (bills outside the app, or the line was never real). Still zero crm_customers rows for the four as of 2026-07-26. Past due since 2026-07-14, left overdue for visibility. — next: Create the CRM records, verifying each account against actual Visma invoices, not seat x list price (F022) (Jul 14) — enterprise arr reconciliation

Qualify the 475 unmonetized monitoring professionals as the warm list — next: Qualify against the Monitoring tier — monitoring professional signature

overdue · Jul 24Enterprise outbound and renewal machine, the 32 churned logos plus lookalikes — Both strategy takes rank this first: the only proven engine at $1M density; target 6 new logos in 12 months. 2026-07-27 audit: the 2026-07-24 ratification date was missed with no note (left overdue, the decision is Erik's). Before ratifying, re-read section 5 against F022/F023/F024: parts of the enterprise numbers the strategy review leans on were retracted 2026-07-19, two days after it was written. — next: Erik ratifies (strategy review section 5); then agents draft ~10 notes/wk, Erik sends (~2h/wk), 3-tier price sheet (Erik, Jul 24) — 1m arr strategy review, enterprise arr reconciliation

—

Data1

overdue · Aug 10Post-release check-ins on the extension upgrade experience — Week-4 product readout delivered 2026-08-03 (company/reports/data/2026-08-03-extension-upgrade-checkpoint-w4.md, F053). Directional answer to the week-4 question: the funnel leaks at the offer step, not at checkout, which converts 1 in 3 once opened. Trial emails run 59.4% open / 19.4% click and have converted 0 of 40 recipients, so this is a page-and-price problem rather than an interest problem; the experiment doc's own fallback (free first feed, paid from the second) is the obvious A/B and does not need to wait for week 8. Floor check is already off pace without needing a closed window: 1 payer in 29 days annualizes to ~13/yr against a ~60/yr bar. Two defects found this run: the day-20 metric recommendation overcounts, and the design guarantee that nobody receives both a trial email and the day-3 reminder is broken for 18 users (4 of them an outright suppression failure). — next: Hold the week-4 redesign call on the offer page, not checkout: 156 verified users reached the offer, 3 opened checkout, 1 paid (F053). Do NOT ship the day-20 updated_at metric fix as written, it overcounts (scored a payer who never entered the funnel); use the funnel-entry query in the week-4 report and update the experiment doc's queries section. Then the week-5 run reports the first closed 30-day cohort (W27 closes 2026-08-04). (Aug 10) — extension upgrade experience, extension upgrade checkpoint 1w

—

—

Marketing7

—

overdue · Jul 31Feed your AI: make /mcp the hub, list in agent directories — 2026-07-27 audit: date set from the plan, P06 Phase A time-boxes directory listings + the /mcp hub to July (company/plans/ai-data-wedge.md, ratified top priority 2026-07-04); the card had sat undated while its own plan carried the deadline. 2026-08-08: Erik reprioritized this direction ('the mcp is enough. maybe if we make an official connector to claude and chatgpt') after killing I002. How-to research for the Claude and ChatGPT directory submissions is in company/reports/marketing/2026-08-08-official-connector-listings.md (PR #339): both portals' requirements, Feeder's gaps (tool annotations missing on all MCP tools; plan-gate upgrade message links to checkout, which OpenAI prohibits), and prerequisites (Claude Team/Enterprise org for the claude.ai submission portal; verified business identity on the OpenAI Platform). Eng prep is ~1-2 days before either submission. — next: Directory placements + hub page (Jul 31) — ai data wedge

Chrome Web Store listing revival — next: Keywords, screenshots, own-surface install traffic — L008 extension funnel broke at post install signup step

Monitoring page and landing pages for the empty $15-199 band — next: First pages — monitoring experience

overdue · Aug 7First batch of AI landing pages at best-converting cohorts — 2026-08-25 marketing-channel-read (W35): card is 18 days past its 2026-08-07 date and still planned. RETRACTION FROM LAST WEEK, stated plainly because it was a stated condition: last week's note said 'leave cybersecurity out until it produces one payer' and it has now produced one. User 1005609 (US) signed up 2026-08-19 14:44 and paid by Chargebee at 15:47, 63 minutes later, inside the reporting week. Deduplicated table (273 users touching exactly one page, 2026 to Aug 23, F059): cybersecurity-teams 108/1, software-engineers 39/0, financial-services 39/2, marketing-professionals 28/2, competitor-monitoring 18/2, 12 others 41/1. The two highest-volume pages are now 147 signups / 1 payer against ~4.4 expected at the discover path's 30-day rate (3.00%, F072), so p is ~0.066, up from 0.014 last week and 0.02 the week before. That is no longer significant at any conventional threshold and three weeks of a hardening zero has reversed. F122. The ranking advice is unchanged in DIRECTION and weaker in strength: the three converting pages are 6 payers on 85 signups (7.1%) against the top two at 0.68%, a 10x gap in rate but on volumes too small to be certain of. Rank the next batch against financial-services, marketing-professionals and competitor-monitoring, but no longer exclude cybersecurity-teams. Method caveat that killed the earlier ranking still binds: page-use-case-* tags are re-applied per visit, so the table must be deduplicated to users carrying exactly one page tag (two further cybersecurity payers exist but touched several pages and are correctly excluded). Evidence: company/reports/marketing/2026-W35.md. No date proposed here, that is Erik's call on an overdue card. — next: Ship the first batch, early August (Aug 7) — ai landing pages, decision memo

overdue · Aug 5Read win-back results, then decide the churned-payer backlog campaign — 2026-08-11 (COO Level 10, W33): this card's premise is answered and the answer is "there is nothing to attribute". I028 exists to attribute the July reactivation line that W30/W31/W32 flagged three weeks running as the largest unexplained positive in the P&L. F062 settled it with one extra ChartMogul call for 2024: reactivation is in a three-year decline ($513.90 -> $364.33 -> $296.29 Jan-Jul monthly average) and July 2026's $385.66 sits below July 2025 and well below July 2024. It looked strong only against 2026's own weak start. So the dormant-nudge rock (rock 3, done as built) has no measurable win behind it, and the 30-day readout this card is waiting on (due 2026-08-05, now 6 days overdue) can be scoped much tighter or the card closed. The CEO's W33 read proposes rescope-or-close; that decision is Erik's or a reviewed CEO session's, so no status was changed here. Recording it because leaving the card reading "attribute the reactivation line" is a wrong memory (rule 1). — next: 30-day readout + framing proposal for Erik (Aug 5) — churn surfaces, marketing plate review

Find and assess the alleged PC World extension-malware article — Issue 8 — next: Find it, assess before it spreads — exit survey mining

overdue · Jul 24Turn shared dashboards into an acquisition surface — A shared dashboard produced one of W28's fastest payers. 2026-07-27 audit: the 2026-07-24 date was missed with no note; left overdue for visibility. — next: Size the channel from public-dashboard tags, then propose the play (Jul 24) — w28 new subscription analysis

—

Eng3

—

overdue · Jul 22Promo admin: pick a percentage and dates, run the summer sale — Time-boxed by summer. 2026-07-27 audit: 4 days past due with the build verifiably not started (no Promotion model on main, no PR), left overdue, every slipped week shrinks E005's summer window. Prompt's closing steps corrected (they instructed hand-editing superseded queue.md/todo.md, rule 13) and the stale queue-3/queue-item-1 numbering fixed, the card had been queue position 2 since I001 closed; moved to queue position 1 on 2026-08-08 when I002 was killed. — next: Build Phase 1 (queue-1 session); summer 50%-off-yearly test vs 13% BF benchmark (Jul 22) — promotion automation, promo decision

See which cohorts produce new payers, weekly: cohorts into ChartMogul + the digest gauge — 2026-07-27 audit: status reset building to planned, no branch, PR, or artifact since the plan's Phase-3 note of 2026-07-02, and F040 already refused rock 2's on_track for exactly this. Title rewritten from 'Classification Phase 3 gauges' (rule 10). Needs a dated commitment from eng; rock 2 is judged on this card. — next: Push cohorts to ChartMogul; wire new-payers-per-cohort into the weekly digest — user classification

Make every upgrade traceable to what caused it — 2026-08-25 marketing-channel-read (W35): 39 days past the original 2026-07-17 date, still planned, still no date. State of the three gaps, reporting week W34 (Aug 17-23): external source attribution still zero for a fifth consecutive week (F046 holds; all 43 distinct utm-campaign values are internal prompts, on 193 users / 12.2% of the week, read to the end of the tail rather than off a LIMIT). App-message ids improved slightly: extension_email_trial appears for the first time (1 user) alongside extension_email_continue_setup (1 user), so two of that family now fire (F044), while extension_email_paywall still tags nobody at 31 days (F082). Localized tag values unchanged and the defect is unchanged in the code: frontend/app/components/notification-settings-box/component.ts:90 still builds ${option.label} notifications from a translated label plus a hard-coded English word, and no commit has touched the file. It did NOT surface in this week's tag values, which is not the same as fixed, it only fires when a non-English user opens an upgrade prompt on one of the four notification features and none did in W34. Third week this defect has been read off tag values and the first two got it wrong in both directions, so read the code. NEW THIS WEEK, and it belongs to this initiative because it is the same instrument: signup tagging silently stopped writing for ~36 minutes on 2026-08-18, 11 consecutive signups (ids 1005195-1005205) with no signup-time tag at all, plus 10 users an hour later with country='NA', a value absent from every other week in the nine-week window. Nothing alerted. Filed separately as issue 53 (owner eng) because the fix is an alert, not tagging coverage, but it sharpens I023's premise: the attribution instrument fails by returning plausible numbers rather than an error. F121. Last week's cost statement still stands and got bigger: the Bangladesh wave reached 437 signups in W34 (743 since Aug 10) and we still cannot say from where. Evidence: company/reports/marketing/2026-W35.md. — next: Finish the tagging: extension_email_paywall arrival tag (the path E001's first conversion took, still unattributable), app-message ids, localized tag values; then scope the external arrival-attribution build (F029: 0 of ~11,400 recent signups carry utm_campaign) — extension upgrade checkpoint 1w, w28 new subscription analysis

—

Finance3

—

Make the invoiced book visible: ChartMogul custom source + drop the 2 ghost subs — Verified missing 2026-07-17: ChartMogul has 9 sources, none invoiced. GUARDRAIL (2026-07-19, F022/F024): the per-account dollars pushed into any custom source must come from reconciled Visma invoices, not subscriptions.quantity x price, which reproduces no invoice (Dagbladet alone was ~$29K high). Importing the DB-derived book would import wrong numbers. Blocked on the Visma sync (F020). 2026-07-27 audit: next_action re-pointed, the 2026-07-19 guardrail declared the original 'create the custom source' step blocked but the field was never updated (rule 2); original 2026-07-13 date cleared with the re-point. — next: Deactivate the 2 ghost subs now; the ChartMogul custom source stays blocked on the Visma sync (F020), decide build vs park — enterprise arr reconciliation, L010 headline arr excludes invoiced enterprise book

overdue · Aug 1Model the usage-ladder cohorts: uptake, cannibalization, retention guardrails — 2026-07-25 (Erik): regional/PPP pricing is NOT part of this card. It was briefly routed here earlier the same day; Erik reversed that, PPP becomes a separate project (issue 17) and the ladder goes first. Reasoning on the record: PPP cannot be measured at any time (India is 295 plan-viewers per 180 days, F035 arithmetic), so there is no PPP learning to protect by sequencing; what sequencing protects is focus on the ladder, which is the larger prize, is already overdue, and CAN be measured on US/EU volume. The L003 cost of a second pricing event (one more grandfathered cohort) is small here because the PPP countries produce very few payers (IN 18/yr, BR 13/yr, geo report 2026-07-05). Evidence that shaped the split: F037 (IN/BR is price resistance, JP/KR/TW is not). CORRECTION 2026-07-25: an earlier version of this note called Japan 'the largest non-US signup geo'. Wrong. Japan is 3rd among non-US by signups (IN 5,025, FR 4,660, JP 4,066, geo report 2026-07-05); what is true is that it is the largest non-US market whose weak conversion is NOT explained by purchasing power. F037's own notes field carries the same slip and should be corrected next time that record is touched. — next: Cohort model for the ladder decision: uptake, cannibalization, retention guardrails. Ladder only, no regional/PPP prices in scope (Erik 2026-07-25 split PPP into its own project, sequenced after the ladder ships). (Aug 1) — usage based pricing

Annual-renewal pre-notice: why doesn't it convert into card updates — next: Diagnose CTA/deliverability on SubscriptionMailer#upcoming_payment; decide monthly-plan variant — exit survey read, failed payment cohorts and premortem

—

CEO2

—

overdue · Jul 15Pricing Phase 2: the usage-ladder one-page proposal — 2026-07-27 audit: status reset building to planned, no draft, branch, or PR anywhere and the W30 CEO read treats it as not started. Date left overdue on purpose: this card blocks the ladder chain (I012, I018) and rock 0. Past due since 2026-07-15. — next: One-page ladder proposal for Erik (Jul 15) — usage based pricing

overdue · Aug 1August retro: judge July by new-payer production per cohort — next: Run the retro (Aug 1) — decision memo

—

Support2

—

Ship the 48-hour-fix intake with the cancel play — next: Intercom early-cancel-save tagging + diagnosis workflow + save-rate gauge, alongside I017 — first 60 day program

overdue · Aug 1Monthly voice-of-customer digest — next: First digest (Aug 1) — exit survey mining

—

COO1

—

Aug 31Build a laptop CLI that runs the recurring agent jobs on the Claude subscription — 2026-07-27 audit correction: the record said 'not yet running: needs merge', but company/fleet/ is merged to main and 8 of 9 chain jobs ran manually Jul 22-25, producing the W30 report set (agents.json last_run + artifacts verified on disk). The CLI is proven end to end on the subscription; what remains is launchd wiring on Erik's machine and Phase 4. data-explorer was the one chain job skipped in the catch-up runs (issue 22). Decision 2026-07-21 (Erik): laptop CLI on the subscription, not cloud routines. Build: P17, company/plans/agent-fleet-runner.md. 2026-08-11 (COO Level 10, W33): the laptop half is DONE. launchd fires on schedule and the chain has produced a full seat report set twice (2026-08-03 on the Monday slot, 2026-08-11 a day late). What is not done is Phase 4, and it is now measured rather than theoretical. Three weeks, three failure modes, all needing a human to recover: 2026-07-27 data-explorer crashed and stop-on-fail dropped five seats (issue 22, F061); 2026-08-10 the fire and its retry both died on 'OAuth session expired and could not be refreshed' and a Tuesday 04:14 attempt died on laptop sleep. F061's retry-once fix fired correctly on 2026-08-10 and bought nothing, because expired auth is not transient. The notifier failed both weeks, so the dead-man's switch that makes silence mean 'broken' is itself broken. An unattended fleet would still be dark today. Dated to 2026-08-17 by this run: this is the COO seat's own card and it is the one thing on the board this seat can date without asking anyone. 2026-08-17 (COO Level 10, W34): the date was missed and the card is re-dated to 2026-08-24, which is the next chain. Recorded plainly because this is this seat's own card and it dated itself. What happened instead: all eight Monday jobs fired in their own slots on the first attempt, no retry, no OAuth wall, no sleep abort. fleet.mjs has not changed a byte since 2026-08-11 09:46, so none of the three pieces exists and nothing about today is repeatable. One further measurement worth keeping, because it is the half people will assume today settled: the notifier was NOT exercised. No seat wrote a signal file (all eight declined on the notify-policy bar), so the '[notify] post failed: fetch failed' path that broke on two consecutive Mondays was never called today. Today is evidence about the OAuth coin toss only, and it came up heads. It is evidence about the dead-man's switch of exactly zero. 2026-08-25 (COO Level 10, W35): re-dated to 2026-08-31 and Phase 4 corrected. The 2026-08-24 date passed and that is the day the chain parked: the revenue digest failed twice (529, then timeout) and stop-on-fail took all 8 downstream seats with it (F105, issue 50). Fourth of the last five Mondays needing a human to recover. CORRECTION to the 2026-08-11 block above, which two weekly reads inherited without re-testing. 'The notifier failed both weeks, so the dead-man's switch is itself broken. An unattended fleet would still be dark today' is WRONG (F125). runList() awaits notifyRun() before the stop-on-fail exit (fleet.mjs:389), notify.json carries a live bot token with heartbeat_channel #fleet-log, and every Slack failure path logs to stderr. The 2026-08-24 block of launchd.err.log (lines 37-40) has the two digest failures, the retry and the stop-on-fail, and NO [notify] line. So Slack received 'Fleet 2026-08-24: 0 ok, 1 failed - weekly-revenue-digest: API Error: 529 Overloaded'. The single '[notify] post failed: fetch failed' in that file sits in the older working-tree-dirty block. Method caveat: inferred from the absence of a logged failure on a path where every failure logs, not from reading Slack. Second correction, same class: stale signal files ARE cleared. runJob() unlinks signals/<id>.json before the job runs (fleet.mjs:338). A signal outlives its week only when its own job does not run, which is exactly why coo-level10.json from 2026-08-17 was still on disk on 2026-08-25. What this changes: Phase 4 item 2 is retired as already built, and replaced by the rung above it. A parked chain is one line in a log channel, indistinguishable from a normal day, and the only tier that rings a phone requires a job to write its own signal file, which a job that died on a 529 cannot do. The runner already knows a job exited non-zero; it tells the wrong channel. Issue 50's two smaller changes (continue-on-fail, move the API-heaviest job out of order 1) are sequenced ahead of all of Phase 4, because they are what actually cost the company the 2026-08-24 read. — next: Phase 4, one item retired and one sharpened by F125. (1) A preflight auth check that verifies the Claude OAuth session before the 04:00 chain and pages while it can still be refreshed, since retry-once cannot clear an expired session. (2) RETIRED, the notifier path already works: notifyRun() is awaited before the stop-on-fail exit and the heartbeat posted the 529 to #fleet-log on 2026-08-24. Replaced by escalation: post to the page tier when any job in a run-due chain exits non-zero, since the runner already knows and only tells the wrong channel. (3) The .claude/settings.json tool allowlist for unattended runs. Ship issue 50's two smaller changes first, continue-on-fail and moving the API-heaviest job out of order 1, because they are what actually cost the company the 2026-08-24 read. (Erik, Aug 31) — status check

—

In progress 5

overdue · Aug 10DataPost-release check-ins on the extension upgrade experience — Week-4 product readout delivered 2026-08-03 (company/reports/data/2026-08-03-extension-upgrade-checkpoint-w4.md, F053). Directional answer to the week-4 question: the funnel leaks at the offer step, not at checkout, which converts 1 in 3 once opened. Trial emails run 59.4% open / 19.4% click and have converted 0 of 40 recipients, so this is a page-and-price problem rather than an interest problem; the experiment doc's own fallback (free first feed, paid from the second) is the obvious A/B and does not need to wait for week 8. Floor check is already off pace without needing a closed window: 1 payer in 29 days annualizes to ~13/yr against a ~60/yr bar. Two defects found this run: the day-20 metric recommendation overcounts, and the design guarantee that nobody receives both a trial email and the day-3 reminder is broken for 18 users (4 of them an outright suppression failure). — next: Hold the week-4 redesign call on the offer page, not checkout: 156 verified users reached the offer, 3 opened checkout, 1 paid (F053). Do NOT ship the day-20 updated_at metric fix as written, it overcounts (scored a payer who never entered the funnel); use the funnel-entry query in the week-4 report and update the experiment doc's queries section. Then the week-5 run reports the first closed 30-day cohort (W27 closes 2026-08-04). (Aug 10) — extension upgrade experience, extension upgrade checkpoint 1w

overdue · Aug 18ProductAI onboarding A/B, ship or kill call — next: Recommendation from the data seat is now on the record: return the default to the reader and keep the agent behind ?onboarding=1 and the sidebar. The last argument for keeping the screen was that some identifiable group might be well served by it and should be routed in rather than switched off. F078 tests that on everything observable before the screen renders and finds no such group: seven segment cuts, seven negative for the AI arm, five regions out of five (sign test p=0.031), and the segments that engage the agent most carry the larger deficits. With F064 (shallower readers at equal feed count) and F066 (a perfect fallback tops out at parity), all three lines of evidence point the same way. Score the one-tap example chips as polish, not as the activation lever that rescues the arm: the 14.56% typers-beat-control number behind it is selection, and the segment evidence runs the other way. Product's call, unchanged in ownership. (Aug 18) — ai onboarding ab readout

Sep 1SalesFix the enterprise CRM data, then chase or close the past-due five — RESOLVED 2026-07-19 (Erik + assistant session, all five worked account by account against Visma invoices, both bank accounts, Gmail and Intercom). Verdict: none of the five needed cancelling. All five were real customers with invoices actually sent. The needs_cancellation flag was wrong on every row. PAID, confirmed against bank statements: - NTB inv 187, 64,800 SEK, paid 2026-06-10, bank ref CINV/187. Period 2026-05-19 to 2027-05-19, 8 seats x 12 months @ 900 SEK/seat/month less 25% loyalty. (Inv 183 was credited by 188 and replaced by 187; the CRM still has the superseded Faktura183.pdf attached.) - Regeringskansliet inv 179, 11,564 SEK, paid 2026-06-12 (11,563.75 via BG 5150-3894, 25-ore rounding). Period 2026-04-15 to 2027-04-15, 2 seats @ 35 USD/seat/month = 327 SEK, plus 150 USD invoicing fee, plus 25% moms. - Virginia Tech inv 182, USD 1,656, paid 2026-05-21, ref 2026052100174093 (USD account). Period 2026-05-01 to 2027-05-01, 2 seats @ 35 USD/seat/month less 10% educational, PLUS a Public Dashboard add-on at 1,000 USD/yr less 10%. UNPAID: - IDMC inv 184, USD 1,620, sent 2026-05-11 via Intercom (Lis confirmed 2026-05-19 she forwarded it to finance). Period 2026-05-17 to 2027-05-17, 10 seats @ 240 USD/seat/yr less 780 (20% public good + 300 custom). Chased 2026-07-19. Note Lis's email hard-bounces; reach her in Intercom or via ivana.hajzmanova@idmc.ch. [SUPERSEDED 2026-08-17, see the correction block below: the address works.] - Dagbladet inv 181, 86,400 SEK, superseded. Credited and reissued 2026-07-19 as 20 seats x 4,320 SEK/seat/yr, period 2026-04-25 to 2027-04-25, sent to Aller Media (Peppol 0192910119877 / Invoice.no.allermedia@aller.com, Referanse 1 'Trym Mogen, desksjef', Referanse 2 'product code: 40600'). Trym confirmed 20 seats on 2026-07-01. DATA FIXED: all four subscriptions rows had next_payment_due corrected to match invoice periods (1075599 NTB 2027-05-19, 885574 Regeringskansliet 2027-04-15, 881920 Virginia Tech 2027-05-01, was 2025-03-28 stale by 15 months, 1527119 IDMC 2027-05-17). CRM customer rows updated by Erik. PREMISE CORRECTION: the Jul 10 reconciliation's '$58.6K in limbo' does not survive (F023). Dagbladet was booked at $37.8K/yr (23% of the enterprise book) from annualising a stale 90-seat row at list price; the real contract is 86,400 SEK (~$9K). Enterprise ARR is overstated by roughly $29K (F022); the book total is retracted as method-unsafe (F024). Actual outstanding across the five as of 2026-07-19 is USD 1,620 plus the Dagbladet reissue. ROOT CAUSE, identified 2026-07-19 (since fixed): the needs_cancellation flip was the OLD CrmAutoTransitionStatusesJob overdue_payment.update_all (daily 05:00), which flipped confirm_payment -> needs_cancellation once invoice_sent_at was 60+ days old, skipping updated_at (the 'undated' flip and no system note) and never checking payment_confirmed_at, so it flipped three already-paid accounts too. The 2026-05-15 11:07 stamp was the invoice-SEND batch (7 accounts, incl. Leatherhead and Ilta-Sanomat), not the flip; the flip fired ~2026-07-14 (invoice_sent + 60d). Backend f527582f (main, 2026-07-19) removed that behavior: needs_cancellation is deleted from the CrmCustomer enum, unpaid invoices are no longer auto-transitioned, and overdue is derived from payment_due_by (payment_overdue?) with the row staying confirm_payment for a human to decide. So there is no re-flip risk and the eng half of issue 12 is done. See issue 12 (now resolved) and issue 13 (Visma bank feed not reconciling, why payment_confirmed_at stays null). ALSO FOUND: quantity x list variant price reproduces NO invoice, every enterprise account bills a negotiated rate the subscriptions table cannot express (VT has an add-on, Regeringskansliet has a fee and VAT, NTB and Dagbladet bill in SEK against a USD variant). Any ARR figure derived from subscriptions.quantity x variants.price is wrong by construction (F022). Visma's paid/unpaid flags are also unreliable: five invoices confirmed paid by bank still sat in 'Obetalda kundfakturor', so the bank feed is not reconciling (carded as issue 13). CORRECTION 2026-08-17 (sales-renewals W34, company/reports/sales/2026-34.md). Two claims above are wrong and were inherited by three weekly reports without anyone re-testing them. 1. Lis Zandberg's email does NOT hard-bounce. Erik emailed lis.zandberg@idmc.ch on 2026-07-19 (Gmail thread 19f7c13c8dd608ba) and she replied from that address on 2026-07-20: 'Absolutely, I will follow up with the responsible department immediately and get back to you as soon as possible.' The chase therefore went by email, not 'in Intercom' as the next action said. 28 days on, nothing has come back and inv 184 is 64 days past due. The class: a contact-channel fact recorded once under pressure and never re-checked. It expires like any other claim (rule 12a). 2. The Dagbladet seat trim is 90 to 20, not 40 to 20. subscriptions.quantity on 1496668 reads 90 against a 20-seat contract, with 32 active users on organization 5594. Whatever the admin screen showed when this card was written, the row is 70 seats over, not 20. STATUS 2026-08-17: neither half has moved. No CRM write since 2026-07-19 22:11 (29 days). No reply from db.no or aller.com since the reissue, and crm_visma_invoices is still empty (F020) so its state is not visible from the app. The CRM's own note 58 on Dagbladet ('New invoice sent with corected seat count') carries due_by 2026-08-20 and no resolved_at. IDMC's support conversation 215473594558152 is still open, waiting since 2026-06-24, 54 days, with a suggested answer sitting unsent in the thread since the day it arrived. — next: TWO left, both past end date. DAGBLADET is now the bigger one: invoice 190 (86,400 SEK) went to Aller Media's scan-only inbox 2026-07-19 and its auto-reply states that an invoice missing any of six mandatory fields is 'not processed or returned' - so 37 days of silence may mean it was deleted on arrival, not that it is queued. Check Invoice190.pdf against those six (their reference, our company info, invoice date+number, payment terms, our VAT/org no., our payment details) BEFORE chasing; reissue if it fails, chase Trym Mogen (tmog@db.no) if it passes. CRM note 58 fell due 2026-08-20. Then trim subscription 1496668 from 90 seats to 20. IDMC: $1,620 (inv 184) now 72 days overdue, Lis Zandberg silent 36 days since promising a finance follow-up, and Intercom 215473594558152 has been open 62 days with the answer already written and unsent. Her email lis.zandberg@idmc.ch WORKS (the hard-bounce claim in the notes below is wrong). Drafts for both are in company/reports/sales/2026-35.md. (Erik, Sep 1) — enterprise arr reconciliation, 2026 W29

Aug 31ErikFix Chargebee's give-up-too-fast billing retries — Audit ran 2026-07-18 (Erik, Chargebee admin UI, config applied). System was already tuned: dunning emails on for years, Account Updater on via Stripe default, 39% recovery (F017). Only material change is the retry window 5 to 21 days, plus schedule spread 2/5/9/14/21 and skip-hard-failures on. Smart Dunning declined: plan-gated, negative ROI against the ~$374/mo residue. See F021 and the 2026-07-18 addendum on the kill report. Expect a ~3-week involuntary-churn trough that is deferral, not impact. — next: Re-run company/checks/dunning-recovery.rb and compare steady-state recovery to the 39% baseline (F017), discounting the transition trough (Data, Aug 31) — failed payment recovery task killed, involuntary churn

ErikLink bookmarking via an auto-created links feed — next: Review PR #237 (on staging)

Up next 28

overdue · Jul 22EngPromo admin: pick a percentage and dates, run the summer sale — Time-boxed by summer. 2026-07-27 audit: 4 days past due with the build verifiably not started (no Promotion model on main, no PR), left overdue, every slipped week shrinks E005's summer window. Prompt's closing steps corrected (they instructed hand-editing superseded queue.md/todo.md, rule 13) and the stale queue-3/queue-item-1 numbering fixed, the card had been queue position 2 since I001 closed; moved to queue position 1 on 2026-08-08 when I002 was killed. — next: Build Phase 1 (queue-1 session); summer 50%-off-yearly test vs 13% BF benchmark (Jul 22) — promotion automation, promo decision

EngSee which cohorts produce new payers, weekly: cohorts into ChartMogul + the digest gauge — 2026-07-27 audit: status reset building to planned, no branch, PR, or artifact since the plan's Phase-3 note of 2026-07-02, and F040 already refused rock 2's on_track for exactly this. Title rewritten from 'Classification Phase 3 gauges' (rule 10). Needs a dated commitment from eng; rock 2 is judged on this card. — next: Push cohorts to ChartMogul; wire new-payers-per-cohort into the weekly digest — user classification

overdue · Jul 15CEOPricing Phase 2: the usage-ladder one-page proposal — 2026-07-27 audit: status reset building to planned, no draft, branch, or PR anywhere and the W30 CEO read treats it as not started. Date left overdue on purpose: this card blocks the ladder chain (I012, I018) and rock 0. Past due since 2026-07-15. — next: One-page ladder proposal for Erik (Jul 15) — usage based pricing

overdue · Jul 14SalesPut the 4 invisible invoiced accounts into the CRM — 2026-07-27 audit: dropped 'incl. DMJX $42K' from the title, the figure came from the seat x list method retracted 2026-07-19 (F022/F024) and was never invoice-verified; sales 2026-30 found DMJX has NO subscription row in the app DB at all (bills outside the app, or the line was never real). Still zero crm_customers rows for the four as of 2026-07-26. Past due since 2026-07-14, left overdue for visibility. — next: Create the CRM records, verifying each account against actual Visma invoices, not seat x list price (F022) (Jul 14) — enterprise arr reconciliation

FinanceMake the invoiced book visible: ChartMogul custom source + drop the 2 ghost subs — Verified missing 2026-07-17: ChartMogul has 9 sources, none invoiced. GUARDRAIL (2026-07-19, F022/F024): the per-account dollars pushed into any custom source must come from reconciled Visma invoices, not subscriptions.quantity x price, which reproduces no invoice (Dagbladet alone was ~$29K high). Importing the DB-derived book would import wrong numbers. Blocked on the Visma sync (F020). 2026-07-27 audit: next_action re-pointed, the 2026-07-19 guardrail declared the original 'create the custom source' step blocked but the field was never updated (rule 2); original 2026-07-13 date cleared with the re-point. — next: Deactivate the 2 ghost subs now; the ChartMogul custom source stays blocked on the Visma sync (F020), decide build vs park — enterprise arr reconciliation, L010 headline arr excludes invoiced enterprise book

overdue · Aug 1FinanceModel the usage-ladder cohorts: uptake, cannibalization, retention guardrails — 2026-07-25 (Erik): regional/PPP pricing is NOT part of this card. It was briefly routed here earlier the same day; Erik reversed that, PPP becomes a separate project (issue 17) and the ladder goes first. Reasoning on the record: PPP cannot be measured at any time (India is 295 plan-viewers per 180 days, F035 arithmetic), so there is no PPP learning to protect by sequencing; what sequencing protects is focus on the ladder, which is the larger prize, is already overdue, and CAN be measured on US/EU volume. The L003 cost of a second pricing event (one more grandfathered cohort) is small here because the PPP countries produce very few payers (IN 18/yr, BR 13/yr, geo report 2026-07-05). Evidence that shaped the split: F037 (IN/BR is price resistance, JP/KR/TW is not). CORRECTION 2026-07-25: an earlier version of this note called Japan 'the largest non-US signup geo'. Wrong. Japan is 3rd among non-US by signups (IN 5,025, FR 4,660, JP 4,066, geo report 2026-07-05); what is true is that it is the largest non-US market whose weak conversion is NOT explained by purchasing power. F037's own notes field carries the same slip and should be corrected next time that record is touched. — next: Cohort model for the ladder decision: uptake, cannibalization, retention guardrails. Ladder only, no regional/PPP prices in scope (Erik 2026-07-25 split PPP into its own project, sequenced after the ladder ships). (Aug 1) — usage based pricing

FinanceAnnual-renewal pre-notice: why doesn't it convert into card updates — next: Diagnose CTA/deliverability on SubscriptionMailer#upcoming_payment; decide monthly-plan variant — exit survey read, failed payment cohorts and premortem

overdue · Jul 29ProductDecide what lapsing to free should actually cost — 2026-07-27 audit: the 2026-07-21 date was missed with no note and the E003 readout never ran; the W30 CEO read set 2026-07-29, applied here (rule 2). — next: Verify enforcement actually started Jul 14 (E003's premise was never independently checked), then read the natural experiment and propose the entitlement diff (Jul 29) — failed payment cohorts and premortem

ProductOne calm pricing moment at day 0, at the end of onboarding — 2026-07-27 audit: ungated, the next_action had waited on 'after the plan-page fix ships' and I001 closed 2026-07-25. — next: Design the day-0 pricing moment; the plan-page gate resolved 2026-07-25 (I001 closed: the cliff is real, currency ruled out as the fix, F031/F034/F035) — payment mechanisms

ProductShip extension 8.0.29 and investigate the 140k disabled installs — Data seat, 2026-08-25 (F107): extension 8.0.28 mislabels its platform. Clients flipped fromPlatform chrome->firefox from the week of 2026-03-09, complete by ~2026-04-06; clients still on 7.9.0 never flipped. Monthly extension readers went chrome 14,939 -> 1,637 and firefox 191 -> 12,233 with the union flat, and 45% of March's readers were counted under both labels. This blinds every chrome-vs-firefox cut in BigQuery, and it is why the 'phantom-install era faded in Apr-Jun' reading was wrong: the 6x multiple changed labels rather than going away. Ask for 8.0.29: one grep of the platform-detection code, fix ships with the build already planned here. Second item from the same run (F106): 96-98% of app:new_install_event clients are never seen again on any event and 3.1% ever attach to a userId, so the 140k disabled-installs question and any install-to-signup rate both rest on a clientId that may not mean one browser profile. Worth establishing what mints a clientId while the build is open. — next: Ship the instrumented post-install flow — L008 extension funnel broke at post install signup step

ProductMonitoring feature audit and one-flow keyword setup — next: Audit, then the one-flow setup — monitoring experience

ProductRoot-cause the 4 bug reports mined from exit surveys — Issue 3 — next: Ticket each: folder-move data loss, signup feed-wipe, blocked Microsoft feeds, Firefox YouTube embeds — exit survey mining

EngMake every upgrade traceable to what caused it — 2026-08-25 marketing-channel-read (W35): 39 days past the original 2026-07-17 date, still planned, still no date. State of the three gaps, reporting week W34 (Aug 17-23): external source attribution still zero for a fifth consecutive week (F046 holds; all 43 distinct utm-campaign values are internal prompts, on 193 users / 12.2% of the week, read to the end of the tail rather than off a LIMIT). App-message ids improved slightly: extension_email_trial appears for the first time (1 user) alongside extension_email_continue_setup (1 user), so two of that family now fire (F044), while extension_email_paywall still tags nobody at 31 days (F082). Localized tag values unchanged and the defect is unchanged in the code: frontend/app/components/notification-settings-box/component.ts:90 still builds ${option.label} notifications from a translated label plus a hard-coded English word, and no commit has touched the file. It did NOT surface in this week's tag values, which is not the same as fixed, it only fires when a non-English user opens an upgrade prompt on one of the four notification features and none did in W34. Third week this defect has been read off tag values and the first two got it wrong in both directions, so read the code. NEW THIS WEEK, and it belongs to this initiative because it is the same instrument: signup tagging silently stopped writing for ~36 minutes on 2026-08-18, 11 consecutive signups (ids 1005195-1005205) with no signup-time tag at all, plus 10 users an hour later with country='NA', a value absent from every other week in the nine-week window. Nothing alerted. Filed separately as issue 53 (owner eng) because the fix is an alert, not tagging coverage, but it sharpens I023's premise: the attribution instrument fails by returning plausible numbers rather than an error. F121. Last week's cost statement still stands and got bigger: the Bangladesh wave reached 437 signups in W34 (743 since Aug 10) and we still cannot say from where. Evidence: company/reports/marketing/2026-W35.md. — next: Finish the tagging: extension_email_paywall arrival tag (the path E001's first conversion took, still unattributable), app-message ids, localized tag values; then scope the external arrival-attribution build (F029: 0 of ~11,400 recent signups carry utm_campaign) — extension upgrade checkpoint 1w, w28 new subscription analysis

overdue · Jul 31MarketingFeed your AI: make /mcp the hub, list in agent directories — 2026-07-27 audit: date set from the plan, P06 Phase A time-boxes directory listings + the /mcp hub to July (company/plans/ai-data-wedge.md, ratified top priority 2026-07-04); the card had sat undated while its own plan carried the deadline. 2026-08-08: Erik reprioritized this direction ('the mcp is enough. maybe if we make an official connector to claude and chatgpt') after killing I002. How-to research for the Claude and ChatGPT directory submissions is in company/reports/marketing/2026-08-08-official-connector-listings.md (PR #339): both portals' requirements, Feeder's gaps (tool annotations missing on all MCP tools; plan-gate upgrade message links to checkout, which OpenAI prohibits), and prerequisites (Claude Team/Enterprise org for the claude.ai submission portal; verified business identity on the OpenAI Platform). Eng prep is ~1-2 days before either submission. — next: Directory placements + hub page (Jul 31) — ai data wedge

MarketingChrome Web Store listing revival — next: Keywords, screenshots, own-surface install traffic — L008 extension funnel broke at post install signup step

MarketingMonitoring page and landing pages for the empty $15-199 band — next: First pages — monitoring experience

overdue · Aug 7MarketingFirst batch of AI landing pages at best-converting cohorts — 2026-08-25 marketing-channel-read (W35): card is 18 days past its 2026-08-07 date and still planned. RETRACTION FROM LAST WEEK, stated plainly because it was a stated condition: last week's note said 'leave cybersecurity out until it produces one payer' and it has now produced one. User 1005609 (US) signed up 2026-08-19 14:44 and paid by Chargebee at 15:47, 63 minutes later, inside the reporting week. Deduplicated table (273 users touching exactly one page, 2026 to Aug 23, F059): cybersecurity-teams 108/1, software-engineers 39/0, financial-services 39/2, marketing-professionals 28/2, competitor-monitoring 18/2, 12 others 41/1. The two highest-volume pages are now 147 signups / 1 payer against ~4.4 expected at the discover path's 30-day rate (3.00%, F072), so p is ~0.066, up from 0.014 last week and 0.02 the week before. That is no longer significant at any conventional threshold and three weeks of a hardening zero has reversed. F122. The ranking advice is unchanged in DIRECTION and weaker in strength: the three converting pages are 6 payers on 85 signups (7.1%) against the top two at 0.68%, a 10x gap in rate but on volumes too small to be certain of. Rank the next batch against financial-services, marketing-professionals and competitor-monitoring, but no longer exclude cybersecurity-teams. Method caveat that killed the earlier ranking still binds: page-use-case-* tags are re-applied per visit, so the table must be deduplicated to users carrying exactly one page tag (two further cybersecurity payers exist but touched several pages and are correctly excluded). Evidence: company/reports/marketing/2026-W35.md. No date proposed here, that is Erik's call on an overdue card. — next: Ship the first batch, early August (Aug 7) — ai landing pages, decision memo

overdue · Aug 5MarketingRead win-back results, then decide the churned-payer backlog campaign — 2026-08-11 (COO Level 10, W33): this card's premise is answered and the answer is "there is nothing to attribute". I028 exists to attribute the July reactivation line that W30/W31/W32 flagged three weeks running as the largest unexplained positive in the P&L. F062 settled it with one extra ChartMogul call for 2024: reactivation is in a three-year decline ($513.90 -> $364.33 -> $296.29 Jan-Jul monthly average) and July 2026's $385.66 sits below July 2025 and well below July 2024. It looked strong only against 2026's own weak start. So the dormant-nudge rock (rock 3, done as built) has no measurable win behind it, and the 30-day readout this card is waiting on (due 2026-08-05, now 6 days overdue) can be scoped much tighter or the card closed. The CEO's W33 read proposes rescope-or-close; that decision is Erik's or a reviewed CEO session's, so no status was changed here. Recording it because leaving the card reading "attribute the reactivation line" is a wrong memory (rule 1). — next: 30-day readout + framing proposal for Erik (Aug 5) — churn surfaces, marketing plate review

MarketingFind and assess the alleged PC World extension-malware article — Issue 8 — next: Find it, assess before it spreads — exit survey mining

overdue · Jul 24MarketingTurn shared dashboards into an acquisition surface — A shared dashboard produced one of W28's fastest payers. 2026-07-27 audit: the 2026-07-24 date was missed with no note; left overdue for visibility. — next: Size the channel from public-dashboard tags, then propose the play (Jul 24) — w28 new subscription analysis

SalesQualify the 475 unmonetized monitoring professionals as the warm list — next: Qualify against the Monitoring tier — monitoring professional signature

SupportShip the 48-hour-fix intake with the cancel play — next: Intercom early-cancel-save tagging + diagnosis workflow + save-rate gauge, alongside I017 — first 60 day program

overdue · Aug 1SupportMonthly voice-of-customer digest — next: First digest (Aug 1) — exit survey mining

overdue · Aug 1CEOAugust retro: judge July by new-payer production per cohort — next: Run the retro (Aug 1) — decision memo

ErikFirewall the undeclared data-service hosts (Redis incident follow-up) — 2026-07-27 audit: PR #241 closed unmerged 2026-07-18 but its iptables config is on main (statistics-db1 in servers.json + hosts/db.json, hosts/rails-worker.json), so in_review pointed reviewers at a dead PR. Both live exposures were already closed by hand; what remains is applying the managed rulesets per host and the straggler decisions. — next: Apply the generated rulesets on statistics-db1 and bhs-rails-worker1 (a default-deny rewrite, follow the PR #241 checklist), then decide the remaining undeclared hosts: bhs-web-app1/2, analytics-frontend1, docker-metabase1, dev-db

ErikTriage or close the 10 stale open PRs — 2026-07-27 audit: the old '7 stale pre-June PRs' list was wrong on both ends, #156 was opened Jun 21 (not pre-June) and genuinely old open PRs #1 #2 #4 (February) were missing. Current stale set is these 10, verified against the open-PR list 2026-07-26. — next: Close or card #1 #2 #4 #7 #36 #37 #48 #68 #103 #156 (every open PR created before July) — status check

Aug 31COOBuild a laptop CLI that runs the recurring agent jobs on the Claude subscription — 2026-07-27 audit correction: the record said 'not yet running: needs merge', but company/fleet/ is merged to main and 8 of 9 chain jobs ran manually Jul 22-25, producing the W30 report set (agents.json last_run + artifacts verified on disk). The CLI is proven end to end on the subscription; what remains is launchd wiring on Erik's machine and Phase 4. data-explorer was the one chain job skipped in the catch-up runs (issue 22). Decision 2026-07-21 (Erik): laptop CLI on the subscription, not cloud routines. Build: P17, company/plans/agent-fleet-runner.md. 2026-08-11 (COO Level 10, W33): the laptop half is DONE. launchd fires on schedule and the chain has produced a full seat report set twice (2026-08-03 on the Monday slot, 2026-08-11 a day late). What is not done is Phase 4, and it is now measured rather than theoretical. Three weeks, three failure modes, all needing a human to recover: 2026-07-27 data-explorer crashed and stop-on-fail dropped five seats (issue 22, F061); 2026-08-10 the fire and its retry both died on 'OAuth session expired and could not be refreshed' and a Tuesday 04:14 attempt died on laptop sleep. F061's retry-once fix fired correctly on 2026-08-10 and bought nothing, because expired auth is not transient. The notifier failed both weeks, so the dead-man's switch that makes silence mean 'broken' is itself broken. An unattended fleet would still be dark today. Dated to 2026-08-17 by this run: this is the COO seat's own card and it is the one thing on the board this seat can date without asking anyone. 2026-08-17 (COO Level 10, W34): the date was missed and the card is re-dated to 2026-08-24, which is the next chain. Recorded plainly because this is this seat's own card and it dated itself. What happened instead: all eight Monday jobs fired in their own slots on the first attempt, no retry, no OAuth wall, no sleep abort. fleet.mjs has not changed a byte since 2026-08-11 09:46, so none of the three pieces exists and nothing about today is repeatable. One further measurement worth keeping, because it is the half people will assume today settled: the notifier was NOT exercised. No seat wrote a signal file (all eight declined on the notify-policy bar), so the '[notify] post failed: fetch failed' path that broke on two consecutive Mondays was never called today. Today is evidence about the OAuth coin toss only, and it came up heads. It is evidence about the dead-man's switch of exactly zero. 2026-08-25 (COO Level 10, W35): re-dated to 2026-08-31 and Phase 4 corrected. The 2026-08-24 date passed and that is the day the chain parked: the revenue digest failed twice (529, then timeout) and stop-on-fail took all 8 downstream seats with it (F105, issue 50). Fourth of the last five Mondays needing a human to recover. CORRECTION to the 2026-08-11 block above, which two weekly reads inherited without re-testing. 'The notifier failed both weeks, so the dead-man's switch is itself broken. An unattended fleet would still be dark today' is WRONG (F125). runList() awaits notifyRun() before the stop-on-fail exit (fleet.mjs:389), notify.json carries a live bot token with heartbeat_channel #fleet-log, and every Slack failure path logs to stderr. The 2026-08-24 block of launchd.err.log (lines 37-40) has the two digest failures, the retry and the stop-on-fail, and NO [notify] line. So Slack received 'Fleet 2026-08-24: 0 ok, 1 failed - weekly-revenue-digest: API Error: 529 Overloaded'. The single '[notify] post failed: fetch failed' in that file sits in the older working-tree-dirty block. Method caveat: inferred from the absence of a logged failure on a path where every failure logs, not from reading Slack. Second correction, same class: stale signal files ARE cleared. runJob() unlinks signals/<id>.json before the job runs (fleet.mjs:338). A signal outlives its week only when its own job does not run, which is exactly why coo-level10.json from 2026-08-17 was still on disk on 2026-08-25. What this changes: Phase 4 item 2 is retired as already built, and replaced by the rung above it. A parked chain is one line in a log channel, indistinguishable from a normal day, and the only tier that rings a phone requires a job to write its own signal file, which a job that died on a 529 cannot do. The runner already knows a job exited non-zero; it tells the wrong channel. Issue 50's two smaller changes (continue-on-fail, move the API-heaviest job out of order 1) are sequenced ahead of all of Phase 4, because they are what actually cost the company the 2026-08-24 read. — next: Phase 4, one item retired and one sharpened by F125. (1) A preflight auth check that verifies the Claude OAuth session before the 04:00 chain and pages while it can still be refreshed, since retry-once cannot clear an expired session. (2) RETIRED, the notifier path already works: notifyRun() is awaited before the stop-on-fail exit and the heartbeat posted the 529 to #fleet-log on 2026-08-24. Replaced by escalation: post to the page tier when any job in a run-due chain exits non-zero, since the runner already knows and only tells the wrong channel. (3) The .claude/settings.json tool allowlist for unattended runs. Ship issue 50's two smaller changes first, continue-on-fail and moving the API-heaviest job out of order 1, because they are what actually cost the company the 2026-08-24 read. (Erik, Aug 31) — status check

overdue · Jul 24SalesEnterprise outbound and renewal machine, the 32 churned logos plus lookalikes — Both strategy takes rank this first: the only proven engine at $1M density; target 6 new logos in 12 months. 2026-07-27 audit: the 2026-07-24 ratification date was missed with no note (left overdue, the decision is Erik's). Before ratifying, re-read section 5 against F022/F023/F024: parts of the enterprise numbers the strategy review leans on were retracted 2026-07-19, two days after it was written. — next: Erik ratifies (strategy review section 5); then agents draft ~10 notes/wk, Erik sends (~2h/wk), 3-tier price sheet (Erik, Jul 24) — 1m arr strategy review, enterprise arr reconciliation

Done 0

One line per card: status dot, money and date chips, the work, the doc behind it — click to unfold. A red chip means a dated card slipped past today. Source: company/state/initiatives.json (edit the record, rebuild — see the schema).

Experiments

every live test with its readout schedule — a missed readout goes red instead of being forgotten

Product E001 Extension upgrade one-pager: offer, payment on page, 7-day trial · running Jul 7 ✓ Jul 12 ✓ Jul 15 ✓ Jul 23 ✓ Jul 25 ✓ Aug 2 ✓ Aug 30

A single-page offer at the email-verify moment converts extension email users to paid at >=1.5%
Premise (2026-08-25): The one-pager is live, instrumented, and can convert end to end
Gauges: verified -> offer view -> checkout open -> paid · trial email open/click
Next readout: Aug 30
Weekly pulse runs on the laptop fleet. Week 4 (2026-08-03) answered the design-call question with a number: the funnel leaks at the offer step. 156 verified users reached the offer page, 3 ever opened Chargebee, 1 paid; checkout is fine, the page is the wall. The trial is the strongest engagement signal in the experiment (59.4% open, 19.4% click) and has converted nobody, which points the redesign at the page and the ask rather than at interest - the experiment doc's own fallback (free first feed, paid from the second) is the obvious A/B and need not wait for week 8. Metric guidance CHANGED at week 4: do not ship the day-20 recommendation (is_active=1 AND updated_at in window) - it overcounts renewals and other-channel payments. Anchor on funnel entry instead: denominator = users tagged upgrade-experience-view email-updates:offer, numerator = those reaching chargebee_checkout thankyou_screen within 30 days. Query in the week-4 report. Also note subscriptions.type IN (...) is load-bearing because free/trial/coupon rows are is_active=1. W27's 30-day window closes 2026-08-04, so the week-5 run is the first with a closed cohort. Floor check is already off pace without a closed window: 1 payer in 29 days annualizes to ~13/yr against the ~60/yr bar (old flow ~6/yr); the week-8 check is due ~2026-08-30. Attribution still unfixed: confirm-page arrival does not tag, so $0 is attributable in ChartMogul against $7.99/mo actual (I023). New defect found: 18 users got both a trial email and the day-3 reminder, which the design forbids (issue 27). See F053 (supersedes F044 via the corrupt F052). · extension upgrade experience

Product E002 AI onboarding A/B, agent-led setup vs manual · decided Jul 26 ✓ Aug 1 ✓

Agent-led onboarding lifts week-1 activation enough to justify cost
Premise (2026-07-03): 50/50 split with exposure tagging is live
Gauges: week-1 activation (2nd day return + 10 posts) · day-7/14 retention
Decided 2026-08-03, two days past the Aug 1 date. Power was met (2.0k/arm vs the ~1.9k July estimated). Randomization is clean: tag fires ~1.4s after signup in both arms, 50/50 every week, all tagged users are new accounts, arms balance on acquisition platform. Two instrumentation lessons for the next experiment: (1) post_reads contains system-generated rows (F051) - sanity-check the denominator distribution before computing any arm comparison; (2) the arm tag carries a null value, but exposure IS instrumented elsewhere and two runs missed it - see below. Amended 2026-08-11 (data-explorer runs on the same day, F064 then F065/F066). The DO NOT SHIP verdict is unchanged; its stated mechanism is corrected twice over. Run #6 said the deficit was that non-engagers are left with fewer feeds than the manual flow gives. F064 killed that premise (equal feed counts at hour 1). F065 killed the reading that the agent failed to reach them: post-signup-saw-ai-onboarding, written on every first reader load since 2026-06-25, shows 96.1% of the arm had the chat pane render. The drop-off is a blank-prompt bounce, not routing - 66.3% saw it and typed nothing, flat across seven weeks and seven locales, and 55% of the 776 who typed sent exactly one message. F066 prices the fallback: ceiling 12.31% vs control's 11.44% (p=0.33), honest estimate parity, and the type rate would have to reach 54.6% to tie. On the larger cohort (2,557 vs 2,562, tagged through 2026-08-04) the ITT gap has narrowed to -14.9%, p=0.048, and ever-paid is 18 vs 15 with the sign now the AI arm's. The open question moved to I005: the routing, not the fallback. Amended 2026-08-17 (data-explorer run #8, F078). The routing question is now answered too, and it does not rescue the arm. Cut on everything observable BEFORE the chat renders, there is no segment where the AI arm wins: seven cuts, seven negative, five world regions out of five (one-sided sign test p=0.031). The strongest pre-chat predictor of typing is the browser extension being installed at signup (34.3% type rate vs 26.0%, z=5.2), and that segment carries the arm's LARGEST deficit (10.40% vs 13.02%), not a win; across regions the correlation between type rate and deficit is rho=-0.70. So the entry screen cannot be saved by routing, and the type rate is not established as the lever - the 14.56% typers-vs-7.64% never-typers gap that motivates the example-chips fix is post-randomization selection, and the segment-level evidence points the other way. Third instrumentation lesson for the next experiment: whether a message was volunteered or prompted by a chip must be tagged at write time, or the chips can never be read out. · ai onboarding ab readout

Product E003 Rules-gating natural experiment: do paused rules convert holders to paid · running Jul 21 missed

Enforcement converts some of the 8,417 noticed users (42 involuntary-churn holders watched closely) instead of just pausing rules
Premise (2026-07-17): Enforcement began Jul 14 after the notice to 8,417 on Jul 7
Gauges: rules paused count, upgrades among noticed users · churn spike watch
Next readout: Jul 21
W29 digest flagged a Jul 13-16 churn clump (-$60/day vs -$31): the readout must separate enforcement-driven cancels from noise. 2026-07-27 audit: the Jul 21 readout is 6 days overdue and still open; I016 owns it (re-dated 2026-07-29 per the W30 CEO read) and its step 1 is verifying enforcement actually started, which this record's own premise flags as unverified. · rules execution gating

Marketing E004 Email-update upsell campaign to the 6,746 · decided Jul 20 ✓

A warm one-off converts 0.5-3% of grandfathered email-update users to paid ($125-750/mo)
Premise (2026-07-17): Campaign merged, console-gated, nothing sends without Erik; audience 6,746 verified against real deliveries
Gauges: open/click/upgrade, tagged extension-email-upsell · unsubscribe/complaint rate
Jul 20 readout row = the send decision itself; after a send, add T+7d and T+30d rows. Premortem pre-registers the failure modes. 2026-07-27 audit: closed as decided, the decision happened 2026-07-21 (I035 killed) but this record was never updated (rule 2). · extension email upsell premortem

Eng E005 Summer promo: 50% off yearly vs the 13% Black Friday benchmark · pending

A summer promo run through the new promo admin converts at a meaningful fraction of BF's 13%
Premise (2026-07-18): Running a promo today requires a code deploy (hardcoded BLACKFRIDAY deal id), so the admin must ship first
Gauges: per-promo conversion tagging
Time-boxed by summer; blocked on queue item 2 (I003). Queue renumbered when I001 closed 2026-07-25; stale 'queue 3' references corrected by the 2026-07-27 audit. · promotion automation

The numbers

94 registered findings — cite the id, never restate the value; freshness = re-run the check (company/checks/)

id	What	Value	As of	Verify
`F001`	Self-serve MRR	$27,980	2026-07-16	method · source
`F003`	June 2026 net new MRR, closed	-$519	2026-07-17	method · source
`F004`	Self-serve customer churn per month	~4.5%	2026-07-02	method · source
`F005`	Self-serve paying customers	2,061	2026-07-16	method · source
`F006`	True company ARR including the invoiced book	$433-492K	2026-07-10	method · source
`F009`	New-payer production pace	778/yr (2025) vs ~1,100/yr needed to replace churn	2026-07-02	method · source
`F010`	Extension email-update upsell audience	6,746 free users with a real delivery in 45 days	2026-07-09	method · source
`F011`	Upsell campaign expected revenue	$125-750/mo (0.5-3% conversion band)	2026-07-10	method · source
`F012`	Plan-page cliff fix expected revenue	$300-450/mo	2026-07-03	method · source
`F014`	MCP weekly active token users	27 (Jul 10-17), up from 5 the week before	2026-07-17	`mcp-weekly-actives.sql` · source
`F015`	Rules-gating notice audience	8,417 users emailed 2026-07-07	2026-07-07	method · source
`F016`	Involuntary share of self-serve churn	27% of cancels; 1 in 284 recovers post-cancel	2026-07-04	method · source
`F017`	Chargebee dunning recovery rate	39% of dunned invoices recover	2026-07-09	method · source
`F018`	Enterprise average contract value	$9.2K/yr across the 11 current accounts	2026-07-10	method · source
`F019`	Early-churn root cause split	50% of first-60-day cancel free texts describe product failure	2026-07-10	method · source
`F020`	Invoiced revenue is not machine-derivable from the app DB	naive sum = $551K vs real ~$163K/yr (3.4x off)	2026-07-18	method · source
`F021`	Dunning audit (I013): the only lever was the retry window	Retry window 5 to 21 days, schedule 2/5/9/14/21, skip-hard-failures on; emails already on for years, Account Updater on via Stripe default, Smart Dunning plan-gated and declined	2026-07-18	`dunning-recovery.rb` · source
`F022`	Enterprise ARR cannot be derived from subscriptions.quantity x variants.price: every invoiced enterprise account bills a negotiated rate the subscriptions table cannot express, so any figure computed that way is wrong by construction	Dagbladet alone was overstated by ~$29K (booked $37.8K/yr, actual contract 86,400 SEK ~ $9K)	2026-07-19	method · source
`F023`	Enterprise renewal "limbo", reconciled account by account (I009)	The $58.6K/yr limbo does not survive: none of the five past-due CRM accounts needed cancelling. NTB, Regeringskansliet and Virginia Tech were already paid (bank-confirmed); IDMC ($1,620, inv 184) is the one genuinely open invoice; Dagbladet was credited and reissued 2026-07-19 (86,400 SEK). Actual outstanding = $1,620 + the Dagbladet reissue.	2026-07-19	method · source
`F024`	Invoiced enterprise book total, Jul 10 figure retracted as method-unsafe	The $163,163/yr book is not a trustworthy number: it was summed from subscriptions.quantity x list/seat price, which reproduces no actual invoice (F022). The one line checked hardest, Dagbladet, was ~$29K too high. Only the five past-due accounts are reconciled to real invoices; a reliable total needs per-account Visma figures and is blocked on the Visma sync (F020).	2026-07-19	method · source
`F025`	AI-feed gating notice audience (AiFeedGatingNoticeCampaign), scoped to match the copy	60 recipients — users who had a paid plan that ended and now carry no ai_source entitlement. The as-shipped predicate (count_ai_feeds > any cap) would have sent to 174: +107 current free users over the free allowance of 3, +2 grandfathered accounts over the general feed cap, whom the "when your paid plan ended, an error kept your AI feeds running free" copy misdescribes. 0 of the 174 are currently paying.	2026-07-20	`ai-feed-gating-audience.rb` · source
`F028`	July 2026 net new MRR, month to date	-$165 MTD through 2026-07-24 (machine pull); -$115 through Jul 22 in the W30 finance digest	2026-07-24	method · source
`F029`	New-signup acquisition attribution coverage (product DB)	0 of ~11,400 signups (ISO wks 2026-21..29) carry utm_campaign; 18 carry any utm_ param; ~42% land in an unattributable web bucket (no source; ~31% empty query string). Only extension, native app, follow-links and use-case pages self-tag. The user_classifications acquisition_platform/path dimensions are a one-time ~2026-07-01 backfill: 100% through wk26, 47% wk27, 0% for wks 28-30, so new signups are unclassified.	2026-07-24	method · source
`F030`	Extension is the largest signup channel and the weakest per-signup converter	~42% of weekly signups (499 of 1,178 in wk2026-29) yet ~0.30% ever-paid (9 of 3,008, wks 20-25 signup cohort at 4-10 weeks maturity) vs ~0.93% for web (30 of 3,230) and ~0.82% native app; directional, small paid n	2026-07-24	method · source
`F031`	Non-USD converts on the plan page at ~half the USD rate, and the entire gap is at plan-view to checkout-open, not checkout-to-paid	view→paid 4.9% non-USD vs 10.2% USD (48%); view→checkout 6.85% vs 13.55%; checkout→paid 71.6% vs 74.9%; non-USD = 74% of 6,771 viewers. Worst currencies: JPY/KRW/TWD 2-4%, EUR 5.3% on biggest non-USD volume; GBP/CAD near USD	2026-07-24	`plan-page-currency-cliff.sql` · source
`F032`	Most new web subscribers pick monthly, not annual, despite yearly being the coded default	monthly 215 (72%) vs annual 82 (28%), new chargebee paid subs, last 180d	2026-07-24	method · source
`F033`	Pre-change baseline: marketing pricing-page viewers who signed up converted to paid at ~the same rate for non-USD and USD, because pre-change everyone saw USD prices there (no currency-display variation to create a gap)	signup→paid: non-USD 4.17% (46/1,102) vs USD 4.06% (16/394); marketing-page viewers registered 2026-04-25..07-23, pre-deploy	2026-07-24	method · source
`F034`	Historical natural experiment: showing localized pricing (pre-v4, before the 2023-03 launch) did NOT improve non-USD conversion. The non-USD/USD conversion gap was WIDER when prices were localized than after the switch to USD-only	non-USD as % of USD conversion (pricing-page viewer -> paid within 30d): localized era 2021=40%, 2022=35%; USD-only era 2024=65%, 2025=66%, 2026=70%. Step change at the 2023-03 v4 launch	2026-07-24	method · source
`F035`	The currency A/B cannot produce a verdict quickly: at current plan-surface volume it needs ~6 months for a large effect and ~2 years for the effect size actually in dispute	~43 tagged users/day (~21/arm). Detecting 1.9% vs 2.4% (0.5pt, the disputed size) needs ~13,000/arm ≈ 2 years; a large effect (2.4%→3.6%) needs ~3,000/arm ≈ 6 months	2026-07-25	method · source
`F037`	The low-converting non-US markets are two different problems, not one: India and Brazil open checkout at normal rates then abandon at payment (price resistance), while Japan, Korea and Taiwan rarely open checkout at all (a problem upstream of price)	checkout-open rate IN 6.4%, BR 6.7% (vs EUR 6.9%, USD 13.6%) but checkout→paid only ~50% (IN 10/19, BR 9/19) vs ~75% USD/EUR. JP 2.2%, KR 3.8%, TW 2.5% checkout-open on 364/183/119 viewers	2026-07-25	method · source
`F038`	Feed-delivery health cannot be measured from the app DB: feeds.health_state and feeds.last_ok_at are both demonstrably unreliable, so breakage (the top support theme) has no metric behind it	Naive reads are unusable: 149,861 subscribed feeds / 237,573 subscriptions sit in health_state='error', and 649,151 feeds / 1,120,834 subscriptions (63%) have last_ok_at older than 30 days. Neither is a breakage rate. Proof: feed 1192 (WIRED, 441 subscribers) is health_state='error' with last_ok_at 2026-07-25 14:50 and last_health_update_at 14:54, i.e. the health updater ran 4 minutes after a success and still wrote 'error'; feed 142833 has last_ok_at Jul 22 but latest_post Jul 24, so last_ok_at trails real successful crawls.	2026-07-25	method · source
`F039`	F019's first-60-day product-failure split cannot be tracked on a weekly cadence: paid cancels inside 60 days arrive at ~2 a week, so weekly reason mixes are noise	2.2 first-60-day paid cancels per week (29 of 157 paid-cancel surveys in the 90 days to 2026-07-25, 18.5%); 12.1 paid-cancel surveys per week overall. Week 2026-30: 2 of 13. Week 2026-29: 3 of 15. Detecting a 50%-vs-20% reason split needs ~8 weeks of accumulation, not one.	2026-07-25	method · source
`F041`	July 2026 decision quality: the L013 test passed and the follow-through failed. Zero symptom patches shipped and five pieces of work killed or retracted on their own evidence, while every root cause the month identified sits on a product card with no date	0 symptom patches shipped; 5 evidence-based kills/retractions; 6 named root causes on cards with next_action.date = null, unmoved for 15 days; net new MRR -$94 MTD through 2026-07-25	2026-07-25	method · source
`F043`	ChartMogul restates recent months upward for weeks after close, so any partial-month net new MRR read is biased low and week-over-week diffs between digests are meaningless.	June 2026 net new MRR read -$556 at the Jul 2 close, -$508 on Jul 22, -$499 on Jul 27: +$57 revision in 25 days. June MRR $27,647 -> $28,156 (+1.8%); June customers 2,029 -> 2,081 (+52). Year-old months drift about half as much (Jun 2025 MRR +0.8% over the same 25 days), so this is late-arriving billing data on a rolling re-import, not a one-time correction. Concretely: W30 flagged a possible new-business cliff from $49 landing Jul 17-22; the same window re-pulled on Jul 27 reads $59.41.	2026-07-27	method · source
`F045`	Paid conversion of new signups by arrival path, 8-week cohort	Discover/use-case pages 3.23% (5 payers / 155 signups); bundle 3.13% (1/32); organic residual 0.66% (39/5,865); extension install 0.29% (10/3,396). A use-case-page signup is worth ~4.9x an organic one and ~11x an extension one.	2026-07-25	`acquisition-path-weekly.sql` · source
`F046`	External acquisition source attribution on new signups	Zero. All 166 distinct utm-campaign values recorded across 9 weeks are internal upgrade prompts (settings_banner_v3, upgrade-dialog_v2_, extension_subscribe_manage, post_max_posts, rss_export). No external source is captured anywhere, and no table stores an arrival referrer. Arrival path coverage is by contrast 99.93% (only 7 of 9,455 signups carry no signup- tag).	2026-07-25	`acquisition-path-weekly.sql` · source
`F047`	New-payer production (first-time payers per month, app DB) through the July 2026 close. The three-year slide is now visible across a 31-month series: this is not a 2026 anomaly but the third and largest step down. Acquisition gauge that cannot restate, unlike ChartMogul new-business MRR.	2026 Jan-Jul: 387 first-time payers (55.3/mo) vs 574 in 2025 (82.0/mo) and 598 in 2024 (85.4/mo), -33% YoY. Annual: 2024 = 1,012 (84.3/mo), 2025 = 937 (78.1/mo), 2026 pacing ~663/yr against the ~1,100/yr needed to replace churn. July 2026 closed at 48 (W31's 26-day partial read 38, ~45/mo pace) vs 87 in July 2025, -45%. The four weakest months in the series are all 2026: May 42, Jul 48, Jun 49, Jan/Mar 57. ChartMogul agrees independently: new-business MRR Jan-Jul averaged $1,097.70/mo in 2025 vs $813.57/mo in 2026, -25.9%. Count falls faster than dollars because new-business MRR per first-time payer rose $13.39 -> $14.72 (+9.9%): price is holding, volume is not.	2026-08-03	`new-payer-production.sql` · source
`F049`	Assignment to AI onboarding lowers week-1 activation versus the manual flow (E002 intention-to-treat, week-1 window closed, activation = 2+ active days and 10+ posts read, counting only reads logged >60s after signup)	9.35% AI (187/2,001) vs 11.74% control (233/1,985); -20.4% relative, z=2.46, p=0.014. Ever-paid flat: 13 vs 13 (0.650% vs 0.655%)	2026-08-03	method · source
`F051`	post_reads contains system-generated rows: the manual onboarding marks ~6 default-feed posts read within 10 seconds of signup, so any activation metric built on it counts the product's writes as user behavior	Control arm: 1,913 of its week-1 reads land within 10s of signup and 6 distinct posts account for the first read of 1,959 users (1,845 within 10s). AI arm: 159 such reads, 534 distinct first posts, mean 12.5h to first read. Worth ~+0.9 free reads per control user	2026-08-03	method · source
`F054`	DMJX was a 100-seat, 2-month student pilot that expired 2026-06-10, not a $42,000/yr contract. The customer deferred the renewal decision to "after the summer holidays" pending an internal evaluation, and that window is open now.	100 seats for 2 months from 2026-04-10 at $500/month, $1,000 total. 46 of the 100 seats were taken up. Against the 2026-07-10 reconciliation's DMJX line of $42,000/yr (100 x $420 list) that is a ~42x overstatement, the largest single instance of the F022 method error. NOT invoice-verified: the $500/month figure comes from an internal assistant note inside Intercom conversation 215473642151758, reconstructed from the thread, and crm_visma_invoices is still empty (F020).	2026-08-03	method · source
`F055`	Joining subscriptions to organizations by organization_id silently drops live invoice contracts: the column is NULL whenever the subscription row is written before the organization row, which is what the admin team-creation flow does. Any account identified that way disappears from the result without erroring.	2 of 22 active invoice subscriptions are orphaned this way, and they are the two the renewal gauge most needed: DMJX (subscription 1784188, 100 seats, the largest seat count in the book, expired, no CRM record) and DW (subscription 1770754, 5 seats, the one account the CRM has no end date for). Separately, 8 of the 22 have no crm_customers record at all, so the CRM-first renewal check cannot see them either. Re-run: company/checks/renewal-coverage.sql — expected 22 rows, 8 with NULL crm_id, 2 with orphaned_sub = 1.	2026-08-03	`renewal-coverage.sql` · source
`F057`	Top-of-funnel signup volume is down 24% year over year and has been year-over-year negative for 13 straight months, with the gap widening. This is the volume half of the acquisition problem F047 measures downstream in payers.	Jan-Jul signups: 2024 = 52,752; 2025 = 54,514 (+3.3%); 2026 = 41,433 (-24.0%). Monthly YoY 2026 vs 2025: Jan -17.4%, Feb -21.2%, Mar -22.7%, Apr -24.1%, May -23.9%, Jun -28.6%, Jul -31.7%. July 2026 (5,102) is the weakest month in the three-year series. The series went YoY negative in July 2025 (-3.0%) and has stayed negative every month since, deepening roughly tenfold.	2026-08-03	`acquisition-path-weekly.sql` · source
`F058`	The browser-extension channel is the concentrated cause of the acquisition decline: it is 37% of signup volume but 59% of the lost signups and 63% of the lost payers. It is shrinking and converting worse at the same time, while organic conversion is flat.	Signups Jan-Jul, 2025 to 2026: extension 23,137 to 15,407 (-33.4%, -7,730); organic residual 31,359 to 25,683 (-18.1%, -5,676); discover/use-case 9 to 335 (new). 30-day paid conversion, Jan-Jun both years (like-for-like window): extension 0.611% (121/19,810) to 0.400% (54/13,493), -34.5% relative, z=2.7, p~0.007, payer output 121 to 54 (-55%); organic 0.779% (212/27,219) to 0.739% (167/22,586), z=0.5, not significant; total 0.710% (334/47,045) to 0.628% (228/36,331). The 32% total payer decline decomposes as -22.8% volume x -11.6% conversion.	2026-08-03	`acquisition-path-weekly.sql` · source
`F059`	The per-page use-case landing page ranking was measured wrong, and corrected it says something different: the two highest-volume pages have produced zero payers. Volume rank is not payer rank.	Deduplicated to the 241 users who touched exactly one page (2026 Jan-Jul): cybersecurity-teams 95 signups / 0 payers; software-engineers 35 / 0; financial-services 35 / 2; marketing-professionals 23 / 2; competitor-monitoring 16 / 2; the other 12 pages 37 / 1 combined. Top five out-produce the tail ~13x per page on signups and ~14x on payers, not the 28x reported in W30. Path level the use-case pages remain the best acquisition path: 293 signups / 11 payers = 3.75%, against organic 0.77% (201/25,970) and extension 0.42% (66/15,555).	2026-08-03	`acquisition-path-weekly.sql` · source
`F061`	The laptop fleet was dark for seven days and nothing reported it: data-explorer crashed mid-run 2026-07-27 leaving untracked files, the runner's dirty-tree guard then aborted every scheduled fire until a human re-ran the chain by hand on 2026-08-03 at 20:57, and the notifier failed too. The shipped fix 4c9de98c4 (retry once) addresses stop-on-fail, which cost the five W31 reports, but prevents none of the six dirty-tree aborts; the fix that mattered, discardWorkspace, shipped unremarked and is untested against a real crash. Corollary: every 2026-08-03 artifact came from hand re-runs, so the finance, ceo and coo W32 claims of firing in the Monday slot are wrong (rule 1).	7 consecutive days dark, 2026-07-27 to 2026-08-03; 6 scheduled fires aborted at job one; 0 artifacts from a scheduled fire	2026-08-03	method · source
`F062`	Reactivation MRR is in a three-year decline, not a program win. Jan-Jul monthly average: $513.90 (2024) -> $364.33 (2025) -> $296.29 (2026). July 2026's $385.66, which W30/W31/W32 flagged three weeks running as the largest unexplained positive in the P&L, is BELOW July 2025 ($427.56) and well below July 2024 ($610.48). The apparent strength was an artifact of benchmarking the line against 2026's own weak start instead of the like-for-like prior year. Expansion is worse: Jan-Jul average $521.45 -> $333.52 -> $127.68, down 76% in two years, the steepest fall of any movement line.	Reactivation Jan-Jul avg $296.29/mo in 2026 vs $364.33 (2025) and $513.90 (2024); expansion $127.68 vs $333.52 and $521.45	2026-08-11	method · source
`F064`	Feeds added on a user's behalf do not read like feeds a user chose. Holding hour-1 feed count fixed, the AI-onboarding arm activates below the manual-flow arm in every feed bucket, so the arm's one win (more feeds) buys far less activation per feed. The premise that the AI arm's non-engagers are left with fewer feeds than the manual flow gives is false: they hold the same feed distribution as control.	E002 cohort tagged 2026-06-25 to 2026-08-04, week 1 closed, 2,491 AI vs 2,496 control. Feeds at 1 hour: AI never-talked 5.95 vs control 5.94 (at 60s: 1.33 vs 1.38); system seed feed 4917223 "Introduction to Feeder" reaches 82.7% of never-talked and 83.2% of control. Activation by hour-1 feed bucket, AI arm vs control: 0 feeds 11.86% vs 18.75% (n=59/80); 1-2 4.67% vs 5.04% (1,583/1,767); 3-5 15.61% vs 24.92% (301/325); 6-10 16.67% vs 30.57% (246/157); 11+ 24.83% vs 33.53% (302/167). Standardizing the AI arm's feed distribution at control's within-bucket rates gives 13.74% expected against 9.80% actual; the reverse standardization puts control at 8.43% against 11.58% actual. Share reading nothing in week 1 is equal (53.3% AI vs 52.0% control), so the arm does not bounce more users, it produces shallower readers (mean 9.91 vs 11.65 reads). ITT on this larger cohort: 9.80% vs 11.58%, -15.4% relative, z=2.04, p=0.042 (was -20.4%, p=0.014 on run #6's smaller cohort). Ever-paid 18 vs 14, p=0.47, no signal.	2026-08-11	method · source
`F065`	The AI onboarding drop-off is not a reach failure: 96.1% of the arm had the chat pane render in front of them and then two in three typed nothing. Exposure has been instrumented since the day the A/B started, correcting F064's corollary that the 69% drop-off "cannot be sized at all".	E002 AI arm tagged 2026-06-25 to 2026-08-04, n=2,557: 2,456 (96.1%) carry post-signup-saw-ai-onboarding, 36 (1.4%) carry post-signup-did-not-see-ai-onboarding, 65 (2.5%) carry neither. 776 (30.3%) sent >=1 message, 352 (13.8%) sent >=2, and 424 of the 776 sent exactly one and never replied. 1,696 (66.3%) saw the pane and never typed. Type rate flat across seven weeks (25.1-35.5%) and across all seven locales with n>=50 (25.8% en-to-fr range, en 29.1%, fr 41.5%).	2026-08-11	method · source
`F066`	A fallback from the AI onboarding to the manual flow cannot make E002 a winner. Its arithmetic ceiling is a statistically undetectable +0.9pp and its honest estimate is exact parity, so the fallback is damage control, not a lever. The only other lever, the type rate, would have to nearly double just to tie.	E002 cohort tagged 2026-06-25 to 2026-08-04, week 1 closed, 2,557 AI vs 2,562 control. ITT activation 9.74% (249) vs 11.44% (293), -14.9% relative, z=1.97, p=0.048 (run #6 measured -20.4%, p=0.014 on a smaller cohort). Ever-paid 18 vs 15, z=0.53, p=0.60, no signal and the sign is now the AI arm's. Ceiling case, every non-typer given control's rate: 12.31% vs 11.44%, z=0.97, p=0.33. Decomposing control at the arm's own composition and assuming the agent does nothing for typers puts control's latent non-typers at 10.11% against the AI non-typers' 7.55%, so a full fallback returns the arm to 11.44%, parity by construction. Type rate needed to tie control with both subgroup rates held fixed: 54.6%, against 30.3% today.	2026-08-11	method · source
`F069`	The unidentified 15-seat invoiced account recorded as "My Team" since the 2026-07-10 reconciliation is the University of Wisconsin Foundation (supportuw.org). That closes the last unknown on the list of paying accounts with no CRM record; all eight now have a named billing owner.	"My Team" = supportuw.org, 15 seats, 14 used, billing owner joshua.krueger@supportuw.org. 8 of 22 active invoice subscriptions still have no CRM record, unchanged in count since 2026-08-03.	2026-08-11	method · source
`F071`	We tell customers "there is nothing we can do on our end" for failures that are ours: the shipped firewall copy denies a proxy escape hatch that 1,708 feeds run on today	1,708 feeds carry a successful proxy fix (1,125 healthy now); 1,696 of the 5,220 feeds in this week's breakage emails already have a feed_fixes row (770 success, 547 failed)	2026-08-11	method · source
`F072`	The acquisition decline has broadened beyond the browser extension. Over the last eight weeks organic is 51% of lost signup volume, level with the extension's 53%, where Jan-Jul had it at 43% vs 59% (F058). Split by quarter, organic's 30-day paid conversion is the best of the last four quarters, so organic is a pure traffic problem, while the extension's conversion drop resolves into a single step between 2025 Q2 and 2026 Q1 rather than a continuing slide.	Eight ISO weeks W25-W32, 2025 to 2026: organic 7,630 to 5,519 (-27.7%, -2,111); extension 5,583 to 3,356 (-39.9%, -2,227); discover 3 to 139; bundle 0 to 25; total 13,216 to 9,042 (-31.6%, -4,174). Jan-Jul gaps were organic -18.1% and extension -33.4%, so both widened and organic widened more. 30-day paid conversion by signup quarter: organic 0.798% (115/14,414) 2025Q1, 0.758% (97/12,805) 2025Q2, 0.680% (86/12,650) 2026Q1, 0.815% (81/9,935) 2026Q2, all four within noise, 2026Q2 vs 2025Q2 z=0.5. Extension 0.645% (69/10,699), 0.571% (52/9,111), 0.382% (28/7,339), 0.423% (26/6,153); 2026Q1 vs 2025Q1 z=2.4, p~0.018; 2026Q2 vs 2025Q2 z=1.3, not significant alone. Discover/bundle 2026Q2 3.004% (7/233), 3.7x organic and 7.1x extension. At 2026Q2's blended 0.698%, the 4,174 lost signups are worth ~29 first-month payers per eight weeks (63 expected from 2026's volume vs 92 from 2025's).	2026-08-11	`acquisition-path-weekly.sql` · source
`F073`	Organic signups broke their seasonal pattern in week 2026-W32, the first week-shaped move in three months of channel reads. Organic W32 is flat against its own prior six weeks in both 2024 and 2025 and fell 11.5% in 2026. The extension did not move off-pattern in the same week, so the anomaly is organic-only. One week of evidence: name it, do not act on it until W33 confirms or retires it.	W32 against the mean of that year's W26-W31. Total: 2024 +2.4% (1,723 vs 1,681.8), 2025 -4.0% (1,584 vs 1,650.8), 2026 -9.6% (1,029 vs 1,138.0). Organic: 2024 -0.4% (1,039 vs 1,043.7), 2025 +2.2% (957 vs 936.7), 2026 -11.5% (615 vs 694.7). Extension: 2025 -12.1% (627 vs 713.7), 2026 -5.7% (399 vs 423.2); 2024 unusable, the series has a path-reclassification discontinuity at W26-W27. Against the two-year seasonal shape organic W32 2026 should have been ~701 and came in at 615, a shortfall of 86 on a weekly sd of 35 (~3 sigma, p~0.001).	2026-08-11	`acquisition-path-weekly.sql` · source
`F074`	Q3 2026 rock status at day 42 of 92, judged with no partial credit. The same 2 of 7 rocks are defensible for the third consecutive read (day 25, day 34, day 42) and no rock changed state in 17 days. The operating finding is unchanged and now measured a third time: of the 12 changes the W32 read proposed, both record/mechanism items landed and 0 of the 10 that required a human to put a date on a card or restate a rock did.	2 of 7 rocks defensible (rock 3 done-as-built, rock 6 delivered its decision and should be marked done). 5 off track: rock 0 entry-tier, rock 1 extension revive, rock 2 data Phase 3 gauges (reads on_track on the board for a third consecutive week while I006 is planned, owner eng, undated, no artifact, untouched since 2026-07-27), rock 4 early-cancel play, rock 5 renewals. 14 cards overdue, up from 12 at day 34. Six cards on live rocks still carry no date at all (I006, I011, I018, I019, I025, I032), unchanged since 2026-07-27. W32 proposals applied: 2 of 12, both record edits (issues 28 and 29 carded), 0 of 10 dated or rock-level items.	2026-08-11	method · source
`F075`	The MCP wedge has converted at most 3 users to paying in its entire lifetime. It is a retention/upgrade instrument inside the existing paid base, not an acquisition channel, and five consecutive weekly digests read its weekly-actives line as evidence about the funnel. Of 78 users who have ever held an mcp-scoped token, 48 were already paying before their first token and 3 first paid after it. Of the 50 users active in the last 7 days, 44 are on an active paid or lifetime plan, 6 are lapsed subscribers, and 0 have never held a subscription of any kind, so the Plus-and-up gate holds. plans/ai-data-wedge.md designed MCP this way ("stays included in Plus+, retention/upgrade driver for humans"); the wedge's revenue leg is the Data Platform API, which is designed and unbuilt.	78 ever-issued MCP users: 48 paid before first token, 3 paid after (~$14/mo each, roughly $42/mo total), 27 never paid under their own user id. 50 weekly actives: 44 on active paid/lifetime plan, 6 lapsed, 0 never-subscribed.	2026-08-17	method · source
`F076`	ChartMogul months never fully settle: ten days past close is when a month becomes usable, not final. February 2026 restated six months after close, and the cause is traceable to one late-booked subscriber. Between the 2026-08-11 and 2026-08-17 pulls exactly two months of 2026 moved: February net new -$38 to -$26.27 (all new business, $894 to $906.00) and July net new -$84.81 to -$74.81 (all contraction). Closing MRR rose by an identical +$11.74 in every month from Feb through Jun and +$21.74 in Jul (that same $11.74 plus the $10.00 contraction correction), January did not move, and customer count gained exactly +1 in every month from Feb onward. That signature is one subscriber who first paid February 2026 at about $11.74/mo and was booked into ChartMogul roughly six months late, propagating forward. Supersedes F063's ten-day rule; F063's "no component is exempt" is confirmed for a third consecutive week (W31 new business, W32-W33 churn, W33-W34 contraction). Operative rules: never build a conclusion on a month-over-month difference under about 2%, never diff a prior report's figure, always re-base the whole series from today's pull, and diff the full year against the last report rather than only the previous month.	Feb 2026 net new -$38 (Aug 3 and Aug 11 pulls) to -$26.27 (Aug 17), +$11.73 in new business six months after close; +$11.74 MRR and +1 customer carried into every month from Feb 2026 onward. Jul 2026 contraction -$133.82 to -$123.82 at +17 days. 2024 and 2025 unchanged to the cent.	2026-08-17	method · source
`F077`	The MCP weekly-actives plateau broke, and unlike last week the growth is retained rather than arrivals. Weekly active MCP users 36 to 50 (+39%), and the returning base, flat at 23-24 for five straight weeks, went to 42. Roughly 7 of last week's 12 first-week users came back. Thirty-day actives 51 to 56, ever-issued 151 tokens/73 users to 169 tokens/78 users, stickiness 72% of ever-issued users active in 30 days. Two consecutive weeks of organic movement with nothing shipped to cause it: I024 (directory placements + hub page), the marketing card built to feed exactly this funnel, is 17 days overdue. Read alongside F075, which establishes that this growth is engagement inside the existing paid base and not acquisition.	Weekly active MCP users 50 (was 36, 23, 25, 23, 27 in W33-W29); returning 42 (was 24, 23), first-week 8 (was 12); tokens used 7d 74 (was 43); 30d actives 56 (was 51); ever 169 tokens / 78 users.	2026-08-17	`mcp-weekly-actives.sql` · source
`F078`	No segment of the AI onboarding A/B shows the arm winning, so there is nothing to route on. The strongest pre-chat predictor of whether a user talks to the agent is whether the browser extension was already installed at signup, and that segment carries the arm's largest deficit rather than a win. The ordering runs backwards from the theory behind the entry-screen fixes: the more a segment types, the more the agent costs it.	Seven segment cuts of E002 (tagged 2026-06-25 to 2026-08-04, week 1 closed, 2,557 AI vs 2,561 control), seven negative for the AI arm. Extension at signup: AI 10.40% (115/1,106) vs control 13.02% (142/1,091), -2.62pp, z=1.91, p=0.056. No extension: 9.24% (134/1,451) vs 10.27% (151/1,470), -1.03pp, z=0.94, p=0.34. Five regions, all negative: EU west 10.36% vs 14.40%; anglo 10.29% vs 12.56%; east Asia 13.69% vs 14.02%; other 8.54% vs 8.77%; south Asia 4.76% vs 5.24%. One-sided sign test on the region partition p=0.031. Region type rate against region delta, Spearman rho=-0.70. Interaction test on the extension cut z=0.90, p=0.37. Type rate itself: 34.34% (476/1,386) with the extension at signup vs 26.03% (505/1,940) without, z=5.18, p=2.2e-07; by country 6.5% (PK) to 41.7% (AU); flat across 24 signup hours.	2026-08-17	method · source
`F079`	The user classification layer is a one-shot backfill, not a live layer: no signup since 2026-07-01 has been classified on any acquisition dimension. Phase 3 of the classification plan (Q3 rock 2, new-payers-per-cohort as a standing report) cannot produce a number until the classifier runs on new signups, because every recent cohort is almost entirely unclassified.	All 782,895 acquisition_path rows carry a classified_at inside 2026-07, the backfill month, and none after; acquisition_platform matches at the same count. Over the E002 arm (signups from 2026-06-25 onward, n=3,326) only 427 users (12.8%) carry an acquisition_path, and those are exactly the ones who signed up in the six days before the backfill ran.	2026-08-17	method · source
`F081`	test probe, will supersede immediately	probe	2026-08-17	method
`F084`	Berlingske Media's invoicing entity changed on 2025-12-12 and was never recorded anywhere. APT Norway AS replaced Berlingske Media A/S as contractual party and all invoices must be issued to Amedia produkt og teknologi AS in Oslo. The renewal is 2026-10-11, so an invoice raised from today's CRM record would go to a company that no longer owes us the money. Second instance of the class that put Dagbladet into 114 days of renewal limbo.	Invoices must go to Amedia produkt og teknologi AS, Schweigaards gate 15, 0191 Oslo, Norway, VAT 935 641 357, via DIFI/ELMA in EHF format or PDF to fakturamottak@amedia.no. Notice dated 2025-12-12, 248 days before this reading and 303 days before the 2026-10-11 renewal. CRM 25 carries NULL for contact_person, email, country, vat_number and visma_customer_id. Utilization is 3 active users against 14 paid seats, the weakest on the book.	2026-08-17	method · source
`F087`	test probe for value field, will supersede	probe	2026-08-17	method
`F088`	probe 2	W33 total 1,320 raw / 1,014 ex-BD vs W32 1,028 / 1,022.	2026-08-17	method
`F089`	probe 3 percent	Eight weeks vs 2025 -30.2% raw, -32.6% ex-BD.	2026-08-17	method
`F090`	W33's +28% signup jump is one country on organic, not growth.	1,320 raw / 1,014 ex-BD vs 1,028 / 1,022.	2026-08-17	method
`F094`	Distinct users successfully adding at least one feed (excluding the get-started feed) average ~358/day (weekdays 350-450, weekends 230-270); ~115/day are accounts under 7 days old, ~245/day older. This is ~3x the E002 per-day testbed (~62/arm/day), so an Add feed A/B reaches ~3.8k/arm in 3 weeks.	~358 adders/day (window 2026-08-03 to 2026-08-16)	2026-08-17	method · source
`F095`	33.9% of feed searches return zero results (22,758 of 67,214, 30 days to 2026-08-17), and a new user whose FIRST search fails ends week 1 with no feeds at 37.4% vs 9.4% on success; 25.5% of new searchers open with a failure. Fixing to parity is worth ~2,300 users/year ending week 1 with a feed (correlational ceiling).	33.9% zero-result; 37.4% vs 9.4% empty week 1	2026-08-17	method · source
`F096`	Valid-URL feed search is non-deterministic: 1,067 distinct queries both succeeded and failed within the same 30-day window, accounting for 2,797 failed searches whose exact query provably works (example: schneier.com/feed/atom/, live feed, 0 results for 4 users). was_error is 0 on all 67,214 rows, so fetch failures are uninstrumented.	2,797 flaky failed searches / 1,067 queries per 30d	2026-08-17	method · source
`F097`	Users arrive at Add feed holding a source: 80% of week-1 feed-search queries are pasted URLs (80.9% non-activated, 81.2% activated users), and search is the activation backbone in both E002 arms (searchers activate 11.7-17.5%, non-searchers ~3.4% regardless of arm). Half of onboarding-chat first prompts were URLs or short search-shaped terms; chat URL-pasters activated worst of all typed groups (7.8%).	80% of queries are URLs; non-searchers activate ~3.4% in both arms	2026-08-17	method · source
`F098`	Feed search error telemetry was dead for ~3.7 years: was_error last fired Oct 2022 (7.1% of searches, 10,373/146,688 in Aug-Oct 2022), 0 in every window Jan 2023 onward, because ParseFeedWithDiscover discarded the fetch error. ~2.5M searches logged since with failure information thrown away; per-error user messages and the Substack retry were dead behind the same wire. Fixed and verified in prod 2026-08-18 (PR #386, failure_reason classes live from 20:07 UTC).	was_error: 7.1% Oct 2022 -> 0 from Jan 2023; ~2.5M searches unattributed	2026-08-18	method · source
`F099`	YouTube began failing Feeder's 03:00-07:00 UTC crawl peak on 2026-08-18: 9,720 subscribed videos.xml feeds flipped health_state=error that morning (baseline 1-4/day), 708 more on 08-19. The 24h error backoff (BadFeedHideTimeoutInMinutes=1440) phase-locks victims: retries land back inside the same daily failure window. No Feeder deploy involved: crawlers unchanged since 08-07, adder-only deploys 08-18/19, and both the crawl UA and a browser UA fetch videos.xml fine (HTTP 200) from spider-crawler1 off-peak.	9,720 error flips on 2026-08-18; 10,856 subscribed YouTube feeds stuck in error (31% of 35,145); 22,389 recovered since 08-18 06:00	2026-08-19	method · source
`F101`	Folders and feeds no folder points at, after the 2026-08-24 repair run	736 folders across 74 users remain, all of them users with no user_folder_items at all; 0 repairable users left. The run re-homed 38,729 feeds and 7,407 folders for 9,888 users	2026-08-24	method · source
`F102`	Aug 1-25 first-time payers 41 vs 48 YoY; the day-17 "+4% turn" was a calendar artifact	41 vs 48 (-15%)	2026-08-25	method
`F103`	Expansion stepped down 72% in June 2025 and never recovered; plan-ladder upgrades never moved	$344/mo May 2025 to $96 Jun 2025; upgrades flat ~2/mo, ~$15/mo	2026-08-25	method
`F104`	MCP wedge is 108 days old (oldest token 2026-05-09); no retention comparison is possible yet	85 users, all first tokens in 2026-05 or later	2026-08-25	method
`F105`	Monday 2026-08-24: revenue digest failed twice (529, timeout) and stop-on-fail parked all 8 downstream fleet jobs	0 of 8 downstream jobs ran; no W35 artifacts from any other seat	2026-08-25	method
`F106`	The extension signup decline is a steady trend, not a break, and F080's -15.8% MoM was mostly a calendar artifact. signup-extension-install has fallen -4.61 tags/week (se 1.20, t=-3.85, -5.2%/month) across 16 weeks with no discontinuity. August 2026 opens on a Saturday, so day 1-16 holds 6 weekend days against July's 4; weekend days run 36 tags vs 62 on weekdays, accounting for 56 of the 146-tag deficit (39%). Days 17-24, where both months carry 2 weekend days, show August ahead (+4.0%). The install-to-signup rate the divergence was read from is not a funnel: on Monday-aligned whole weeks it correlates -0.818 with its own denominator and +0.109 with its own numerator, and 96-98% of install clients are never seen again on any event (3.1% ever carry a userId). Not one locale either: 8 countries to reach 81% of the decline, and the US is 24% of the base against 31% of it.	-4.61 tags/week, t=-3.85; 39% of the -15.8% was calendar; weekly corr(installs, conversion) -0.82	2026-08-25	method · source
`F107`	The extension's fromPlatform label flipped chrome to firefox across the whole installed base starting the week of 2026-03-09, complete by ~2026-04-06, so every chrome-vs-firefox cut of 2026 is wrong. Monthly distinct extension readers went chrome 14,939 to 1,637 and firefox 191 to 12,233 between Feb and Jul while the union stayed flat (15,437 to 13,571). It is not a real browser migration: 45.0% of March's extension readers emitted events under both labels in the same month, against 1.0% in February and 2.2% in July. Clients on extension 7.9.0 never flipped and still report chrome; the flip is confined to 8.0.28. This also corrects the standing claim that the phantom-install era faded in Apr-Jun 2026: the chrome-side multiple fell from 6.1x CWS installs (Mar) to 1.2x (Jun) only because those clients relabelled, and chrome+firefox install clients together ran 63,023 (Mar) to 39,578 (Jun) to 38,597 (Aug 1-23). Run #1's events audit flagged the label flip on 2026-07-03 as an open question and it was never picked up.	chrome readers 14,939 (Feb) to 1,637 (Jul); firefox 191 to 12,233; union flat; 45% dual-labelled in March	2026-08-25	method · source
`F108`	Extension upgrade experience (P12), day 51: the first settled 30-day cohort conversion landed, 1 of 95 closed windows = 1.05%, still under the 1.5% target. No new payer in 21 days while offer viewers went 228 to 270 and checkout openers 9 to 12, so checkout conversion fell to 2 of 12. Only 1 of the 2 payers is retained (payer B lapses 2026-09-04). Trial emails remain 0 for 90. The week-8 floor check fails on current evidence: ~14.5 payers/yr gross and ~7.2/yr retained against a ~60/yr bar, both falling for a third checkpoint. Separately, extension email submissions fell to 53 in W34, the lowest week in the 16-week series, while the verify-rate canary stayed clean at 90.6%, a capture-volume problem upstream of the paywall and not caused by it.	1 of 95 settled cohort windows converted = 1.05%, under the 1.5% target; 2 of 270 offer viewers all-in = 0.74%; floor check ~14.5 payers/yr gross and ~7.2/yr retained vs a ~60/yr bar; W34 extension email submissions 53, a series low	2026-08-25	method · source
`F109`	Prescient's 2026-2027 renewal is invoiced and its value is invoice-verified, the first enterprise contract in the book with a negotiated price the app can read. crm_subscriptions row 1 (created 2026-08-19, the first row that table has ever held) and the invoice emailed to Concur on 2026-08-21 agree to the cent. Supersedes the F083 risk: the account did have no billing mechanism on 2026-08-17, and now it does.	$15,300/yr net (1,200 seat-months @ $15.00 = $18,000, less 15% volume discount -$2,700), VAT 0% reverse charge to UK VAT GB538838890, 30-day terms, period 2026-09-09 to 2027-09-09, payment due 2026-09-18. Mirrors invoice 164 (2025-09-09). Against the 2026-07-10 reconciliation's Prescient line of $17,988 (100 x $179.88 list) that is a 17.6% overstatement, the second account checked against a real invoice and the second one that came in low.	2026-08-25	method · source
`F110`	CRM status and invoice_sent_at are not evidence of whether an enterprise account has been invoiced, because invoicing happens in Visma and Gmail and nothing writes back. Prescient was invoiced on 2026-08-21 and acknowledged by the customer's AP system, while CRM 23 stayed status send_invoice with invoice_sent_at NULL and crm_visma_invoices stayed empty. The field produces false all-clears when set and false alarms when not, so any renewal gauge or page trigger reading it alone is unsafe.	1 of 1 invoices sent in the last 40 days is invisible to the CRM. CRM 23: status send_invoice, invoice_sent_at NULL as of 2026-08-25, four days after the invoice went out and was auto-acknowledged. crm_visma_invoices: 0 rows (F020 still holds). Week 34's restated page trigger ("page if CRM 23 still has invoice_sent_at NULL") would have fired a false page on this.	2026-08-25	method · source
`F111`	The staging copy of the daily CRM action mail has stopped. Since 2026-08-20 exactly one mail arrives each morning, from production, and every item in it is real. The alarm that was 93% false is now 100% true. Supersedes F068.	Last staging mail 2026-08-19 05:00:01 ("CRM: 15 customers need follow-up", Gota Media first, feederstaging.com admin links, 14 of 15 items false). 2026-08-20 to 2026-08-25: 6 consecutive days, 1 mail per day, 3 items (IDMC, Prescient, Dagbladet), 3 of 3 true. 2 of those 6 mails were opened, against 0 in the preceding 4 weeks.	2026-08-25	method · source
`F115`	A 3h40m platform outage on 2026-08-20, posts database corrupted by a sudden shutdown and rebuilt from backup, produced two fifths of the week's support inbox in five hours and landed on the enterprise monitoring book: Ritzau, NTB, Reforma, Oracle, Cantor Fitzgerald, Stout, Roth Capital, Genesis Analytics, Prism MediaWire and a US city government all wrote in during it	43 Intercom conversations from 41 distinct people opened 2026-08-20 12:50-18:00 UTC against a baseline near 15 a day; 34 of the 43 are outage reports and 3 more carry the same symptom the next day. Week total 105 conversations against 46 the prior week, so 41 of every 100 conversations in the week arrived inside those five hours.	2026-08-23	method · source
`F116`	The feed-health breakage email has no circuit breaker: when YouTube ingestion degraded on 2026-08-19 the job mailed 20,215 feeds in one week, 4.6 times the prior week, and 82 percent of the named feeds crawled fine right afterwards. The false-positive floor is no longer a steady leak, it amplifies exactly when the platform is already in trouble	20,215 feeds notified in the week to 2026-08-24, against 4,369 (wk33), 5,220 (wk32) and 5,842 (wk31). 16,657 of them (82 percent) crawled OK after the notice, against 39, 32 and 34 percent in the three prior weeks; 9,080 (45 percent) published a post after it; only 2,881 (14 percent) read health_state ok now. Blast radius doubled: 894 users emailed against 390, of whom 209 pay against 102, about one in ten of the roughly 2,067 paying accounts getting a mostly-wrong alarm in one week. 10,463 of the 20,215 notified feeds (52 percent) are youtube.com feeds, 9,740 of them mailed on 2026-08-19 alone, and 9,586 (92 percent) crawled fine afterwards.	2026-08-23	`feed-health-email-false-positives.sql` · source
`F117`	The Bangladesh signup wave is not a one-week spike: it grew again in week 2026-34 and is now the largest single-country source of signups, bigger than the US, while still producing zero paying customers	BD signups 7 (wk32) to 306 (wk33) to 437 (wk34), now 28 percent of all signups and ahead of the US at 282. Total signups 1,028 to 1,315 to 1,585. Of the 437 who arrived 2026-08-17 to 08-23, 403 (92 percent) hold one feed or none against 40-49 percent for US, IN, GB, DE and BR; mean 1.57 feeds against 6.04 US and 8.64 DE. 0 of 437 hold any paid subscription, in a week when 1 US and 1 DE signup did.	2026-08-23	`signup-country-mix.sql` · source
`F118`	A support thread that has never received a human reply is invisible to whatever makes us come back to a thread, and naming it in a report does not fix that. Two weeks running, every named thread with one prior reply got closed and every named thread with zero replies did not	Both threads the wk34 report named as never-answered are still never-answered on 2026-08-25: Jason Bryant (215475419302877, Professional annual 179.88 a year, renews 2026-09-26) at 15 days with first_admin_reply_at still null, and 215475414703029 at 16 days. All 6 threads on the same list that had already received one human reply are now closed. Independently, in week 2026-34, 28 of 105 conversations (27 percent) never received an admin reply and 8 of those are still open, including an inbound enterprise lead from REGIOCAST, a German 24/7 radio news operation with about 30 staff asking for a custom solution, open and unanswered since 2026-08-18.	2026-08-25	method · source
`F119`	Organic's shortfall closed: W33+W34 is inside both control years.	+0.4% vs 2024 -1.8%, 2025 +4.3%	2026-08-25	method
`F120`	BD wave ended in W34: peak Aug 19, 13/day by Aug 24.	437 signups, 0 payers, 92.2% one feed or none	2026-08-25	method
`F121`	Signup tagging silently failed on 2026-08-18; no alert fired.	11 signups, ids 1005195-1005205, 36 min	2026-08-25	method
`F122`	cybersecurity-teams got its first payer; the zero is retracted.	147 signups, 1 payer, p 0.066 from 0.014	2026-08-25	method
`F123`	Q3 2026 rock status at day 56 of 92, judged with no partial credit. The same 2 of 7 rocks are defensible for the fifth consecutive read (day 25, 34, 42, 48, 56) and no rock has changed state in 31 days. Rock 0's premise died this week: F103 shows the usage ladder it is built on addresses at most 3-9% of expansion. Rock 5 splits for the first time - its worklist clause is met (Prescient closed and invoice-verified, F109) while its close-out clause is not (three contracts 76-122 days past end date). Of W34's 14 proposed board changes plus 4 named human actions, 1 human-required item landed - the Prescient invoice, the only ask on five consecutive CEO pages carrying both a date and a dollar figure.	2 of 7 rocks defensible (rock 3 done-as-built, rock 6 delivered its decision 2026-08-03 and should be marked done). 5 off track: rock 0 entry-tier (I007 41 days overdue, I012 24, I018 undated), rock 1 extension revive (I019/I025 undated 29 days, scorecard clause uncomputable 55 days), rock 2 data Phase 3 gauges (reads on_track, false since F079), rock 4 early-cancel play (I032 undated 29 days), rock 5 renewals (I010 42 days overdue). 15 cards overdue, up 1 on W34. Execution queue: 1 card, I003, 34 days overdue.	2026-08-25	method · source
`F124`	Second open-PR sweep: the count of substantive open PRs with no board record went 4 to 5 despite one merging, and the reason none were carded is mechanical. #293 merged about 14 hours after W34 priced it, which is the first sweep result to land. #242 (38d, 6,745 YouTube feeds, 275 users spammed), #339 (17d, serves I024), #355 (14d, deploy race behind an 82-hour outage, verified unmerged: main's spider/bin/deploy blob is exactly this PR's base blob), #417 (1d, feed delegation, a mechanism for the WAF-blocked class behind issues 34 and 37) and #415 (1d, Google Calendar plugin, a new user-facing source type with no launch plan, issue 20's class) have no initiative and no owner. Carding them was impossible: the board has had no create path since the 2026-07-18 cutover (issue 48).	17 open PRs, 5 substantive with no card (was 4 of 15); #293 merged 2026-08-17 20:27 UTC, ~14h after the W34 ask; 3 new PRs 2026-08-24 19:33-21:20 UTC totalling +3,850 lines across 63 files	2026-08-25	method · source
`F125`	The fleet notifier is not broken and Monday 2026-08-24 was not dark. notifyRun() is awaited before the stop-on-fail exit, so the heartbeat posted "Fleet 2026-08-24: 0 ok, 1 failed - weekly-revenue-digest: API Error: 529 Overloaded" to #fleet-log. The dead-man's switch works; there is no rung above it. The only tier that rings a phone requires a job to write its own signal file, which a job that died on a 529 cannot do, so notify-policy.md's "the fleet itself is broken" page is unreachable by exactly the failure it exists for. Second correction: stale signal files ARE cleared, at the start of each job's own next run, so a signal outlives its week only when its job does not run - which is why coo-level10.json from 2026-08-17 sat on disk until 2026-08-25.	launchd.err.log lines 37-40 (the 2026-08-24 block) carry the two digest failures, the retry and the stop-on-fail, and no [notify] line; notify.json has a live bot token with heartbeat_channel #fleet-log	2026-08-25	method · source
`F126`	W34's three asks landed 2 of 3, the first movement on this page after two consecutive 0-of-3 weeks. Both landings named one artifact, one date and one number; the ask that did not land named a decision with no artifact and no cost if missed. The third ask did not fail, it was unexecutable: "card these three PRs" asked for a record type the board cannot create (issue 48), so four weeks of this seat concluding that the board rejects human-required work was measured on a board that had no create path. Contamination, not refutation: I005's routing call needed no endpoint and still did not happen, and the sales L2 grant needed only a sentence.	2 of 3, against 0 of 3 in each of the two prior weeks; PR #293 merged 2026-08-17 20:27 UTC, Prescient invoiced 2026-08-21 08:38 against a 2026-08-22 deadline	2026-08-25	method · source

A finding older than 60 days flags red. Superseded findings stay in state/findings.json with a pointer, never edited in place. Registry rules: SCHEMA.md, born from L015.

The enterprise book

19 accounts, one record each — CRM claims and verification dates side by side · as of 2026-07-19

Account	$/yr	Ends	CRM says	Verified
DMJX (Danish School of Media & Journalism)	$42,000	2026-06-30	not in CRM	2026-07-10
Dagbladet	$37,800	2026-04-25	needs_cancellation	2026-07-18
Prescient	$17,988	2026-09-05	active	2026-07-10
Ritzau	$12,600	2027-01-01	active	2026-07-10
Berlingske Media / APT Norway	$9,072	2026-10-11	active	2026-07-10
NTB	$8,640	2026-05-19	needs_cancellation	2026-07-18
My Team (org unidentified)	$6,300	2026-04-01	not in CRM	2026-07-10
Ekstra Bladet	$3,780	2027-04-03	active	2026-07-10
Ring LLC	$3,780	2026-08-08	send_invoice	2026-07-10
Gota Media	$3,120	2027-02-14	active	2026-07-10
Stampen group (GP + 2 locals)	$2,970	2027-02-06	active	2026-07-10
DW	$2,100	2027-03-01	active	2026-07-10
MIT Lincoln Laboratory	$1,944	2027-05-04	active	2026-07-10
IDMC	$1,920	2026-05-17	needs_cancellation	2026-07-18
NWT Media (Webbredaktorer)	$1,890	2026-10-11	active	2026-07-10
Telegraaf	$1,799	2025-12-01	not in CRM	2026-07-10
Regeringskansliet	$840	2026-04-15	needs_cancellation	2026-07-18
Virginia Tech	$840	2026-05-01	needs_cancellation	2026-07-18
Det Nordjyske Mediehus	$420	2025-10-30	not in CRM	2026-07-10

Bucket totals from the Jul 10 reconciliation ($101,244 current / $58,559 limbo / $3,360 ghost) are superseded: see F022 (method error), F023 (limbo) and F024 (book total retracted). I009 reconciled the five past-due accounts account by account against Visma invoices and both bank accounts; none needed cancelling. For SEK-billed accounts, annual_value_usd is an approximation at the 9.36 SEK/USD contractual rate (F022); the exact invoice amount and currency are in each note.

The fleet

9 of 9 agents live — live means a real trigger AND a fresh artifact; everything else says so

Finance weekly-revenue-digest · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

Data data-explorer · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

Data extension-upgrade-readout · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

Sales sales-renewals · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

Support support-themes · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

Marketing marketing-channel-read · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

CEO ceo-weekly · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

COO coo-level10 · live · last ran Aug 25 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

COO monthly-retro · live · last ran Aug 4 · latest artifact · laptop-fleet (launchd com.feeder.fleet, company/fleet/jobs.json)

No verified scheduler exists (2026-07-17): cloud-session routines proved unreliable, API-priced runs are unaffordable, and subagent fleets hit the subscription cap. Cadence is manual until the substrate decision (see the board). Source: state/agents.json.

The flow

shipped, day by day · today · what's committed next — drag sideways

Aug 1710

Aug 181

Tick P20 ledger: #383 shipped; addendum dates the dead error wire to Nov 2022 (F098)

Aug 196

Aug 258

Aug 261

First weekly P20 re-read: 29.8% zero-result, new index-coverage row (#424)

Today

Aug 26

Aug 31

COOBuild a laptop CLI that runs the recurring agent jobs on the Claude subscription — 2026-07-27 audit correction: the record said 'not yet running: needs merge', but company/fleet/ is merged to main and 8 of 9 chain jobs ran manually Jul 22-25, producing the W30 report set (agents.json lastrun + artifacts verified on disk). The CLI is proven end to end on the subscription; what remains is launchd wiring on Erik's machine and Phase 4. data-explorer was the one chain job skipped in the catch-up runs (issue 22). Decision 2026-07-21 (Erik): laptop CLI on the subscription, not cloud routines. Build: P17, company/plans/agent-fleet-runner.md. 2026-08-11 (COO Level 10, W33): the laptop half is DONE. launchd fires on schedule and the chain has produced a full seat report set twice (2026-08-03 on the Monday slot, 2026-08-11 a day late). What is not done is Phase 4, and it is now measured rather than theoretical. Three weeks, three failure modes, all needing a human to recover: 2026-07-27 data-explorer crashed and stop-on-fail dropped five seats (issue 22, F061); 2026-08-10 the fire and its retry both died on 'OAuth session expired and could not be refreshed' and a Tuesday 04:14 attempt died on laptop sleep. F061's retry-once fix fired correctly on 2026-08-10 and bought nothing, because expired auth is not transient. The notifier failed both weeks, so the dead-man's switch that makes silence mean 'broken' is itself broken. An unattended fleet would still be dark today. Dated to 2026-08-17 by this run: this is the COO seat's own card and it is the one thing on the board this seat can date without asking anyone. 2026-08-17 (COO Level 10, W34): the date was missed and the card is re-dated to 2026-08-24, which is the next chain. Recorded plainly because this is this seat's own card and it dated itself. What happened instead: all eight Monday jobs fired in their own slots on the first attempt, no retry, no OAuth wall, no sleep abort. fleet.mjs has not changed a byte since 2026-08-11 09:46, so none of the three pieces exists and nothing about today is repeatable. One further measurement worth keeping, because it is the half people will assume today settled: the notifier was NOT exercised. No seat wrote a signal file (all eight declined on the notify-policy bar), so the '[notify] post failed: fetch failed' path that broke on two consecutive Mondays was never called today. Today is evidence about the OAuth coin toss only, and it came up heads. It is evidence about the dead-man's switch of exactly zero. 2026-08-25 (COO Level 10, W35): re-dated to 2026-08-31 and Phase 4 corrected. The 2026-08-24 date passed and that is the day the chain parked: the revenue digest failed twice (529, then timeout) and stop-on-fail took all 8 downstream seats with it (F105, issue 50). Fourth of the last five Mondays needing a human to recover. CORRECTION to the 2026-08-11 block above, which two weekly reads inherited without re-testing. 'The notifier failed both weeks, so the dead-man's switch is itself broken. An unattended fleet would still be dark today' is WRONG (F125). runList() awaits notifyRun() before the stop-on-fail exit (fleet.mjs:389), notify.json carries a live bot token with heartbeatchannel #fleet-log, and every Slack failure path logs to stderr. The 2026-08-24 block of launchd.err.log (lines 37-40) has the two digest failures, the retry and the stop-on-fail, and NO [notify] line. So Slack received 'Fleet 2026-08-24: 0 ok, 1 failed - weekly-revenue-digest: API Error: 529 Overloaded'. The single '[notify] post failed: fetch failed' in that file sits in the older working-tree-dirty block. Method caveat: inferred from the absence of a logged failure on a path where every failure logs, not from reading Slack. Second correction, same class: stale signal files ARE cleared. runJob() unlinks signals/<id>.json before the job runs (fleet.mjs:338). A signal outlives its week only when its own job does not run, which is exactly why coo-level10.json from 2026-08-17 was still on disk on 2026-08-25. What this changes: Phase 4 item 2 is retired as already built, and replaced by the rung above it. A parked chain is one line in a log channel, indistinguishable from a normal day, and the only tier that rings a phone requires a job to write its own signal file, which a job that died on a 529 cannot do. The runner already knows a job exited non-zero; it tells the wrong channel. Issue 50's two smaller changes (continue-on-fail, move the API-heaviest job out of order 1) are sequenced ahead of all of Phase 4, because they are what actually cost the company the 2026-08-24 read. — next: Phase 4, one item retired and one sharpened by F125. (1) A preflight auth check that verifies the Claude OAuth session before the 04:00 chain and pages while it can still be refreshed, since retry-once cannot clear an expired session. (2) RETIRED, the notifier path already works: notifyRun() is awaited before the stop-on-fail exit and the heartbeat posted the 529 to #fleet-log on 2026-08-24. Replaced by escalation: post to the page tier when any job in a run-due chain exits non-zero, since the runner already knows and only tells the wrong channel. (3) The .claude/settings.json tool allowlist for unattended runs. Ship issue 50's two smaller changes first, continue-on-fail and moving the API-heaviest job out of order 1, because they are what actually cost the company the 2026-08-24 read. (Erik, Aug 31)
ErikFix Chargebee's give-up-too-fast billing retries — Audit ran 2026-07-18 (Erik, Chargebee admin UI, config applied). System was already tuned: dunning emails on for years, Account Updater on via Stripe default, 39% recovery (F017). Only material change is the retry window 5 to 21 days, plus schedule spread 2/5/9/14/21 and skip-hard-failures on. Smart Dunning declined: plan-gated, negative ROI against the ~$374/mo residue. See F021 and the 2026-07-18 addendum on the kill report. Expect a ~3-week involuntary-churn trough that is deferral, not impact. — next: Re-run company/checks/dunning-recovery.rb and compare steady-state recovery to the 39% baseline (F017), discounting the transition trough (Data, Aug 31)

Sep 1

SalesFix the enterprise CRM data, then chase or close the past-due five — RESOLVED 2026-07-19 (Erik + assistant session, all five worked account by account against Visma invoices, both bank accounts, Gmail and Intercom). Verdict: none of the five needed cancelling. All five were real customers with invoices actually sent. The needscancellation flag was wrong on every row. PAID, confirmed against bank statements: - NTB inv 187, 64,800 SEK, paid 2026-06-10, bank ref CINV/187. Period 2026-05-19 to 2027-05-19, 8 seats x 12 months @ 900 SEK/seat/month less 25% loyalty. (Inv 183 was credited by 188 and replaced by 187; the CRM still has the superseded Faktura183.pdf attached.) - Regeringskansliet inv 179, 11,564 SEK, paid 2026-06-12 (11,563.75 via BG 5150-3894, 25-ore rounding). Period 2026-04-15 to 2027-04-15, 2 seats @ 35 USD/seat/month = 327 SEK, plus 150 USD invoicing fee, plus 25% moms. - Virginia Tech inv 182, USD 1,656, paid 2026-05-21, ref 2026052100174093 (USD account). Period 2026-05-01 to 2027-05-01, 2 seats @ 35 USD/seat/month less 10% educational, PLUS a Public Dashboard add-on at 1,000 USD/yr less 10%. UNPAID: - IDMC inv 184, USD 1,620, sent 2026-05-11 via Intercom (Lis confirmed 2026-05-19 she forwarded it to finance). Period 2026-05-17 to 2027-05-17, 10 seats @ 240 USD/seat/yr less 780 (20% public good + 300 custom). Chased 2026-07-19. Note Lis's email hard-bounces; reach her in Intercom or via ivana.hajzmanova@idmc.ch. [SUPERSEDED 2026-08-17, see the correction block below: the address works.] - Dagbladet inv 181, 86,400 SEK, superseded. Credited and reissued 2026-07-19 as 20 seats x 4,320 SEK/seat/yr, period 2026-04-25 to 2027-04-25, sent to Aller Media (Peppol 0192910119877 / Invoice.no.allermedia@aller.com, Referanse 1 'Trym Mogen, desksjef', Referanse 2 'product code: 40600'). Trym confirmed 20 seats on 2026-07-01. DATA FIXED: all four subscriptions rows had nextpaymentdue corrected to match invoice periods (1075599 NTB 2027-05-19, 885574 Regeringskansliet 2027-04-15, 881920 Virginia Tech 2027-05-01, was 2025-03-28 stale by 15 months, 1527119 IDMC 2027-05-17). CRM customer rows updated by Erik. PREMISE CORRECTION: the Jul 10 reconciliation's '$58.6K in limbo' does not survive (F023). Dagbladet was booked at $37.8K/yr (23% of the enterprise book) from annualising a stale 90-seat row at list price; the real contract is 86,400 SEK (~$9K). Enterprise ARR is overstated by roughly $29K (F022); the book total is retracted as method-unsafe (F024). Actual outstanding across the five as of 2026-07-19 is USD 1,620 plus the Dagbladet reissue. ROOT CAUSE, identified 2026-07-19 (since fixed): the needscancellation flip was the OLD CrmAutoTransitionStatusesJob overduepayment.updateall (daily 05:00), which flipped confirmpayment -> needscancellation once invoicesentat was 60+ days old, skipping updatedat (the 'undated' flip and no system note) and never checking paymentconfirmedat, so it flipped three already-paid accounts too. The 2026-05-15 11:07 stamp was the invoice-SEND batch (7 accounts, incl. Leatherhead and Ilta-Sanomat), not the flip; the flip fired ~2026-07-14 (invoicesent + 60d). Backend f527582f (main, 2026-07-19) removed that behavior: needscancellation is deleted from the CrmCustomer enum, unpaid invoices are no longer auto-transitioned, and overdue is derived from paymentdueby (paymentoverdue?) with the row staying confirmpayment for a human to decide. So there is no re-flip risk and the eng half of issue 12 is done. See issue 12 (now resolved) and issue 13 (Visma bank feed not reconciling, why paymentconfirmedat stays null). ALSO FOUND: quantity x list variant price reproduces NO invoice, every enterprise account bills a negotiated rate the subscriptions table cannot express (VT has an add-on, Regeringskansliet has a fee and VAT, NTB and Dagbladet bill in SEK against a USD variant). Any ARR figure derived from subscriptions.quantity x variants.price is wrong by construction (F022). Visma's paid/unpaid flags are also unreliable: five invoices confirmed paid by bank still sat in 'Obetalda kundfakturor', so the bank feed is not reconciling (carded as issue 13). CORRECTION 2026-08-17 (sales-renewals W34, company/reports/sales/2026-34.md). Two claims above are wrong and were inherited by three weekly reports without anyone re-testing them. 1. Lis Zandberg's email does NOT hard-bounce. Erik emailed lis.zandberg@idmc.ch on 2026-07-19 (Gmail thread 19f7c13c8dd608ba) and she replied from that address on 2026-07-20: 'Absolutely, I will follow up with the responsible department immediately and get back to you as soon as possible.' The chase therefore went by email, not 'in Intercom' as the next action said. 28 days on, nothing has come back and inv 184 is 64 days past due. The class: a contact-channel fact recorded once under pressure and never re-checked. It expires like any other claim (rule 12a). 2. The Dagbladet seat trim is 90 to 20, not 40 to 20. subscriptions.quantity on 1496668 reads 90 against a 20-seat contract, with 32 active users on organization 5594. Whatever the admin screen showed when this card was written, the row is 70 seats over, not 20. STATUS 2026-08-17: neither half has moved. No CRM write since 2026-07-19 22:11 (29 days). No reply from db.no or aller.com since the reissue, and crmvismainvoices is still empty (F020) so its state is not visible from the app. The CRM's own note 58 on Dagbladet ('New invoice sent with corected seat count') carries dueby 2026-08-20 and no resolvedat. IDMC's support conversation 215473594558152 is still open, waiting since 2026-06-24, 54 days, with a suggested answer sitting unsent in the thread since the day it arrived. — next: TWO left, both past end date. DAGBLADET is now the bigger one: invoice 190 (86,400 SEK) went to Aller Media's scan-only inbox 2026-07-19 and its auto-reply states that an invoice missing any of six mandatory fields is 'not processed or returned' - so 37 days of silence may mean it was deleted on arrival, not that it is queued. Check Invoice190.pdf against those six (their reference, our company info, invoice date+number, payment terms, our VAT/org no., our payment details) BEFORE chasing; reissue if it fails, chase Trym Mogen (tmog@db.no) if it passes. CRM note 58 fell due 2026-08-20. Then trim subscription 1496668 from 90 seats to 20. IDMC: $1,620 (inv 184) now 72 days overdue, Lis Zandberg silent 36 days since promising a finance follow-up, and Intercom 215473594558152 has been open 62 days with the answer already written and unsent. Her email lis.zandberg@idmc.ch WORKS (the hard-bounce claim in the notes below is wrong). Drafts for both are in company/reports/sales/2026-35.md. (Erik, Sep 1)

Left: every commit touching company/ in the last 14 days, straight from git. Right: board cards carrying a future date, from state/initiatives.json.