Skip to content

Shimmy Global Strategy Suite

Description 12-year foundational business plan — six pillars, moderation & infrastructure briefs, market appendix, financials, risk and roadmap
Copyright © 2026 Shimmy Group Ltd. All rights reserved.

Table of Contents

Authors: Elliot Crabtree & Samira Elhamy  |  Status: In Review  |  Version: 0.1  |  Last updated: 23 July 2026 Part of: Shimmy Global Strategy Suite Related documents: Master Architecture Owner: Shimmy Strategy Team  |  Review cadence: Quarterly

This contents page mirrors the document order used in both the PDF and the MkDocs site.

It is intentionally sequence-based rather than page-number-based, because PDF page numbers shift whenever content is added, removed, or reformatted.

Reading Order

Part 1 — Business Plan

Part 2 — Master Architecture

Part 3 — Strategic Pillars

Part 4 — Deep-Dive Briefs

  • Infrastructure — current architecture, scaling path, and mid-term re-architecture
  • Shimmy Shield — moderation system design and longer-horizon trust-safety evolution

Part 5 — Appendix & Reference

Suggested Ways To Read

  1. Investor read: Executive Summary, The Ask & Team, Financials, Roadmap & Milestones
  2. Strategic read: Business Plan, Master Architecture, all six Strategic Pillars, then Market Appendix
  3. Technical read: Pillar II — Product, Pillar III — Operations, Infrastructure, Shimmy Shield, then References

Structural Notes

  • The Business Plan is now the first substantive section after this contents page.
  • Master Architecture is now a concise orientation document instead of a duplicate front-matter summary of later sections.
  • Working documents such as the template and TODO backlog have been removed from the primary navigation and print flow.

Business Plan

Executive Summary

The problem

Mainstream social platforms are optimised for engagement, not wellbeing. The dominant feed model rewards outrage and compulsive scrolling because that is what maximises session time and ad revenue — a design choice, not an accident. The measurable cost of this ("doomscrolling") is now well-documented: disrupted sleep, elevated anxiety, and a broadly held sense — reflected in the market research underpinning this suite — that time on these platforms leaves people worse off than when they arrived (see Market Appendix, Section B).

The solution

Shimmy is a purpose-driven social network built around "less doom, more do." Its core product primitive — Shimmies — are modular, adaptable social feeds that let users and communities compose the kind of feed they actually want (calm/curated, community, fundraising-native) rather than being locked into one engagement-maximising algorithm. Every post exists inside a Shimmy — there is no undifferentiated global feed to post into — and a post can carry text plus up to five images or videos, keeping content native to the context it was shared in rather than floating free of it. Trust and safety are handled by Shimmy Shield, an in-house AI moderation system, and giving is native to the product via a signed GoFundMe integration — not bolted on as a CSR afterthought (see Pillar II: Product and Pillar V: Philanthropy & Impact). Shimmy launches invite-only, a deliberate choice that protects trust density and moderation headroom during the growth-critical early period (see Compounding Growth & User Psychology).

Why now

Three trends converge in Shimmy's favour:

  1. Fatigue with incumbent platforms is measurable and growing — see the digital-wellbeing data underpinning the product thesis (Market Appendix, Section B).
  2. AI moderation and AI-leveraged small teams have only recently become viable at this quality/cost point — Shimmy Shield's tiered architecture (fast-pass classifiers backed by a slow-lane reasoning model) and the small-team operating thesis in Pillar III: Operations would not have been credible three years ago.
  3. Regulatory tailwinds — the UK's Online Safety Act regime rewards platforms that treat trust and safety as core infrastructure rather than a compliance afterthought, which is a genuine moat for a platform built trust-first from day one (see Shimmy Shield, Part 1).

Traction and current state

Shimmy is pre-launch, with a Laravel/PHP API backend, a Flutter/Dart mobile client, and Vue/TypeScript web and internal surfaces in active development by a small, fully remote team. Immediate engineering priorities include hardening authentication and completing the Shimmy Shield moderation pipeline's first tier.

The model

Revenue is blended across three mechanisms — advertising, subscription/premium tiers, and a fundraising take-rate — with the fundraising line being the genuinely differentiated one, since it scales with local charitable-giving culture rather than pure engagement (see Pillar I, Part 2.1). Full modelling detail, including sensitivity bands, is in Financials.

The ask

Shimmy is raising £1,000,000 via a SEIS/EIS-eligible round at a £5,000,000 pre-money valuation, to fund the team through launch and the first two international markets. Full detail — use of funds, cap table context, and team — is in The Ask & Team.

The 12-year arc, compressed

Timeline showing the four horizons: Horizon 1 (Years 1-3) UK launch and Tier 1 expansion, Horizon 2 (Years 4-5) fast-follow markets and predictive moderation, Horizon 3 (Years 6-8) decentralisation-aware moderation and trust-as-product, Horizon 4 (Years 9-12) agent-mediated interaction and global scale

Horizon What's true by then
Years 1–3 UK-first launch, Shimmy Shield reaches real-time multimodal moderation, Tier 1 markets (Ireland, Canada, ANZ) sequenced in
Years 4–5 Fast-follow markets live, moderation shifts from reactive to predictive, modular feed architecture opens to configurable/creator modules
Years 6–8 Decentralisation-aware moderation for a majority-synthetic-content web, provenance infrastructure doubles as fundraising-trust product
Years 9–12 Agent-mediated interaction, cognitive-defence-era moderation, physical presence and philanthropic infrastructure operating at global scale

Full detail in the Master Architecture and the six pillar documents it indexes.

Why this keeps compounding, and why we keep building

Shimmy's growth model isn't additive — see Compounding Growth & User Psychology for the full argument, but the short version is that trust-first moderation, resonance-tuned feeds, and shareable feed configurations are designed to reinforce each other rather than operate as separate initiatives. And V1 is a foundation, not a ceiling: Innovation Intent & Future Features sets out the standing commitment to keep shipping — starting with member and access tiers within individual Shimmies, extending the modular feed architecture already scoped in Pillar II: Product.

The Ask & Team

The ask

Shimmy is raising £1,000,000 via a SEIS/EIS-eligible priced equity round at a £5,000,000 pre-money valuation (£6,000,000 post-money). This figure and structure follow directly from the pitch materials previously prepared for this round; this document sets it in the context of the full strategy suite rather than restating the deck.

Term Detail
Raise amount £1,000,000
Pre-money valuation £5,000,000
Post-money valuation £6,000,000
Instrument Priced equity round (ordinary/preferred shares per final legal terms)
Tax relief SEIS/EIS eligible
Round type Seed

Company values

These values define how Shimmy builds product, operates internally, and scales internationally:

  1. User first
  2. Large scale, tangible positive impact
  3. Doing things differently and better
  4. Empowering and liberating others
  5. Conviction
  6. Straightforwardness
  7. Authenticity
  8. Astronomical thinking

Use of funds

Modelled against the headcount and tooling sequencing set out in Pillar III: Operations and the Forward Hiring Roadmap:

Category Allocation Rationale
Engineering & product headcount ~45% Covers the Phase 1 immediate hires (Senior Laravel Developer, ML Developer for content moderation, part-time UI/UX Designer) and early Phase 2 hires (Senior Flutter Developer) from the hiring roadmap
Trust & safety / moderation build-out ~20% Shimmy Shield Tier 1/Tier 2 build per the moderation brief — this is Shimmy's core differentiator and is treated as capital infrastructure, not a discretionary cost, consistent with Pillar III
Legal & compliance ~10% UK legal counsel (already flagged as a Phase 1 hire), Online Safety Act compliance groundwork, SEIS/EIS administration
AI tooling & infrastructure ~10% Budgeted as a percentage of the headcount cost it augments, per the tooling-as-infrastructure principle in Operations
Marketing & launch (UK beachhead) ~10% UK-first launch per the market sequencing in Pillar I
Working capital / contingency ~5% Buffer against the CAC and timeline uncertainty flagged throughout Pillar I's sensitivity bands

Runway this buys

At the burn rate modelled in Financials — Burn & Runway, this raise is sized to fund the team through UK launch and the first Tier 1 international market (see Pillar I's four-tier model), with the milestone sequencing detailed in Roadmap & Milestones.

Team

Founder

Elliot Crabtree — Founder & CEO. Runs and operates across every function of the business — product and design, engineering and cloud infrastructure, data, moderation strategy, and the cap table — with hands-on involvement that spans Shimmy's Laravel/PHP backend and Vue frontend (currently leading the authentication-hardening security work on the fix/auth-bypass-and-shimmy-image branch) through to company-wide strategic planning and fundraising.

Leadership team

Samira Elhamy — Chief Technology Officer. Runs the technical team and engineering process at Shimmy, including infrastructure and operations — the direct owner of the architecture documented in Infrastructure and Shimmy Shield's V1 implementation.

Current team

Shimmy operates with a small, fully remote team.

  • Aswathy Gopan — Backend Developer
  • Sahar Elhamy — ML Developer
  • Mitchell Ward — ML Developer

Governance

Board composition and decision-rights structure are under active definition and will be published as part of the final fundraising pack.

Hiring plan

The Forward Hiring Roadmap sets out two phases:

  • Phase 1 (immediate, pre-launch): Senior Laravel Developer, ML Developer (Content Moderation), UK Legal Counsel, part-time UI/UX Designer
  • Phase 2 (growth phase, 5,000+ users / +12 months): Senior Flutter Developer, ML Engineers, Distributed Systems Engineers, Infrastructure & Security Engineer, Cloud Architect, Security Engineer

Hiring sequencing beyond Phase 2 follows the pod-outstaffing logic in Pillar III: resource whichever pod is currently unable to own its outcome end-to-end.

Financials

Confirmed Model Structure

The model structure for Revenue(t), Cost(t), sensitivity bands, and tier-based CAC logic is adopted across the suite and is in active use for planning.

Assumptions Pending Validation

ARPU by tier, retention-curve inputs, and final quarterly burn values remain open until the live spreadsheet model is fully populated.

Revenue model

Per market, per Pillar I:

Revenue(t) = Addressable_Population × Penetration(t) × Blended_ARPU
Cost(t)    = CAC × New_Users(t) + Localisation_Fixed_Cost + Compliance_Fixed_Cost

Blended ARPU is deliberately not a single number — it separates three mechanisms that scale differently by market, per Pillar I:

Revenue line Scales with Notes
Advertising / sponsored content Engagement, regional ad-rate benchmarks Historically variable 3–5x across mature vs. emerging ad markets
Subscription / premium tier Disposable income, willingness-to-pay norms Expected to differ materially UK/US vs. Nordic vs. Gulf
Fundraising take-rate Local charitable-giving culture, average fundraiser size The differentiated line — directly tied to the GoFundMe integration; see Pillar V: Philanthropy & Impact

Illustrative S-curve showing Tier 1 market penetration over 36 months, with low, base, and high sensitivity bands

Cost model & CAC

CAC is modelled with an explicit Tier 1 vs. Tier 2/3 multiplier: typically 3–5x higher outside beachhead markets in year one, converging toward Tier 1 levels only after 18–24 months of brand-awareness compounding (per Pillar I). A single global CAC assumption is flagged there as the single most common error in early-stage international-expansion modelling — this plan does not make that error, and any future version of this document should preserve that discipline.

One further wrinkle worth modelling explicitly once real data exists: Shimmy's invite-only launch (see Compounding Growth & User Psychology, Loop 4) should suppress paid CAC materially during the invite-gated period, since growth is deliberately routed through invitation-based, near-zero-marginal-cost distribution rather than paid acquisition. The burn model below should treat early-period CAC as a distinct, lower-cost regime from the post-expansion CAC figures above, not blend them into one curve.

Illustrative chart showing CAC convergence: Tier 2/3 markets start at roughly 4-5x Tier 1 CAC and converge toward Tier 1 levels over approximately 18-24 months

Burn & runway

Quarter Headcount cost Infra & tooling Other opex Monthly burn Cumulative Runway remaining
Q3 2026 — — — — — —
Q4 2026 — — — — — —
Q1 2027 — — — — — —
Q2 2027 — — — — — —

This table should be driven directly from the £1,000,000 raise and the use-of-funds allocation — the runway figure here is what determines whether the milestone dates in Roadmap & Milestones are actually achievable before the next raise is needed.

Unit economics

Metric Definition Current value
CAC (Tier 1) Cost to acquire one user in beachhead markets To be confirmed
CAC (Tier 2/3) Cost to acquire one user outside beachhead markets (3–5x Tier 1 in year one) To be confirmed
LTV Present value of blended ARPU over expected retention To be confirmed
LTV:CAC ratio Standard health check To be confirmed
Payback period Months to recover CAC from cumulative ARPU To be confirmed
Donation completion uplift Increase in fundraiser completion rate vs. baseline platforms To be confirmed

Sensitivity — bands, not point estimates

Consistent with Pillar I: every market projection in this plan should ship as low / base / high bands, driven primarily by penetration-curve steepness and CAC-convergence speed — the two inputs with the widest genuine uncertainty. Pillar I is explicit that a single-point five-year revenue forecast for a market Shimmy hasn't entered yet is not a credible artefact for board or investor purposes. This document inherits that standard; any figures added here should arrive with bands and stated assumptions, not as bare numbers.

Compounding Growth & User Psychology

Why "compounding," specifically

Most social products grow additively: each pound of marketing spend buys a roughly fixed number of new users, and CAC stays flat or rises as easy audiences are exhausted. A compounding growth model is different — each new user makes the next user cheaper, stickier, or more likely to arrive organically. Shimmy has four structurally different compounding loops available, and the strategic priority is building the product so all four reinforce each other rather than competing for engineering time.

Shimmy's compounding growth loop: trust-first moderation leads to higher fundraiser completion rates, which leads to more successful fundraisers being shared, which drives organic growth at low CAC, which generates more community data and signal, which improves resonance-tuned feeds, reinforcing trust-first moderation

Loop 1 — Trust compounds into completion rate, completion rate compounds into organic reach

This is Shimmy's most differentiated loop, because it's structurally unavailable to engagement-first incumbents. Per Pillar I, Part 2.3, the provenance/trust infrastructure built for moderation directly increases donor confidence and thus fundraiser completion rates. A completed, successful fundraiser gets shared by the people it helped — genuinely, not incentivised — which is lower-CAC distribution than any paid channel. The loop only works if trust infrastructure (Shimmy Shield) keeps pace with growth, which is why Risk R-4 and R-5 (audit-log scaling, synthetic-spam resistance) are existential to this specific growth mechanism, not just technical hygiene.

Loop 2 — Resonance data compounds into better feeds, better feeds compound into retention

Per Pillar II, Part 4, Shimmy tracks resonance metrics (time-well-spent ratio, completed-intent rate, regret rate) alongside standard engagement metrics from V1 onward. The compounding mechanism: more usage generates more resonance signal, which tunes the Ranking Logic layer of the Shimmies architecture (Pillar II, Part 1.1) more precisely per community, which increases the odds any given session leaves someone better off, which increases retention and referral. This is the same data-flywheel mechanic that powers engagement-first platforms — Shimmy's bet is that optimising it against resonance rather than raw engagement produces a different, defensible feed quality rather than a worse one.

Loop 3 — Shared feed configurations compound into low-CAC distribution

Per Pillar II, Part 1.4, because Shimmy compositions are portable, storable objects, a user who builds a genuinely good feed can share it as a link/template others adopt. This is architecturally cheap once the Source Selector / Ranking Logic / Presentation Shell decoupling is built correctly, and it is a growth mechanic native to the product thesis rather than a bolted-on referral programme — it only exists because of a specific architecture decision, which is why Pillar II flags that decision as the single highest-leverage near-term engineering choice.

Loop 4 — Invite-only scarcity compounds into perceived value and curated quality

Shimmy launches invite-only. This is a deliberate growth-and-quality lever, not just an access-control decision, and it compounds through two separate, well-evidenced mechanisms:

  • Scarcity increases perceived value. Invitation-gated access is a well-documented driver of early adoption intensity — Gmail's multi-year invite-only period and Clubhouse's invite-only launch both converted scarcity into outsized word-of-mouth demand, precisely because an invitation signals both exclusivity and personal endorsement from the person extending it. Each invite sent is therefore a small, high-trust act of social proof — closer to Loop 1's fundraiser-sharing mechanic than to a conventional referral programme.
  • Gating access protects the two things Shimmy can't recover once lost: trust density and moderation headroom. An invite-only cohort lets Shimmy Shield's tiered moderation stack (see Shimmy Shield) and the Tier 0 pre-launch team (Pillar IV) scale into demand rather than being overwhelmed by it — directly consistent with the small-team-plus-AI-leverage thesis in Pillar III: Operations. A slower, invite-gated ramp is a genuine trust-and-safety control, not only a growth tactic.

The strategic risk to manage explicitly: invite scarcity is a growth accelerant only while it's genuinely scarce. Recommend the invite mechanism have an explicit, planned expansion trigger (tied to moderation-capacity headroom and Shimmy Shield's Tier 0/1 readiness, not an arbitrary date) so the transition from invite-only to open access is a deliberate Roadmap decision — see Roadmap & Milestones — rather than something that quietly erodes the exclusivity value before Shimmy is ready to defend open access with mature moderation infrastructure.

The user psychology this depends on

None of the above works unless the underlying behavioural bet is correct. Four psychological mechanisms are worth being explicit about, because they are testable, not just asserted:

1. Habituation and hedonic adaptation cut both ways

Engagement-maximising feeds rely on variable-ratio reinforcement (unpredictable rewards, the same mechanism behind slot-machine design) to sustain compulsive use even as satisfaction declines — this is well-established in behavioural psychology and is a large part of why time-on-platform and reported wellbeing have diverged industry-wide (see the doomscrolling data below). The same habituation mechanism can work in Shimmy's favour: if early sessions reliably leave a measurable positive residue (per the resonance metrics), that becomes the variable a user's habit forms around instead of pure novelty-seeking — a stickier, less extractive habit loop, but a habit loop nonetheless. This is a real psychological bet, not a purely feel-good one, and should be tracked with the same rigour as any other retention driver.

2. Social proof compounds fastest around identity-relevant causes

Donation behaviour is unusually sensitive to social proof from people the donor already trusts (per the donation-based crowdfunding data, campaigns with visible community backing convert meaningfully better than cold outreach). This is why Loop 1 above is structurally different from generic virality — a shared fundraiser isn't asking someone to try a new app, it's activating an existing trust relationship for a specific, legible cause, which has a much higher conversion ceiling than feature-based virality.

