Luck Operating System

The luck-system describes what luck is and how it compounds. This file describes how Matt operates that system — the subsystems, projects, data models, cadence, and accountability that together run the weekly LSA ritual without depending on remembering what to do on any given day.

The theoretical model is timeless; this operating architecture is also timeless. The current state of which projects are in flight, stalled, or complete lives in the tracking experiment ([[exp-2026-04-20-0012-luck-system-install]]).

Architecture — 9 subsystems

Each subsystem owns a data model, a set of entry points (when Matt or Claude interacts with it), an automation layer (what runs without intervention), and a health metric (is this subsystem healthy?).

1. Relationship OS — fresh, enriched, cluster-mapped contact database with hybrid deep-research + Matt-input enrichment. Foundation for M, B, G, L6, D6. See [[relationship-os]].
2. Publication Pipeline — drafted → edited → published → distributed lifecycle for all public artifacts. Foundation for T1, T3, T4, T6, T7, D3.
3. Ask Engine — 4-slot ask template + release-valve default + ask-log + warm-intro check + tier tracking. Foundation for L1–L6.
4. Give Engine — give-log + target surfacing + weekly amplification + quarterly deep give. Foundation for G1, G3, G5, G6, G7.
5. Memory Engine — M1/M3/M4/M5/M6 running on ntfy + Relationship OS. Foundation for M.
6. Encounter Engine — calendar slots + event feed + dinners + peer pool + third-place discipline. Foundation for F1, F2, F4, F5, F7.
7. Signal Engine — S1 pitch + homepage + /now + bios + public surfaces. Foundation for S1, S2, S3, S4, S6, T2.
8. Doing Engine — reference doc + weekly cadence + monthly external review + Hamming Friday + problem hold. Foundation for D1–D6.
9. Leverage Engine — third-party distribution: podcast guesting, guest posts, speaking, collaboration, email list, flagship artifact. Converts own-channel output into 10–100x reach. Foundation for the 100x regime; gated on S1-locked + T1-shipped. Foundation for T5 (expanded), T-tail magnitude, and the cross-cluster B compounding.

Cross-cutting:

• Ntfy scheduler — all time-based triggers (daily, weekly, monthly, quarterly prompts) run through the existing [[ntfy-notifications]] server.
• Vault as database — structured markdown files are the source of truth; no external DB.
• Agent sessions — Claude runs drafts, parses, enriches; Matt approves and executes.

Project map — 11 discrete projects

Projects are categories of work. The status of each project (in progress / stalled / complete) lives in [[exp-2026-04-20-0012-luck-system-install]]. The descriptions here are timeless. P1–P10 are the base engine; P11 is the Leverage layer that activates once P2 and P3 have shipped output.

P1 — Relationship OS (foundational, unblocks the most)

Build the CRM v2: enriched contact profiles with hybrid automated research + scheduled Matt-input enrichment, cluster map, staleness detection, tiered depth. Full design in [[relationship-os]].

P2 — S1 Pitch Convergence (foundational, unblocks Signal and Doing layers)

Draft 5–8 candidate 12-word pitches, broker-test with 3 people, select lowest-variance. All of T2, T4, T5, T6, T7, S4, S6, D1, M6 depend on this converging.

P3 — Signal Engine (runs on S1)

Public-surface rewrite + /now generator + biweekly topical cadence + weekly cross-post + quarterly long-form asset. Governs what the world can see and find.

P4 — Publication Pipeline

capture/drafts-to-ship/ folder with lifecycle states; ntfy-triggered biweekly publish cadence; automated distribution (tweet + LinkedIn draft + M4 personalized notes). Wraps every shipped artifact.

P5 — Ask Engine

Ask-log file + 4-slot template discipline + warm-intro check against cluster map + daily tier tracking + 100 Asks integration. L1 is already active-rule; P5 makes it durable.

P6 — Give Engine

Give-log file + weekly amplification target + quarterly deep-give planning + G5 100-gives-alongside-100-asks integration.

P7 — Memory Engine

Sunday M1 ntfy prompt with pre-drafted 3 messages; quarterly M3 blast (30–50 contacts); M4 post-publish surface; M5 birthday expansion (3 touchpoints); M6 6-month re-meeting ritual.

P8 — Encounter Engine

F1 cal.com slots; F2 recurring monthly dinner; F4 event feed + pre-event question prep; F5 peer intro pool; F7 cross-cluster dinner variant.

P9 — Doing Engine

D1/S6 niche reference doc; D2 v0-within-48h trigger; D3 weekly shipping cadence (rides P4); D4 Friday Hamming block; D5 12-month problem hold; D6 monthly external review.

