The AstroMatrix Archive

One bet, three document lanes, one roadmap. Everything scattered across those sessions is one of three lanes describing the same company from a different angle.

You are not missing a roadmap. You have one, and it is buried.

The roadmap is competitive-position-2026-09.md §7 — Horizon 0 / 1 / 2. Nothing else is a roadmap. Everything else is either evidence feeding into it, or a defect register tracking what breaks underneath it.

State of the code, checked against the working tree

The quarter's bet: relationships as distribution, not a feature

The diagnosis behind it: Android active installs fell 137,256 → 88,659 over four years — steady, structural, not a bad release. In that same period product work was real and effective, but no feature ever had “create a new user” as its primary job. This quarter tries the one mechanism that has never been tried.

Explicitly deprioritised for the quarter — not for lack of value, but because running them in parallel makes the one question unanswerable: more chart types · more generic interpretations · broad Ask-AstroMatrix development · journalling expansion · meditation/harmoniser expansion · a generic social feed · a large UI redesign · extensive ASO iteration · growth-content campaigns · offline/local calculation.

The roadmap, with what has actually moved

Horizon 0 — this month, no new systems

Entirely additive or price-side. Carries no grandfathering exposure. There is no case for scoping a new paywall limit until 0.1–0.4 have shipped and been measured — until then nobody knows what the product converts at when its entrance is findable and its paywall describes the real product.

Horizon 1 — the quarter, relationships and time-to-value

1.1–1.3 are the core bet — make the relationship layer timed, legible and not only romantic. Everything else in this horizon distributes it.

Horizon 2 — the year, new models

Built, working, and connected to nothing

Repeatedly, strategy passes proposed things that turned out to already exist. These are code-verified as present and unreachable — the common shape is that the computation exists and the distribution does not.

Decisions nobody else can make

Each has the analysis finished and is waiting on a call, not on engineering.

1. Cut a build ships 24 commits

   Two days of finished fixes, including the instrumentation that makes every later question answerable, sitting unreleased behind an unchanged version number.

2. The lifetime SKU — reprice or retire Horizon 0.2

   41% of purchases and the largest structural cap on lifetime value. No existing user loses anything either way. See B2 — the measured answer is $79.99, do not retire.

3. The ISSUE-61 remediation rollout 48,576 accounts

   Birth locations silently mismatched from their town labels. The id-based fix is live and stops new profiles hitting it, but the rollout — auto-correct 39,839 high-confidence records, ask the other 8,737 to re-enter — was designed and never started. The largest data-integrity exposure on the register by account count, frozen until someone says go.

4. The paywall's fourth bullet ISSUE-147

   Removing the two ungated claims leaves paid plans showing three bullets instead of five. Nothing was invented to fill the gap. Whether a fourth gets added is a copy decision, owned by positioning-and-paywall-copy.md.

5. The Matrix report size gate ISSUE-136

   The Summary + All Aspects report is gated as an oversized payload, but the gated path allows 50MB against an estimated ~1MB report. The 100kb limit that is real belongs to a route that button never calls. Needs the original dev to say whether it was ever measured — otherwise re-justify it as a render-memory gate and move it to the PDF path.

6. Confirm the language decision on paper Horizon 0.5

   Already made in code. That forecloses charging for localisation, which is a real strategic choice worth making deliberately rather than inheriting.

The tracking system itself has drifted

Part of why this feels scattered is that the doc meant to prevent scattering is out of date. Verified against both files:

• The Flutter fire doc is missing real, open, Flutter-owned issues — 91, 94, 104, 111, 138, 142 and 146 are all in the master register and absent from the derived view. Its own banner flagged four of them on 09-10 and they are still missing.
• There is a numbering collision — see B4.
• It is being hand-patched against its own stated rule that it must be regenerated rather than edited — which is how both problems above arose.
• The two biggest absentees are not small. ISSUE-138: the 2,921-test suite never runs anywhere, there is no CI test or analyse step, master deploys straight to production ungated, and the suite is currently red with 82 failures. ISSUE-142: release attribution — whose absence is why no fix in the register can be proven to have worked.

The fix is a regeneration from the master register, not another patch. Until that happens, check the master's index before concluding any Flutter issue is not tracked.

The fullest of the three orientation documents, and the one that does the most correcting. It collates and reconciles the scattered docs, introduces no new findings, and points every claim at the doc that owns it.

The company, in one paragraph

AstroMatrix is a profitable, deeply-built astrology product — roughly $17–20K/month, 87,467 MAU, 4.6★ — whose Android install base has declined about 35% over four years, steadily. Three years of real product depth work were effective at what they targeted, but no feature ever had user-creation as its explicit job.

Separately, the loyal base that remains is badly monetised (5.37% ever paid, $0.20 ARPMAU) — largely because the paths to pay were structurally broken, not because demand is absent. Those are two distinct problems: a growth-engine failure and a packaging failure. They have separate fixes and should not be collapsed into one narrative.

The single company question this quarter: can AstroMatrix generate users from users?

The five lanes