3. Fatigue is not the same as disengagement — it's latent demand

The data in Market Appendix, Section B is worth reading psychologically, not just statistically: 46% of UK adults actively avoiding news because of its emotional cost, and 91% of young UK women reporting negative mental-health impact from social media, are not people who have stopped wanting connection or information — they are people paying an emotional tax to get it from the only available channels. That gap between demand for the underlying need and tolerance for the current delivery mechanism is the actual market opportunity, and it should be monitored over time (see the tracking note below) rather than assumed permanent.

4. Calibrated friction increases trust rather than reducing engagement

A counterintuitive but evidence-supported point: interfaces that introduce small, legible friction at moments of potential regret (a pause before a large donation, a gentle prompt before an angry reply) tend to increase long-run trust and satisfaction even though they reduce short-run action rate. This is the psychological justification for Pillar II's stance on streaks and notification design — deliberately not manufacturing anxiety-driven return visits — and it should be treated as a genuine design principle to defend under growth pressure, not a nice-to-have that gets cut when a growth target is missed.

5. Scarcity and in-group belonging drive early intensity, but only if the "in-group" earns it

Invite-only access (Loop 4, above) works psychologically because scarcity and social endorsement are among the most robust findings in behavioural psychology — but the effect is conditional, not automatic. Scarcity that isn't backed by genuine differentiated value curdles into resentment once the novelty wears off (a well-documented failure mode of hype-driven invite-only launches that didn't have a real product underneath the exclusivity). Shimmy's position is stronger than a pure-hype invite mechanic because the exclusivity is doing real work — protecting moderation quality and trust density, per Loop 4 — which means the early cohort's experience should be measurably better, not just exclusively branded. This is testable against the resonance metrics in Pillar II, Part 4 and should be tracked as a specific hypothesis: does the invite-only cohort show higher resonance scores than a comparable open-access cohort would, or is the exclusivity purely perceptual?

The evidence behind the psychological bet

Bar chart showing doomscrolling and digital wellbeing statistics: 31% of US adults doomscroll regularly, rising to 46% of Millennials and 51% of Gen Z; 46% of UK adults report news avoidance; 91% of UK young women aged 16-24 report negative mental health impact from social media

This is the same data underpinning the Executive Summary's "why now" argument, but worth sitting with directly here: the generational gradient (31% → 46% → 51% from general US adults to Millennials to Gen Z) suggests this isn't a fixed trait but a worsening trend concentrated in exactly the cohort most valuable to a new social platform's long-run growth. This should be re-checked at each suite review — per the Market Appendix's own read, if UK news avoidance or doomscrolling prevalence starts declining, that's a signal to revisit whether "anti-doomscroll" remains the strongest lead positioning, rather than a permanent assumption baked into the brand.

What would falsify this thesis

In the interest of the evidence-over-assertion standard applied throughout this suite, it's worth naming what would indicate the compounding-growth bet is wrong, not just citing supporting data:

  • Resonance metrics fail to predict retention — if time-well-spent and completed-intent scores don't actually correlate with 30/90-day retention once real data exists, Loop 2 doesn't hold and the product should compete on conventional engagement mechanics instead.
  • Fundraiser-driven sharing shows normal, not elevated, conversion — if Loop 1's social-proof advantage doesn't show up in actual referral conversion data once measurable, the trust-first positioning is a cost without a compounding payoff and should be re-priced as pure brand differentiation, not a growth engine.
  • Friction reduces trust rather than building it — if calibrated-friction UX patterns simply reduce usage without an offsetting retention/trust benefit, that specific design principle should be revisited rather than defended on faith.
  • Invite-only exclusivity shows no resonance uplift — if the invite-gated cohort doesn't measurably outperform on resonance metrics once comparable data exists, the exclusivity is doing perceptual work only, not quality work, and the expansion trigger discussion in Loop 4 should move up rather than wait for a moderation-capacity milestone.

Tracking these three falsification checks is recommended as a standing quarterly review once V1 usage data exists, alongside the Risk Register's review cadence.

Innovation Intent & Future Features

The standing commitment

Shimmy is not building a fixed feature set and then maintaining it — the Modularity Ladder in Pillar II, Part 1.3 is explicitly designed so that new capability can be added as new modules rather than rewrites, and the small-team-plus-AI-leverage thesis in Pillar III exists specifically so that pace of innovation doesn't require proportional headcount growth. This document names the concrete directions that commitment currently points toward.

Member & access features within Shimmies — the near-term priority

The single most requested category of near-term product work, and a natural extension of the Modularity Ladder's Stage 2 (configurable modules) described in Pillar II, is giving communities and creators more control over who sees what, and what different members can do within a given Shimmy. Concretely, this points toward:

This sits alongside, not instead of, Shimmy's platform-level access model: Shimmy launches invite-only (see Compounding Growth & User Psychology, Loop 4 for the full growth and trust rationale). The features below are about within-Shimmy membership tiers once someone already has platform access — a second, finer-grained layer of access control, not a replacement for the invite gate at the platform level.

Tiered membership within a Shimmy

Rather than a single flat "member/non-member" model, individual Shimmies (particularly community and fundraising feeds) should be able to define their own membership tiers — a free/public tier, a supporter tier, and a closer-community tier — each with different visibility and interaction rights within that specific Shimmy. This is a direct extension of the Source Selector concept in Pillar II, Part 1.1: tier membership becomes another input the Source Selector can condition on, not a separate system bolted alongside the feed architecture.

Creator and organiser access controls

For fundraiser-native and community Shimmies specifically, the organiser should be able to grant specific members elevated access — co-organiser rights on a fundraiser, moderation delegation within a community Shimmy, or early/exclusive access to updates. This connects directly to two things already scoped elsewhere in the suite:

  • The Ranking Logic swappable per-community principle from Pillar II, Part 1.2, which already anticipates community-level configuration
  • The pod-level authority model from Pillar III, Part 1.2, which is the same "decoupled authority within a defined scope" pattern applied internally — worth building the product version of this pattern consistently with how Shimmy already organises itself internally

Supporter recognition and perks

Extending the "Meaning and Value" framework from Pillar II, Part 4: access tiers should be designed to reward prosocial behaviour specifically (consistent, verified support for a cause or community) rather than pure spend or pure engagement — directly consistent with Pillar II's existing caution against gamification mechanics that manufacture anxiety-driven return visits rather than genuine value. A supporter tier earned through verified donation history or sustained positive community participation is a fundamentally different mechanic from a paywall, and should be built and marketed as the former.

Extending the post model as tiering matures

Today, every post lives inside exactly one Shimmy and carries text plus up to five images or videos (see Pillar II, Part 1.2) — a deliberately simple, consistent unit across the whole platform. As within-Shimmy tiering above matures, the natural next question is whether post capability (not just visibility) should vary by tier — for example, a closer-community tier eventually supporting longer-form posts or a higher media count for verified organisers running an active fundraiser. This is flagged as a direction worth having, not a commitment: the five-image/video ceiling is a sound default for a calm, non-overwhelming feed, and any tier-based exception should be justified against the resonance metrics in Pillar II, Part 4, not granted as a default perk.

Why this is sequenced now, not later

Per the Modularity Ladder's own sequencing discipline (do not skip to Stage 3 early), member/access tiering is a Stage 2 capability — it extends the native modules already being built rather than requiring the third-party SDK ecosystem of Stage 3. That makes it realistic to scope within the Horizon 1 window in the Roadmap, rather than something that waits for the platform-ecosystem moment years out.

Broader innovation directions already seeded in the suite

The rest of the document suite already contains the seeds of a substantial forward roadmap — this section makes those explicit as directions of travel, not commitments with dates:

Direction Where it's rooted in the suite What it unlocks
Glanceable / cover-screen mode for foldables Pillar II, Part 2.1 A genuinely near-term, low-engineering-cost differentiator — check a fundraiser or a close-friend update without opening the full app
Voice-native donation and status-check flows Pillar II, Part 2.2 Targeted, not general-purpose voice support — fits the fundraising use case specifically
Configurable Shimmy composition (Stage 2 of the Modularity Ladder) Pillar II, Part 1.3 Users and community admins build their own feed logic from exposed primitives — member/access tiering (above) is one part of this
Third-party/creator modules and SDK (Stage 3) Pillar II, Part 1.3 The genuine platform moment — deliberately deferred until Stage 2 proves the abstraction holds
Provenance/authenticity badges surfaced in-feed Pillar II, Part 5; Shimmy Shield, Horizon 3 Visible trust signal on fundraiser content, converging product and trust/safety design
Agentic feed-assembly modules Pillar II, Part 1.3; Shimmy Shield, Horizon 4 Long-horizon — an agent curating a personalised fundraiser-discovery feed on a user's behalf, subject to the provenance layer
Moderation-as-a-service labeler Shimmy Shield, Horizon 3 A possible new product line if the social web decentralises as expected — Shimmy's calm-norms moderation stack licensed to other clients

Roadmap & Milestones

Timeline showing the four horizons: Horizon 1 (Years 1-3) UK launch and Tier 1 expansion, Horizon 2 (Years 4-5) fast-follow markets and predictive moderation, Horizon 3 (Years 6-8) decentralisation-aware moderation and trust-as-product, Horizon 4 (Years 9-12) agent-mediated interaction and global scale

Near-term milestones (next 2 quarters)

These are the concrete, currently-in-flight items, not horizon-level abstractions:

Milestone Target Status
Authentication-hardening branch (fix/auth-bypass-and-shimmy-image) merged Q3 2026 In progress — MySQL test connectivity, deleted_at migration, and auth test assertions outstanding
Shimmy Shield Tier 1 (fast-pass classifiers) live in staging Q3 2026 [TBC] Depends on the architectural transition described in Shimmy Shield
Seed round close (£1,000,000) [TBC — insert target close date] See The Ask
Phase 1 hires complete (Senior Laravel Developer, ML Developer, UK Legal Counsel, part-time UI/UX Designer) Within 1 quarter of raise close See hiring roadmap
UK closed beta [TBC] Precedes UK-first public launch

Horizon 1 — Years 1–3: UK launch and Tier 1 expansion

Aligned to Shimmy Shield's Horizon 1 and Pillar I's Tier 1 market definitions.

Milestone Target
UK public launch [TBC]
Shimmy Shield reaches real-time multimodal reasoning (moving off pure regex/keyword moderation) Within Horizon 1
First Tier 1 international market live (Ireland, Canada, or ANZ — see Pillar I for tier definitions) Year 2 target
Phase 2 hiring wave triggered (5,000+ users) — Senior Flutter Developer, ML/Distributed Systems Engineers, Infrastructure & Security Engineer Post-5,000-user threshold, per the hiring roadmap
GoFundMe integration live and generating measurable donation-completion uplift Within Horizon 1, tracked per Pillar I

Horizon 2 — Years 4–5: Fast-follow markets, predictive moderation

Aligned to Shimmy Shield's Horizon 2.

Milestone Target
Remaining Tier 1/fast-follow Tier 2 markets sequenced in Per Pillar I's four-tier model
Moderation shifts from reactive to predictive Per Shimmy Shield Horizon 2
Modular feed architecture opens to configurable/creator-built Shimmies Per Pillar II: Product
First physical-presence trigger point evaluated (see Pillar IV) [TBC]

Horizon 3 — Years 6–8: Decentralisation-aware moderation, trust-as-product

Aligned to Shimmy Shield's Horizon 3.

Milestone Target
Moderation architecture adapted for a majority-synthetic-content web Per Shimmy Shield Horizon 3
Provenance/authenticity-verification workstream converges with the GoFundMe/fundraising trust product line Explicitly flagged in Shimmy Shield's summary recommendations as a rare case of moderation infrastructure becoming directly monetisable
Tier 3 markets (per Pillar I) evaluated for entry Ongoing through Horizon 3

Horizon 4 — Years 9–12: Agent-mediated interaction, global scale

Aligned to Shimmy Shield's Horizon 4.

Milestone Target
Moderation unit redefined for agent-mediated interaction Per Shimmy Shield Horizon 4
Philanthropic infrastructure (Pillar V) operating at global scale, integrated across all live markets See Pillar V: Philanthropy & Impact
Physical presence and local activation network (Pillar III / Pillar IV) mature across primary markets See Pillar III: Operations

Risk Register

Top company risks

ID Risk Likelihood Impact Source Mitigation status
R-1 Auth-layer vulnerabilities block safe re-architecture work Medium High Infrastructure — re-architecture work (service boundaries, multi-region auth) is materially riskier against an unverified auth layer In progress — fix/auth-bypass-and-shimmy-image branch active; MySQL test connectivity, deleted_at migration, and auth test assertions outstanding before merge
R-2 Single-global-CAC modelling error in international expansion Medium High Pillar I — explicitly flagged as the single most common early-stage international-expansion modelling error Mitigated by design — Pillar I's model already builds in a Tier 1 vs. Tier 2/3 CAC multiplier; risk is in execution discipline, not methodology
R-3 UK Online Safety Act "duty of care" category threshold triggers stricter compliance requirements at scale Medium Medium–High Pillar I — flagged as needing formal legal assessment before scale triggers stricter thresholds Not started — needs a formal legal assessment commissioned, not left implicit
R-4 SQLite audit-logging cannot support multi-region rollout volume High (if unaddressed before Tier 2 rollout) Medium Infrastructure — explicitly flagged as a near-term, not distant, risk Planned — recommended migration to Aurora before, not during, first Tier 2 market rollout
R-5 Synthetic/AI-generated spam and coordinated inauthentic behaviour outpaces volume-based moderation heuristics High (structural, worsens over time) High Shimmy Shield — Horizon 3's "80%-synthetic-content world" Planned — shift to behavioural-economic signals (cross-session identity consistency, proof-of-personhood, cost-to-post models) sequenced into Horizon 3
R-6 Regulatory audit-log requirements (UK OSA, EU DSA) retrofitted late, at high cost Low (if acted on now) / High (if deferred) High Shimmy Shield — "regulatory alignment as embedded infrastructure, not compliance overhead" Planned — compliance logging designed to be built into the ML pipeline from day one, not retrofitted
R-7 AI coding agent output overstates verification (e.g. claims tests pass when they don't) Medium Medium Operational pattern observed directly in current engineering workflow (GPT-5.3-Codex output cross-checked against Claude) Ongoing mitigation — active practice of cross-checking AI agent output rather than trusting verification claims at face value
R-8 Pillar IV (Building & Growth) is incomplete beyond the current hiring roadmap High (blocks accurate milestone dating) Medium Pillar IV Not started
R-9 Fundraising readiness gaps — no cap table, no confirmed SEIS/EIS split, no governance structure documented High (blocks credible external fundraising) High The Ask & Team Not started
R-10 CAC/penetration assumptions presented as point estimates rather than sensitivity bands, undermining investor credibility Low (if discipline holds) Medium Pillar I — explicitly flagged as a credibility risk for board/investor-facing projections Mitigated by design — Financials document inherits the low/base/high band requirement; risk is in execution discipline

Risk heatmap plotting all ten company risks by likelihood and impact, with R-5 (synthetic spam) and R-9 (fundraising readiness) sitting in the high-likelihood, high-impact zone

Review cadence

This register should be reviewed on the same cadence as the Roadmap & Milestones document — recommended quarterly, with each risk re-rated and any newly closed mitigations moved to a "resolved" log rather than deleted, so the suite retains a record of what was addressed and when.

Shimmy Global Strategy Suite — Master Architecture

Shimmy

STATUS: DRAFT

A 12-year foundational plan, in six pillars.

Authors: Elliot Crabtree & Samira Elhamy  |  Status: Draft  |  Version: 0.1  |  Last updated: 20 July 2026 Part of: Shimmy Global Strategy Suite Start here: Executive Summary — a one-page, standalone read covering the problem, the model, and the ask. Related documents: Table of Contents · Infrastructure · Shimmy Shield · Pillar II: Product · References Owner: Shimmy Strategy Team  |  Review cadence: Quarterly

What This Document Is For

This page is the suite-level orientation layer. It explains how the document set is organised, what order to read it in, and how the business plan, strategy pillars, and technical briefs fit together.

For the full ordered contents, use Table of Contents.

  1. Quick investment read: Executive Summary, The Ask & Team, Financials, Roadmap & Milestones
  2. Full strategic read: Business Plan, Master Architecture, Strategic Pillars, Market Appendix
  3. Product and technical read: Pillar II — Product, Pillar III — Operations, Infrastructure, Shimmy Shield

Document Order

The suite is intentionally ordered in five layers:

  1. Table of Contents
  2. Business Plan
  3. Master Architecture
  4. Strategic Pillars
  5. Deep-Dive Briefs, followed by Appendix & Reference

That order is now shared by both the PDF and the MkDocs navigation so the site and exported document read the same way.

Architecture Summary

The suite is built around one central idea: Shimmy is not just another social platform. It is a trust-first, fundraising-native, modular social system designed to produce better user outcomes than engagement-maximising incumbents.

At the suite level, the architecture connects five planning layers:

  1. The business case: why the product exists, how it grows, what it needs financially, and what milestones matter first
  2. The strategic operating model: how market expansion, product sequencing, operations, physical presence, philanthropy, and long-term technology fit together
  3. The product system: Shimmies, moderation, trust, fundraising rails, and user-outcome metrics
  4. The infrastructure system: backend architecture, scaling, compliance, and multi-region readiness
  5. The reference layer: market evidence, source backing, and shared terminology

Company Values

These values apply across strategy, product, operations, and market expansion decisions:

  1. User first
  2. Large scale, tangible positive impact
  3. Doing things differently and better
  4. Empowering and liberating others
  5. Conviction
  6. Straightforwardness
  7. Authenticity
  8. Astronomical thinking

Strategic Pillars

Pillar I — Global Markets & Economic Expansion

Pillar I Research Brief — Shimmy Strategic Document Suite

Scope: This brief moves from the four-tier framework sketched in the master architecture to actual regional analysis, economic modelling methodology, competitive landscape, and the currency/payments implications of a fundraising-native platform expanding cross-border. It assumes the Product pillar's V1 scope (mobile/web, Shimmies, GoFundMe integration) as the thing being taken to market.

Part 1 — The Four-Tier Model, Populated

1.1 Tier 1 — Beachhead Markets

Criteria recap: English/near-English fluency, high smartphone penetration, low regulatory friction, cultural affinity with "calmer social" positioning, direct launch feasibility.

Market Why it fits Specific consideration
UK Home market, existing team/brand context, Ofcom's Online Safety Act regime is real compliance work but well-understood and already a design input via the moderation brief Regulatory: OSA "duty of care" categorisation will depend on user numbers/risk profile — worth a formal legal assessment before scale triggers stricter category thresholds, not after
Ireland Near-zero localisation cost, EU-adjacent for eventual DSA exposure without full EU-scale complexity yet, strong startup/tech-friendly ecosystem Natural bridge market before wider EU entry — GDPR compliance already required regardless, so minimal incremental cost
Canada High English fluency, mature fundraising/donation culture (relevant to GoFundMe-integration value prop specifically), smartphone penetration comparable to UK PIPEDA privacy regime distinct from GDPR — requires its own compliance review, not an assumed GDPR-equivalence
Australia / New Zealand High cultural affinity, strong charitable-giving norms, but higher CAC historically for social apps due to smaller total addressable population and higher ad costs relative to reach Best sequenced after UK/Ireland/Canada prove the model, given smaller absolute market size — good for validating international ops, not for early volume

Sequencing logic: UK first (home advantage), Ireland fast-follow (near-zero marginal localisation cost), Canada third (proves the model works with a genuinely separate regulatory regime), ANZ fourth (proves it works with real time-zone/ops distance).

1.2 Tier 2 — Fast-Follow Markets

Criteria recap: large addressable population, moderate regulatory complexity, mobile-first culture, visible gap versus local incumbents.

Candidate categories rather than a fixed list (this needs live market research to finalise, not assumption):

  • Nordic markets (Sweden, Denmark, Netherlands) — extremely high smartphone/social penetration, strong English fluency reducing localisation cost despite not being English-first, digital-wellbeing-conscious culture that may be unusually receptive to anti-doomscroll positioning specifically (worth validating via app-store sentiment analysis on existing platforms in-region before committing spend).
  • Germany — largest EU economy, but historically higher bar for data-privacy trust (relevant given Shimmy's trust-first positioning could actually be an advantage here, not just a compliance cost) and typically slower organic adoption curves for new social platforms versus UK/Nordic comparables.
  • Gulf markets (UAE, Saudi in specific segments) — very high smartphone penetration and strong charitable-giving cultural norms (zakat-adjacent giving culture may align unusually well with fundraising-native product), but requires serious content-moderation policy localisation given different regulatory/cultural content norms — should be scoped jointly with the moderation brief's regional policy variation work, not treated as a pure growth decision.

1.3 Tier 3 — Strategic/Regulated Markets

Criteria recap: high value but requires data-localisation or specific compliance builds before entry is viable at all.

  • EU broadly (beyond Ireland) once DSA systemic-risk-assessment thresholds become relevant at scale — this is a compliance-build-first market, meaning the audit-logging/rationale-capture infrastructure flagged in the moderation brief needs to exist before wide EU marketing spend, not after.
  • India — enormous addressable population and strong mobile-first growth, but data-localisation requirements and a genuinely different payments/donation infrastructure landscape (UPI-native flows) mean the GoFundMe-integration value prop needs local payment-rail work before the core product thesis even transfers.

1.4 Tier 4 — Long-Horizon Markets

Markets requiring fundamentally different product assumptions (offline-first design, feature-phone support, non-card payment norms) — explicitly deferred, revisit as infrastructure costs fall per the technology-horizon trajectory, not on a fixed calendar.

Part 2 — Economic Projection Methodology

2.1 Bottom-up model structure

For each market, project:

Revenue(t) = Addressable_Population × Penetration(t) × Blended_ARPU
Cost(t) = CAC × New_Users(t) + Localisation_Fixed_Cost + Compliance_Fixed_Cost

Penetration curve: model as a logistic (S-curve), calibrated against comparable platform launches in each region rather than a single global assumption — a Tier 1 English-market launch typically shows a materially steeper early curve than a Tier 2 market requiring localised marketing to build initial awareness. Recommend three named comparable-platform launch curves per tier as calibration anchors, sourced at the time each market's deep-dive is commissioned (comparable data ages quickly and should be refreshed at planning time, not assumed from today's figures).

Blended ARPU should explicitly separate three revenue mechanisms rather than a single blended number, since they scale differently by market:

  • Advertising/sponsored content ARPU (scales with engagement and regional ad-rate benchmarks — historically variable by 3-5x across mature vs. emerging ad markets)
  • Subscription/premium-tier ARPU (scales with disposable income and willingness-to-pay norms — likely to differ significantly UK/US vs. Nordic vs. Gulf)
  • Fundraising take-rate ARPU (the differentiated line — scales with local charitable-giving culture and average fundraiser size, which is why the Gulf/Nordic charitable-giving-culture notes in Part 1 matter economically, not just culturally)

CAC should be modelled with an explicit Tier 1 vs. Tier 2/3 multiplier (typically 3–5x higher outside beachhead markets in year one, converging toward Tier 1 levels only after 18-24 months of brand-awareness compounding) — a single global CAC assumption is the single most common error in early-stage international expansion modelling, and should be explicitly flagged as a red line in any board-facing projection.

2.2 Sensitivity, not point estimates

Every market projection should ship as low/base/high bands, not a single number — driven primarily by penetration-curve steepness and CAC-convergence-speed assumptions, since those are the two inputs with the widest genuine uncertainty. This matters specifically for board/investor credibility given the stated preference for evidence over assertion — a single-point 5-year revenue forecast for a market Shimmy hasn't entered yet is not a credible artefact, and presenting bands with explicitly stated assumptions is both more honest and more persuasive to a sophisticated investor.

2.3 Localised impact framing

Given the philanthropy/impact positioning, each market's economic model should carry a parallel impact-side projection: projected fundraiser volume, projected total donation value facilitated, projected donor-trust-driven completion-rate uplift (if the provenance/trust infrastructure from the moderation brief measurably increases donation completion versus baseline fundraising platforms, that's both an economic and a mission-relevant number, and should be tracked as one integrated model rather than two separate spreadsheets).