P10 — Meta / Accountability

Weekly LSA review ritual; drift detection (project-watcher-style flagging of projects with no update >7 days); 30/60/90-day intervention check-ins; calibration of predictions against outcomes; master dashboard that shows status at a glance.

P11 — Leverage Engine (the 100x layer; gated)

External-channel distribution: pitch pipelines + editorial and host relationships + flagship artifact. Converts Matt's own-channel output into 10–100x reach via other people's audiences. Gated: does not start until P2 (S1 locked) and P3 (≥3 posts shipped) are complete — a leveraged pitch without a legible niche and portfolio wastes the pitch and the relationship. Five sub-projects:

• P11a — Podcast guesting pipeline. Target list (10–20 shows sorted by fit × reach), pitch template ("here's why my work matches your show in 3 sentences"), prep checklist (listen to 2 recent eps, draft 5 talking points + 1 story + 1 controversial take), post-appearance amplification (cross-post, invite guests to subscribe). Cadence: 2 pitches/month.
• P11b — Guest-post pipeline. Editorial targets by niche (LessWrong, AstralCodexTen, Asterisk, tech newsletters like Import AI), pitch template, editorial relationship tracking. Cadence: 1 pitch/month once T1 shipped.
• P11c — Speaking pipeline. Conference/meetup target list, CFP template, speaker reel assembly (clip best 2 min of recorded talk), post-talk follow-up protocol. Cadence: 1 submission/quarter.
• P11d — Email list + subscribe funnel. Dedicated CTA at the end of every post, one subscriber magnet (a narrow-niche reference doc given away on sign-up), monthly digest to list. Goal: 500 subscribers by Month 12. Cadence: list owner reads every sign-up; monthly digest; re-engagement sweep quarterly.
• P11e — Flagship artifact. One canonical long-form artifact per year — book, benchmark, dataset, tool, comprehensive framework doc. The single thing Matt wants to be known for. Cadence: quarterly progress check; annual commit. Distinct from T7 (quarterly evergreen asset) in that the flagship is the definitive reference, not a lateral asset.

Outcome gate: P11 is "working" when Matt has (a) ≥1 podcast appearance/quarter, (b) ≥1 guest post/quarter, (c) ≥1 speaking engagement/year, (d) email list growing ≥15%/month, and (e) a named flagship in draft within 6 months. Pitches-sent without acceptance after 6 months = pitch craft is broken (fix pitch before pitching more).

Dependency graph

                     ┌──────────────────────────────┐
                     │     P2: S1 Pitch             │
                     │  (12-word, broker-tested)    │
                     └──────┬───────────────────────┘
                            │
             ┌──────────────┼──────────────────┐
             ↓              ↓                  ↓
     ┌───────────────┐ ┌──────────┐  ┌─────────────────┐
     │ P3: Signal    │ │ P9: Doing│  │ P7 M6: re-meet  │
     │ (T2,T4,T5,    │ │(D1/S6,D3)│  │                 │
     │  T6,T7,S4,S6) │ │          │  │                 │
     └───────┬───────┘ └─────┬────┘  └─────────────────┘
             │               │
             ↓               ↓
     ┌───────────────────────────────┐
     │ P4: Publication Pipeline      │
     │ (drafts-to-ship lifecycle)    │
     └───────┬───────────────────────┘
             │  (requires ≥3 posts shipped)
             ↓
     ┌──────────────────────────────────────────┐
     │  P11: Leverage Engine (100x layer)       │
     │  ├── P11a Podcast guesting               │
     │  ├── P11b Guest posts                    │
     │  ├── P11c Speaking                       │
     │  ├── P11d Email list                     │
     │  └── P11e Flagship artifact              │
     └──────────────────────────────────────────┘

     ┌──────────────────────────────┐
     │  P1: Relationship OS         │
     │  (CRM v2 — enriched,         │
     │   cluster-mapped, fresh)     │
     └──────┬───────────────────────┘
            │
     ┌──────┼──────┬───────┬───────┬───────┐
     ↓      ↓      ↓       ↓       ↓       ↓
  ┌────┐┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐
  │ P7 ││ P6   ││ P5:L6││ P8   ││ P9:D6││ B1-3 │
  │ Mem││ Give ││ warm ││ Enc  ││ ext. ││      │
  └────┘└──────┘└──────┘└──────┘└──────┘└──────┘

     ┌──────────────────────────────┐
     │  P10: Meta / Accountability  │
     │  (weekly review, drift det.) │
     └──────────────────────────────┘
              ↑
              │  binds all projects
              │