There is no single project here. There are five parallel lanes that each acquired their own tracker — which is the actual source of the “it's all over the place” feeling.

Four documents read like roadmaps — they are one plan at four altitudes

Read in that order and nothing conflicts. Use FEATURE-LIST as the working list and competitive-position §7 as the sequence.

Pricing, measured — this supersedes “reprice 3–4× or retire”

The last price rise already ran the experiment. Lifetime went $29.99 → $49.99 in Oct 2025. Same month year-over-year, which controls for the Nov–May slump that hit every SKU:

Keep vs retire is settled by arithmetic, not elasticity. Retiring only pays if enough lifetime buyers switch to annual. Break-even switch rate = lifetime net ÷ annual net over its life (annual $39.99 × renewal depth × 0.798 payout):

The only direct evidence: the +78% rise moved 13% of lifetime-inclined buyers elsewhere — a lower bound, since a price rise is a smaller shock than removal. Raising the price is what settles the keep/retire question — at $79.99, retiring can never pay. Lifetime money also arrives today; annual money arrives over 2+ years, conditional on a renewal depth nobody has measured per SKU.

Execution: price fields only, three consoles, two traps

Verified: products_config.json carries no prices; there are no hardcoded prices in any .dart/.ts/.tsx; and the 30% discount works by swapping to a separate product id, not a coupon. So changing two price fields is sufficient.

The engine correction — relationship transits are not free

Both FEATURE-LIST §8b.1 and competitive-position 1.1 claim the engine already supports this — “it treats the composite as a natal chart” and “its orb system has a transit slot for synastry/composite.” Both supporting points are misreadings. Verified in the engine source:

• CalcChart() has exactly two chart slots — dPos and TransitPos. A chart is natal (syn=0), synastry (syn=1), or transit (syn=2).
• applyComposite() consumes both slots to build the composite — it midpoints person 1 and person 2 into dPos. Line 869 only labels the result like a natal chart.
• Transits to a composite need three charts at once — person 1, person 2, and the sky now. The two-slot model cannot express that in one call.
• Orbs[] is [0]=natal, [1]=synastry/composite, [2]=transit — three orb settings for three chart types, not a transit slot for composite.

Three options, not equivalent. (1) Transits to the composite — what the plan implies; needs a third slot or a two-pass API. Real engine work. (2) Davison chart — the midpoint in time and space, so it has a genuine date/time/location and runs through the existing engine as an ordinary natal chart with syn=2 transits, no engine change. Not implemented anywhere. (3) Each partner's own transits side by side — works today with two existing calls, but answers a different question.

Name which one 1.1 is before estimating it. The asymmetry itself is real: the self matrix has six lenses, the relationship matrix has none.

The one thing blocking everything

Per-user event measurement does not exist — ISSUE-77, ISSUE-142. Metrics go to Prometheus, an aggregate time-series store. A uid label across 460,694 accounts is a cardinality explosion, not a one-liner. This was mis-priced as trivial and it is design work — a uid-keyed event collection that does not exist yet.

What it blocks: grading the Q4 bet · every gating, capping and pricing question · per-session funnels · experiment assignment.

Live state — verified against git, not against a prior summary

The fire docs' deploy-state claims lag reality in both directions.

Uncommitted at time of writing

• Branch note: the shipping Flutter branch is new-ui, 116 commits ahead of master. Don't reason about Flutter state from master.
• Website deploys work again. Push to astromatrix-public master → Gitea Actions → live. Run npm run build locally first and check git log origin/master..HEAD, because the server takes whatever is on origin/master. The “no auto-deploy” note in older docs is stale.
• Concurrent sessions are editing these docs. docs/README.md changed on disk mid-session. Re-read before editing anything under astromatrix-nodejs/docs/.

The doc map

Nine standing traps

Things that keep getting re-derived wrongly. Each one has cost a session already.

1. Don't propose a feature without checking whether it already exists. Event-triggered push, UGC/community, rewarded ads, the Guide deep-link and the in-chart South Node were each proposed as new work and each already shipped. Two of two “Bet”-tier items in one doc already existed.

2. Usage of an undiscoverable state is not a measure of demand. /chartupcoming at 0.2% and Progressed at 1.3% are evidence of no route, not no demand.

3. Never convert a destination into a state without leaving a signpost for one release. This has produced four confirmed “you deleted it” reports for features that still ship. ~25 of ~49 UI complaints are “I can't find things”; one named complexity.

4. “Too complex” and “too sparse” are both right. Six users want more on screen; one articulate user wants less. Solve it with a density mode — never by picking a side.

5. Never quote a truncated list as complete. Print a count, reconcile it, state N of N. Paginated Meta reads return partial data silently under rate limiting.

6. Verify writes by re-reading state — not by an exit code or a chained echo.

7. profiles = accounts (531,848). users = charts/people (1.24M). Not interchangeable, and they have been mixed up in published figures.

8. Pausing a Meta campaign does not pause its ads. Audit status, never effective_status.

9. Committed ≠ pushed ≠ deployed ≠ released. For Flutter, add ≠ in a build a real user has.