Part 3 — Localisation & Cultural-Fit

3.1 Beyond translation

Localisation for Shimmy specifically needs to cover, per market:

  • Content-norm localisation — direct extension of the moderation brief's "community-local norm embeddings," but at country/regional granularity for launch-market policy tuning (what counts as acceptable register, satire, political speech varies significantly by market and by regulatory regime).
  • Charitable-giving norm localisation — fundraiser categories, framing, and trust signals that resonate vary meaningfully (e.g., individual-need framing vs. community/collective framing) — this should be researched per-market before launch marketing is finalised, not assumed to transfer from the UK model.
  • Calm-positioning cultural fit — "anti-doomscroll" as a value proposition assumes a baseline of doomscroll fatigue in the target market; this should be validated (via app-store review sentiment analysis on incumbent platforms in-region, and/or lightweight market research) rather than assumed universal — it's plausible some markets show less fatigue-driven demand for calm positioning and need a different primary value prop (e.g., trust/fundraising-first framing) to lead with.

Part 4 — Competitive Landscape by Region

Rather than a single global competitive set, recommend the deep-dive maintain a per-market competitive matrix tracking: dominant incumbent(s), any local "calm social" or digital-wellbeing-positioned challengers already active, and — critically — any local fundraising-platform incumbents Shimmy's GoFundMe integration would compete or need to differentiate against (this varies significantly more by market than general social-platform competition does, since charitable-giving platforms tend to be more nationally fragmented than social networks).

This matrix should be a living, quarterly-refreshed artefact rather than a one-time snapshot in this brief — competitive landscapes in the social/fundraising space move fast enough that a static analysis ages out within 2-3 quarters.

Part 5 — Currency, Payments & Cross-Border Giving

5.1 The specific complexity of fundraising-native cross-border expansion

Unlike a pure social/ad-revenue platform, Shimmy's GoFundMe integration means cross-border expansion carries payment-rail complexity beyond typical app localisation:

  • Multi-currency donation handling — donors and fundraisers may be in different currencies; FX handling, transparency of conversion rates, and timing of settlement all directly affect donor trust (a donor who feels an opaque FX spread was taken is a direct hit to the trust positioning the whole platform is built on).
  • Local payment-rail integration — card-based flows dominate Tier 1 markets but are materially less relevant in some Tier 3 markets (UPI in India, for instance) — the GoFundMe-integration value prop doesn't automatically transfer without local payment-rail work, which should be scoped as a market-entry prerequisite for those markets, not a post-launch enhancement.
  • Regulatory: money-transmission and charity-law variation — fundraising platforms face different regulatory treatment by market (charity registration requirements, money-transmission licensing thresholds) that can be a harder gate than general social-platform regulation — recommend this be assessed jointly with legal counsel per-market before committing to a Tier 2/3 entry date, since it can silently become the actual bottleneck even when every other criterion looks favourable.

Part 6 — Initial Target Audiences & Content Categories

Alongside the geographic sequencing in Part 1, Shimmy's early go-to-market is anchored on four initial target audience/content categories. These define the content and community types the platform is built to serve first, ahead of broadening further.

6.1 Personal Life & Daily Moments (Lifestyle)

Core focus: Authentic connection, personal expression, and digital scrapbooking.

  • Purpose: social media functions primarily as a communication tool and personal archiving space.
  • Content types: everyday updates and candid moments; milestones, celebrations, and family/friend gatherings; "day-in-the-life" glimpses and personal reflections.
  • Audience vibe: relatable, informal, real, and relationship-driven.

6.2 Health, Fitness & Wellbeing

Core focus: Holistic self-care, physical improvement, and mental clarity.

  • Purpose: spanning physical fitness, mental health, wellness practices, and diet/nutrition.
  • Content types: workout routines and progress journeys; mindset, mindfulness, and mental health discussions; healthy recipes, nutrition tips, and wellness habits.
  • Audience vibe: empowering, encouraging, disciplined, and supportive.

6.3 Travel, Places & Nature

Core focus: Aesthetic exploration, escapism, and inspiration.

  • Purpose: high visual appeal paired with aspirational value.
  • Content types: scenic landscapes and nature photography; travel guides, city tours, and local spots; weekend getaways and bucket-list experiences.
  • Audience vibe: visual-first, inspiring, adventurous, and dreamy.

6.4 Entertainment, Educational & How-To

Core focus: Value-driven engagement through fun, curiosity, and skill-building.

  • Purpose: captivating attention through humour/storytelling or teaching actionable skills.
  • Content types: quick tutorials, tips, and life hacks; industry insights and step-by-step guides; memes, lighthearted commentary, and engaging challenges.
  • Audience vibe: informative, entertaining, dynamic, and shareable.

6.5 Quick category comparison

Category Primary focus Key content type Audience intent
1. Lifestyle Connection & memories Daily updates & milestones Sharing & keeping in touch
2. Wellbeing Self-improvement Workouts, mindset, nutrition Motivation & wellness
3. Travel & Nature Inspiration & escapism Scenic views & destination guides Aspirational planning
4. Edu-tainment Learning & amusement Tutorials, hacks, humorous clips Curiosity & value discovery

These four categories are the initial target areas informing early content strategy, moderation policy tuning, and creator/community seeding — not an exhaustive taxonomy. As the Shimmies architecture matures (see Pillar II: Product), further categories should be added based on observed usage rather than assumed upfront.

Pillar II — Product

Part 1 — Shimmies: From Feature to Platform

1.0 Current product baseline (as built)

Shimmy's product surfaces are currently delivered through:

  • Mobile app: Flutter/Dart client for core social and community usage.
  • Web and internal surfaces: Vue 3 + TypeScript stack for public marketing and internal operations tooling.
  • Core application API: Laravel 11/PHP 8.3+ backend with Sanctum bearer tokens plus API key middleware.
  • Content model in production: posts, comments, reactions, and Shimmy group workflows over versioned API routes.

1.1 What "modular social feed" actually needs to mean architecturally

The risk with "Shimmies" as currently scoped is that it stays a configuration feature (users toggle feed types) rather than becoming a genuine composition system (feeds are built from interoperable primitives that compound in value as more exist). The difference matters enormously for defensibility: a configuration feature can be cloned by a competitor in a sprint; a composition system with an ecosystem around it cannot.

Concretely, a Shimmy should be modelled as a triple:

Shimmy = (Source Selector, Ranking Logic, Presentation Shell)

  • Source Selector — where content comes from (a community, a topic graph traversal, a fundraiser category, a followed-account list, a hybrid).
  • Ranking Logic — how it's ordered (recency, curated, "calm" algorithmic dampening, trust-weighted per the moderation stack).
  • Presentation Shell — how it's rendered (card feed, story-strip, map-based for location-tied fundraisers, digest/summary mode).

Decoupling these three from day one — even while only shipping a handful of native combinations — is what allows later composability (Part 1.3) without a rewrite. This is the single highest-leverage near-term architecture decision, because retrofitting composability onto a monolithic feed implementation 18 months from now is materially more expensive than building the seam now while the surface area is still small.

1.2 Data model implications

Every post is created inside a specific Shimmy — there is no global, contextless compose action, and posting is always an act of posting in a Shimmy, not into the platform generically. A post carries text plus up to five images or videos. This is a deliberate constraint, not a current-scope limitation to relax later: it keeps every piece of content anchored to the community norms, ranking logic, and moderation configuration of the Shimmy it was authored in, which is the foundation the rest of this section's data model depends on.