Reading the graph:

• P1 and P2 are foundational — most downstream work is gated on one or both.
• P10 is cross-cutting — it binds every other project to execution.
• P4 is a shared service — P3 and P9 both write into it.
• P5, P6, P7, P8, P9 all consume from P1 (Relationship OS).
• P11 is the 100x layer — gated on P2 (S1 locked) and P3 (T1 ≥3 posts shipped). Launched prematurely it burns host/editor relationships on an illegible pitch.

Execution order implied by the graph:

1. P1 and P2 in parallel (both foundational, no deps).
2. P10 scaffold in parallel (lightweight; it's the tracking).
3. P3, P4 as soon as P2 converges.
4. P5, P6, P7, P8 as soon as P1 has basic tier-1 enrichment (top 15 contacts).
5. P9 full build once P1 + P2 + P3 are producing output.
6. P11 unlocks once P3 has shipped ≥3 posts — the leverage gate. Expect Day 60–90 at earliest.

Cadence — when the system runs

Compounding loops

The reason the system reaches 100x and not 5x is that subsystem outputs feed other subsystems' inputs. None of the loops fire without the adjacent subsystem running — which is why the 9-subsystem design matters more than any one subsystem. The loops:

1. Post → Contacts loop. Every shipped artifact (P3/P4) fires M4 (surface 5–10 contacts who should see this post specifically) and re-appears in cross-post, guest amplification, and email digest. Each post seeds ~3–10 new contacts into the CRM at decay-resistant freshness. Multi-post runs turn readers into correspondents.
2. Give → Ask loop. Every give logged in P6 reduces the friction on the next ask (P5) by virtue of recent visibility + goodwill + a specific favor to reference. A running ≥2/week give pace after 90 days creates 50+ latent claims you can invoke sparingly.
3. Event → Bridges loop. P8's monthly dinner introduces guests to each other — new B ties form without Matt's intermediation. After 3–4 dinners, some guests bring their own guests; the event becomes a flywheel whose marginal bridging cost is zero.
4. Memory → Magnitude loop. M1 Sunday refreshes + quarterly M3 blast keep top-50 contacts at λ > 0. A warm tie is 5–10× more likely to route an opportunity than a cold tie (Rajkumar 2022). The magnitude of lucky breaks lifts as more warm ties exist who can route bigger things.
5. S1 → Everything loop. A locked 12-word pitch feeds every downstream surface — homepage, /now, bios, guest-post pitch, podcast pitch, ask-intro, cold-email hook. S1 is the single highest-leverage node; change it and 8 downstream artifacts auto-invalidate.
6. Distribution → Doing loop. Audience on P3/P11 creates a stake in D quality (people-watching raises quality bar) and produces reader feedback that informs what to work on (D5 problem hold becomes informed). Quality D then produces better Distribution. This is the Stage 3 tail where magnitude compounds.
7. Speaking → Network loop. One talk (P11c) → ~10 post-talk conversations → 2–3 new cross-cluster bridges (B) → 1 podcast invite (P11a) → 1 guest-post invite (P11b) → 1 introduction → 1 lucky break. The chain is slow but the tail is fat. Every speaking gig seeds ≥2 other P11 gigs.

Design implication: if one subsystem is stalled, the loops containing it starve. P10 drift detection flags stalled subsystems explicitly; at 7 days untouched, the agent surfaces the stall and proposes the smallest action that restarts the loop.

Accountability architecture

The signal audit flagged Matt's pattern of designing systems without executing them. The operating system's job is to defeat that pattern. Four mechanisms:

1. Scheduled prompts, not remembered intentions

Every recurring action has an ntfy trigger. The agent does not rely on Matt remembering "it's Sunday, do M1." Ntfy fires; the action is pre-drafted; Matt reviews and sends. Execution cost at the moment of trigger is minutes, not planning.

2. Drift detection (project-watcher pattern)

The weekly review queries: which projects haven't been touched in >7 days? Those get flagged in the ntfy Sunday review. A stalled project with no explicit "paused" status is a bug — either un-stall it or move it to paused.

3. Outcome gates, not activity gates

A project is "done" when it produces its outcome, not when the setup is complete. Example: P2 is not done when candidates are drafted; it's done when Matt has a 12-word pitch that three brokers repeat back consistently. The experiment file's status column tracks outcomes, not checkmarks.

4. Automation over willpower

Every intervention that Claude can partially automate gets automated. This reduces Matt's per-moment execution cost and survives low-motivation weeks. The HIGH-automation interventions (21 of 57) should run without Matt remembering to trigger them.

100x operating targets

The architecture above is sized for an order-of-magnitude improvement over a year of consistent operation. The 100x target is not a marketing number — it's the product of reach-expansion × conversion-improvement × magnitude-widening, each roughly 3–5× over 12 months:

The math. $$\text{LSA}{365} / \text{LSA}0 ;=; \frac{\lambda{365}}{\lambda_0} \cdot \frac{p{365}}{p_0} \cdot \frac{E[m]_{365}}{E[m]_0}$$

Realistic Year-1 ratios, given this operating system running:

• $\lambda$: 8–12× (own channel growth + Leverage Engine external reach)
• $p$: 2–3× (S1 locked + memory-freshness kept above 0 for top 50 + V sub-24h)
• $E[m]$: 2–3× (fatter tail from speaking/podcasts/flagship reaching larger audiences)

Product: 32–108×. Wide bounds — 50x is likelier than 100x in Year 1; 100x+ is the Year 2 regime when compounding loops have run multiple full cycles. The target holds for the operating system as a whole, not for any individual dial.

Quantitative targets by horizon. Calibrated against Matt's current baseline (self-assessment 2026-04-20).

What "100x" means in plain terms at Day 365:

• Matt's work is seen by ~100,000 unique people over the year (vs. ~1,000 today).
• Matt's pipeline produces 20–30 unplanned positive outcomes/month (vs. ~1–2).
• The top 50 contacts are all warm (<90 days since last touch), not cold.
• Matt is known for one thing (S1-locked niche) across ≥3 external communities, not "yet another consultant."
• An inbound opportunity per week exceeds what Matt can fulfill — the binding constraint shifts from scarcity to triage.

What falls out of 100x regime that 10x doesn't:

• Inbound triage becomes the problem. Speed-system becomes load-bearing.
• Quality-gate compression — D (Doing) must keep up or Distribution outpaces Doing and reputation inverts.
• Time budget — weekly ritual must shrink or be delegated as volume grows (parse-capture, enrich-contact automation become mandatory, not optional).

What does NOT scale 100x (expectations management):

• Individual 1:1 relationships. Matt's cognitive budget for ~150 Dunbar relationships is fixed. The compound happens at layers 2–4 (50/150/500), not layer 1 (5).
• Deep work output. D output may scale 2–3× not 100×. Distribution does the heavy lifting.
• Sleep. Non-negotiable; interventions that trade sleep for LSA are auto-rejected.

How to extend the system

When a new LSA intervention emerges (or an existing one fails to stick), the protocol:

1. Locate the subsystem it belongs to from the 8-subsystem map. If none fit, that's a signal the architecture needs a ninth subsystem — rare, pause and think before adding.
2. Identify the dependencies. Does it need the Relationship OS? S1? Publication Pipeline?
3. Add to the experiment file under the appropriate project with status proposed.
4. Propose the adherence mechanism — what ntfy trigger, calendar hold, or rule-file entry enforces it?
5. Design the automation — what fraction can Claude do? Specify the data contract and the invocation cadence.
6. Ship the MVP — the smallest version that actually runs; the system is additive.

Every new intervention must pass: Is this intervention operated by the system (automation + adherence) or by willpower? If willpower, it's not durable.

Integration with the luck-system theory

This operating system is the how to the luck-system's what. Specific mappings:

• LSA formula's λ (encounter rate) → P7 + P8 + P1
• LSA formula's p (conversion) → P5 + P6 (via response speed) + P2 (specificity)
• LSA formula's m (magnitude) → P3 + P4 + P9
• Weekly ritual in luck-system → cadence table above
• Monthly compounding in luck-system → quarterly + monthly triggers above
• Personal priors in luck-system → specific interventions (F2 dinners, F3 third-place, G6 amplification, F7 cross-cluster mix)

Related

• luck-system — the theoretical model
• [[luck-system-variables-deep-dive]] — how each dial works
• [[luck-system-interventions-catalog]] — the 57 interventions
• [[luck-system-self-assessment-2026-04-20]] — current diagnostic
• [[relationship-os]] — the Relationship OS specification
• speed-system, [[asking-system]], [[cold-emailing-system]], [[email-writing-system]], [[communicating-system]], [[anti-holding-back-system]], [[essentialism-system]], [[never-eat-alone]] — adjacent systems the LOS calls into
• [[exp-2026-04-20-0012-luck-system-install]] — current project status
• [[2026-04-20-luck-system-100x-protocol]] — the temporal 12-month execution plan (Activation → Compounding → Leverage)