The twelve-month concentration — four systems, not twenty features

AI sits across these — it is not one of them.

A fifth thing not to postpone: surfacing. The product is already large. The next win is making users realise what they already have.

So: what now?

1. Horizon 0.4 — link the store, give reports a route. Small, verified, and everything downstream is unmeasurable without it.

2. Decide the lifetime SKU (0.2) and the language gate (0.5). Both are decisions rather than builds, and both are load-bearing.

3. Scope the event store properly. It gates grading the quarter, and it is not the one-liner it was priced as.

4. Ship Horizon 1.1 — relationship transits. It is the prerequisite half of the committed bet that the Q4 plan assumed already existed.

5. Leave the ads campaign alone until day 3 gives an honest CPI. judge it against $1.78, not $0.85 — see B9

6. Resolve the legacy .NET reverts before the database sunset makes it urgent.

The shortest route in. Nothing here is new information — it is the existing docs, arranged. The confusion has one cause: three separate tracking systems run in parallel, each with its own source of truth, and the roadmap lives in a fourth place that is not called a roadmap.

The three lanes

Every doc in the project belongs to exactly one of these. They are deliberately separate — a technical defect, a thing to build, and a customer who did not get an answer are different jobs with different owners. Mixing them is what makes the folder look chaotic.

Two more workstreams that are none of the above

Which repo holds what

The product lane spans two repositories, which is the second-biggest source of “I can't find it”. Strategy docs live in the Flutter repo; feature and competitive docs live in the Node repo.

State of the board

see B5 These counts are a snapshot; the highest number known across the whole set is ISSUE-152.

Work that exists but isn't live

This is the gap most worth closing, because several items are already written. Four commits sit unpushed in astromatrix-nodejs — including the ISSUE-143 tarot recovery (31,507 rows, 8,866 users unblocked) and the ISSUE-144 account-deletion data purge, both compliance-relevant. The Flutter tree holds uncommitted edits to products_config.json and gated_content_widget.dart — those are Horizon 0.1 and 0.3. The website tree holds the Terms of Use fix (ISSUE-148), which gates the pending store-metadata submission.

Pushing auto-deploys and restarts production here, so these are decisions, not chores.

Five traps — things the docs still get wrong

These are the reasons two documents can disagree and both look authoritative.

1. Everything in docs/analytics/ is pre-correction

   Those files still quote conversion inflated ~2.8× and volumes understated 14–44×, plus a retracted “tarot converts worst” framing. five-user-modes.md was corrected; the analytics files were not. FINDINGS-2026-09-11.md Part 1 lists every number to un-believe.

2. Sample levels are not fleet levels

   The usage-stats sample covers 16.6% of accounts and skews engaged. Use it to compare segments; never quote a level from it. node scripts/_analytics.js verify re-derives the headline numbers from production in ~2.5 minutes.

3. The reach percentages are due a re-pull

   Reports 7.8%, store 0.2%, harmonizer 2.8% — all quoted throughout the FEATURE-LIST, and all exactly the kind of level that moved. The ISSUE-77 instrumentation fix shipped on both platforms 2026-09-09, so a clean post-09-09 measurement is now possible and has not been taken.

4. Per-user measurement is mispriced as trivial

   It is named as the blocker for most of the monetisation work, and the original “one-liner” estimate was wrong. sendCounter writes to Prometheus — aggregate-only. A uid label across 460,694 accounts is a cardinality explosion. This is an event-store design task.

5. Usage of a hidden feature is not a measure of demand

   Reports have no route; the harmonizer has one link; astrocartography's route isn't registered; 8,352 journal prompts were built and never surfaced. Low numbers on any of these mean nothing until they're reachable.

Where to start — the reading order

1. FINDINGS-2026-09-11.md

   Twenty minutes. The verified baseline and the list of retracted numbers. Everything else assumes it.

2. competitive-position-2026-09.md §7

   The roadmap itself — the three horizons, with the reasoning attached to each item.

3. FEATURE-LIST.md

   The ranked list and, in the second half, every direct user request with its repeat count. This is where a new ask gets filed.

4. The fire report's index table

   Just the table at the top — 147 rows with a status each. Skip the detail sections unless a specific issue matters.

5. docs/README.md and docs/product/README.md

   The two folder indexes. Both were stale and were brought current on 09-11 — every file on disk now appears in one of them.

What the product actually is, what it has that nobody else does, what it's missing, how it makes money, and the four places new users could come from.

The sentence that isn't anywhere in the product

Practitioner-grade astrology in a consumer app — the charts the serious tools have, the packaging the popular ones have, for one payment instead of every year.

appears in no store screen · no upgrade dialog · no store listing · no web page

The four major subscription competitors average ~$230/year — Nebula $415, Sanctuary $240, CHANI $144, The Pattern $120. The $49.99 lifetime is 22% of that in year one and 7% over three; the $39.99 annual is 17%. “More than the competition in several areas, at under a fifth of the price” is literally true on both SKUs, and it is said nowhere. This is the largest unexploited marketing asset in the business, and it is free to use.

Buying is a day-zero impulse