The Source Selector / Ranking Logic / Presentation Shell split implies a content and interaction data model where:

  • Content objects carry portable metadata (topic tags, community ID, fundraiser linkage, provenance/trust signals from the moderation stack) independent of which feed(s) surface them — a post's origin Shimmy is fixed at creation, but the post object itself can still be surfaced, differently ranked and shelled, in other Shimmies' Source Selectors without duplication. Posting and surfacing are deliberately different operations: a user posts in exactly one Shimmy; a Source Selector elsewhere may choose to display that post downstream.
  • Ranking Logic should be swappable per-user or per-community, not global — this is both a product differentiator (communities set their own norms, echoing the moderation brief's "community-local norm embeddings") and a technical requirement for the eventual third-party module ecosystem.
  • User-level Shimmy compositions (which combination of selector/ranking/shell a given user has assembled) should be a first-class, storable, shareable object — this is what eventually allows users to share/export their feed configuration, which is a meaningfully viral, low-cost growth mechanic (Part 1.4).

1.3 The Modularity Ladder — sequencing

Reiterating and expanding the ladder from the master architecture:

Stage What ships Rough timing Strategic purpose
1. Native modules In-house-built Shimmies: community feed, fundraiser feed, calm/curated feed, "close friends" feed Now (V1/Beta) Prove the core mechanic and content model works before generalizing
2. Configurable modules Users/community admins compose from exposed primitives — choose source + ranking dampening + shell ~12–24mo Validates the triple-decomposition holds up under real usage patterns before opening to third parties
3. Third-party/creator modules SDK + review process for external developers/creators to publish Source Selectors or Presentation Shells ~Year 3–5 The actual platform moment — analogous to app-store/Shopify-app-style ecosystem value capture
4. Agentic modules Modules that actively curate/act (e.g., an agent that assembles a personalised fundraiser-discovery feed based on a user's stated causes, subject to the cognitive-defence/provenance layer from the moderation brief) Year 7+ Converges with Horizon 4 of the moderation brief — feed composition becomes agent-mediated

Do not attempt to skip to Stage 3 early. The temptation with a "modular" pitch is to overpromise an open ecosystem before the primitives are proven — this is the most common platform-strategy failure mode (shipping an SDK against an unstable core abstraction, forcing a breaking migration on early third-party developers, which poisons ecosystem trust permanently).

1.4 Growth mechanic embedded in the architecture

Because Shimmy compositions are portable, storable objects (1.2), the natural low-CAC growth loop is shareable feed configurations: a user builds a genuinely good "calm news + local fundraisers" Shimmy and can share it as a link/template others can adopt. This is architecturally cheap once the data model decision above is made correctly, and gives Shimmy a growth mechanic that is native to the product thesis rather than a bolted-on referral programme — worth prioritising in the roadmap specifically because it compounds with the platform strategy rather than competing with it for engineering time.

Part 2 — Platform & Device Roadmap

2.1 Near-term: mobile, web, and the flip/foldable form factor

Foldable and flip-form devices (cover-screen glanceable UI, vertical-fold aspect ratios when open) are a genuinely near-term, non-speculative product surface — not a Horizon-6 bet. Two specific implications for Shimmy:

  • Cover-screen/glanceable mode: Shimmy's calm positioning is unusually well-suited to a glance-then-decide interaction model (check a fundraiser's progress, see if a close-friends post needs a response, without opening the full app) — this is a low-engineering-cost, high-brand-coherence opportunity to differentiate from doomscroll-optimised competitors who have no incentive to build good glanceable summaries (a glance is the opposite of what maximises their session time).
  • Vertical-fold unfolded aspect ratio: card-based Shimmy shells generally adapt well; story-strip or map-based shells need explicit responsive testing — should be a checklist item in the design system, not an afterthought per-release.

2.2 Mid-term: wearable and voice-native surfaces

The realistic near-to-mid-term wearable use case for Shimmy is notification-and-glance parity, not full app parity — fundraiser milestone alerts, community check-ins. Voice-native interaction has a specific, non-generic fit for the fundraising use case (voice-initiated donation/status-check flows), which should be scoped as a targeted feature rather than a general "add voice support" initiative.

2.3 Long-term: agentic/ambient convergence

By the point agents mediate significant user interaction (see moderation brief Horizon 4), the Shimmies architecture decision in Part 1 pays off directly: a well-decoupled Source Selector / Ranking Logic / Presentation Shell system is exactly the shape needed for an agent to assemble a feed on a user's behalf, subject to the same provenance/trust layer. Product and trust/safety architecture should be reviewed jointly at this horizon rather than treated as separate roadmaps — recommend an explicit cross-functional review checkpoint once Stage 3 (third-party modules) is live, since that's the point where the two roadmaps' assumptions first have to hold simultaneously under real third-party pressure.

Part 3 — Feature & Social-Norms Codex

Every feature signals a social norm, whether intentionally designed or not. This should be an explicit, living document (not left implicit), because unexamined norm-signalling is where "calm social network" positioning most commonly erodes in practice. A few concrete examples worth codifying early:

  • Read receipts / "seen" indicators: signal obligation-to-respond, which is in direct tension with "calm." Recommend defaulting off, or making them opt-in per-community rather than platform-wide.
  • Follower/following counts: a core doomscroll-platform status mechanic; even displaying them prominently re-introduces the comparison dynamics Shimmy is positioned against. Worth a deliberate design decision (de-emphasise, or contextualise differently — e.g., "supporters" framing on fundraiser profiles rather than generic follower counts).
  • Streaks/gamification mechanics: powerful for engagement, directly in tension with "less doom, more do" if used to manufacture anxiety-driven return visits rather than genuine value. If used at all, should be scoped only to pro-social behaviours (consistent fundraiser support, community contribution) rather than app-open frequency.
  • Notification design: the single highest-leverage lever for the calm-vs-doomscroll distinction in practice — batched/digest notifications by default, with real-time reserved for genuinely time-sensitive items (a fundraiser you back reaching goal, a close-friend direct interaction).

This codex should be a required review step in the product spec process for any new feature, not a retrospective audit — the cheapest point to catch norm-misalignment is before a feature ships, not after usage data shows it eroded trust metrics.

Part 4 — Meaning, Resonance & Value: Making It Measurable

"Impact and resonance and meaning and value" is only a real product discipline if instrumented. Recommend defining and tracking resonance metrics alongside standard engagement metrics from V1 onward, reviewed with equal seriousness at the leadership level:

Metric What it captures How to measure
Time-well-spent ratio Whether sessions leave users better or worse off Lightweight post-session sentiment sample (occasional, non-intrusive prompt) compared to session-start baseline
Completed-intent rate Did the user achieve what they opened the app to do Instrumented task completion (checked a fundraiser, responded to a close friend, made a donation) vs. aimless scroll sessions
Regret rate Self-reported "wish I hadn't spent that time" Periodic lightweight survey, tracked as a north-star inverse metric
Real-world action rate Donations completed, fundraisers created/shared, offline meetups arranged via the platform Direct product-native tracking — this is Shimmy's most differentiated possible metric given the GoFundMe integration, and should arguably be the headline metric in investor and board reporting, not a footnote

The strategic point: these metrics only earn credibility if they're sometimes allowed to trade off against engagement/DAU in actual product decisions — if resonance metrics are tracked but never override an engagement-maximising decision, they become marketing theatre rather than product discipline, which undermines the brand positioning they're meant to support.

Part 5 — Trust & Moderation Integration Points

This section deliberately doesn't duplicate the existing moderation brief — it flags the specific points where Product and Trust/Safety architecture must be co-designed rather than sequenced:

  • Community-local norm embeddings (moderation brief, Horizon 1) require the Shimmies data model to expose community/context identifiers cleanly — this is a shared dependency, not two separate features.
  • Provenance/authenticity signals (moderation brief, Horizon 3) should surface directly in the Presentation Shell layer (e.g., a trust badge on fundraiser content) — this is a product decision as much as a trust decision, and should be designed jointly.
  • Resonance metrics (Part 4) and moderation's calibrated-abstention design both depend on capturing user sentiment/state without being intrusive — worth sharing instrumentation infrastructure rather than building two parallel lightweight-survey systems.

Summary: What to Build Now vs. Defer

Build now (V1–18mo):

  • The Source Selector / Ranking Logic / Presentation Shell decoupling — even for a small number of native Shimmies, this seam must exist before the surface area grows.
  • Glanceable/cover-screen mode for foldable form factors.
  • Notification-design overhaul as the primary lever for calm positioning.
  • Resonance metrics instrumentation (start collecting even before it drives decisions, so there's a baseline).

Defer deliberately (Year 2–5):

  • Configurable module exposure to end users (Stage 2) — only once native Shimmies prove the abstraction holds.
  • Third-party SDK (Stage 3) — resist pressure to announce this before Stage 2 is validated in production.

Long-term, revisit as context changes (Year 6+):

  • Agentic modules and full agent-mediated feed composition — track alongside the moderation brief's Horizon 4 rather than planning in isolation.

Pillar III — Operations

Pillar III Research Brief — Shimmy Strategic Document Suite (Revised)

Scope: This brief treats operations as a design problem, not an admin function — how Shimmy stays a small, high-density team while operating globally, by making AI-leverage and tooling architecture a first-class strategic decision rather than a cost-centre afterthought. The thesis: headcount growth and capability growth should be decoupled wherever modern tooling makes that possible, and every hire should be evaluated against "does this need a person, or does this need better infrastructure." This revision adds an explicit local activation function — how a small core team gains the ability to stand up bigger, on-the-ground capacity fast, without carrying that capacity as permanent headcount.

Part 1 — The Small-Team Thesis

1.1 Why this is a real strategic bet, not just a cost preference

Historically, company capability scaled roughly linearly with headcount. That assumption is now false in specific, identifiable domains — and the strategic opportunity is to build Shimmy's organisational design around where it's false, rather than assuming it's false everywhere (a common overcorrection) or nowhere (the default legacy assumption most competitors are still operating on).

Domain Is AI-leverage genuinely changing headcount-to-output? Implication
Software engineering (implementation) Yes — materially compresses spec-to-shipped time for well-scoped work Senior architecture/design ownership still needs a human; implementation capacity does not scale 1:1 with headcount any more
Content moderation operations Yes — human headcount scales with Tier 2 escalation volume, not total content volume, if tiering is built correctly Direct extension of the moderation brief's tiered-inference architecture
Customer/community support Partially — AI-assisted triage and first-response drafting compresses response time for well-understood query classes Novel or emotionally sensitive cases should still be explicitly routed to a person, not auto-handled
Market/competitive research, first-pass analysis Yes — a small strategy function augmented by AI research tooling can credibly do work that used to need a larger analyst team A human must still own judgement and validation on top
Senior engineering leadership, legal/regulatory judgement No Should scale conventionally with headcount — treating these as leverageable is the most common failure mode of "lean team" strategies
Community trust relationships, partnerships, regulator relationships No Genuinely relationship-bottlenecked; not substitutable by tooling
Creative/brand direction No Judgement-heavy, low AI-leverage today

1.2 The Pod Model

Recommend structuring teams as small, cross-functional pods (typically 3–6 people) each owning a complete outcome end-to-end, rather than functional silos (a "backend team," a "moderation-ops team") that require coordination overhead to ship anything. Each pod should have a clear, single outcome it owns, direct access to the AI-tooling stack relevant to its domain, and explicit authority to make small, independently reviewable changes within its scope without cross-pod sign-off — the same principle already applied to code review, extended as an organisational principle.

This is the structural mechanism that keeps Shimmy small and globally capable: pods can be geographically distributed without needing a large central coordination layer, because each pod's scope is genuinely decoupled.

Part 2 — The Modern Tooling Stack as Infrastructure, Not Perk

2.1 Treat AI-tooling investment as capital infrastructure, budgeted like headcount

The single biggest operational-strategy mistake available here is treating AI tooling as a discretionary software-licence line item rather than the thing that determines whether the small-team thesis holds. Recommend an explicit annual tooling budget benchmarked as a percentage of the headcount cost it's replacing or augmenting, reviewed with the same rigour as a hiring plan.

2.2 Build vs. buy, applied consistently

Category Default Rationale
Coding agents / dev tooling Buy (best-in-class vendor) Not a differentiator; the differentiator is what Shimmy builds with the tool
Moderation Tier 0/1 inference Buy (API-based) at current scale; revisit self-hosting only above a defined volume threshold Consistent with the moderation brief's own conclusion
Support/community-ops automation Buy for triage/drafting; build the routing logic that decides what stays automated vs. escalates The routing logic is the actual brand-alignment decision and shouldn't be outsourced
Growth/localisation research tooling Buy general research tooling; build the market-tiering/scoring framework on top (Pillar I) Same pattern — the framework is proprietary, the raw tool is not
Internal knowledge/process documentation Build lightweight, AI-searchable internal documentation from day one Highest-leverage low-cost investment for staying small; cheap now, expensive to retrofit once knowledge is tribal

2.3 The Operational Maturity Curve, applied per function

Map each function (engineering, moderation-ops, growth, finance, support, local activation — see Part 5) against a five-stage maturity model independently, and resource the tooling/process investment toward whichever function is the actual current constraint, not uniformly. A useful quarterly diagnostic: which function, if it broke today, would most visibly and immediately hurt the company? That is the function to invest in next.

Part 3 — Global Reach Without Headcount Sprawl

3.1 Distributed-by-design, not distributed-by-accident

  • Time-zone banding: organise pods to cluster within roughly a four-hour overlap window internally, even if the company spans many zones overall.
  • Follow-the-sun only where it's genuinely valuable: apply true 24-hour coverage surgically to Tier 2 moderation escalation and infrastructure/incident response, not company-wide.
  • Market-embedded pods for localisation-heavy work: for Pillar I's Tier 2/3 markets, a pod with genuine local presence materially outperforms a fully remote-from-elsewhere approach for culturally sensitive work — one of the few cases where physical/cultural proximity is not substitutable by tooling.

3.2 Headcount sequencing

Building on the already-identified post-investment hires (DevOps Lead, Senior Backend Developer), the next hiring wave should be evaluated against "which pod is currently understaffed to own its outcome end-to-end," not "which department feels thin" — the former keeps the organisation lean and outcome-aligned.

3.3 The efficiency metric that actually matters

Track output per fully loaded headcount pound, segmented by pod, as the core operational efficiency metric. If a pod's tooling investment isn't showing up in this ratio within a defined review window, that's a signal to fix adoption or reallocate the budget to headcount, not to keep the investment on faith.

Part 4 — Process & Incident Discipline

A small team has less slack to absorb the cost of lost institutional knowledge, so process documentation and incident-response discipline should be proportionally more rigorous per person, even though the absolute overhead is lower.

Minimum viable discipline recommended from the current stage onward:

  • A living incident-response runbook for infrastructure outages and trust & safety escalations — this should already exist given the active auth-bypass security work, and should be generalised as a template for future incident classes.
  • Documented, versioned decision logs for pod-level architectural and policy decisions, not just code — the same rationale-capture discipline the moderation brief recommends for compliance, applied internally for institutional memory.

Part 5 — The Local Activation Function

5.1 The problem this solves

The pod model keeps the permanent core small. But certain situations genuinely need more hands, in a specific place, fast: a market launch, a moderation-policy crisis in a specific region, a large-scale fundraising surge tied to a real-world disaster event, or a regulatory/PR event requiring local on-the-ground representation. Carrying that capacity as permanent headcount defeats the small-team thesis. The answer is a tiered activation network — a designed capability to scale temporarily and locally, not a standing large team.

5.2 The three tiers

Tier Composition Activation time Typical trigger Cost model
Tier A — Core Pods Permanent, small, cross-functional (Part 1.2) Always on Day-to-day operations Fixed headcount cost
Tier B — Local Activation Network Vetted freelance/contract specialists and regional community leads, on a standing retainer or "on-call" agreement, pre-briefed on Shimmy's tools and standards 24–72 hours Market launch surge, moderation-policy incident in a specific region, urgent localisation need Retainer (low fixed cost) + activation-day rate
Tier C — Community & Support Groups Volunteer ambassadors, power users, charity/NGO partners already embedded in a market or cause area 1–2 weeks to mobilise at scale Large-scale fundraising surge (disaster response, high-profile cause), grassroots market-entry support Largely non-monetary (recognition, early access, platform features) with a small coordination budget

5.3 What needs to exist before this is activatable

A network like this only works if it is built ahead of need, not assembled in a crisis:

  • A maintained roster of Tier B specialists per target market, pre-vetted and pre-briefed, reviewed quarterly for currency — an idle roster six months out of date is not meaningfully faster than starting from zero.
  • A lightweight onboarding kit (brand, tone, moderation policy basics, tooling access) that can bring a Tier B or Tier C contributor to baseline competence in hours, not weeks.
  • Pre-negotiated activation terms (day rates, notice periods, data-access agreements) agreed in calm periods, not renegotiated under time pressure during an actual surge.
  • A clear owner: one core pod (likely sitting alongside growth/community) should own the roster and the activation playbook as its actual outcome, so it doesn't fall into the gap between functions.

5.4 Worked example — disaster-response fundraising surge

Phase Who acts Timeframe
Trigger identified (major disaster, high fundraiser-volume spike detected) Core moderation/trust pod monitoring Hour 0
Tier B activation for the affected region (moderation-policy review, local-language support, verification support) Local Activation Network Hours 24–72
Tier C mobilisation (NGO partners, ambassadors amplifying verified fundraisers, community moderation support) Community & Support Groups Days 3–10
Stand-down and roster review (what worked, update playbook) Owning core pod Within 2 weeks of surge ending

This tiered structure is what lets the earlier claim — "small team, global reach" — hold up under real pressure rather than only in steady-state conditions, which is usually where lean-team strategies are first tested and most often found wanting.

Summary: The Operational Bet, Stated Plainly

Shimmy's operational strategy is a bet that AI-leverage lets outcome-ownership scale faster than headcount, provided four things hold: pods are structured around complete, decoupled outcomes rather than functional silos; tooling investment is budgeted and scrutinised like headcount rather than treated as a perk; the genuinely human-bottlenecked functions are explicitly protected from over-automation; and a pre-built local activation network exists so the company can scale temporarily and locally without carrying that capacity permanently. The risk to actively guard against is treating "small team" as a headcount target rather than as the consequence of getting these four things right.

Pillar IV — Building & Growth (Physical Presence)

Pillar IV covers physical presence, real estate, and scaling infrastructure as team size and user volume grow.

Forward hiring roadmap (immediate → +12 months & scale)

Forward hiring roadmap: Phase 1 immediate/pre-launch hires (Senior Laravel Developer, ML Developer for content moderation, UK legal counsel, part-time UI/UX designer) and Phase 2 growth-phase hires at 5,000+ users (Senior Flutter Developer, ML Engineers, Distributed Systems Engineers, Infrastructure & Security Engineer, Cloud Architect, Security Engineer)

This roadmap defines two hiring phases: pre-launch hiring and a second phase triggered at 5,000+ users.

Pillar V — Philanthropy, Impact & Outbound

Pillar V Research Brief — Shimmy Strategic Document Suite

Scope: This brief moves "making the world a better place" from a mission statement to a structured, measurable, financially coherent programme — one that reinforces the "less doom, more do" brand rather than sitting beside it as a separate initiative. It draws directly on the GoFundMe integration (Product pillar), the Tier B/C activation network (Operations pillar), and the trust/provenance work (moderation brief) as shared infrastructure rather than treating philanthropy as its own silo.

Part 1 — Three Concentric Circles of Impact

Circle What it is Primary mechanism Owner
1. Product-native impact The GoFundMe integration itself functioning as real philanthropic infrastructure Verified fundraising, trust signals that increase donor confidence and completion rates Product pillar, jointly with Trust & Safety
2. Company-native impact A defined, disclosed share of revenue or profit directed to causes aligned with the platform's mission Formal giving programme (Part 2) Dedicated impact function, reporting to leadership
3. Industry-native impact Outbound advocacy and standard-setting Participation in cross-industry trust/provenance consortia (moderation brief, Horizon 2–3) Leadership + Trust & Safety

The strategic point, stated plainly: Circle 1 is where philanthropy and product economics genuinely overlap, and should get first-priority investment, because it is simultaneously mission-fulfilling and commercially additive — a rare combination worth deliberately over-resourcing relative to Circles 2 and 3 in the early years.

Part 2 — Giving Model & Mechanism Design

2.1 Options, compared honestly

Model Description Strength Weakness
% of revenue pledge Fixed, disclosed percentage of revenue directed to a cause fund Simple, publicly verifiable, credible to press/investors Can feel disconnected from the product if not tied to platform activity
% of fundraising take-rate matched Shimmy matches a portion of its own take-rate on completed fundraisers with additional platform-funded contribution Directly reinforces the product's core value proposition; scales naturally with platform usage More complex to administer; take-rate economics need to support it
Employee/community-directed fund A pool of committed funds, allocation partly decided by staff or community vote Strong internal culture and community-engagement value Weaker as an external, easily-communicated headline commitment
Cause-matching on user-created fundraisers Shimmy tops up donations toward specific high-priority or verified causes (e.g., disaster response) at moments of surge Ties directly into the Tier C activation network from the Operations brief; highly visible, timely Needs the activation-network infrastructure to already exist to execute credibly at speed

Recommendation for further validation (not a final number — this needs your input and real unit-economics modelling): a hybrid of the take-rate-matching model as the steady-state mechanism, with surge-matching activated through the Tier C network for major disaster/high-priority events. This is the option most structurally coherent with what Shimmy already is, rather than a generic CSR bolt-on.

2.2 Coherence check

Before finalising any mechanism, run it against a simple test: does this giving model make the core product better, or does it sit next to the product? A take-rate-matching model passes (it increases the credibility and completion rate of every fundraiser on the platform). A generic annual charity-of-the-year donation, disconnected from platform activity, does not — it may still be worth doing, but shouldn't be presented as central to the brand story if it is.

Part 3 — Impact Measurement Framework

Philanthropy needs the same rigour as revenue reporting, or it becomes marketing rather than discipline — directly echoing the resonance-metrics discussion in the Product brief.

Metric What it captures Reporting cadence
Total donation value facilitated (platform-wide) Headline scale metric Quarterly
Fundraiser completion-rate uplift vs. industry baseline Whether the trust/provenance infrastructure is measurably improving donor confidence — ties directly to the moderation brief's provenance work Quarterly, once baseline data exists
Company-matched/contributed value The direct cost/commitment of Circle 2 Quarterly, disclosed publicly
Surge-response activations and outcomes How the Tier C network performed against real events Post-event, per activation
Verified-cause diversity Whether giving/matching is concentrated in a few large causes or genuinely broad, to avoid the programme looking curated for PR rather than authentic Annually

Recommend these sit in the same reporting rhythm as the Product pillar's resonance metrics, reviewed by leadership with equal seriousness — and, per the same discipline flagged in that brief, only credible if these numbers are occasionally allowed to justify a cost (matching-fund spend, activation-network retainer cost) that a purely engagement- or revenue-maximising view would not.

Part 4 — Outbound & Advocacy Positioning

4.1 Where philanthropy and competitive moat overlap

Joining or co-founding industry consortia for content provenance and coordinated-behaviour detection (flagged in the moderation brief's Horizon 2–3) is simultaneously an act of genuine industry good and a defensive strategic move — early participants in standard-setting bodies disproportionately shape the standards that later become compliance requirements for everyone. This should be planned and resourced as one workstream, owned jointly by Trust & Safety and the impact function, not treated as two separate initiatives competing for budget.

4.2 Policy engagement

Given the UK base and the direct relevance of the Online Safety Act regime (moderation brief, Part 1), proactive rather than purely reactive engagement with regulators and policy bodies is worth scoping as a deliberate outbound function — a small, purpose-driven platform that engages constructively and early tends to be treated as a credible voice in shaping proportionate regulation, which is a genuine asset relative to larger incumbents seen as adversarial to regulators by default.

Part 5 — Brand-Philanthropy Coherence Check

A short, honest test to run before any philanthropy initiative is greenlit, worth keeping as a standing checklist rather than a one-off exercise:

  1. Does this reinforce "less doom, more do," or could it belong to any generic tech company's CSR page?
  2. Does it use infrastructure Shimmy already has (GoFundMe integration, trust/provenance layer, activation network), or does it require building something parallel?
  3. Is it measurable with the same rigour as a product or revenue metric, not just a feel-good annual summary?
  4. Would it survive being scrutinised by a sceptical journalist or a sceptical investor equally well?

Any initiative that fails more than one of these is worth reconsidering before commitment, not after launch.

Pillar VI — Technology Horizon

Scaling Architecture (Under 10K Users)

Shimmy scaling architecture diagram — data flow from client through moderation pipeline to feed generation

2.1 Stack design

1. Client & Edge Layer

  • Global User Clients: Users access the platform via Mobile Apps (iOS/Android) or tablets using standard secure protocols (HTTPS) for traditional requests and WebSockets (WS) for real-time updates (like feeds or notifications).
  • API Gateway: Acts as the single entry point for all client traffic. It handles:
  • Rate Limiting: Protects downstream services from being overwhelmed or attacked.
  • Authentication (JWT): Validates user identity tokens before routing traffic.
  • Request Routing: Directs user traffic either to the Core Social Services or Moderation Services.

2. Core Social Services & Primary Data Stores

This is the operational heart of the application where everyday user actions happen.

  • Core Social Services: Split into three decoupled microservices:
  • A. Research & Paper CRUD: Handles the creation, reading, updating, and deleting of academic papers. Because papers scale massively, this service talks to a Vitess-managed sharded MySQL cluster, split across multiple physical shards (SHARD_0, SHARD_1, SHARD_2) using a research_paper_id partitioning key.
  • B. Researcher Profiles & Feed Generation: Manages user feeds and timelines using native MySQL JOIN operations.
  • C. Identity & Relations: Manages user accounts, followers, and social graph connections, storing this data in a dedicated Identity, Profiles, & Relations MySQL database.
  • Redis Cluster: A high-speed, in-memory database used for global caching, fast timeline retrieval, user session data, and aggregating quick model votes.

3. The Event Ingestion & Asynchronous Queue

When a user uploads a paper or makes a post, it must be checked for toxicity or policy violations before going live globally.

  • POST_CREATED Event Ingestion: As soon as a post is made, a direct SQL insert injects a POST_CREATED event into a Moderation Queue.
  • MySQL SKIP LOCKED State: The queue uses a native MySQL concurrency feature (SELECT ... FOR UPDATE SKIP LOCKED). This allows multiple background worker processes to grab incoming posts simultaneously without locking the same row or stepping on each other's toes, making it an incredibly lightweight and fast volatile message queue.

4. Moderation Services (The AI & Human Pipeline)

This section uses an asymmetrical "Fast vs. Slow" design to balance speed with deep reasoning. Workers pull tasks asynchronously from the queue.

  • Tier 1: Fast Pass Workers (RoBERTa): Optimised for pure speed (<50ms processing time).
  • Uses a smaller language model (RoBERTa) to perform a rapid toxicity check. If a post is overwhelmingly clean, it passes immediately.
  • Tier 2: Slow Lane Workers (Gemma 3 Thinking Mode): Optimised for deep reasoning (>500ms processing time).
  • If Tier 1 is uncertain, or if the post requires complex contextual nuance, it gets routed here. It uses Gemma 3's advanced reasoning capabilities to cross-reference platform policies and multi-model context.
  • Human Mod Queue & Audit Logs: If the AI tiers cannot confidently make a decision, the event falls back to a dedicated MySQL queue for manual human review via Staff Clients. This also records all audit logs for tracking mod decisions.
  • Fast Model Cache (Redis): A shared cache layer that allows the workers and staff clients to quickly look up cached model results or flag states without hitting the primary databases.

Scaled Architecture (Growth Phase)

1. The Write Gateway & Fast Ingestion

When a user creates a post/shimmy (text, images, or video), it follows the blue path into the Write Gateway:

  • Asynchronous Trust Profiling (Triage Layer 0): Instead of choking the database with synchronous queries, the gateway intercepts the request and instantly checks a low-latency User Trust Cache (Redis). This tells the system if the poster is a trusted user, a known spammer, or a new account.
  • Optimistic Initial Write: The post is instantly dumped into ScyllaDB with a state of mod_status: pending_review. It is completely hidden from public feeds at this stage, freeing up the client connection in milliseconds.
  • The Event Backbone: Simultaneously, the write event is fired into the Kafka Event Stream to trigger asynchronous processing downstream.

2. Shifted-Left Moderation Pipeline (The Purple Box)

Shimmy Shield -our AI moderation system- reads from Kafka and uses a smart multi-tiered approach to maximise compute efficiency:

  • Early p-HASH Deduplication: Before burning expensive GPU cycles on vector embeddings, the media goes straight through a p-HASH Deduplication Cache. If the image/video matches a known piece of spam, violating content, or viral media, it is instantly routed without further ML inference.
  • The Multi-Tiered AI Gauntlet: Clean/unique items pass to the text normalizer and ViT Inference (for visual embeddings).
  • Triage Layer 2 (Fast Pass): Lightweight models (RoBERTa + Toxic-BERT) evaluate the text concurrently. If the safety score is clearly "clear" or "violation", it skips ahead to the persistence layer.
  • Triage Layer 3 (Slow Lane - GEMMA 3): If the score lands in the ambiguous "Grey Zone" (0.2−0.8), the system routes it to a heavy LLM (GEMMA 3) to break the tie using deep contextual awareness.

3. Decentralized Storage via CDC (The Red & Green Boxes)

To prevent database race conditions and the risky "dual-write" problem, we have introduced a robust CDC (Change Data Capture) Event Collector & Router:

  • The Triage Layer 3: Persistence Worker writes the final moderation verdict to the core PostgreSQL Engine (the source of truth for metadata, audit logs, and reports).
  • The CDC Collector & Router listens to database transaction logs. It seamlessly replicates and maps these state changes out to the rest of the Polyglot Data Layer:
  • Updates the mod_status to approved/hidden in ScyllaDB (which powers high-volume chronological feeds).
  • Streams the heavy Text & Media ViT embeddings into the Vector DB to serve as the structural framework for semantic search and discovery.

4. The Telemetry & Signal Feedback Loop

A recommendation system is only as good as its data. The bottom track captures real-time user behaviour:

  • The user scrolls through their app, generating implicit signals (e.g., how long they stare at a post via Dwell Time, likes, shares, or skips).
  • The Telemetry API ingests this massive stream, pumps it through Kafka, and passes it to an Analytical Pipeline.
  • This pipeline converts raw behaviour into mathematical vectors and instantly executes a Redis Update to mutate the user's Active User Preference Vectors inside the Redis Cluster.

5. The Recommendation & Read Engine (The Discovery Engine)

When the client requests a feed, the Feeds & Discovery Read Path (the orange/tan loop) jumps into action, combining the telemetry with data retrieval:

  • Step 1: Candidate Retrieval (ANN): The Personalised Feed Generation Service hits the Vector DB (which doubles as the Recommendation Candidate Pool). Using the user's Active User Preference Vectors from Redis, it performs an Approximate Nearest Neighbour (ANN) search to pull a few hundred posts that semantically match the user's real-time tastes.
  • Step 2: Blending with Momentum: The Read Gateway pulls from the Trending ZSets (Redis) to blend these highly personalised vector candidates with high-velocity, platform-wide viral content (Shimmy Momentum Scoring).
  • Step 3: Service Delivery: The final mixed, deduplicated, and ranked feed is delivered back to the Client Application with sub-second latency.

Deep-Dive Briefs

Infrastructure — Current State to Mid-Term Re-Architecture

Pillar VII Research Brief — Shimmy Strategic Document Suite

Scope: This brief maps Shimmy's current infrastructure (public site, internal L4+ site, notification system, microservices, AWS footprint) to a mid-term re-architecture horizon, with Shimmy Shield treated as a major standalone section given it's a genuinely distinct ML pipeline. It is written to be extended — each major section is scoped so it can later become its own dedicated technical document (an ADR set, a service catalogue entry, a runbook) without restructuring this brief.

Part 0 — Current-State Baseline

0.1 As documented today

Layer Current implementation
Frontend Flutter/Dart mobile client + Vue 3.5+, TypeScript 5.8+, Vite 7.1+, Tailwind 3.4+, Vue Router 4.5+, Axios for public web and internal L4+ site
Core API Laravel 11, PHP 8.3+, Sanctum bearer-token auth + API key middleware, versioned api/v1 routes
Web/internal services Node.js 20+, Express, worker services for notifications and internal automations
Compute AWS Lambda (API handlers), EC2/Fargate (worker services)
Data Aurora MySQL (relational), ElastiCache Redis (queues/cache), S3 (assets)
Messaging SES email delivery, multi-channel notification service (email/SMS/push/in-app), scheduled delivery and retry backoff via BullMQ
Observability CloudWatch
CI/CD GitHub Actions, Docker, AWS Amplify (hosting/deployment)
Services User Management (L4+), Content Management (public API), Payment Processing (L5 only), Analytics (L3+), Notification (L4+), Recommendations (in development), Explore (public API)

0.3 Runtime topology and delivery flow

Shimmy currently runs as a hybrid platform:

  • Mobile/web product surface: Flutter/Dart mobile app and Vue/TypeScript web experiences consume the versioned Laravel API layer.
  • Internal operations surface: L4/L5 internal dashboard controls notifications, user access, and system administration.
  • Notification execution: templates, scheduling, and channel routing are handled through queue-backed worker services with delivery audit logging in Aurora.
  • Content and media path: user content is written through API services and media assets are stored in S3.

0.2 Honest read of the current architecture's shape

This is a Lambda-and-managed-services-first architecture — sensible and appropriately lean for current stage, but it has an implicit ceiling worth naming now rather than discovering under load:

  • Service boundaries currently look like they're defined by access-level (L3/L4/L5) as much as by domain responsibility. That's a reasonable v1 shortcut but conflates authorisation policy with service architecture — worth deliberately separating before the service count grows further (Part 1).
  • BullMQ/Redis as the sole job-queue mechanism is fine at current volume but becomes a scaling and observability constraint once cross-service event flows (not just background jobs) start to matter — this is precisely the transition Part 2 addresses.
  • Aurora MySQL as the single relational store across Notification, User Management, Analytics, and (per the Shimmy Shield README) a separate SQLite store for moderation audit logs, is an early signal of data-layer fragmentation that should be resolved deliberately rather than left to accumulate (Part 2.3, Part 3.5).

Part 1 — Near-Term Foundations (Brief, as Groundwork for the Mid-Term Work)

Kept intentionally short since the mid-term horizon is the priority, but these are the prerequisites the 2–5yr work depends on:

  • Resolve the currently-flagged auth-bypass work on fix/auth-bypass-and-shimmy-image and restore a green, trusted test suite — the re-architecture work in Part 2 (service boundary changes, multi-region auth) is materially riskier to execute against an unverified auth layer, so this is a hard prerequisite, not parallel work.
  • Establish an Architecture Decision Record (ADR) practice now, before the mid-term re-architecture generates the volume of consequential decisions Part 4.3 assumes exists as a trail.

Part 2 — Mid-Term Re-Architecture (2–5 Years)

2.1 Service boundary maturity: from access-level to domain-driven

Recommend re-deriving service boundaries around genuine domain ownership (fundraising/payments, identity, content/moderation, notification, analytics, recommendations) with access control (L3/L4/L5/Admin) implemented as a cross-cutting policy layer (a shared auth/claims service every microservice calls into) rather than a boundary-defining property of the services themselves. This directly supports the Operations pillar's pod model — a pod can own a genuine domain service end-to-end without also having to own bespoke access-control logic duplicated across services.

Current framing Recommended mid-term framing
"User Management Service (L4+ Access)" User/Identity Service, with L4+ enforced via shared policy layer
"Payment Processing Service (L5 Only)" Payments Service, with L5 enforced via shared policy layer, plus dedicated PCI-scope isolation (see 2.5)
"Analytics Service (L3+ Access)" Analytics Service, access-scoped via policy layer, decoupled from the ingestion pipeline (2.4)

2.2 API Gateway and event-driven evolution

Current Lambda + API Gateway pattern works well for request/response API handlers. As service count and cross-service interaction grows, recommend introducing an event backbone (EventBridge, or a Kafka-class stream if volume justifies it by year 3–4) alongside — not instead of — the existing request/response layer:

  • Request/response (API Gateway → Lambda) stays for synchronous, user-facing calls.
  • An event bus carries domain events (fundraiser created, donation completed, moderation verdict issued, user verified) that multiple services need to react to independently — this is what lets, for example, the Notification service, Analytics service, and a future Recommendations engine all react to a donation-completed event without the Payments service needing to know about any of them, directly supporting decoupled pod ownership.
  • BullMQ/Redis remains appropriate for intra-service job queues (retry logic, scheduled sends) but should not become the de facto cross-service integration mechanism as more services are added — that pattern degrades badly (implicit coupling via shared queue naming conventions) once more than a handful of services participate.

2.3 Data layer evolution

Current Mid-term recommendation Rationale
Single Aurora MySQL cluster shared across services Aurora per-domain (or per-domain schema with strict access boundaries as an interim step) Prevents cross-service coupling via shared tables, a common source of "can't deploy independently" pain as pods multiply
Aurora MySQL 8.0 Evaluate Aurora Serverless v2 for variable-load services (notification bursts, analytics) vs. provisioned for steady-load services (payments) Cost efficiency matched to actual load shape, rather than one provisioning model for everything
ElastiCache Redis (queues + caching, same cluster) Split queue Redis from cache Redis once either workload's scaling needs diverge (they usually do — cache wants high hit-rate/eviction tuning, queues want durability guarantees) Avoids one workload's scaling event degrading the other
SQLite audit log (Shimmy Shield) Migrate to Aurora or a dedicated append-only/time-series store before multi-region moderation load (Part 3.5) SQLite's single-writer model is a hard ceiling well before Shield needs to operate at the volume implied by global rollout

2.4 Multi-region architecture

Directly informed by the Global Markets pillar's Tier 1–3 sequencing:

  • Read path: CloudFront + regional edge caching for the public site is likely sufficient through Tier 1 (UK/Ireland/Canada/ANZ) without a full active-active database rebuild — most read-heavy public content doesn't need multi-region write capability yet.
  • Write path: Aurora Global Database (or equivalent) becomes relevant once Tier 2/3 markets with data-residency requirements (EU DSA-scope data, India's data-localisation rules per the Global Markets brief) are entered — this should be scoped as a market-entry prerequisite for those specific markets, echoing the same "prerequisite not afterthought" framing used for payment-rail localisation in the Global Markets brief, not a general infrastructure upgrade done speculatively ahead of need.
  • Data residency: recommend a per-market data-residency matrix (which user data must stay in-region, which can be centrally processed) be maintained as a living document jointly owned by Infrastructure and Legal/Compliance, reviewed at each new market-tier entry — this is exactly the kind of cross-functional artefact that should exist before, not after, a Tier 3 market commitment is made.

2.5 Security & compliance hardening

  • Payments isolation: given L5-only payment processing already exists as a concept, recommend formalising this as genuine PCI-DSS scope isolation (separate VPC/network boundary, minimal blast radius) as part of the service boundary rework in 2.1 — worth doing as part of the re-architecture rather than as a separate later project, since retrofitting network isolation onto an already-live payments service is materially more disruptive.
  • Audit logging consistency: the notification system's Aurora-based audit logging is the right pattern; Shimmy Shield's SQLite audit logging is not yet at that standard (2.3) — recommend a single audit-logging standard (schema, retention, access-control) applied consistently across every service that produces compliance-relevant logs, directly supporting the rationale-capture discipline flagged in both the moderation brief and the Operations brief.
  • GDPR-class data retention: already implemented for the notification system per the current README — recommend this become a shared, reusable data-retention service/library other services (User Management, Shimmy Shield audit logs) consume, rather than each service reimplementing retention logic independently.

2.6 Observability maturity

CloudWatch is an adequate starting point but becomes a limiting factor once cross-service tracing matters (a single user-facing request now touching Identity, Content, Notification, and Shield services). Recommend adopting OpenTelemetry instrumentation across services in this horizon specifically so traces are portable regardless of downstream backend choice (CloudWatch, or a dedicated APM tool if cost/features justify a switch later) — instrumenting with a vendor-neutral standard now avoids a second migration later.

2.7 CI/CD maturity

Current GitHub Actions + Docker + Amplify stack is appropriate for the current service count. As service count grows under the domain-boundary rework (2.1), recommend:

  • Per-service pipelines with independent deploy cadences (a direct technical enabler of the Operations pillar's pod-level autonomy — a pod shouldn't need another pod's release to ship).
  • Canary or blue-green deployment for anything touching Payments or Identity specifically, given the blast-radius asymmetry of those services versus, say, the public content site.

Part 3 — Shimmy Shield: Path to V2+

3.1 Current architecture, read against the moderation brief's tiering model

Correction from an earlier draft of this document: Shimmy Shield V1 is not a flat, always-on ensemble — the full V1 Implementation detail is documented in the Shimmy Shield brief, and it already implements genuine tiered routing: a Layer 0 metadata Risk Vector, a Layer 1 RoBERTa/Toxic-BERT fast pass, and Layer 2's Gemma 3 escalation invoked conditionally on only the Grey Zone (score 0.20–0.80, roughly 10–15% of posts) rather than on every request. The table below reflects that reality, not the flat-ensemble assumption an earlier pass of this document made.

Moderation brief tier Shield V1's actual equivalent Genuine V2+ gap
Tier 0 (cheap, high-recall filter) Layer 0 metadata Risk Vector (account age, trust record, destination Shimmy) plus the Two-Tiered Hash Defence (exact-match + similarity) — a real pre-filter, not merely conceptual Extend Tier 0 to cover image/video content, which is currently text-only (see 3.4 below)
Tier 1 (contextual mid-size model) Layer 1: RoBERTa + Toxic-BERT concurrent fast pass, sub-50ms, with unanimous-clear and unanimous-violation short-circuits that skip Gemma 3 entirely Category-specific threshold tuning already exists (Production Tweaks, Shimmy Shield brief) — the remaining gap is validating these thresholds against real production data once volume exists, not building the mechanism
Tier 2 (escalation reasoning) Layer 2: Gemma 3, invoked only on Grey Zone content (score 0.20–0.80) with Shimmy-context enrichment pulled from PostgreSQL Already conditional, already context-enriched — the main open item is the region-conditioned policy layer for multi-market rollout (3.3, below), not making invocation conditional (that's already true)

The cost-discipline conclusion still holds — tiered routing, not model choice, is the primary lever on blended inference cost — but the credit for having already built it belongs to V1, and V2+'s job is extending the same discipline to multimodal content and multi-region policy variation, not introducing tiering from scratch.

This tiering discipline — Gemma 3 invoked only where the fast lane can't confidently decide — is likely the single largest reason Shield's inference cost scales sub-linearly rather than linearly with content volume, directly consistent with the moderation brief's Horizon 1 conclusion that tiered routing, not model choice, is the primary lever on blended inference cost. At current scale this may be a modest saving; at the volume implied by Tier 1–2 global rollout (Global Markets pillar), it becomes the difference between manageable and unmanageable inference spend.

Chart showing GPT-4-class AI inference cost falling from $30 per million tokens in 2023 to $0.45 by 2026, a roughly 95% reduction, on a logarithmic scale

This is why the tiering discipline compounds rather than becoming unnecessary over time: per-token cost is falling fast, but reasoning-token consumption and always-on agentic workloads are growing — see Market Appendix, Section E.2 for the full nuance.

3.2 Preprocessing pipeline evolution

The current 30+ obfuscation patterns and 15+ slang expansions are a reasonable rules-based v1 approach but are inherently a maintenance-debt-accumulating pattern — every new obfuscation technique or slang term requires a manual rule addition, and adversaries adapt faster than manual rule sets can be maintained (directly echoing the moderation brief's adversarial-ML research vector). Recommend V2 evaluate a learned normalisation layer (a small fine-tuned model that handles obfuscation/slang normalisation as a generalisable task rather than a fixed rule list) as a medium-term replacement, with the existing rule-based system kept as a fast-path fallback rather than discarded outright.

3.3 Multi-region policy variation

Per the Global Markets pillar's localisation work, Shimmy Shield's 5-category severity classification will need region-specific calibration, not a single global model — what counts as Category 3 (harassment/profanity) versus acceptable register genuinely varies by market and regulatory regime. Recommend:

  • Keep the core ensemble architecture global (the underlying models don't need per-region retraining).
  • Introduce a region-conditioned policy layer on top of the ensemble output — the same underlying confidence scores and category classification feed into region-specific thresholding/action rules, rather than retraining separate models per region. This is materially cheaper to maintain than N regional model variants and matches the "community-local norm embeddings" pattern from the moderation brief, applied at country/region granularity.

3.4 Real-time and multimodal extension

Current Shield V1 is text-focused. Extending to the moderation brief's Horizon 1 multimodal scope (image/video moderation) should be planned as an additive service, not a rework of the existing text ensemble:

  • A separate VLM-based image/video moderation path, following the same Tier 0/1/2 structure independently, sharing only the confidence-thresholding and audit-logging infrastructure with the text pipeline.
  • Adaptive frame sampling for video (per the moderation brief) rather than dense per-frame analysis, for cost reasons that scale even more steeply for video than for the text ensemble.

3.5 Data infrastructure: the SQLite ceiling

Flagging this plainly as a near-term risk, not a distant one: SQLite's single-writer model is not compatible with the audit-log volume implied by global, multi-region rollout, let alone the multi-region policy layer in 3.3, which will want to query audit history for calibration purposes. Recommend migrating Shield's audit logging to Aurora (matching the notification system's existing, proven pattern per 2.3/2.5) before — not during — the first Tier 2 market rollout, since a mid-rollout database migration under live load is a materially riskier and more disruptive change than doing it as a deliberate pre-rollout step.

3.6 Rate limiting and reliability at scale

Current 100 requests/60 seconds per-user rate limiting is a sensible per-user control but doesn't address aggregate system-level load once request volume scales with global user growth. Recommend adding a system-level adaptive rate-limiting/backpressure layer (shedding load toward the Tier 0 fast-path preferentially over dropping requests outright) as part of the V2 tiering work in 3.1 — this is a natural extension of the same architecture change, not a separate project.

3.7 Confidence thresholding as the connective tissue

Shield V1's thresholding is more granular than a single global cutoff — the V1 Implementation section documents category-specific auto-hide/auto-approve bands (severe toxicity at ≥0.75/<0.30, spam at ≥0.85/<0.40, profanity at ≥0.90/<0.50), which is already, functionally, the moderation brief's "calibrated abstention" concept applied per-category rather than globally. Recommend extending this same category-specific thresholding matrix to serve as the routing trigger for the resonance/trust-metric input feeding the Product pillar's provenance-badge display (Product brief, Part 5) — this is a case where a mechanism already built for moderation is directly reusable as shared infrastructure across pillars, rather than re-implemented per consumer.

Part 4 — Cross-Cutting Infrastructure Decisions

4.1 Build vs. buy, infrastructure-specific

Consistent with the Operations pillar's build-vs-buy framework, applied here:

Category Default Rationale
Base ensemble models (RoBERTa, Toxic-BERT) Buy/use open pretrained weights, fine-tune in-house Not a differentiator; the tiering/routing architecture and calibration data are
Gemma3:12b (or successor) hosting Buy (API-based) at current scale; revisit self-hosting only above a defined volume threshold, consistent with the moderation brief's own conclusion Avoid premature self-hosting investment
Event backbone (2.2) Buy (managed EventBridge/equivalent) initially; revisit self-managed streaming only if volume/latency needs exceed managed-service limits Consistent with the "buy the commodity layer" pattern used throughout the other pillars
Observability backend Start with CloudWatch + OpenTelemetry instrumentation; revisit dedicated APM only once cross-service tracing needs exceed CloudWatch's practical limits Vendor-neutral instrumentation now avoids lock-in regardless of the later choice

4.2 Cost modelling against Global Markets sequencing

Recommend infrastructure cost projections be built market-by-market, aligned to the Global Markets pillar's tiering, rather than as a single global infrastructure budget line — multi-region database costs, data-residency compliance overhead, and Shimmy Shield's regional policy-layer maintenance all scale with which markets are entered, not just with user count, so the two pillars' planning cycles should be reviewed jointly at each new market-tier decision.

4.3 Documentation structure (space for further documentation)

Recommend the following living documentation set sit underneath this brief, each maintained independently and referenced from here rather than duplicated:

  • ADR log — one lightweight record per consequential architecture decision (service boundary changes, data store choices, the Tier 0/1/2 routing decisions in Part 3), timestamped and never deleted, only superseded.
  • Service catalogue — one page per service (owner pod, dependencies, data stores, SLOs) kept current as services are added or re-scoped under 2.1.
  • Runbooks — incident-response procedures per service class, extending the Operations pillar's minimum-viable-discipline recommendation.
  • Regional configuration matrix — the data-residency and Shield policy-layer configuration per market, referenced in 2.4 and 3.3, updated at every market-tier entry.

This structure is designed so that as Shimmy scales, this brief remains the stable map while the underlying documents absorb the churn — matching the same "map vs. deep-dive" relationship the master strategy suite architecture established for the six business pillars.

Shimmy Shield — The Future of Automated Content Moderation

A Foundational Research Brief for Shimmy's 3/5/8/12-Year Strategic Horizon

Prepared for: Shimmy Executive & Product Strategy Scope: ML/NLP/CV architecture evolution, sociopolitical dynamics of digital spaces, and infrastructure economics governing trust & safety systems through 2038 Framing note: Shimmy's positioning as a "calmer, anti-doomscroll" network with contextual feeds and built-in moderation gives it a structural advantage over incumbents in Horizons 1–2 (moderation is a first-class product feature, not a bolted-on cost centre) but also raises the stakes for Horizons 3–4, where trust infrastructure is the product.

Executive Horizon Matrix

Horizon Core ML Architecture Primary Moderation Challenge Infrastructure Bottleneck
1–3 yr (Near) Multimodal LLMs & VLMs, mixture-of-experts routing Sarcasm, regional slang/code-switching, real-time video/audio latency Inference cost ($/token, $/frame) at scale
4–5 yr (Mid) Edge-AI, federated learning, graph neural nets for coordination detection Privacy-preserving cross-device signal, cross-platform coordinated inauthentic behaviour (CIB) On-device compute/thermal constraints, federated aggregation bandwidth
6–8 yr (Long) Cryptographic provenance (C2PA-class), zero-knowledge attestation, synthetic-content classifiers Hyper-realistic deepfakes, synthetic spam swarms, protocol-level (AT Proto/Nostr) content with no central chokepoint Content authenticity tracking across federated/decentralized graphs
9–12 yr (Vision) Agent-native semantic consensus protocols, cognitive defence layers Agent-to-agent negotiation on behalf of humans, algorithmically-induced echo chambers between AI agents themselves Bandwidth/latency of real-time decentralized semantic consensus

V1 Implementation — Current Architecture (As Built, Text Moderation)

This section documents Shimmy Shield's actual current build, not a recommendation — it sits ahead of the forward-looking Horizon 1–4 analysis below because it's the ground truth those horizons build from. Where this section shows the system already doing something Horizon 1 recommends (conditional Gemma 3 invocation, tiered routing), that's a sign V1 is ahead of where a from-scratch build would be, not a reason to skip the horizon analysis — it still governs where V2+ goes next.

Create Post/Shimmy: the entry flow

Every post or Shimmy creation follows the same entry path before anything is visible publicly:

  1. A mobile user creates a post or Shimmy from the client.
  2. The post/Shimmy Create API call reaches the server, which immediately returns a 202 response to the user — the user's client doesn't wait on moderation to complete before the UI unblocks.
  3. The post is written with STATUS_PENDING. Posts in this state are never added to feeds — this is the same shadow-buffering principle used later in the Grey Zone escalation (Layer 2, below), applied from the very first millisecond of a post's life.
  4. A fast Redis-backed hash check runs against known spam/abuse hashes (Two-Tiered Hash Defence, below) before the post enters the main triage pipeline.

Shimmy Shield create-post flow: mobile user creates a post, API returns 202, post is written with STATUS_PENDING and hidden from feeds, a fast Redis hash check screens for exact-match spam before background anti-spam and similarity checks run, with instant blocking on an exact match and routing to Shimmy Shield's triage pipeline otherwise

Two-Tiered Hash Defence

Before a post reaches any ML model, it passes through two progressively more expensive hash-based checks — cheapest, highest-confidence signal first.

Tier 1 — The Exact-Match Firewall. Standard SHA-256 or MD5 hashing of binary files (attachments, known spam images, malware scripts) and raw text. On submission, the post is hashed instantly and checked against a blacklisted_hashes set in Redis. An exact match is blocked instantly — no further AI inference is spent on content Shimmy has already positively identified as violating.

Tier 2 — The Similarity Filter. Exact hashing fails the moment content is even slightly altered, which is why a second, smarter layer exists for near-duplicate text and images: Locality-Sensitive Hashing (LSH) or vector embeddings, converting content into a numerical representation of its meaning rather than its literal bytes. Shimmy Shield uses MySQL's native VECTOR data type and DISTANCE() function (available since MySQL 9) to store and query spam embeddings directly in the primary database, rather than standing up a dedicated vector store for this tier. The known catch, flagged honestly rather than glossed over: native in-database vector distance calculation can get computationally heavy under traffic spikes — this is a specific, named scaling risk for Shield's hash-defence layer, distinct from the inference-cost scaling already discussed in Infrastructure, Part 3.5.

The Triage Strategy: Short-Circuiting the Vote

Content that clears the hash defence enters a four-layer triage pipeline designed to spend expensive model inference only where it's actually needed.

Shimmy Shield triage pipeline: Layer 0 metadata profiling splits content into Low Risk and High Risk paths, both feeding into Layer 1's RoBERTa plus Toxic-BERT fast pass, which either takes instant action on high-confidence scores or escalates low-confidence grey-zone content to Layer 2's slow lane, before Layer 3 persists the final verdict to the post status and human-review database

Layer 0 — Metadata Profiling (the pre-filter)

Before a single AI model is touched, the API Gateway evaluates the metadata of the user and the destination Shimmy to assign a Risk Vector:

  • Low Risk — an aged account with a clean trust record, posting in a private or low-traffic Shimmy.
  • High Risk — a new account (under 24 hours old), any history of flags, or posting in a globally trending/public Shimmy.

Low-risk posts are greenlit for the Fast Lane (Layer 1); high-risk posts bypass certain optimisation cutoffs to ensure they always receive full scrutiny, regardless of what the fast-pass models conclude.

Account age is tiered, not binary:

Phase Age What it means
"Sandbox" 0–7 days Highest-risk window — roughly 90% of automated spam bots reveal themselves within this period. Public-Shimmy posts from Sandbox-phase accounts route straight to the slow lane.
"Established" 30 days The standard baseline for treating an account as sufficiently aged to remove basic training-wheel scrutiny — a spammer's account is usually caught or reported within its first month if it's going to be.
"Veteran" 6 months – 1 year True aged status. Accounts that survive this long with a clean record are highly trusted by the algorithm.

The trusted-aged-user determination is a simple, explicit rule rather than a learned model — worth keeping simple deliberately, since this gate feeds directly into how much scrutiny everything downstream receives:

if (accountAge >= 30_DAYS && totalLoginDays >= 7 && successfulInteractions >= 15) {
    setIsAgedUser(true);
}

Layer 1 — The Fast Lane (encoder consensus)

The post is processed concurrently by Toxic-BERT and RoBERTa, both returning a result in under 50ms.

  • Scenario A — Unanimous absolute clear (score < 0.20): bypass all further AI. Status immediately becomes APPROVED and the post goes live.
  • Scenario B — Unanimous absolute violation (score > 0.80): flag as hidden instantly, write the offence to the user's account profile in MySQL, and skip Gemma 3 entirely — an unambiguous violation doesn't need an expensive reasoning model to confirm what two fast classifiers already agree on, which is precisely the cost discipline Infrastructure, Part 3.1 recommends generalising into V2+.

Layer 2 — The Slow Lane / Grey Zone escalation (score 0.20–0.80)

When Toxic-BERT and RoBERTa disagree, or the score falls in the ambiguous middle band, the post escalates rather than forcing a premature decision:

  1. State isolation — the post is written to MySQL with mod_status = 'pending_review' and is visible only to its author, so the posting experience doesn't feel interrupted even though the post isn't public yet (the same shadow-buffering principle from the entry flow, applied again here).
  2. Context enrichment — the triage system pulls the parent Shimmy's title, category, and the user's risk profile from PostgreSQL and appends this context to the post text before escalating it.
  3. Gemma 3 evaluation — the enriched context block is sent to Gemma 3, which uses the parent Shimmy's theme to judge whether the text is genuinely toxic or contextually acceptable (an aggressive-sounding phrase in a competitive-gaming Shimmy reads very differently in a bereavement-support Shimmy) — this is the concrete mechanism behind the "community-local norm embeddings" concept referenced throughout this brief's Horizon 1 discussion below, not a separate idea.

Layer 3 — The Persistence Layer (database split)

Once a verdict is reached, the result is synced across Shimmy's polyglot database layer:

  • MySQL (the post/feed engine) — updates the post's status. A Gemma-3-cleared post moves to approved and becomes instantly discoverable in the public feed; a rejected post moves to hidden.
  • MySQL (the system core) — if a post was hidden, an entry is created in moderation_reports. If the user has crossed a violation threshold, their account status is automatically updated to suspended or flagged in the users table, without requiring a human to action the escalation manually.

Architectural benefits of this design

  1. Cost efficiency — expensive Gemma 3 inference is spent only on the roughly 10–15% of posts that land in the Grey Zone or come from high-risk accounts, not on every post. This is the same tiering discipline Infrastructure, Part 3.1 recommends generalising, already proven out in Shield's actual V1 build.
  2. Resilience to traffic spikes — if a Shimmy goes viral, Layer 1 absorbs the mass influx of content instantly; if the Gemma 3 queue backs up, shadow-buffering means users never see a stalled posting experience while their content waits in the slow lane.
  3. Contextual accuracy — by blending the parent Shimmy's own context directly into the triage payload, Shimmy Shield behaves less like a generic content sensor and more like a moderator who understands where in the platform a conversation is actually happening.

Production tweaks — the confidence thresholding matrix

Not every violation category should be held to the same bar. Shimmy Shield applies category-specific auto-action thresholds rather than one global severity cutoff:

Violation category Auto-hide threshold Auto-approve threshold Action for the middle zone
Severe toxicity / threats ≥ 0.75 < 0.30 Lock & hide instantly, route to human review
Spam / promotional ≥ 0.85 < 0.40 Keep live but demote in public-Shimmy discover feeds
Profanity / slang ≥ 0.90 < 0.50 Approve, but flag for the Shimmy creator's own content filters

Severe categories are held to a tighter, more cautious band (a wider "must escalate" middle zone) than lower-stakes categories like profanity, where the creator's own community settings are the more appropriate control than a platform-wide auto-hide.

Production tweaks — per-category telemetry

Rather than logging a single aggregate pass/fail ratio, Shield pipes telemetry asynchronously into a time-series store (Prometheus-class, or an OpenSearch dashboard) tracking three specific signals:

  • Model divergence rate — how often Gemma 3's Layer 2 verdict reverses the initial Toxic-BERT/RoBERTa assessment, which is the single best available signal for whether the fast-lane models need retraining or threshold adjustment.
  • False-positive ratio per Shimmy category — whether specific Shimmy types (Gaming vs. News, for instance) see elevated false-positive rates, which is exactly the kind of per-community calibration need this brief's Horizon 1 section (below) argues for on first-principles grounds — V1 is already instrumented to detect it empirically.
  • Pipeline latency per phase — Layer 1 vs. Layer 2 vs. Layer 3 processing time, broken out so a latency regression can be traced to a specific phase rather than triaged as a vague "moderation feels slow" report.

Horizon 1 (Years 1–3): From Regex to Real-Time Multimodal Reasoning

1.1 The architectural transition

The dominant paradigm shift is from classification-first pipelines (a keyword/regex layer feeding a binary or multi-class toxicity classifier, e.g., Perspective-API-style scoring) to reasoning-first pipelines, where a multimodal LLM/VLM ingests text, image, and short-form video jointly and produces a policy-grounded judgement with rationale, not just a score. This matters strategically because rationale generation is what makes moderation decisions appealable, auditable, and trainable — three properties regulators and users increasingly demand simultaneously.

Practically, this means Shimmy's moderation stack should be architected around three tiers rather than one model:

  • Tier 0 (cheap, high-recall filter): small distilled classifier (\< 1B params) or even non-ML heuristics doing a first pass at near-zero cost, screening the ~95% of content that is unambiguously benign.
  • Tier 1 (contextual VLM): a mid-sized multimodal model (think current-generation 8B–30B class, quantized/distilled) evaluating flagged content with context — thread history, poster reputation, community norms of the specific group/feed.
  • Tier 2 (escalation reasoning model): a larger frontier-class model reserved for edge cases, appeals, and novel adversarial patterns, invoked at low volume but high stakes (legal exposure, self-harm, coordinated harassment).

This tiering is the single highest-leverage cost lever available in this horizon — routing correctly can cut blended inference cost by 80–95% relative to running a frontier model on all content.

This is already substantially true of Shimmy Shield V1 — see V1 Implementation, above. Layer 0's metadata Risk Vector plays the role of Tier 0, Layer 1's RoBERTa/Toxic-BERT fast pass plays Tier 1, and Layer 2's conditional Gemma 3 escalation plays Tier 2 — invoked only on the 10–15% Grey Zone, not on every post. What V1 doesn't yet do is the multimodal half of this section (image/video moderation is still text-only in V1, per Infrastructure, Part 3.4) — that remains genuine Horizon 1 forward work, not something already shipped.

1.2 Context-awareness and the sarcasm/nuance problem

Sarcasm, irony, and reclaimed slurs remain the hardest unsolved subclass of moderation error because they require theory-of-mind-adjacent inference: what does the speaker believe the listener believes? Three concrete mitigations differentiate leaders from laggards here:

  1. Thread-conditioned inference — feeding the model the preceding N messages and the poster's relationship to the community (new member vs. long-tenured), not just the flagged utterance in isolation. Context window cost scales linearly, but false-positive reduction is often the single largest driver of user trust and retention.
  2. Community-local norm embeddings — rather than one global policy, maintain a learned representation of acceptable register per community/feed (a private meme group vs. a public fundraising thread on Shimmy has categorically different baselines), and condition the Tier 1 model on it.
  3. Calibrated abstention — the model should be explicitly trained/prompted to output "insufficient confidence, escalate to Tier 2 / human review" rather than forcing a binary decision. Uncalibrated forced-choice classifiers are the leading cause of both false-positive user backlash and false-negative harm at this horizon.

1.3 Real-time video/audio latency

Live and short-form video moderation is constrained by frame-sampling economics: running a VLM on every frame is infeasible at scale, so the practical approach is adaptive frame sampling — sample sparsely by default, and dynamically increase sampling density when audio transcription (via a lightweight streaming ASR model) or motion/scene-change detection signals elevated risk. Audio-channel moderation (via streaming Whisper-class ASR feeding the text pipeline) is frequently cheaper and higher-signal than dense visual sampling for most harm categories except CSAM/graphic violence, which require frame-level CV regardless of cost.

1.4 Infrastructure economics: the compute-vs-latency tradeoff

The central bottleneck of this horizon is $/token at acceptable p99 latency. Three concrete strategic levers:

  • Batching vs. real-time tension: asynchronous post-publish review can batch aggressively and use cheaper spot/batch inference pricing; pre-publish (pre-send) moderation cannot, and must run on always-on provisioned capacity, which is 3–5x more expensive per unit inference. Shimmy's product philosophy (contextual, non-doomscroll feeds) may actually permit more async, post-publish-with-soft-quarantine moderation than a real-time feed product, which is a genuine cost advantage worth building into the roadmap explicitly.
  • Model distillation cadence: frontier labs release new base models roughly every 6–9 months; the winning operational pattern is a standing pipeline that re-distills a frontier "teacher" model into a smaller in-house "student" classifier every cycle, rather than re-architecting from scratch. This should be a funded, recurring line item, not a one-off project.
  • Vendor vs. self-hosted inference: at Shimmy's likely scale through year 3, API-based inference (Anthropic/OpenAI/etc.) will almost certainly beat self-hosted GPU infrastructure on total cost of ownership once engineering/ops overhead is accounted for — the crossover point to self-hosting typically only favours self-hosting above roughly hundreds of millions of moderation calls/month, and only for the Tier 0/1 layers.

Bottom line for Horizon 1: the strategic asset to build is not "a moderation model" but the tiered routing and context-injection infrastructure around off-the-shelf models — this is what's defensible and what compounds.

Horizon 2 (Years 4–5): Predictive, Federated, and Coordination-Aware Systems

2.1 From reactive to predictive moderation

The paradigm shift here is from scoring individual pieces of content to modelling networks and trajectories. The key technical enabler is graph neural networks (GNNs) applied to the interaction graph (who replies to whom, timing patterns, account creation clustering, content-similarity clustering across accounts) to detect coordinated inauthentic behaviour (CIB) before any single piece of content trips a content-level filter. A single hostile post is often policy-compliant in isolation; the same post posted by 400 accounts within 90 seconds is a network-level signal invisible to any per-item classifier.

Concretely, this requires:

  • A near-real-time graph store capable of streaming updates to the interaction graph (not a nightly batch job).
  • Anomaly detection on temporal and structural graph features (burstiness, account-age distribution of a cascade, cross-account text/image near-duplication) rather than content semantics alone.
  • Virality-curve interception: modelling the predicted diffusion curve of a piece of content (using early engagement velocity as a leading indicator) to intervene during the exponential-growth phase rather than after peak reach — this is the technical core of "predictive" moderation and is where the actual harm-reduction leverage lives, since most real-world harm from misinformation/harassment cascades occurs in the first few hours of virality.

2.2 Federated learning and on-device moderation

Regulatory and user trust pressure (post-GDPR-successor regimes, on-device processing expectations set by mobile OS vendors) pushes first-pass moderation onto the device itself. The realistic architecture is:

  • A small on-device model (distilled, quantized to run in the low hundreds of MB, feasible on-device even on mid-range hardware) performs local pre-screening before content ever leaves the device — catching the most severe categories (CSAM, extreme violence) locally and instantly, and flagging borderline content for server-side Tier 1/2 review.
  • Federated learning aggregates model weight updates, not raw user data, from on-device usage back to a central model, using secure aggregation protocols so no individual user's data is ever visible in the aggregate. This is technically mature (used in production by major mobile keyboard/predictive-text systems already) but remains non-trivial for moderation specifically because label quality on-device is inherently noisier — most practical implementations combine federated learning with a smaller, centrally-labelled "gold set" to prevent model drift toward device-population biases.
  • Cross-platform coordination detection becomes the hard unsolved problem at this horizon: coordinated campaigns increasingly originate or coordinate off-platform (via encrypted messaging apps, other social platforms) and only manifest on a given platform as a burst. This pushes toward industry-shared threat-intelligence signals (hash-sharing consortia, similar to existing CSAM hash-sharing infrastructure like PhotoDNA, but generalized to coordination fingerprints) — a strategic partnership decision, not purely a technical one, and one Shimmy should evaluate joining or co-founding given its trust-first brand positioning.

2.3 Strategic implication for Shimmy

Federated/edge moderation is expensive to build in-house at Shimmy's likely scale in years 4–5. The higher-leverage move is a hybrid: adopt vendor/open infrastructure for the commoditized layer (on-device pre-screening SDKs, hash-sharing consortium membership) while investing proprietary engineering effort specifically in the graph-based coordination detection tuned to Shimmy's actual social graph shape (which, given the contextual-feed/community structure, likely differs meaningfully from open, follower-graph platforms).

Horizon 3 (Years 6–8): Decentralisation and the Synthetic Content Majority

3.1 Moderation without a chokepoint

Protocol-based social graphs (AT Protocol/Bluesky's model, Nostr's relay model) explicitly decentralise the moderation chokepoint: there is no single company positioned to unilaterally remove content from the network, only from the views it serves (feeds, relays, labelers). The architectural response is composable/portable moderation: instead of a single moderation verdict, the system publishes labels/attestations (via signed, portable label services, as AT Protocol's model does) that downstream clients and feed algorithms can choose to honour or ignore.

Strategically, this reframes the moderation product from "we decide what's allowed" to "we operate one of several trust layers a user or client can subscribe to" — which is a fundamentally different business model (a moderation-as-a-service labeler that other apps/clients can subscribe to) worth scenario-planning now, since it could become either a threat (disintermediation of Shimmy's current control) or a new product line (Shimmy's moderation stack, tuned for calm/anti-doomscroll norms, licensed to other decentralised clients).

3.2 The 80%-synthetic-content world

When the majority of content is AI-generated or AI-augmented, binary "is this AI-generated" detection becomes strategically useless — it will have near-universal positive hits and provides no actionable signal. The paradigm must shift from detecting synthetic content to verifying provenance and intent:

  • Cryptographic provenance (C2PA-class content credentials): content is signed at the point of capture/generation with a tamper-evident manifest describing its creation history (camera, edits, generative tool used). The moderation question shifts from "was this made by AI" to "does this content's provenance chain match its claimed context" — e.g., a synthetic image is not inherently harmful, but a synthetic image presented as raw photographic evidence of a real event is a provenance-mismatch, which is the actual harm vector.
  • Intent verification over content classification: the practical unit of moderation becomes the claim attached to content (this is real, this is satire, this is a paid endorsement) rather than the pixels/text themselves. This requires moderation systems to reason jointly over content and the structured/unstructured claims accompanying it — a natural extension of the context-conditioned reasoning built in Horizon 1, now applied to authenticity claims rather than toxicity.
  • Synthetic spam swarms (AI agents generating high-volume, human-plausible engagement/content at near-zero marginal cost) make volume-based heuristics (post frequency, account age) increasingly useless, since synthetic actors can trivially mimic human temporal patterns. Defence shifts to behavioural-economic signals that remain expensive for an attacker to fake at scale even with generative AI: cross-session identity consistency, verified real-world attestations (proof-of-personhood systems), and economic staking mechanisms (cost-to-post models) rather than purely content-based detection.

3.3 Strategic implication for Shimmy

Given Shimmy's existing GoFundMe/fundraising integration, provenance and intent-verification infrastructure is not merely a defensive moderation investment — it's directly monetisable trust infrastructure for the fundraising use case specifically (verifying a fundraiser's claims/identity is a superset of the general provenance problem). This is a case where the Horizon 3 moderation investment and a core product line converge, and should be planned as one workstream rather than two.

Horizon 4 (Years 9–12): Agent-Mediated Interaction and Cognitive Defence

This horizon is necessarily speculative; the following is grounded extrapolation from current agentic-AI trajectories (tool-using agents, agent-to-agent protocols such as emerging standards for agent identity and negotiation) rather than confident prediction.

4.1 Redefining the moderation unit

When AI agents transact, negotiate, and communicate on behalf of human principals, "content moderation" as a discrete review-and-remove function becomes only one layer of a broader cognitive defence stack. The relevant question is no longer "should this post be visible" but "should this agent-to-agent interaction be permitted to influence my principal's information environment/decisions at all." This implies moderation infrastructure converges with:

  • Agent identity and provenance verification (which agent, acting for whom, under what delegated authority) — a direct extension of Horizon 3's provenance work, now applied to actors rather than content.
  • Real-time semantic consensus protocols: rather than a single platform unilaterally judging content, groups of agents (representing users, platforms, and possibly regulatory bodies) reach distributed consensus on classification/action in real time, analogous to how distributed systems reach consensus on transaction validity today, but applied to semantic/policy judgments. The bandwidth and latency cost of this is the defining infrastructure bottleneck of this horizon — semantic consensus at conversational latency across a decentralized agent network is a substantially harder distributed-systems problem than today's content-delivery-network-style caching.
  • Cognitive echo chambers between agents: a genuinely novel risk class where agents, optimising for engagement or task-completion proxies on behalf of users, reinforce each other's outputs in agent-to-agent loops with no human in the loop to notice drift — this requires moderation systems to monitor agent behaviour patterns over time, not single interactions, and is closer to an alignment/interpretability problem than a classical trust-and-safety problem.

4.2 What "moderation" plausibly means at this horizon

Best current framing: a cognitive defence layer operating as a permissioning and provenance-verification substrate that agents must satisfy before their outputs are allowed to reach or influence a human principal's information diet — less "content police," more "authenticated, rate-limited, provenance-checked API surface between autonomous agents and human attention." Shimmy's specific opportunity, if this trajectory holds, is to be a human-attention-protective layer by design (consistent with its anti-doomscroll positioning), which is a differentiated, defensible position relative to engagement-maximising incumbents who are structurally disincentivised from building genuine cognitive defence.

Critical Research Vectors to Track (Cross-Horizon)

  1. Cost-to-accuracy ratio migration. Track the crossover economics between centralized cloud inference, hybrid edge/cloud, and eventual on-device-first architectures. This should be a standing quarterly metric (blended $/moderation-decision, tracked by tier), not a one-time architecture decision — the crossover points will move as model efficiency improves faster than most roadmaps assume.

  2. Regulatory alignment as embedded infrastructure, not compliance overhead. The EU Digital Services Act and its successors (and comparable emerging frameworks in the UK, given Shimmy's base, via Ofcom's Online Safety Act enforcement) increasingly require auditable decision logs and systemic risk assessments as a matter of law. Building compliance logging (rationale capture from the Tier 1/2 reasoning models described in Horizon 1) into the ML pipeline from day one is dramatically cheaper than retrofitting it, and doubles as the audit trail needed for appeals and for training data curation.

  3. Adversarial ML and the perturbation arms race. Track the specific technique classes: adversarial visual perturbations (imperceptible-to-human pixel changes that flip classifier outputs), prompt-injection-style attacks against the moderation LLM itself (content crafted to manipulate the moderator model's own reasoning, not just evade a classifier), and steganographic encoding of prohibited content within otherwise-benign generative outputs. Red-teaming the moderation stack itself (not just the platform's user-facing surface) should be a standing, funded workstream starting in Horizon 1, since the moderation model is now an attack surface in its own right.

Indicator Dashboard (Quarterly)

To stay vigilant on the future of AI, social dynamics, and Shimmy's market position, maintain the following standing dashboard and review it quarterly at leadership level.

Indicator Why it matters Threshold / trigger Owner
Blended moderation cost per decision (Tier 0/1/2 split) Tracks economic viability of Shield routing model Trigger review if >15% QoQ increase without matching risk reduction Infrastructure + Trust & Safety
Grey-zone escalation rate Signals model confidence quality and ambiguity drift Trigger retraining/calibration if rate drifts beyond agreed range for 2 consecutive quarters Trust & Safety
Model divergence rate (fast lane vs. escalation verdict) Measures quality of Tier 1 decisioning Trigger threshold audit if divergence trend rises quarter-over-quarter Trust & Safety + ML
False positive rate by Shimmy category Protects user trust and community fit Trigger category-specific policy revision when FP exceeds policy tolerance Product + Trust & Safety
High-severity miss rate (post-publication reversals) Core safety integrity measure Trigger incident review immediately on breach of severity threshold Trust & Safety
Synthetic-content share of total submissions Tracks AI-generated content transition speed Trigger provenance roadmap acceleration if synthetic share rises above planned horizon assumptions Product + Infrastructure
Provenance mismatch rate Measures authenticity risk in fundraising/social content Trigger verification hardening when mismatch trend accelerates Trust & Safety + Fundraising Product
Coordinated behaviour detection lead time Measures ability to stop campaigns early Trigger graph-model upgrade if lead time degrades quarter-over-quarter Trust & Safety + Data
Trust score trend (user-reported safety confidence) Links moderation performance to product trust Trigger joint Product/Shield review on sustained decline Product + Trust & Safety
Regulatory response SLA (appeals, rationale logs, audit export) Ensures compliance readiness as regulation evolves Trigger compliance programme escalation if any SLA misses occur Legal + Trust & Safety
Market sentiment shift: doomscroll fatigue and social trust signals Connects macro-social behaviour to Shimmy's positioning Trigger messaging/positioning update if signal weakens materially Strategy + Product Marketing
Emerging agentic-social adoption signal Tracks speed of Horizon 4 arrival risk Trigger horizon timing review when enterprise/consumer signal crosses target adoption bands Strategy + Product

This dashboard should be mirrored into Roadmap & Milestones, Risk Register, and Financials so strategy, risk, and spend remain synchronized.

Summary Strategic Recommendations

  • Years 1–3: Invest in tiered routing infrastructure and context-injection, not a single "moderation model." Exploit Shimmy's non-real-time, contextual-feed product design to shift more moderation to cheaper async/batch inference than competitors with live feeds can.
  • Years 4–5: Build proprietary graph-based coordination detection tuned to Shimmy's community/feed graph shape; buy/partner for commoditized on-device and hash-sharing infrastructure rather than building it in-house.
  • Years 6–8: Converge the provenance/authenticity-verification workstream with the GoFundMe/fundraising trust product line — this is a rare case of moderation infrastructure being directly monetisable, not just a cost centre.
  • Years 9–12: Position Shimmy's brand-native "protect human attention" philosophy as the differentiator in an agent-mediated web, where most incumbents are structurally misaligned to build genuine cognitive defence.

Appendix & Reference

Market Data & Projections Appendix

Statistical Reference — Shimmy Strategic Document Suite

Purpose: This appendix compiles researched market sizing, projections, and behavioural statistics relevant across all pillars of the suite, organised by theme and cross-referenced to the specific briefs they support. It is meant to sit underneath the existing pillar documents as evidence, not to replace the frameworks already built.

A methodological note before anything else: market-research estimates for every category below vary substantially by provider, sometimes by an order of magnitude, because firms define market boundaries differently (e.g. "crowdfunding" sized anywhere from ~$2 billion to ~$66 billion by 2030 depending on whether equity/debt crowdfunding is included alongside donation-based). Where sources disagree materially, this is stated explicitly rather than presenting a single number as settled fact. Treat every figure here as directional, not a number to put in a contract.

Section A — The Global Social & Digital Landscape (supports Pillar I, Global Markets)

A.1 Market size and growth

Global social media market size estimates cluster around $208–234 billion in 2025/2026, with most forecasters projecting roughly $390 billion by 2030 at a compound annual growth rate near 13–14% (The Business Research Company, Research and Markets, 2026). A broader "social media platforms" market definition (including underlying infrastructure and monetisation services, not just advertising/subscription revenue) is sized considerably higher, reflecting how differently providers scope this category — worth noting precisely because it means any single "market size" figure quoted externally needs its definition checked before being used in board materials.

A.2 Users and engagement

  • Global social media user identities reached 5.79 billion as of April 2026, equivalent to 69.9% of the world's population, with internet penetration at 73.8% (DataReportal/We Are Social, April 2026).
  • Average daily time spent on social media sits at 2 hours 21 minutes globally, down slightly from 2 hours 28 minutes the prior year — a modest but real decline worth tracking as a leading indicator of category-wide fatigue (DataReportal, sqmagazine analysis, 2026).
  • The average user is active across 6.5–6.7 different platforms monthly — relevant to the Product pillar's "6.7 platforms" fragmentation point, since it means Shimmy is competing for a share of attention split across many apps, not a single incumbent.
  • Generative AI adoption is accelerating sharply: active GenAI users more than doubled in the 12 months to April 2026, reaching 29.2% of the global population, a 141% annual growth rate (DataReportal, April 2026) — directly relevant to the Technology Horizon pillar's agentic/AI-native distribution surface discussion.

A.3 Regional penetration — Tier 1 candidate markets

Directly populating the Global Markets brief's Tier 1 sequence with current data (DataReportal/We Are Social, April 2026; ±2–5 percentage points per country):

Market Active social media penetration (% of total population) Note
Canada 82.4% Near-saturation tier
Australia 81.8% Near-saturation tier
UK 81.3% Near-saturation tier; internet penetration separately measured at 97.8%
Ireland Not separately reported in this dataset, but Facebook reach data places it at 76.2%, consistent with near-saturation Near-zero-cost localisation market per Global Markets brief
Nordic markets (Norway, Denmark, Sweden) 85–88% Highest-penetration bloc globally alongside Gulf states
Gulf states (UAE, Qatar, Kuwait, Saudi Arabia) 82.7–99.0% UAE is the single highest-penetration market measured globally
India 34.6% Confirms the Global Markets brief's Tier 3 framing — large population, materially lower current penetration, genuine long-runway market rather than near-term volume driver

Read for strategy: the entire Tier 1 sequence (UK, Ireland, Canada, Australia) sits within a tight 76–82% penetration band with near-identical platform mixes and demographic adoption curves (businesstats.com/DataReportal analysis, 2026) — this is empirical support for treating them as a single coherent beachhead cohort rather than four separate market strategies, consistent with what the Global Markets brief already recommended on qualitative grounds.

TikTok penetration specifically in the Tier 1 cohort (UK 34.8%, Australia 33.9%, Canada 33.1%) sits meaningfully below these markets' overall social penetration, indicating real headroom for newer entrants in the short-form/algorithmic-feed space rather than TikTok having already saturated attention in these markets (DataReportal, April 2026).

Section B — Digital Wellbeing, Doomscrolling & Fatigue (supports Pillar II, Product — validates core brand thesis)

This section matters most: it's the empirical case for "less doom, more do" as a genuine market opportunity rather than only a values statement.

B.1 Prevalence

  • Roughly 31% of US adults doomscroll regularly, rising to 51% of Gen Z and 46% of Millennials (Morning Consult survey, 2024, widely re-cited through 2026).
  • 62% of adults report experiencing recurring digital burnout according to 2026 survey data (multiple 2026 sources).
  • News avoidance — people actively steering away from news content because of its emotional cost — reached 46% in the UK and 40% globally, up from 29% in 2017 (Reuters Institute Digital News Report, cited February–June 2026) — this is a striking, UK-specific data point given Shimmy's home market, and a direct signal that a calmer information/content experience has real demand there specifically.
  • The 2025 Cybersmile Digital Wellbeing Report (UK, ages 16–24, n=1,000) found 91% of young women say social media negatively affects their mental health, and the same share feel unsatisfied with their lives after social comparison on the platforms — an unusually stark, UK-sourced statistic worth citing directly in any UK market-entry or brand positioning material.

B.2 Sleep and physical health

  • 38% of US adults report that bedtime phone/tablet news viewing worsens their sleep (American Academy of Sleep Medicine, February 2026).
  • 69% of respondents in one 2026 screen-time survey had experienced a phone-related physical health issue in the past year (eye strain, neck/shoulder pain, headaches) (Harmony Healthcare IT, cited 2026).

B.3 Economic cost — relevant to the "resonance metrics" business case

  • Excessive, unmanaged screen time among American workers is estimated to have cost $151 billion in combined health-system, productivity, and wellbeing costs in a single year (American Optometric Association/Deloitte Economics Institute analysis, cited 2026), with productivity losses ($50.6 billion) the largest single component.
  • Broader information-overload costs to the US economy are estimated as high as $1 trillion annually when reduced productivity, degraded decision-making, and turnover are included (2026 workplace-fatigue research) — this figure is a much broader, more speculative aggregate than the AOA/Deloitte figure above and should be treated as an order-of-magnitude indicator, not a precise estimate.

Read for strategy: these aren't soft, vibes-based justifications for the brand positioning — there is a measurable, UK-anchored, currently-worsening pattern of doomscrolling harm and active news/content avoidance that a genuinely calmer product is positioned against. This is exactly the kind of evidence the Product pillar's resonance-metrics section should be validated against periodically — if UK news avoidance or doomscrolling prevalence starts declining, that's a signal to revisit whether "anti-doomscroll" remains the strongest lead positioning.

Section C — Content Moderation & Trust Market (supports the Moderation Brief and Infrastructure Pillar)

Market sizing here varies more than almost any other category surveyed, again due to scope differences (pure AI moderation software vs. moderation services inclusive of human review workforce):

Scope 2025/26 estimate 2030 estimate CAGR
Content Moderation AI (software only) ~$1.5–3B $10.0–10.4B 26.8–27%
Content Moderation Solutions (software + services, broader) $13.3B (2025) $26.1B 14.5%
Content Moderation Services (inclusive of human workforce) $12.5–13.9B (2025/26) $22.8–42.4B (by 2030/2035 depending on source) 13–13.4%
Automated Content Moderation (narrower software definition) $1.48B (2026) $2.76B 16.9%

Despite the scope disagreement, every source agrees on direction and rough order of magnitude: double-digit CAGR, driven explicitly by regulatory pressure (EU DSA, UK Online Safety Act, US state-level rules, India's IT Rules) rather than by voluntary platform investment alone (Research Nester, 2026; multiple concurring sources). This directly supports the moderation brief and Infrastructure pillar's framing of compliance/audit-logging infrastructure as a near-term necessity rather than a nice-to-have.

A specific, useful data point: cumulative GDPR and EU DSA fines across the industry already exceed $2 billion, and Australia has implemented an under-16 platform access ban — concrete evidence that the regulatory cost curve the Global Markets and Infrastructure briefs both flag is already materialising, not merely anticipated (Mordor Intelligence social networking market analysis, 2026).

Section D — Crowdfunding & Philanthropy Market (supports Pillar V, Philanthropy)

This is the category with the widest source disagreement encountered in this research — estimates for the 2030 global crowdfunding market range from roughly $3.6 billion to $66.7 billion, a nearly 20x spread, depending entirely on whether equity- and debt-based crowdfunding (business financing) are included alongside donation-based crowdfunding (the category actually relevant to Shimmy's GoFundMe integration).

The figure most relevant to Shimmy specifically: donation-based crowdfunding alone is projected to reach approximately $59.7 billion globally by 2032 (coinlaw.io market analysis, 2025) — this is the number worth anchoring to internally, since it isolates the actual category the product competes in, rather than blending in unrelated business-equity financing.

Supporting data points:

  • Donation-based campaigns show a roughly 25% success rate, and campaigns using video are 60–105% more likely to succeed than those without, depending on source — directly relevant to the Product pillar's fundraiser-presentation-shell design work.
  • North America currently dominates the broader crowdfunding market (~31% share), with the UK specifically noted as one of the most developed and well-regulated crowdfunding markets in Europe (Grand View Research, 2026) — a genuine tailwind for Shimmy's UK-first sequencing.
  • Millennials remain the largest donor demographic (42% of backers), with Gen Z's share rising fastest (20%, up from 15% in 2021) (coinlaw.io, 2025) — useful demographic grounding for the Product pillar's audience assumptions.

Read for strategy: given the scale of source disagreement here, I'd recommend the Philanthropy pillar's eventual sourced-numbers work commission a bottom-up estimate specific to donation-based/personal-cause crowdfunding rather than quoting any single top-down market report — the category is genuinely large and growing, but the published numbers are too inconsistent to anchor a board projection to directly.

Section E — Technology Horizon: Devices, AI Cost Curves, and Agentic Systems (supports Pillar VI / Infrastructure)

E.1 Foldable devices — near-term, not speculative

This is now a confirmed near-term product surface, not a bet: Apple's first foldable iPhone is expected in 2026, alongside Samsung's Galaxy Z TriFold, and analyst forecasts have been revised upward specifically because of it — IDC forecasts 30% YoY growth in foldable shipments for 2026 (up from a prior forecast of 6%), Omdia forecasts a 50% YoY rebound, and Counterpoint forecasts 20% YoY growth, with foldables expected to exceed 10% of total smartphone market value by 2029 despite remaining a low single-digit percentage of unit volume (IDC, Omdia, Counterpoint Research, 2025–2026). One analyst estimate puts global foldable shipments at 100 million units by 2027.

Relevant technical/market detail for the Infrastructure and Product briefs:

  • Book-style (fold-out) devices hold roughly 62% of 2025 revenue share, with flip-style devices representing about 67% of total foldables owned — the two form factors need distinct UI treatment, consistent with what the Product brief already flagged.
  • Enterprise foldable adoption is growing faster than consumer adoption (26.2% CAGR vs. overall market growth), with real productivity use cases already documented (DHL reported 22% faster inventory audits using Galaxy Z Fold devices) (Mordor Intelligence, 2026) — a data point worth being aware of if Shimmy ever explores B2B/community-organisation-facing tooling.
  • Middle East is forecast as the fastest-growing regional foldable market (23.4% CAGR) — worth cross-referencing against the Global Markets brief's Gulf Tier 2 candidacy, since it suggests device readiness there is ahead of, not behind, Tier 1 markets.

E.2 AI inference cost — the single most important trend underpinning the Infrastructure and Moderation briefs

This is worth stating plainly because it's the empirical backbone of the Shimmy Shield V2+ tiering recommendation: inference cost for a fixed capability level has fallen extremely fast and consistently.

  • GPT-4-class inference cost fell from roughly $30 per million tokens in March 2023 to under $0.50 by 2026 — a ~95% reduction in two years, and closer to 1,000x over three years for some benchmark-matched comparisons (a16z "LLMflation" analysis; Epoch AI research, cited 2026).
  • Independent academic analysis (Epoch AI, arXiv 2026) confirms the broad direction but shows the rate varies hugely by task — from roughly 9x to 900x per year depending on benchmark — and cautions that the very fastest drops seen in 2024 are unlikely to be sustained at the same pace going forward. A more conservative forward estimate suggests 3–5x annual reductions through 2027, tapering to 1.5–2x annually thereafter.
  • Critically — and this is the nuance the Infrastructure brief's tiering recommendation depends on — falling per-token cost does not automatically mean falling total inference spend, because reasoning-model architectures consume far more tokens per query than earlier models, and "always-on" agentic workloads (monitoring, background agents) are a genuinely new and rapidly growing cost category that barely existed in 2024 (oplexa.com AI cost analysis, 2026). This is direct, current-data support for the Infrastructure brief's specific recommendation to make Shimmy Shield's LLM tier conditional rather than always-on: cost is not falling passively enough to make an always-on architecture safe by default — the routing discipline still has to be engineered in.

E.3 Agentic AI market

Every major research firm agrees the agentic AI market is entering a period of very fast growth, though absolute-size estimates vary by roughly 3x depending on scope (enterprise-only vs. broader "AI agents" market):

  • Enterprise-specific agentic AI: roughly $2.6–6.8 billion in 2024/25, projected to reach $24.5–46 billion by 2030 (Grand View Research, MarketsandMarkets, 2026), at CAGRs of 46–47%.
  • Broader AI agents market (Precedence Research): $7.9 billion in 2025 to $236 billion by 2034.
  • Gartner projects 40% of enterprise applications will integrate task-specific AI agents by end of 2026, up from under 5% at the start of the trend — an extremely fast adoption curve worth tracking as a leading indicator for when agent-mediated interaction (the moderation brief and Product brief's shared Horizon 4 territory) starts becoming operationally relevant, likely faster than the original 9–12 year estimate in those briefs if this pace holds.
  • The EU AI Act's phased compliance obligations (rolling out through 2026) are already shaping agentic AI investment patterns in Europe specifically, pushing toward auditable, explainable agent architectures (dataintelo/Kaiso Research analysis, 2026) — directly reinforcing the Infrastructure brief's ADR/audit-logging recommendations as something that will matter for agent-facing infrastructure specifically, not just content moderation.

Read for strategy: the pace of agentic AI adoption evidenced here suggests the moderation brief's Horizon 4 (agent-mediated interaction, years 9–12) may arrive materially earlier than a straight-line 12-year estimate implies, at least for the "agents transacting on a user's behalf" pattern in narrow domains (customer service, task automation) — worth flagging as a reason to revisit that horizon's timing at the next full suite review, rather than treating the 9–12 year label as fixed.

Summary: What This Changes in the Existing Briefs

  • Global Markets pillar: the UK/Ireland/Canada/Australia Tier 1 cohort is now empirically, not just qualitatively, supported as a coherent single beachhead — penetration rates, platform mix, and demographic patterns are genuinely similar across all four.
  • Product pillar: the "less doom, more do" positioning has real, current, UK-specific evidence behind it (46% UK news avoidance, 91% of young UK women reporting negative mental-health impact) — this is defensible in front of investors, not just aspirational language.
  • Philanthropy pillar: anchor future sourced projections to the donation-based-crowdfunding-specific figure (~$59.7B by 2032), not a blended crowdfunding market number that includes unrelated equity/debt financing.
  • Infrastructure/Moderation briefs: the AI inference cost data is direct empirical support for the Shimmy Shield tiering recommendation — but with the important caveat that total spend is not falling as fast as per-token price, because reasoning-token consumption and always-on agentic workloads are growing. The tiering discipline is doing real work, not a hedge against a problem that's solving itself.
  • Technology Horizon: foldables are now a confirmed near-term (2026) surface given Apple's entry, not a mid-horizon bet — worth pulling forward any glanceable/cover-screen UI work already flagged in the Product brief. Agentic AI adoption is moving fast enough that the moderation brief's Horizon 4 timing is worth revisiting at the next suite review.

References

This page collects the external sources that back figures and claims across the suite.

Pillar I — Global Markets

Source list in progress.

Pillar II — Product

Source list in progress.

Pillar III — Operations

Source list in progress.

Pillar IV — Building & Growth

Source list in progress.

Pillar V — Philanthropy, Impact & Outbound

Source list in progress.

Pillar VI — Technology Horizon

Source list in progress.

Shimmy Shield (Moderation Brief)

Source list in progress.

Infrastructure

Source list in progress.

Market Appendix

Source list in progress.

Glossary

Shimmies

Modular social feeds built from three components: Source Selector, Ranking Logic, and Presentation Shell.

Tier 1-4 Markets

Four-level market entry model: - Tier 1: beachhead markets - Tier 2: fast-follow markets - Tier 3: strategic/regulated markets - Tier 4: long-horizon markets

Resonance Metrics

Product metrics designed to measure user outcomes beyond raw engagement (for example: time-well-spent ratio, completed-intent rate, regret rate).

Trust Signals

Indicators surfaced in product and moderation systems to increase user confidence and reduce harmful or inauthentic content exposure.

L3/L4/L5 Access

Internal access model used across operational tools and services: - L3: analytics and operational access - L4: advanced operational/admin access - L5: highest-risk controls (for example payments and kill-access operations)

Source Selector

The logic that determines which content sources feed a Shimmy.

Ranking Logic

The logic that orders content within a Shimmy.

Presentation Shell

The UI layer that determines how a Shimmy is displayed (card feed, digest, map, and other shells).

Legal

Terms of Use

By accessing this site, you agree to the following terms.

Informational Use Only

This site is provided for general informational review of Shimmy Group Ltd materials. Nothing on this site grants any right to reuse, reproduce, commercialise, or adapt the contents except where Shimmy Group Ltd has provided prior written permission.

Intellectual Property

All content on this site, including text, documents, visuals, branding, structure, and strategy materials, is owned by or licensed to Shimmy Group Ltd and is protected by copyright and other intellectual property laws.

No Reliance or Offer

These materials are provided for discussion and informational purposes only. They do not constitute legal, financial, investment, fundraising, or other professional advice, and do not form a binding offer, solicitation, or contractual commitment.

No Unauthorised Use

You may not copy, share, republish, scrape, extract, modify, distribute, sell, or create derivative works from this site or its contents without prior written permission from Shimmy Group Ltd.

Accuracy and Changes

Shimmy Group Ltd may update, revise, remove, or restrict access to materials on this site at any time without notice.

External Sharing

If you wish to cite, quote, redistribute, or otherwise use these materials beyond private review, you must first obtain written permission from Shimmy Group Ltd.

Contact

For permissions or rights inquiries, contact Shimmy Group Ltd.

For the broader Shimmy legal and policy framework, see shimmyapp.com/policies.

License & Rights Notice

Copyright (c) 2026 Shimmy Group Ltd. All rights reserved.

This site and the materials published within it are protected by copyright and other applicable intellectual property rights.

Permitted Use

You may view this site and its contents for personal, informational, non-commercial review purposes only.

Restricted Use

Unless Shimmy Group Ltd has given prior written permission, you may not:

  • copy or reproduce any material from this site;
  • republish, distribute, or transmit any content;
  • modify, adapt, translate, or create derivative works;
  • use any material for commercial purposes;
  • remove branding, attribution, or proprietary notices.

Ownership

All text, strategic content, research framing, brand assets, layout elements, and supporting materials remain the property of Shimmy Group Ltd unless stated otherwise.

Contact

For permissions, licensing, or reuse requests, contact Shimmy Group Ltd.

For the broader Shimmy legal and policy framework, see shimmyapp.com/policies.