The two opportunities that fall out of the charts-held table (see §C) are different jobs. The near one — 11,500 accounts holding 8+ charts who never paid: they already exhibit the strongest purchase predictor in the product and did not convert, so this is a conversion job — packaging, a reason, a findable way to pay. The far one — 300,710 accounts holding exactly one chart: all the headroom is here, but the question isn't “how do we sell to them”, it's what makes a second chart worth adding.

What we have that they don't, and what they have that we don't

Verified against the competitors' own published material. Composite charts appear in the practitioner tools and in none of Co–Star, The Pattern, CHANI, Sanctuary or Nebula.

The complexity complaint is not a complexity problem

Of ~49 interface complaints, one named complexity. ~25 said some version of “I can't find things.” The app is legible at the top of every screen and expert one level down — which is a much smaller problem than “the app is too complex”, and it means the fix is almost always the step between, not the screen. Three places that step is missing:

• The home tiles. Moon House, Astro House and Planetary Hour are three of the seven tiles on the first screen a new user sees, and they're the first thing that says “this isn't for you.” Translate them to consequence, or demote them.
• Between the slider and the aspects. The summary says Communication: +4; one tap down is “Mercury square Saturn”. Nothing bridges them.
• The chart-type names. “Draconic”, “Progressed”, “Composite” are offered with no one-line explanation of what question each one answers.

The loop, and the scoping rules that are easy to get wrong

Someone adds a partner → the app generates a live relationship reading, not a static score → they send it → the partner opens it with no install required → the partner sees content about themselves and the relationship they're in, not someone else's content → they create an account to unlock their own side → the pair is now live, and both have an ongoing reason to return.

• Aim it at people with 2+ charts who've never opened the relationship screen, and at Self-Explorers. Not Newcomers — half of solo accounts are Newcomers already holding 5.2 charts, for whom “add someone” is a bigger, riskier ask than “open a reading”.
• Do not gate the first reading behind the partner installing. The first user gets full value alone; the partner joining unlocks genuinely new shared state.
• Fix the cold-arrival landing before sending more traffic at it. Inbound relationship demand exists today and is being wasted.
• Cap the pair maths. 120 pairs at 16 charts, 79,800 at 400. Any “your notable relationships” feature needs pre-filtering.

The test — and it is a hard one on purpose. Not “people loved it.” Not “relationship engagement rose.” Not “shares increased.” Did attributable acquisition from this loop exceed enough of the existing user-loss rate to change the net growth curve? If it fails after a properly instrumented quarter, that's a real answer too. The only bad outcome is running it too loosely to tell the difference.

Premium is five annoyance-removals and one real capability

The structural problem: five of six are “the annoyance stops”, and the reading gate tightens the more someone uses the app. So the heaviest, most engaged users — exactly the ones most likely to pay — experience premium mainly as nag-removal. That is why a retained paying subscriber, asked directly, could not name a single benefit beyond “no ads.”

If new limits are added anyway — ranked by upside ÷ backlash

The competitor is not beating us on depth or accuracy — the things premium could gate — but on packaging and time-to-value, which is free to fix.

Four channels, and only one where the audience already exists

1. The website → app handoff the standout

~89,000 monthly web users and 54,872 search clicks per 28 days already exist. There is zero conversion tracking between the site and the app, so nobody knows how much of that earned attention ever becomes an install — and a known parameter-drop bug breaks part of the handoff before it can even be measured. Every other item below is a bet on manufacturing new discovery in a saturated market. This one is finding out how much already-earned discovery is silently leaking. It's plumbing, not a growth hack, and it's the only place the audience is already there.

2. Creator seeding pilot sized, not greenlit

Not paid placements — free premium access to creators in exchange for organic content. The one anecdotal signal that has ever worked for this product is that people are blown away when shown the app in person, and competitors can't replicate that on camera because they don't compute this depth.

3. Paid advertising not now — a triggered re-test, not a permanent no

At $0.20 per user per month, twelve-month value is $2.40 — which sits right at the bottom of the iOS lifestyle cost-per-install range ($2–4) and roughly matches Android's average ($1.92). That's break-even-to-marginal, not wildly unprofitable. The honest caution is that paid-acquired users typically retain worse than organic. Raising revenue per user to $0.35 would put twelve-month value at $4.20 — comfortably inside the range, and a real case rather than a break-even one. So: re-run this math once the premium layer ships, and if it's ever tried, pilot Android-only, which is both cheaper and the platform with the confirmed decline. compare against $1.78, not $2.40, when judging a live campaign — see B9

4. Press and store editorial free to attempt, unproven

• Apple's Featuring Nominations is a real, structured channel in App Store Connect. Lead time is 6–8 weeks realistically, up to three months ideally. Pitch the relationship loop, not “Chart Wrapped” — the loop is actually shipping this quarter. Working backwards from a mid-December ship, the submission window is early-to-mid November, and the feature must be demoable by then, not just described. Visual craft is reportedly the highest-weighted informal criterion, so an honest look at the relationship screen belongs in October.
• Google Play editorial is not an addressable channel at this scale — no public submission route, and editorial contact runs through an assigned account manager reserved for far larger publishers. The only real lever on that side is the algorithmic quality signal.
• “Chart Wrapped” is the stronger press story — genuinely hard to copy, because we retain multi-year chart history most astrology apps don't track. But it isn't scheduled, and pitching a feature with no build date is pitching vaporware. Park it until it has one.
• Fleet-data hooks — “the most common placement among X”, seasonal trend pieces — run on a real anonymised dataset most competitors don't have. Close to free to attempt, no guaranteed pickup.

Eighteen identified advocates, and nothing in the product serves them

Praise clusters on content depth and visuals, not on the interface — which confirms “the substance is better, the packaging isn't” from the opposite direction. Mostly from payers.

People volunteer gifting, promoting and reviewing, and no feature supports any of those actions. There is no gift flow, no referral path, no share-a-reading built for advocacy, and no prompt that catches someone at the moment they say it. One user gifted a lifetime subscription to her sister in 2019 — organic gifting happens today with zero product support and zero tracking. Another left a review before buying, then bought lifetime because of the experience: the advocacy-to-conversion loop running entirely by accident.

Four things to build, none needing new astrology: capture the moment (when someone expresses advocacy, that is the point to hand them the link — cheapest version is a prepared reply with a store link and a gift link) · a gift flow (it already happens manually, so it neither scales nor is measurable) · an individual referral path distinct from the creator-scale affiliate programme · a practitioner surface — client charts, sharing a reading with a client, export. The five professionals identified have the highest switching cost, the loudest professional networks, and the most to lose.

One user asked for Part of Fortune, got it, and came back with “thank you for hearing my requests” — a complainer converted into an advocate purely by visibly shipping what they asked for.

The value isn't only in the feature; it's in the reporter learning it shipped.

Already proposed, checked, and ruled out

Each of these was suggested in a previous pass and retracted after checking. They keep coming back, so they're written down.

• Don't gate the existing free chart and report depth. It's the one thing that produces the “blown away” reaction when the app is shown in person — locking it away kills the only organic signal that currently works.
• Don't merge the Report and Chart screens. Deliberately separate, both convert well, working as intended.
• Don't treat store-listing copy as a growth lever. Fix it once, cheaply — the current copy leads with “free and easy” instead of depth, and drops “horoscope” as a keyword — then stop iterating.
• Don't build offline calculation as a growth play. Real and worthwhile for practitioners handling other people's sensitive birth data, but it has no sharing mechanic and won't move installs.
• Don't replace the tarot free-text box. The 28-character typed question is the product — the only place in the app where users tell us in their own words what they want to know, and there are 4.5 million of them.
• Don't push tarot on the basis that it has “lowest reach.” That guidance was backwards: within any collection size, tarot users convert better.
• Don't chase organic social growth. A documented prior dead end for this brand — a 30k stale audience in a saturated niche. Targeted creator partnerships are a different thing and remain untested.
• Don't build non-English store screenshots. All non-English users combined are ~14%, split across 29 languages.

Decisions nobody else can make

1. The lifetime SKU — reprice, retire, or leave it

   45% of purchases, one SKU at $49.99 is 41% of all sales, and it's the largest structural cap on lifetime value. The only change with zero grandfathering risk, and everything else in the pricing conversation is downstream of it.

2. Are we adding new limits at all, or only new capabilities?

   The recommendation is additive-first, and there's a real case that a product already seen as harder to use than a cheaper competitor cannot afford a subtractive change. But this is a pricing call, not an analysis one.

3. Is localisation a premium feature or a free one?

   Effectively decided free by default. Gating it afterwards becomes a withdrawal rather than an addition. See B3.

4. Greenlight the $750 creator pilot?

   Yes/no, contingent on the relationship-loop attribution shipping first. The number it produces — a real, AstroMatrix-specific cost per install — doesn't exist anywhere today and can't be borrowed from industry benchmarks.

5. Commit to the November Apple nomination?

   Free, and rides on work shipping anyway, but it forces a date: the relationship feature must be demoable by early November, and the visual pass has to happen in October.

6. Is “Chart Operator” a named product surface or not?

   A workspace mode — client notes, last-seen, session history, pinning, transit alerts — for the practitioner segment. It doesn't fit inside the four-pillar story, so it needs an explicit yes or no rather than drifting.

The Matrix is the most-reached screen in the app after Home, and the second best at bringing people back. It is also the same screen every single time you open it. This is about closing that gap.

The Matrix is our simplification, not our complexity

It takes a birth chart — 29 bodies, several hundred aspects, a vocabulary that takes years to learn — and turns it into five words anyone can read: Purpose, Harmony, Love, Abundance, Evolution. That is the whole product thesis in one screen. Someone who knows nothing about astrology can open it and understand what they are looking at. No competitor ships the depth underneath it, and almost none ship a way in that is this gentle.

That last figure is the one to sit with. Months were spent treating “the app is too complex” as a Matrix problem. Of roughly forty-nine people who complained about the new interface, exactly one said the Matrix itself did not make sense. Everyone else said a version of “I cannot find a thing I already know exists.” Those are opposite problems with opposite fixes. Simplifying a screen that is already the simplification would make the product worse.

And because the Matrix's parts also render inside Home, the Moon screen and the weekly report, anything improved here lands on six surfaces at once. It is the highest-leverage screen in the product.

Three journeys — where people actually fall out

• Journey one — the newcomer, thirty seconds after signing up

  They finish a four-step setup — name, what they care about, birth date, birth place — and are dropped straight onto the Matrix, on the category they chose. This screen is the payoff for signing up. What they get is a radar chart and a grid of scored categories. After four screens of questions, the reward for answering is one more thing to navigate.

  The break: we asked them what they cared about and then handed them a menu instead of an answer. Reading one interpretation is the sharpest activation threshold measured — activity jumps from 2.7% to 17.9% once someone reads one. We route them to the door and do not walk them through it.

• Journey two — the returner, on their fourth visit

  They tap the Matrix tab. They see what they saw last time. Same categories, same scores, same cards, in the same order. By default the screen shows everything it knows at once — their birth chart and every current transit, merged into one list. Nothing says what is permanent and what is passing. Nothing says what is happening today.

  The break: a screen that never changes gives no reason to come back tomorrow. Retention is a smooth slide, not a cliff — 94% reach a second visit, 78% a fifth, 41% a twentieth. That shape is what “no fresh reason to return” looks like.

• Journey three — the person who was sent a link

  A friend shares their compatibility. The link opens the Relationship Matrix. Roughly half of these people are gone inside ten seconds — and among people arriving cold from a share link, 93% leave in under ten seconds. It is the worst-performing surface in the app. What greets them: no time filter at all, so there is nothing about right now. And in the default view, no Report button — the screen's main action is simply not rendered until you change a setting you do not know exists.

  The break: this is also the best monetisation signal. Adding a second chart moves conversion from 20.7% to 51.2%. The relationship surface is where that happens, and it is the one finished least. 72% of accounts have never opened it.

Almost every complaint is the same complaint

Time lord and profection year are on the Summary tab. They were never removed. This is the fourth separate confirmed case of a live feature being reported as deleted — the others were weekly and monthly transits, solar return interpretations, and saved charts.

This is the actual problem, said plainly. Not too much, not too hard — too flat. When every card looks like every other card, the eye has nowhere to land, and a person who knows the feature exists still cannot find it.

Worth taking seriously as a minority signal, not as a mandate. “Difficult to read through” is closer to the flatness complaint above than to a request for fewer features.

We are not failing to give people enough. We are failing to tell them what they are looking at.

Five moves, in the order to make them

• 1 · Make the screen different every day

  highest returnsmall buildno new data

  Right now cards are ordered by category — houses, then aspects — which never changes. But every card already knows whether its influence is active right now and how close it is to peaking. We compute this for every item and then ignore it completely. Sort by what is live and cresting today. Badge the active ones. The screen then changes on its own, every day, because those values move on their own.

  Why this one first: it is the only fix on this list that gives people a reason to return tomorrow, and it needs nothing we do not already have. It also sidesteps the argument about which default view is correct — the screen becomes time-aware without anyone choosing a default.

• 2 · Answer the question instead of showing the data

  high returnfree — no AI cost

  Every category already carries a pair of words and a count — Passion against Distance, Success against Obstacles, eight supporting influences against two challenging ones. The screen holds all of it and displays only the category name. Put one line under each category: “Intimacy & Romance — Passion 8, Distance 2.” That is the difference between a chart and an answer, and it is the thing the setup flow implicitly promised.

  It also fixes a quieter problem: the score bars scale to each person's own maximum, so no number on the screen means anything in absolute terms. Words give it a direction even when the bar does not.

  Keep the AI where it is. The deep written report stays behind the button — that is the payoff for tapping in, and it is genuinely good: people who reach a report spend 1.4 minutes there and 90% do not bounce.

• 3 · Fix the relationship first-run

  highest commercial upsideone engineering unknown

  The worst-performing surface is also the strongest conversion signal. Three things are wrong on arrival: the main action is invisible (in the default view the Report button is not shown at all); there is no “right now” (the solo Matrix has weekly, monthly and all-transits views — the relationship side has none); and we pick their partner for them (if an account has exactly two people saved, opening the Relationship Matrix silently pairs them and remembers it, changing what every other relationship screen shows, without asking).

  The unknown: the hidden Report button was disabled because that specific report was thought too large to save. The reasoning does not match how the app actually saves it, and the real limit looks to be roughly fifty times larger than the report. One measurement settles whether it can simply be turned back on.

• 4 · Stop features from feeling deleted

  medium returnreduces support load

  Four confirmed cases of people reporting removals that never happened. The Matrix makes this worse in a specific way: influences that have finished quietly disappear from the list. Correct behaviour, never explained. Someone who saw an aspect last week and cannot find it today concludes we took it away. Two cheap moves: say when a view is empty and why, instead of showing a blank panel; and give finished influences a visible “ended” state rather than vanishing them.

  The wider version: our depth is invisible — synastry 1.5%, composite 0.3%, the store 0.2%. We are not short of things to sell. We are short of people finding them.

• 5 · Don't lose people's reports

  low volumetiny buildhigh indignation per occurrence

  When a report is generated but fails to save — a network blip — we show a warning with a “View Now” button so the person can still read what they waited for. That button goes nowhere. It has never worked. Rare, but it lands at the worst possible moment: right after we told someone their thing was ready, and then lost it.

Three things not to do

The blocker: we cannot currently tell whether any of this worked

Everything measured is screen-level: how many people reached a screen, how long they stayed, whether they came back. Nothing tells us what they were trying to do, or what they tried just before giving up. Three things are missing, and each blocks grading the bets above:

• Session-level events — we count screen views, not app opens, so “visits” means something different from what everyone assumes when they read it.
• An app-version tag on stats — without it, no change we ship can be separated from any other change we ship. shipped 09-11 — see II §05
• Any A/B capability at all.

None of this should stop bets 1, 2 and 5 — they are small, obviously directionally right, and cheap to reverse. It should stop expensive or irreversible calls, like the default view, until the result can be read.

Evidence: production scan of 11 Sept 2026 covering 102,600 tracked accounts — the first pull after the instrumentation fix released on both platforms, so the first trustworthy one. Complaint analysis from 45 days of in-app support (756 users) plus store and Facebook backlogs. Engineering detail behind bets 3 and 5 is filed as issues 131, 132, 136 and 137.

A code-level stock-take of everything the product currently stores, observes or could derive about a person — and how much of a user knowledge profile is already sitting in production, unread. The suspicion behind this audit was right, and stronger than expected: three of the five layers already exist as production data.

Five headline findings

1. The most valuable fact we collect is thrown away in the same frame it is collected. Onboarding step 2 asks “What do you need answers about?”, requires an answer to advance, and never persists it — not to disk, not to the server, not even as an analytics label. It has been that way since the step shipped in df13e1ab (2025-12-22); git log -S selectedFacet shows nothing has touched it since.

2. A per-user behavioural store already exists in production and is write-only. stats.pagecounts and stats.avgs accumulate on every screen change and sync to Mongo. The only read anywhere in the app increments a separate ads counter.

3. Behavioural granularity is destroyed at three specific choke points — all fixable, none architectural. We can answer “how many people opened a relationship interpretation this week”; we cannot answer “has this user been reading relationship content”.

4. The AI knows nothing that distinguishes a returning user from a first-timer with the same chart. The richest AI request in the product sends a chart, a list of transit items, and a first name.

5. The interest taxonomy we would need to build already exists — as the 14 Self-Matrix and 12 Relationship-Matrix categories, already rolled up to the five onboarding facets by a tested mapping.

The ledger — identity and astrology, well covered

Every row was verified in source. Persistent means it survives app restart; AI means it reaches an AI prompt today.

Every chart, aspect, transit, progression, synastry, composite, draconic and return is computed on demand and cached disposably. No computed-chart collection exists anywhere — the engine README still lists “Database integration” and “Caching layer” as Not Implemented.

Behaviour — a real store exists, and nothing reads it

Where the granularity goes

Three choke points, each a deliberate past decision that was right for its own purpose and wrong for this one. The most consequential is a single line.

Choke 1 · The route already carries the answer, and drops it

The component name and its category are present in the route, at the call site, and are discarded one line later. We record that a user opened 200 interpretations; we never record which. This is the cheapest high-value fix in the document.

Choke 2 · Prometheus cannot carry a person

All metrics go to Prometheus counters and gauges. A session id is generated and deliberately left unattached — the comment at metrics_service.dart:30–52 spells out why: an unbounded label is one time series per session, a cardinality bomb. It ends: “It exists so session-scoped events can carry it once a real event store exists to receive them.” No such store was ever built.

Choke 3 · The one content metric carries category only

component_opened_total is labelled {category, source} — never the component name, never a user. Aggregate by construction. Firebase Analytics is not a second source: its whole surface is purchases, shares and four main-user diagnostics, it is disabled on web, and it joins to no user id we hold.

What reaches the AI today

Three AI endpoints exist. Two are reachable from the app, and the third is only used for translation.

Path 1 · Chart reports — POST /ai/calculatereport

Path 2 · Matrix reports — POST /ai/generateDataReport the main AI surface

Path 3 · GPTService — generic completion, one caller: translation

• No conversation exists. No chat surface, no follow-up, no history. specificQuestion is plumbed end-to-end in Node and unreachable from the client — the “ask about this reading” capability is built and unwired.
• AI history is a file, not a record. logAIInteraction appends to ai_log_YYYY_MM.json by rewriting the whole file, stores a first name and no user id, races across a clustered process, and has a user_feedback field that is always null. It is prompt QA, not memory.
• A working memory schema is one repo away. CrucibleChat defines per-user history with per-turn metadata, running stats, and a currentState block documented as “re-injected into next prompt”. It belongs to the quiz funnel, not the app — but it is a reviewed design for exactly this layer, already running against the same Mongo.

The model: facts, signals, inference

Twelve relationship lookups support relationship_interest: high. They never support has_relationship_problems: true.

Five layers, separated so an observation can never be promoted into a fact by accident. Facts and saved acts mostly exist already; signals need scoring; inference needs receipts and decay.

Action weights — intentional acts outrank passive ones

Scored with a 30-day half-life for current interest and 180-day for long-term themes, damped by novelty — ten opens of one component means attachment to that item, not interest in its domain. Nothing is reportable below 3 events across ≥2 distinct days.

An inference is only ever written with its receipts

The whole knowledge document is derived and disposable: delete it and it rebuilds from journals, events and settings. That single property is what makes “reset my personalization” a one-line delete, and what makes changing the scoring rules safe to ship.

The taxonomy already ships. The interest dimensions exist twice over, as the 14 Self-Matrix categories — Path & Career, Intimacy & Romance, Security & Roots, Soul Path & Karma, Emotional & Mental Health and ten more — and the 12 Relationship-Matrix categories. They are already rolled up to the five onboarding facets by a tested mapping in component_image_helper.dart:247–273, so Intimacy & Romance → Love is the same vocabulary the discarded onboarding answer speaks.

Retrieval, not ingestion

The profile is the index, not the payload. Each request assembles a budgeted context from ranked candidates: relevance × recency × actionWeight.

Summarising at write time rather than read time keeps this flat: a prior report costs ~40 retrieval tokens instead of ~1,500. A fully personalised Matrix report grows from roughly 2,500 to 4,000 prompt tokens — about +60% on a gpt-4.1-mini call, a rounding error against the revenue those reports gate.

Trust, and one thing to fix regardless

The design goal is that a user reading their own profile page thinks “yes, that's fair” — not “how do you know that?” Every stored claim carries its provenance, and inferred ones are dismissible in one tap, with the dismissal actually suppressing the inference rather than hiding it.

Forbidden outright: never infer or store sexual orientation, gender identity, religion, health or mental-health status, pregnancy, substance use, immigration status, financial distress, or the state of a relationship. These are exactly what astrology browsing tempts. Reading twelve “Intimacy & Romance” interpretations is a content preference. The permitted claim is always “you have been reading X”, never “you are Y”.

What to do first

Ordered by value ÷ effort, and specific to what already exists. Everything here is capture or repair — none of it depends on the model being right, and all of it makes the model possible.

1. Persist the onboarding facet

   One field, one line, today. A self-declared life priority collected from 100% of new users at the moment of highest intent, currently discarded between two function calls. Before any AI work it can order the home screen and pick the first Matrix tab.

2. Read stats.pagecounts

   Already in Mongo for every user. One read-only query answers “which categories does this person actually spend time in” — no new capture, no migration, no client release.

3. Stop stripping the query string

   One line in each of two files converts the most-used behavioural counter in the app from “opened the component screen 200 times” into real content history.

4. Write subjectPersonIds onto journal entries

   Additive to an existing Mixed field, so no migration. Unblocks the entire relationship model — and fixes the real bug where reopening a saved relationship report renders whoever the partner is now.

5. Harden journal access

   Do it before anything above enriches journal data.

6. Fix the Matrix AI language gap

   Small, self-contained, and the last English-only AI surface in the product.

7. Read the tarot questions

   Already in Mongo, already indexed, and the only unmediated user language the product holds. Even a manual read of a few hundred would inform the taxonomy and the prompt more than any inference engine.

8. Then start scoring

   Phase 2 and beyond only after the capture gaps are closed.

Item 1 alone is arguably worth more than Phases 2–5 combined per unit of effort. It should not wait for a roadmap.

Full audit with every file:line citation, the complete data structures, the event taxonomy, the privacy controls and the five-phase roadmap: docs/user-knowledge-audit-2026-09.md. Companion docs: built-but-disconnected-2026-09.md · strategy-reference-2026-09.md · product-strategy-2026-09.md.

Everything here is plausibly under half a day. Anything bigger was deliberately left out — the last block says what, and why. This is the most recently written of the seven, so where its issue numbers differ from the others, its are the current ones.

✓ verified in code or live on 2026-09-11    § from the docs, not re-verified

A · The price change

Lifetime $49.99 → $79.99, discounted lifetime $34.95 → $55.99. No new products and no app release — ✓ products_config.json carries no prices, ✓ no hardcoded prices in any .dart/.ts/.tsx, and ✓ the 30% discount works by swapping to a separate product id, not a coupon.

While in the consoles: grab the three real prices. The corrected store copy is blocked on exactly those, and the iOS listing is wrong today — it advertises a 6-month plan that does not exist, and “10 profiles free” when the real limit is 5.

B · Ship what is already fixed

Zero new code. ✓ Verified against git on 2026-09-11.

C · Quick code fixes

× · Deliberately excluded — not quick

Source: astromatrix-nodejs/docs/DEV-quick-wins.md. Companion to docs/ROADMAP.md, which carries the reasoning behind the price change and the engine correction.