Lobster Tank

How do we build a system for generating, curating, validating, and prototyping ideas? That's the question this document tries to answer.

TL;DR

The cost of shipping software is collapsing. As a result, bottleneck has moved upstream: knowing what to ship, for whom, and why now. There are a lot of words on this page—as Mark Twain once said, "I would have written you a shorter letter if I had more time"—but at the end of the day, I'm pitching a system with a few simple steps:

  1. Idea farming: Ingest Reddit, Hacker News and whatever other sources we can get our hands on.
  2. Idea generation: Use a collection of strategies to generate ideas for a number of different personas inspired by the data we ingest.
  3. Idea validation: Do some deep research to try to put some due diligence behind the proposed ideas.
  4. Real world validation: Build a simple landing page with pricing information and a sign-up form.

If you're going to build products that leverage OpenClaw and other technologies, you might as well use the same philosophy and to build out your own infrastructure.

The end result is continuously-running pipeline that mines a wide variety of sources for opportunities, scores them against a structured rubric, runs cheap experiments against the survivors, and feeds every outcome back into the system so it gets sharper over time.

The by-product of ingesting content and processing through Claws for synthesis and having them compare notes is to come up with non-obvious opportunities that we might want to pursue.

A image from "Jurassic Park" where Jeff Goldblum's character says, "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

The hypothesis is fairly straight forward: If we can cast a wider net to surface ideas for a diverse set of sources, that's a competitive advantage. If we can automate as much of due diligence process, kill off ideas quickly, and surface the signal from the noise from that wider data set faster than most, we win.

While the cost of shipping software is shrinking, it's not zero and if figure out a way to place a higher number of better bets quickly, then we can spend our time and energy on the ones that are more likely to yield results.

On the division of labor

Agents are very good at searching out, collecting, and synthesizing information. Humans are very good at creativity and connecting disparate ideas and experience together to see the relationships between non-obvious pieces of information. A core tenet is to build the workflow in such a way that we're able to both recognize that distinction and optimize for it.

At the same time, humans have been known for using an assortment of tricks over the centuries in order to kickstart creativity. Writing prompts are a great example of this. As we dig into the details below, we'll explore how we could potentially leverage some of these techniques with our agents in order to try to get our Claws to engage in similar exercises.

NOTE

There are smaller milestones along the way.

This document seeks to walk a fine—and possibly, ill-advised—line between being North Star and reasonable scope for a one-year or so time horizon. There are smaller milestones along the way. Any one of the phases listed above can be shipped individually and start providing value immediately. Any given phase can and should be scoped down to a smaller MVP along the way—but, I think it's useful to get a sense of how a somewhat robust version of the system might operate and then work back from there.

Terms of Art

A few concepts the rest of the document leans on. None are novel; but it certainly doesn't hurt for us all to get on the same page up front.

The pipeline, at a high level

What the pipeline actually does, end to end:

Idea Farming

Idea farming seeks to keep our collective finger-on-the-pulse of industry trends and—more importantly—the wants, needs, and frustrations of potential customers. But, the goal here is to have lots of fingers on lots of pulses and separate the signal from the noise and analyze content at scale.

A polished brass-and-glass opportunity factory operated by lobsters in lab coats: ideas travel along a conveyor belt through stages for sources, signals, trends, frictions, memos, and validation experiments, with humans at decision gates

We'll discuss the system for ingesting data, surfacing signals, and generating ideas—which I'll call opportunities in a moment, but let's take a beat and talk about how all of these things relate. An opportunity always anchors to both a persona and a trend. An idea without a persona is a fantasy; an idea without a trend is a feature for an old market.

Decision ownership in Idea Farming: Adding new sources, adopting a new persona, and retiring one are human calls. At first, we want to make sure that the breadth of this system isn't ballooning for the sake of ballooning, just because a Claw got overly enthusiastic. Opportunity promotion from the curation board into Idea Validation is also a human call, with a written rationale logged on the artifact. Anyone reviewing the work can propose a kill; kill calls also need a name and a rationale on the record.

Over time, we can potentially optimize the system to have a bit more autonomy. But, as I asserted above: Humans are the arbiters of taste and intuition.

A grand brass decision gate inside a venture-studio aquarium room where eager lobster Claws line up with opportunity memos and a calm human reviewer stands at the gate with a clipboard, deciding what passes through

Sources we ingest

Sources come in two flavors: general (Hacker News, Reddit, earnings calls, broad social feeds, general technology news—anything that might surface relevance for multiple personas) and persona-specific (a subreddit for real estate agents, a forum for dentists, an industry newsletter for paralegals, a Discord for high school math teachers—anything we already know belongs to one persona). Each flavor takes a different path through the pipeline, but both share the same ingestion machinery underneath.

In terms of a roadmap, we can start with the general feed and build out abstractions for different types of sources, but I do think the personal-specific analysis is where things get interesting.

The shared part is the boring part. We build common tooling for the source types we keep running into: RSS readers, the Reddit API, a Hacker News firehose, transcript drops, a forum scraper for sites without APIs.

Each connector knows how to pull content from one kind of place, hash it, dedupe it, and drop the raw payload into object storage with provenance metadata. That layer doesn't care about personas; it cares about getting bytes onto disk reliably and noticing when a source goes dark. We figure out some of the common shapes of feeds we want to ingest and then build out some abstractions that make it trivial to additional sources in the future.

What happens next depends on which flavor of source the content came from.

%% Source routing
flowchart LR
  G["General sources"] --> C["Classifier"]
  P["Persona-specific sources"] --> PC["Persona Claws"]
  C -->|"fan out"| PC

Either way, the content lands in front of a Persona Claw.

Persona Claws

Every persona has a dedicated Persona Claw with its own memory—the Claw's accumulating perspective on the persona it owns, and that hydrates automatically on every new session. The way that OpenClaw's memory architecture works under the hood and the fact that a given Claw is basically an isolated memory namespace works extremely well for what we're trying to do here.

The dentist Claw's memory store is a separate workspace from the teacher Claw's; the dentist Claw reads a lot of insurance-billing complaints, sees the same workflow tools mentioned across years of dentist forums, and gets quietly opinionated about what dentists actually care about versus what they say they care about. The Claw watching the real estate agent persona is doing the same thing in its own memory store: listing copy, lead-generation platforms, brokerage politics. These Claws don't share a brain. They share a roster.

When content arrives—either fanned out by the classifier or pushed directly from a subscribed source—the Persona Claw evaluates it against everything it already knows about its persona and decides whether it's relevant. Relevant content becomes signals, gets tagged to the persona, and flows into the rest of the pipeline. Irrelevant content gets logged and dropped: we keep the audit trail of what was rejected and why, because that record is how we tell whether a Claw is being too generous or too stingy. (Also: I don't want to waste tokens processing the same piece of content twice.)

OpenClaw is a natural fit for this. It's ability to react to events allows it to process information as it comes it and it's ability to run background tasks on a regular interval allows us proactively take on work in between.

In their downtime—when the pipeline isn't shoving fresh content at them—Persona Claws hunt for new sources. The dentist Claw notices it keeps seeing references to a niche podcast it isn't subscribed to and proposes adding it. The teacher Claw notices a Discord server that keeps coming up in its evaluation comments and proposes subscribing. New source proposals land in the human review queue with the Claw's reasoning attached—nothing gets added to the ingestion list without me signing off, but the Claws are the ones surfacing candidates.

Every ingestion cycle also refines the persona profile—across both memory layers. The structured slice (communities, influencers, vocabulary, the workflow tools people actually pay for, the TAM estimates, the registered sources) gets written transactionally to Postgres so other Claws and the internal curation dashboard can query it.

The Claw's own evolving understanding (the half-formed hypotheses it wants to revisit, the patterns it has noticed but hasn't formalized, the predictions it's still mad about getting wrong) goes into its memory store. A Persona Claw a year into operation knows more about its persona than the day-one version did because both layers compound—the database in clean structured rows, the memory store in long-form prose the Claw can read back next session and build on.

Finding personas we don't have a Claw for yet

Per-persona Claws are great at owning the personas we already know about. They're worthless at noticing the persona we don't. If a coherent new audience starts showing up in our general feeds—municipal arborists complaining about permit software (a story as old as time), indie game studio producers wrangling contractor payroll, hospital chaplains drowning in compliance documentation—nothing in the per-persona setup will see it. Each existing Claw is looking through its own lens and ignoring the rest.

That's the Scout Claw's job. It watches the general source feed and samples across every persona-specific feed, looking for clusters of signals that don't map cleanly onto any existing persona. When it finds one, it proposes a candidate persona: rough sketch of the role, sample evidence, candidate sources that already exist in the ingestion layer, and a one-paragraph case for why this group is worth spinning up a dedicated Claw for.

TIP

A word on sequencing and milestones

The Scout Claw probably isn't the first thing to work on. Most of the work initially will be optimizing the ability to ingest content and synthesize it, but the nice part is that this purely a progressive enhancement and can be added at any time.

It also scores and ranks every candidate. Running a new Persona Claw is not free—synthesis-grade model calls add up, the per-run hydrate/snapshot cycle against Postgres adds up, the time I spend curating its outputs adds up. The Scout's job is to make those costs legible. The scoring rubric: signal volume (how often is this persona showing up in the feeds?), signal coherence (do the signals share workflow vocabulary, or am I pattern-matching on noise?), economic plausibility (does this persona look like a buyer or a charity case?), distinctness from existing personas (is this actually new, or a re-skin of one I already cover?), and source availability (are there enough findable sources to keep a new Claw fed?).

Ranked candidates land in the human review queue. I decide which ones get promoted into a new Persona Claw, which ones get dropped, and which ones get parked as "interesting, but not yet."

Persona Claws compare notes

A standing Weekly Source Review is where I look at source coverage, freshness, persona representation, the new sources each Persona Claw proposed that week, and the candidate personas the Scout Claw surfaced. I deliberately seed lower-AI-readiness personas (teachers, dentists) into the initial source mix so the curation queue does not collapse into Tech-Bro Consensus®.

Claws compare notes

(Pay no attention to the fact that there is a lobster on a plate in the illustration above.)

So far each Persona Claw has been described as a lonely specialist sitting in its own cubicle reading the dentist forums. But, that's not how humans work. What makes humanity special is our ability to share ideas and compare notes.

The interesting opportunities almost never live cleanly inside one persona—they live in the seams. A workflow pattern that's well-established for software engineers might be revelatory for paralegals; a billing fracture that's old news for dentists might be a brand-new opportunity for veterinary clinics. Nobody sees those transfers unless somebody puts the Claws in a room together.

On a regular cadence, every Persona Claw publishes a digest of what it has learned recently: new frictions surfaced for its persona, workflow tools it's seeing show up, vocabulary shifts, anything that's changed in its persona profile. Every other Persona Claw reads those digests and asks the question that drives the whole exercise: is there a version of this that applies to my persona?

%% Cross-Persona Digest peer reads
flowchart LR
  D["Dentist Claw"] -- "digest" --> T["Teacher Claw"]
  D -- "digest" --> L["Lawyer Claw"]
  T -- "digest" --> D
  T -- "digest" --> L
  L -- "digest" --> D
  L -- "digest" --> T

That question has a name. It's the Hollywood Method.

The Hollywood Method

The Hollywood Method is a shorthand pitching technique where you explain a new idea by combining a familiar concept with a new domain, audience, or twist. The structure is usually "X, but for Y" or "X meets Y." Hollywood loves this because executives are terrified of uncertainty and deeply comforted by recycling. Humanity built the moon landing and CRISPR, yet entire industries still communicate primarily through "Uber for dogs." We're a remarkable species.

Good versions work because they instantly transfer emotional tone, mechanics, audience expectations, and market positioning. A few genuinely strong examples:

The best Hollywood Method pitches do three things immediately: transfer a known emotional experience, clarify the audience, and reveal the novelty in under ten seconds. Bad ones are just taxonomy soup—"It's Slack meets blockchain meets TikTok for dentists"—which usually means "we have no idea what this is, but investors were trapped in a conference room long enough to nod politely."

For Persona Claws, the Hollywood Method is the engine of cross-persona transfer. When the software-engineer Claw publishes a digest about how AI code review tools are reshaping pull-request workflows, the lawyer Claw reads it and asks "AI code review, but for contract redlines?" The dentist Claw reads it and asks "AI code review, but for treatment-plan documentation?" Most of those questions die immediately—the workflow topology doesn't actually match, or the persona doesn't have the budget, or the regulatory layer kills it. But the ones that survive become opportunity candidates flowing into the rest of the pipeline.

Other methods at the same meeting

Hollywood is the headliner, but it's not the only tool Persona Claws bring to their digests. The full set lives in the Pattern Library section later in the document, but the ones that show up most often when Claws are comparing notes:

The point of the meeting is not for one Claw to declare the right answer. The point is for ten Claws asking ten different versions of "could this apply to me?" to produce a much larger candidate set than any single Claw could generate on its own. The curation board then sorts the wheat from the taxonomy soup.

NOTE

Cadence

The Cross-Persona Digest runs weekly. Each Claw publishes a token-capped digest (new frictions, new tool mentions, vocabulary shifts), then opens a fresh session whose skill allowlist was set by the Pattern Library router (see the pattern library) based on the digests being read. Transfer candidates flow into the curation board alongside primary opportunity memos.

Persona intelligence

A lobster cartographer with spectacles studying an antique nautical map table inside the venture studio, where economic personas appear as elegant islands with workflow currents, budget reefs, regulatory storms, and community harbors marked

A persona is a bundle: workflows, incentives, budgets, anxieties, constraints, communities, influencers, and the software they already pay for. We are not trying to know who the user is—we are trying to know whether the user has recurring pain, workflows, visible communities, adoption pressure, and a distribution channel we can reach.

NOTE

The types are pseudocode-ish

I think in types. If that's not your jam, skim the code blocks—the prose carries the load. Besides, they're pseudocode anyway.

type Persona = {
  id: string;
  name: string;
  industry: string;
  related_roles: string[];
  // Economic profile
  market_size: {
    tam: number;
    sam: number;
    som: number;
    method: 'top_down' | 'bottom_up';
  };
  willingness_to_pay: {
    who_pays_today: string;
    software_spend_usd: number;
    labor_spend_usd: number;
  };
  buyer_vs_user: 'same' | 'different' | 'committee';
  ai_readiness: {
    // AI readiness (drives the AI Readiness Index)
    adoption_stage: 'early' | 'experimenting' | 'productionizing' | 'mature';
    digital_workflow_maturity: number; // 0-1
    technical_literacy: number; // 0-1
    regulatory_resistance: number; // 0-1
    competitive_pressure: number; // 0-1
    information_work_ratio: number; // 0-1
    data_accessibility: number; // 0-1
  };
  workflow_stack: {
    // Workflow profile
    tools: string[];
    spreadsheets: string[];
    manual_processes: string[];
  };
  core_workflows: string[];
  pain_points: string[];
  handoffs: string[];
  communities: {
    // Ecosystem
    name: string;
    platform: string;
    size?: number;
    norms: string;
  }[];
  influencers: {
    name: string;
    platform: string;
    representative_work: string;
  }[];
  conferences: string[];
  publications: string[];
  vendors: string[];
  // Market dynamics
  fragmentation: 'high' | 'medium' | 'low';
  incumbent_strength: 'high' | 'medium' | 'low';
  switching_costs: 'high' | 'medium' | 'low';
  distribution_channels: string[];
  constraints: string[]; // regulatory, trust, procurement, integration, cultural
};

The AI Readiness Index estimates adoption velocity per persona—the same opportunity can be too early for one persona and immediately viable for another. The factors: digital workflow maturity, economic incentive alignment, information work ratio, competitive pressure, existing software spend, regulatory resistance, technical literacy, data accessibility. A software engineer and a real estate agent might both be affected by AI-assisted work, but they will adopt different products for different reasons.

For example, we know that a large number of software engineers have adopted agentic coding tools and we can make some small bets about the next ring of professions: real estate agents or lawyers, potentially. On the opposite side of the spectrum, monks are probably not the next group to hop on the bandwagon.

The persona profile updates continuously as signals arrive, snapshots daily, and surfaces to the human review queue any time the delta exceeds a configured threshold—so I can see when a profile is drifting and ask why before the drift is baked in. Before any persona's opportunity reaches prototype, I want at least one outside read from a practitioner or customer in that field—an outsider's perspective beats insider confidence here, and the Skeptic Claw isn't a substitute for someone who actually does the work.

Some of the scores are still a bit hand-wavy and we can always use those waving hands to adjust their values or their weights manually based on our own intuition.

Due diligence the system automates

A Persona Claw generates an idea. The next question is the obvious one: is this idea worth pursuing? The Market Analyst Claw exists to answer it numerically.

When a Persona Claw promotes an opportunity, the Market Analyst fires (webhook, synthesis-grade model) and runs the financial and market gauntlet. It does not re-discover communities, influencers, or workflow tooling—the Persona Claw already owns that standing knowledge. The Market Analyst's job is to take the idea, crunch the numbers, and return a pursuit recommendation with the reasoning attached. The reasoning lives across four scores, each a number between 0 and 1, each with a written justification linking back to source:

The four scores combine into a single pursuit score between 0 and 1, with weights I tune at the Quarterly Thesis Review. Low pursuit scores do not automatically kill an idea—I still decide at the curation board—but they require a written defense to override. "Looked exciting in the room" is not a defense.

NOTE

Inputs and outputs

The Market Analyst reads the opportunity memo, the persona profile that produced it, the linked trend, and the friction artifacts—no new crawling, just what the Persona Claw already cataloged plus standing connectors to Crunchbase-equivalent funding data and search APIs for competitive checks. Every score is a paragraph of rationale plus inline citations. Lands on the curation board alongside the memo and the Skeptic critique.

Trend intelligence

A trend is a pattern that explains why a workflow or market is changing. It becomes useful when it points toward friction, timing, or transferable opportunity. A trend with no actionable downstream is just a Twitter thread.

In terms of sequencing, this can probably come a bit later on—just like the Scout Claw that we discussed previously. That said, it's would exploring conceptually up front.

Lobster strategists studying an elegant underwater observatory map where trends are glowing stars, personas are planets, workflows are orbital paths, and opportunities are route markers connected by fine graph lines

type Trend = {
  id: string;
  name: string;
  scope: 'macro' | 'industry' | 'workflow' | 'persona_specific';
  persona_ids?: string[]; // optional; trends can span personas
  supporting_signal_ids: string[]; // minimum 3 to be named a trend
  scoring: {
    evidence_strength: number; // 0-1
    cross_domain_reach: number; // 0-1
    acceleration: number; // 0-1
    non_obviousness: number; // 0-1; weighted heaviest
    actionability: number; // 0-1
  };
  composite_score: number;
  status: 'candidate' | 'monitored' | 'promoted' | 'retired';
};

Trends operate at four resolutions:

  1. Macro: AI-assisted knowledge work becomes normalized.
  2. Industry: real estate agents use AI for listings and follow-up.
  3. Workflow: (professionals draft regulated documents with AI.
  4. Persona-specific: (teachers draft parent communications with AI.

Non-obviousness does the most work in scoring: if the trend is already on the cover of a magazine, we are late. We didn't need to build this system just to surface up obvious trends and ideas, right?

NOTE

Extraction is plumbing

Trend, friction, and workaround tagging are heartbeat jobs on a fast-extraction model—plumbing, not Claws. Trend candidates require at least three supporting signals (never one anecdote). Workaround detection (DIY processes, spreadsheet glue, copy-paste loops, manual reconciliation) gets its own pass because it's the single most valuable signal in the system. None of these jobs can promote anything—that's a curation-board call.

Opportunity scoring

As I said earlier:

The by-product of ingesting content and processing through Claws for synthesis and having them compare notes is to come up with non-obvious opportunities that we might want to pursue.

A lobster scribe at a polished mahogany desk drafting a structured opportunity memo under a brass lamp, with assistant lobsters bringing evidence cards, counterargument notes, persona folders, and workflow diagrams

An opportunity is not an idea name on a sticky note. It is a structured hypothesis that connects a persona, a trend, a workflow, a friction, a capability, a timing rationale, a competitive gap, a distribution path, and a validation plan. Persona and trend are the two required anchors—an opportunity that cannot name both does not get a memo.

type Opportunity = {
  id: string;
  name: string;
  persona_ids: string[]; // required, primary + secondary
  trend_ids: string[]; // required, at least one
  workflow_ids: string[];
  friction_ids: string[];
  capability_ids: string[]; // AI capabilities making it viable now
  pattern_ids: string[]; // Hollywood, Shopify, Cursor, etc.
  memo: {
    // The opportunity memo (narrative)
    thesis: string;
    why_now: string;
    ai_advantage: string;
    prototype_concept: string;
    distribution_hypothesis: string;
    falsification_criteria: string; // what would make us reject this
    mystic_note: string; // first-person, what it FEELS like; cannot be empty
    artist_note: string; // what the artifact should feel like as a gift; cannot be empty
  };
  score: {
    // Ten-factor score, multiplicative against the right-to-build filter
    pain_severity: number;
    frequency: number;
    economic_impact: number;
    ai_advantage: number;
    prototype_speed: number;
    distribution_accessibility: number;
    competition_density: number;
    defensibility: number;
    composite: number;
  };
  validation_plan?: ValidationExperimentConfig;
  status:
    | 'draft'
    | 'reviewing'
    | 'promoted'
    | 'validating'
    | 'rejected'
    | 'archived';
};

Each opportunity is evaluated against a number of factors: pain severity, frequency, economic impact, AI advantage, prototype speed, distribution accessibility, competition density, and defensibility. All of these are obviously up for discussion.

There are two interesting ones hidden here: the Mystic Note and the Artist Note. If the mystic note explains the future, the artist note explains the soul. An a good opportunity has both: The mystic note explains why the company matters historically; the artist note explains why users love it emotionally.

Mystic Note

Mystic Note is a first-person prose about what the opportunity feels like. Not the market case, not the score. The moment from a real interaction with the persona that made you realize the opportunity exists.

The point is not that the statement is fully provable today. The point is that it reframes the world in a way that feels prophetic. Good mystic notes create gravity. They make investors and early employees feel like they are participating in history rather than merely joining another SaaS company that helps dentists schedule appointments more efficiently. Humanity’s true calling.

Artist Note

An Artist Note is more about taste and emotional intent. Why does this product exist aesthetically or philosophically? What experience should users feel? What does the creator care about at a deep level?

NOTE

This will likely need human involvement.

I'd love to be wrong about this, but I'd be remiss that I'd call out that I'm not totally sold on a models ability to do this with any fidelity. Luckily, this doesn't have to be a one-way door.

Microscopic case study

Let's explore a fictitious example, AI Review Copilot for Insurance Claims:

The pattern library

A grand underwater business library with towering mahogany shelves, brass ladders, and leather reading chairs, where lobsters in tailored attire pull ornate method books representing reusable business patterns shown as tasteful icons

A Pattern is a reusable innovation transformation—a method that, given a trend or friction, produces a new opportunity hypothesis. We saw a few of them before when we talked about the Hollywood Method and others. Patterns are not labels you attach after the fact. They are generators. The library is tuned over time by tracking which patterns produce ideas that survive validation.

These are ways to hopefully trick the Claws into generating some unexpected insights that they can investigate to see if there are any hidden opportunities.

Under the hood, the Pattern Library is a collection of skill bundles—prompt template, output schema, applicability criteria, and a track record—plus the routing layer that decides which bundles a Persona Claw should have access to on a given run. That routing layer matters: OpenClaw snapshots an agent's skill list when a session starts and reuses it for the duration, so "load the right bundle dynamically based on what the Claw is currently looking at" isn't a thing the platform does. Skill selection has to happen before the session starts.

The router is a small Postgres-and-prompt-template service (plumbing, not a Claw): given a digest's contents or a draft memo's friction-and-capability tags, it queries the Pattern Library, ranks bundles by their applicability_criteria match, and starts the Persona Claw's session with the top-K bundles allowlisted. The Persona Claw then has those bundles available as skills in the usual OpenClaw way. The router is the reason applicability_criteria is a useful field—without it, every Claw would have to either carry the full library in its session prompt (expensive) or run one fresh session per bundle (slow). The router handles the trade-off.

type PatternBundle = {
  id: string;
  name: string; // e.g., "Hollywood Method", "Cooperative Method"
  mechanism: string; // one-sentence summary of how it transforms an input
  prompt_template: string; // the instantiation prompt a Claw loads to apply this pattern
  output_schema: JSONSchema; // the structured shape the application must produce
  applicability_criteria: string[]; // conditions under which the bundle is worth loading
  anti_patterns: string[]; // conditions that should cause the bundle to abort
  required_capabilities: string[];
  failure_modes: string[];
  examples: { company: string; outcome: string }[];
  performance_metrics: {
    times_applied: number;
    curation_promotion_rate: number;
    validation_survival_rate: number;
    prototype_outcomes: { passed: number; killed: number };
  };
};

The Reflection Claw (discussed later) recomputes performance_metrics quarterly. Bundles with sustained bad ratios get retired or refined; new bundles get added when I write them and approve them at the Quarterly Thesis Review. Adding a new pattern means writing a bundle file, not deploying a new Claw.

output_schema is a contract the database enforces at write time, not something OpenClaw validates inside the Claw. Same rule as the rest of the system: the operational database rejects any artifact whose shape doesn't match the schema or whose evidence chain doesn't resolve back to underlying signals. The schema lives on the bundle so the Claw can be prompted to produce the right shape; the rejection lives in Postgres so the guarantee is structural, not vibes.

The obvious patterns are all Silicon Valley archetypes. They are useful, but they narrow imagination if they are the only patterns the library knows. The interesting bets often live where two unfashionable things meet—software plus craft, data plus lived experience, technology plus civic infrastructure. The library has a second tier for exactly that reason.

SaaS and platform archetypes:

Non-SaaS archetypes — the patterns that produce companies the Valley defaults do not see:

A lobster film director on a polished studio soundstage transferring an underlying workflow pattern from one elegant set representing code review to another representing insurance claims review, with the reusable skeleton visible

The Hollywood Method is the engine of cross-persona transfer—the full definition, examples, and the "X, but for Y" framing live earlier in the doc where Persona Claws apply it to each other's digests (see The Hollywood Method). One technical rule the Pattern Library enforces on every Hollywood-style transfer, regardless of who proposed it:

WARNING

The transfer rule

The system should not just copy product names across industries. It extracts the underlying workflow topology, then tests whether the target persona has equivalent artifacts, incentives, constraints, and willingness to pay. "AI code review, but for X" is a bad opportunity by default. "Code review topology applied to X, where X has the matching ingredients" is a candidate.

NOTE

When bundles get loaded

Bundle selection happens at session-start time, not mid-session. The router fires twice: once when the Cross-Persona Digest job spawns a Persona Claw's weekly session (allowlisting bundles whose applicability criteria match the digests being read) and once when an opportunity memo session opens (allowlisting bundles that match the memo's friction-and-capability tags). Every bundle application within the session is its own trace, with bundle id and prompt_template version recorded—that's how the Reflection Claw scores pattern performance later.

Four non-SaaS worked examples

The machinery has to run on more than SaaS. Four sketches, each running the same right-to-build filter, ethics gate, and validation experiment as anything else:

The Claw roster

The way to think about Claws is not "automated workers" but professionals—each one is the equivalent of a person you would hire for a specific job. They have memory. They have continuity. They get better at their job over time. They hand artifacts off to each other the way a small team would. The roster is short on purpose: as many Claws as we need, as few as we can get away with.

NOTE

This is not a hill that I'm willing to die on.

More than maybe any other part of this plan, this is probably the most up for debate. I think that in the act of building this system, we'll learn a lot and this will change significantly. The nice part is that the earlier ones (e.g. the Persona Claw) are probably the least controversial.

Here's the whole roster at a glance:

ClawCadenceReadsWrites
Persona Claw (one per persona)ContinuousIncoming signals routed to its persona; its own memory store; persona's structured slice in PostgresFiltered signals, opportunity memos, persona-profile updates
Scout ClawWeeklySampled slice of general feed + stratified sample of persona-specific feedsCandidate new-persona proposals (human review queue)
Market Analyst ClawWebhook on memo promotionThe drafted memo, persona profile, linked trend, friction artifactsPursuit score (4 dimensions + composite) with citations
Skeptic ClawDB-write triggered (every memo, score, scorecard)The artifact under review + its evidence chainCritique artifact alongside the original
Web Developer ClawOn experiment publishExperiment configDraft landing pages, pricing tables, surveys (preview env, human-released)
Marketer ClawOn experiment publishExperiment config, channel historyCampaign briefs, UTM-tagged links (queued, human-released)
Researcher ClawContinuous during validationInterview transcripts, concierge notes, uploaded artifactsCoded transcript summaries, qualitative scorecard ratings
Reflection ClawQuarterlyPostmortems, original memos + scorecards + critiques, Pattern Library bundle tracesQuarterly recalibration packet (proposed weight changes, retirements)

Idea Farming Claws

Idea Validation Claws

Cross-phase

Reflection and Improvement Claws

What's not a Claw

The word Claw should mean something. If we call every script and webhook handler a Claw, the word loses its weight. The things below get the job done in the pipeline but do not deserve the title:

Naming these as plumbing rather than Claws keeps the architecture honest about where the actual reasoning lives. This is covered in greater detail it the Architecture section.

What every Claw owes the system

Every Claw's model calls, tool calls, and memory reads are logged via OpenTelemetry. Every artifact carries the trace ID of the Claw that wrote it, so any claim in any memo can be traced back to the run that produced it and the evidence it was looking at.

Memory is split between two layers, and getting the split right is the most important architectural detail in this document. OpenClaw sessions are independent—each new session starts with a fresh agent context. But OpenClaw gives every agent a memory store: a workspace-scoped, versioned document collection that the agent reads and writes via standard file operations, and that persists across sessions. The agent doesn't carry conversation history forward; it carries its accumulated notes, evolving opinions, and learned vocabulary forward in the memory store.

So memory works in two layers:

%% Memory model
flowchart LR
  C["Claw session"]
  C <--> M["Memory store<br/>(evolving understanding)"]
  C <--> P["Postgres<br/>(typed artifacts)"]

The rule for which goes where: if it's a typed artifact that anything besides the originating Claw needs to read, it goes in Postgres. If it's the originating Claw's own evolving understanding—its mental model, its half-thoughts, the patterns it's noticed but not yet formalized—it goes in the memory store. The Persona Claw's "I keep seeing this billing complaint from three different dentist forums and it's starting to feel like a real pattern" lives in the memory store. The Persona Claw's "this is the pursuit score and these are the evidence links" lives in Postgres.

Every Claw run starts with two reads: the memory store hydrates automatically when the session attaches to it, and the Claw fetches the relevant structured slice from Postgres. Every run ends with the same two writes: a memory store update (auto-versioned by OpenClaw) and a structured Postgres write (transactional, RLS-checked, evidence-validated by trigger).

Two things Claws do not get to do (for now), in any configuration: no outbound communication (no email, no posts, no ad spend; drafts sit in queues until released by a human) and no status changes that close a decision (a Claw can write status: drafted or status: critiqued, never status: promoted, status: killed, or status: validating).

The pipeline, end to end

Tiny lobster agents in hard hats running a miniature brass-and-glass data refinery: tangled raw material enters as papers, transcripts, and comments; clean glowing signal capsules emerge, each tethered back to its source by a fine evidence line

The pipeline runs continuously, not in batches. Each stage produces an artifact the next stage reads and an audit trail the reviewer can walk back through whenever a claim looks suspicious.

%% Pipeline, end to end
flowchart TB
  A["Source ingestion"] --> B["Normalization & enrichment"]
  B --> C["Signal extraction"]
  C --> D["Trend & friction clustering"]
  D --> E["Opportunity memos<br/>(Persona Claw)"]
  E --> F["Skeptic critique"]
  F --> G["Curation board<br/>(human gate)"]
  G --> H["Validation experiments"]
  H --> I["Scorecard"]
  I --> J["Prototype decision<br/>(human gate)"]

After ingestion, raw content gets cleaned, deduplicated, timestamped, and enriched with source type, source credibility, persona associations, entities, industries, geography, author, publication date, content hash. Boring; load-bearing. This is plumbing—a heartbeat-triggered normalization job on a fast-extraction model—not a Claw with memory or judgment.

The analysis engine extracts atomic signals—narrow enough to trace back to a source. Extraction types include behavioral shift ("real estate agents are using AI to draft listing copy"), market shift ("vendors are packaging AI features into existing professional software"), workflow shift ("teachers draft lesson materials with AI then adapt them"), friction ("dentists complain that insurance documentation creates repeated delays"), and workaround ("users export CSVs, paste into ChatGPT, copy outputs back"). Every signal stays linked to the source it came from—a Claw that produces a signal without a citation has its output rejected at write time.

Signals get clustered along behavioral, market, cultural, and workflow axes. Clusters produce trend candidates that retain links to underlying signals, so reviewers can inspect the evidence instead of trusting a summary. Clustering happens at multiple resolutions: small clusters for specific frictions, medium for persona-specific trends, larger for macro trends that may transfer across industries.

A lobster detective in a tailored trench coat studying a corkboard in a premium wood-paneled office, with screenshots, spreadsheet fragments, CSV scraps, and red string connecting repeated manual workarounds

The system explicitly searches for workflow fractures: CSV exports, copy-paste behavior, screenshots used as APIs, spreadsheets used as databases, Slack threads used as process management, humans retyping between systems, repeated checking of AI output. Latent demand leaves footprints. These are where the existing tooling is broken and where someone is doing manual work that a real product could absorb.

Opportunity generation combines trend context, persona context, workflow friction, AI capability mapping, and pattern transfer. The goal isn't a long list of startup ideas—it's a smaller set of coherent opportunity theses with evidence, risks, and validation plans. Anyone with a model API key can generate a hundred ideas before lunch. The hard part is making each one defensible.

NOTE

Who writes the memo

The Persona Claw writes it—everything the memo needs (persona context, workflow friction, capability mapping, pattern bundles) is already in its hands. Output is status: drafted. The database rejects any memo whose evidence chain doesn't resolve back to underlying signals, and the Claw can't promote to validating—that's human-only.

Adversarial review

Every trend and opportunity faces an adversarial pass before it reaches the curation board. The reviewer's job is to disprove the thesis and find where the logic is weak. The questions:

If a thesis cannot survive that list, it does not reach the Curation Board.

A stern but elegant lobster prosecutor cross-examining an opportunity memo in a dramatic business courtroom, with the memo sitting on a witness stand under a spotlight and glowing evidence threads connecting it to source cards

The indifference filter deserves a longer note. A workaround is sometimes a footprint of latent demand, sometimes a footprint of expressed indifference—the user has a free fix that is good enough and will not pay to replace it. CSV-pasting into a free LLM signals the user already found the answer, not that they are waiting for a paid version. Two cases worth keeping in the library: real demand—small-firm legal teams paying integration consultants quarterly to keep hand-curated multi-tool stacks talking; indifference—hobbyist users pasting documents into a free LLM for personal reading. Every adversarial review of a workaround signal should be able to cite which case applies.

NOTE

Why the Skeptic is structurally separate

Two guarantees make this work and both have to hold. First: the Skeptic runs on a different model family from whichever Claw produced the artifact—two Claws on the same model that share the same blind spots produce theatre, not critique. Second: the trigger is the database write, not the upstream Claw firing the Skeptic directly. The artifact lands in Postgres, the same transaction writes an outbox row, the Temporal CDC subscriber tails the replication slot and starts a fresh Skeptic workflow. The upstream Claw cannot decide whether its own draft gets reviewed. One finding per adversarial question, each with a confidence tag and a citation. Cannot promote, kill, merge, or rename.

The Curation Board

Lobster reviewers and human collaborators gathered in a refined intelligence war room around a large glowing curation board showing opportunity cards, evidence chains, counterarguments, scores, and decision stamps

The Curation Board is where humans take over—and also where they can observe the process in the mean time. It shows AI-generated trend and opportunity candidates with evidence, scores, adversarial critiques, the due-diligence packet, adjacent patterns, and recommended next steps. Reviewers can merge, split, rename, reject, monitor, or promote.

Each item carries: opportunity name, one-sentence thesis, strongest signals, surprising examples, counterarguments, who benefits, who is threatened, what would make this false (falsification criteria), suggested adjacent trends, recommended action, plus the Mystic Note and Artist Note that we discussed above.

The Weekly Opportunity Review is where we walk the board: promote or reject candidates that have aged enough to decide on, identify which ones need more evidence. The output is a list of opportunities entering validation and a list of kills with reasons.

NOTE

No Claw owns the board

The Curation Board is a human review surface—status writes only come from a logged-in human. The inbox is pre-sorted by score and confidence (a SQL ORDER BY, not a Claw). When a human promotes a candidate, a prompt template drafts the Idea Validation experiment configuration (also a function call, not a Claw); the Idea Validation Claws pick up from there.

Stage gates

Most failures happen at the seams between stages, not inside any one stage. An experiment that should have stayed an experiment gets nudged into a concierge MVP; a concierge MVP that should have died gets nudged into a prototype. Every stage gate has the same shape: a small list of conditions, plus a human approver. If the conditions are not met, the project stays at its current stage or gets killed—those are the only two moves.

%% Stage gates
flowchart LR
  S["Signal"] -->|"gate"| O["Opportunity"]
  O -->|"gate"| V["Validation"]
  V -->|"gate"| C["Concierge MVP"]
  C -->|"gate"| P["Prototype"]

I own every gate decision. The Claws produce the evidence; humans approve or kill. Every promotion and every kill is logged with my name and a one-sentence rationale on the artifact.

The ethics gate

Before any prototype investment, the proposed venture passes a six-question yes/no gate. If I cannot answer all six with "yes," the project does not get prototype budget. This is not a scoring rubric. It is a yes/no.

%% Ethics gate
flowchart LR
  Q1["1. Agency"] -->|"yes"| Q2["2. Dignity"]
  Q2 -->|"yes"| Q3["3. Non-exploitative"]
  Q3 -->|"yes"| Q4["4. Trust"]
  Q4 -->|"yes"| Q5["5. Defensible model"]
  Q5 -->|"yes"| Q6["6. Sovereignty"]
  Q6 -->|"yes"| PASS["Prototype budget"]
  Q1 & Q2 & Q3 & Q4 & Q5 & Q6 -.->|"any no"| KILL["Kill"]

Each question carries anchor examples—yes, no, borderline—drawn from real ventures, so I am voting on the question rather than the room's mood.

Any single "no" fails the gate; the answer has to be six unanimous yeses, with a written rationale per question on the record. The ethics veto is live: anyone reviewing the work can invoke it at any stage, not just at the formal gate.

WARNING

The published failure log

Every quarter, the log of ventures that failed the gate that quarter goes public, naming the question that killed each one and the rationale. If no ventures failed in a quarter, that fact is itself published. Silence is a signal: either the gate is doing nothing, or the upstream pipeline is already filtering out the cases the gate exists to catch. I need to know which. The gate's authority comes from the artifacts it produces, not the conversation it describes.

A Monthly Design Review reads every venture currently in concierge MVP or prototype against a rubric covering visual craft, interaction quality, copy quality, and feeling-as-gift. I do the read myself, recorded against the rubric so it's auditable, not just vibes. Output: a written design read attached to the venture's evidence pack, carrying the same weight as the scorecard in the next stage-gate decision.

Idea Validation

This where things get interesting. The Claws have scoured the internet far and wide to surface the tastiest idea nuggets that they could possibly find. But, are we right? Are people actually interested in this? Are they willing to pay for this? Is this a plausible venture?

The way to answer those questions is simple (but, not necessarily easy): We give them the opportunity to sign up and pay. In my humble opinion, that's a pretty good way to tell.

Idea Validation is the part most opportunity-discovery efforts skip. Discovery produces memos. Memos are not businesses. A memo says "this looks interesting." A validation experiment says "here is what happened when I put this in front of the actual persona and asked them to commit something." The gap between those statements is where most startup ideas quietly die after burning a quarter of engineering time.

A transparent brass-and-glass validation engine inside a refined laboratory: a structured opportunity memo enters one side; persona-specific landing pages, pricing tests, surveys, call bookings, analytics funnels, and scorecards emerge from the other

The validation engine is a repeatable experiment factory that converts selected candidates into instrumented market experiments—persona-specific landing pages, pricing tests, qualification surveys, ad variants, outbound campaigns, analytics funnels, decision dashboards. All generated from structured opportunity data, all measuring a standard set of signals so different opportunities can be compared fairly.

A compelling idea is not evidence of a business. A trend is not a buying signal. A pain point is not automatically a budget. The validation engine forces each candidate to survive contact with a real audience before engineering time is committed.

Decision ownership in Idea Validation. Validation budget, concierge MVP greenlight, prototype investment, experiment kill—all my calls. Prototype investment also requires the ethics gate to clear and at least one outside read from a practitioner in the persona's field. Every promotion and every kill is logged with my name and a one-sentence rationale on the artifact.

At a high level, this is the general shape (which is definitely up for debate and discussion):

  1. Take an opportunity that we vetted above
  2. Whip up a quick website with some product details, pricing information, and other requisite information.
  3. Add a sign-up form or—even better—the ability to book a call with us.
  4. Run some ads (Google, LinkedIn, Reddit, etc.) targeted at the persona in order to drive traffic to the site.
  5. Measure.

What we actually need to prove

A refined split-screen tableau: on the left a cheerful lobster collects lightweight bubbles representing casual signups; on the right a focused lobster weighs heavy brass tokens representing booked calls, artifact uploads, pricing selection, deposits, and paid pilots

The central test is commitment, not interest. Lots of ideas are interesting. Seven dimensions, each with the evidence that answers it:

TIP

Signal strength

A signup is a polite click. A booked call costs the visitor thirty minutes. A deposit costs them money. The system measures each separately. "We got 400 signups" sounds great in a Friday update and means almost nothing in a Monday strategy meeting. The metric that matters is the count of people who gave us something costly—time, money, information, or workflow access.

The validation pipeline

Eight stages, each feeding the next: select opportunity, define hypothesis, generate experiment configuration, publish validation assets, drive traffic and outreach, capture evidence, score and review, decide. The decide step is what this whole apparatus exists to feed.

NOTE

Three Claws, plus plumbing

Idea Validation runs end-to-end through OpenClaw with three professional Claws on top of webhook plumbing. The Web Developer Claw renders the landing pages, pricing variants, and surveys. The Marketer Claw prepares campaign briefs and UTM links. The Researcher Claw drafts interview scripts, codes transcripts, and runs the qualitative side. Webhook handlers normalize PostHog, Stripe, and Cal.com events into the operational database; a nightly aggregation produces the quantitative scorecard; the Skeptic Claw critiques the assembled packet before it reaches the Weekly Validation Review.

The Weekly Validation Review is where I read the scorecards and decision packets from live experiments and produce kill / revise / validate-more / concierge / prototype decisions—each with my name on it.

Landing page strategy

Every landing page is persona-specific and evidence-seeking. It doesn't read like the generic AI SaaS page—you know the one: purple gradient, "Supercharge Your Workflow" hero, a "Join Waitlist" button that tells you nothing about whether anybody wants the thing. I've personally shipped that page. Twice. The signal it produces is "people will click a button." The signal we need is "people will commit something costly." The page has to make a concrete promise, describe a recognizable workflow pain, show a plausible before-and-after, and ask for an action that reveals commitment.

Each page follows a standard skeleton. The hero states persona, pain, and promised outcome in one screen (signal: CTR-to-CTA alignment, bounce, scroll). Problem proof describes the pain in the persona's language (signal: scroll depth, time on page). Before-and-after workflow shows how the product changes the process. Use cases make the idea concrete through three to five specific tasks. Pricing reveals perceived category (signal: pricing-page view, tier selection, checkout start). Qualification survey captures role, company, tools, frequency, urgency, current workaround. Artifact upload asks for a real workflow input where appropriate—high-intent evidence and prototype material in one move. Book a call offers research, pilot, or design-partner conversations. FAQ handles common objections.

Each opportunity tests at least two positioning angles where the channel supports it. The five worth testing: time savings (high-frequency manual workflows), revenue capture (work that drives sales), risk reduction (regulated work), quality improvement (expert work where review matters), coordination reduction (multi-stakeholder workflows with handoffs).

Lobster analysts testing pricing assumptions in an elegant laboratory using brass scales and polished tokens, with lightweight individual plans, heavier team plans, custom pilot contracts, and refundable deposits appearing as physical objects with different weights

Pricing is part of the experiment, not deferred until after prototype. The number tells you what category the persona naturally puts you in. Five tests, weakest to strongest signal: $19–$49 individual (personal productivity?), $99–$299 team (pain extends beyond one user?), $499–$1,500 agency or business (linked to revenue?), custom pilot pricing (sales-led validation?), refundable deposit or paid pilot (does stated interest convert into economic commitment?). The refundable deposit is the demand test most teams flinch at—and the one that actually tells you something. If asking someone to put down $50 makes you uncomfortable, that's a sign you don't yet believe the demand is real.

Channels

Paid traffic is useful for message resonance and demand discovery, but it can validate clever ad copy rather than real product demand. The Marketer Claw prepares upload-ready campaign briefs and UTM-tagged links per channel and queues them for a human to publish—no Claw has API write access to a paid platform in the first wave. (To be 100% clear, it would be great if we got this Claw optimized to the point where we did fully trust it.)

The Marketer carries continuity from week to week: it remembers which channels flopped for which personas, which subject lines won the last outbound batch, and which audience definitions are running too hot. That memory is what separates it from a stateless template renderer.

Channels with their best-fit use: Google Ads for high-intent search where the persona already names the pain; Microsoft Ads for professional and older-skewing search at lower cost; Reddit Ads for community-based persona tests where weak creative backfires fast; LinkedIn Ads for B2B by title and seniority, expensive but precise; Meta and TikTok for consumer, prosumer, creator; newsletter sponsorships for niche professional audiences; outbound email for narrow B2B; communities and forums for persona-specific qualitative signal (carefully, without spam); Product Hunt and Hacker News for developer tools, a poor proxy for traditional industries.

Personas live in different places. Software engineers live on Hacker News, Reddit, GitHub, dev newsletters, X, Product Hunt. Professional services live on LinkedIn, Google Search, niche newsletters, industry communities, outbound, webinars. Local businesses live on Google Search, Meta, local groups, trade publications. Teachers and public-sector users live in interviews, communities, procurement research, district conversations—that row matters most and gets noticed last. You do not validate a teacher product with a LinkedIn ad. That conversation is six months long, not six days.

Qualitative validation

A dignified lobster butler manually delivering a promised product outcome to an early customer before full software exists, with small lobster operators assembling the result by hand behind a velvet curtain using documents and checklists

Analytics show what happened. They rarely explain why. For each opportunity that clears the demand threshold, run five to ten interviews focused on past behavior, not hypothetical enthusiasm—people are generous when asked "would you use this?" and accurate when asked "tell me about the last time this came up." Ask what triggered it, what tools and people were involved, what it cost in time and money, what they already pay for near this workflow, who would approve a purchase, what would block adoption, and—critically—what would make the product untrustworthy. That last question is the one most interviewers skip and the one that most often saves the prototype from foreseeable failure.

Before building a full product, manually deliver the promised outcome for a small number of qualified users. If the manual version does not create value, automation will not rescue the idea. Four qualitative methods carry different jobs: concierge MVP (does the user value the outcome enough to repeat or pay?), clickable mockup (is the workflow understandable?), artifact-based test (will users share real workflow inputs?), pilot application (operational need and implementation readiness?).

NOTE

A researcher with continuity

The Researcher Claw drafts interview scripts, codes transcripts, ingests concierge session notes, runs the Six-Month Dignity Check, and produces structured ratings for the scorecard. It doesn't replace human interviews—it summarizes and codes them so qualitative reads compare cleanly across experiments. And like any decent researcher, it remembers what each persona keeps saying across calls, even when nobody named it out loud.

The technical stack

This is discussed further in the Architecture section.

A compact experiment factory machine on a polished mahogany workbench: a structured opportunity brief slides into the input tray; landing page mockups, pricing variants, UTM cards, ad briefs, surveys, analytics dashboards, and scorecards emerge in neat stacks

The validation engine is a reusable experiment factory, not a collection of one-off landing pages. A new opportunity is defined as structured config, then used to generate pages, tracking, forms, pricing variants, ad briefs, UTM links, and dashboards.

Baseline stack: SvelteKit on Vercel for experiment pages, Neon Postgres for the data plane (same database the Idea Farming pipeline uses—no separate validation stack), PostHog for product analytics and feature flags, GTM + GA4 for ad tracking, Stripe for pricing tests and deposits, Resend for transactional email, Cal.com for booking, Attio for the relationship-aware CRM, Cloudflare Turnstile on every CTA so the "qualified signups" number isn't half scrapers, and the Google Ads API introduced only after manual launch stabilizes. Full stack rationale in Architecture.

Each experiment is defined by a structured ValidationExperiment config. Hypothesis and success criteria are required; the experiment cannot launch without them.

type ValidationExperimentConfig = {
  id: string;
  opportunity_id: string;
  persona_id: string;
  hypothesis: string; // required, what must be true
  positioning: {
    headline: string;
    subheadline: string;
    pain_statement: string;
    promised_outcome: string;
    before_state: string;
    after_state: string;
  };
  pricing: {
    model: 'individual' | 'team' | 'agency' | 'pilot' | 'deposit';
    tiers: {
      name: string;
      price_usd: number;
      interval?: 'monthly' | 'annual' | 'one_time';
    }[];
  };
  ctas: {
    primary:
      | 'book_call'
      | 'signup'
      | 'deposit'
      | 'pilot_application'
      | 'artifact_upload';
    secondary?: 'survey' | 'newsletter';
  };
  channels: ChannelPlan[];
  success_criteria: ExperimentThresholds; // required, set BEFORE launch
};

The data model preserves relationships between opportunity, persona, experiment, variant, channel, visitor, and event:

%% Experiment Data Model
flowchart LR
  Opportunity --> Experiment
  Persona --> Experiment
  Experiment --> LandingPageVariant
  Experiment --> PricingVariant
  Experiment --> ChannelPlan
  ChannelPlan --> AdVariant
  Experiment --> Visitor
  Visitor --> Event
  Visitor --> Signup
  Signup --> SurveyResponse
  Signup --> ArtifactUpload
  Signup --> CallBooking
  Signup --> CheckoutSession
  Experiment --> ExperimentScore

The standard event taxonomy is named identically across every experiment so cross-experiment comparison is possible without rewriting analytics: page_view, scroll_50/scroll_90, hero_cta_click, pricing_view, pricing_tier_selected, signup_started/signup_completed, survey_started/survey_completed, artifact_upload_started/artifact_upload_completed, book_call_clicked, checkout_started/checkout_completed, faq_expanded. Every event carries the same property bag: experiment_id, opportunity_id, persona_id, variant_id, UTM fields, plus the qualifying fields role, company_size, selected_tier, declared_budget, urgency.

Scoring

Five ornate brass decision gates in a polished aquarium-lit hall, representing kill, revise, validate more, concierge MVP, and prototype, with a thoughtful lobster guide and a human reviewer choosing a gate using a scorecard

NOTE

Three artifacts, one decision packet

Scoring runs nightly during an active experiment (on-demand on request). The quantitative half is a SQL aggregation—not a Claw. The Researcher Claw produces the qualitative ratings. The Skeptic Claw critiques the assembled scorecard, watching for cases where a single channel, a single high-intent visitor, or a clever positioning angle is doing all the work. All three land on the reviewer's decision packet. The decision column is null until a human writes it.

WARNING

Who scores, and who does not

The person who designed and ran a validation experiment cannot also be the one who scores it. The same person who built the demo does not grade the demo. Qualitative interviews with concierge users are conducted by someone without skin in the opportunity. Where team size makes strict separation impossible, the scoring partner is the one whose calendar shows the least time spent on the opportunity that quarter.

Seven dimensions:

const validationScore =
  personaFit * 0.2 +
  painSeverity * 0.2 +
  paidIntent * 0.15 +
  sixMonthDignity * 0.15 +
  channelAccess * 0.15 +
  messageResonance * 0.1 +
  prototypeConfidence * 0.05;

Persona fit, pain severity, paid intent, and six-month dignity together carry 70%—intentional. The first three are where teams most often deceive themselves at the funnel; the fourth is where they deceive themselves about the longer arc. A funnel will book a call for a predatory product and a humane one with equal enthusiasm—six-month dignity is the dimension that distinguishes them. The dignity check is lagged (data does not exist until month six), so until then the dimension scores as pending and lower-/upper-bound scores both surface on the decision packet. Once data arrives, the dimension is binding.

The decision-gate logic:

%% Decision Gate Thresholds
flowchart TD
  A["Experiment scorecard"] --> B{"Target persona qualified?"}
  B -- "No" --> C["Kill or revise persona"]
  B -- "Yes" --> D{"Pain recent and costly?"}
  D -- "No" --> E["Revise positioning"]
  D -- "Yes" --> F{"Paid intent present?"}
  F -- "No" --> G["Validate more"]
  F -- "Yes" --> H{"Workflow still uncertain?"}
  H -- "Yes" --> I["Concierge MVP"]
  H -- "No" --> J["Prototype"]

Five possible outcomes per experiment: kill (weak persona fit, weak pain, no paid intent, poor channel access), revise (audience engages but persona, copy, pricing, or promise looks wrong—change one and retest), validate more (signals promising but ambiguous), concierge MVP (pain and access are real but workflow is uncertain—manually deliver the outcome before building), prototype (strong qualified demand, clear pain, credible paid intent, narrow MVP scope). Kill and Revise should be the most common outcomes. If we are not killing or revising the majority of what we test, the bar is too low.

Thresholds get calibrated by persona, price point, and channel. Still, every experiment defines minimum success criteria before launch, because post-hoc rationalization is the single most common failure mode in validation work.

Validation MVP scope

Must have on day one: config-driven landing pages, the experiment/persona/variant/channel data model, the standard event taxonomy, signup/survey/pricing-tier/call-booking capture, manual ad briefs and UTM generation, the scorecard and decision-gate workflow.

Should have later: automated copy generation from opportunity records, dashboard templates, PostHog feature flags and A/B variants, Stripe deposit and paid-pilot flows, artifact upload and review workflow, concierge MVP workflow templates.

Not in the first version: full ad-platform campaign automation, custom attribution modeling, complex ML-based opportunity scoring, full CRM replacement, automated lead enrichment, general-purpose marketing CMS. The third column is the one to defend—most validation projects fail because they accidentally build it on day one, then run out of energy before doing the first column properly.

The first production use tests a small portfolio, not a single opportunity. Three to five opportunities, spread across at least one technical persona, one professional-services persona, and one non-technical SMB or operator persona, run across at least one search-intent test, one community/persona test, and one outbound test. Weekly evidence review. The primary output is ranked prototype recommendations supported by evidence, not subjective enthusiasm—replacing the meeting where the loudest person picks the next prototype with a scorecard anybody can read.

Every experiment starts from the same brief. The fields look simple, but each one forces a decision that prevents post-hoc rationalization later: opportunity name, persona, hypothesis, pain statement, promised outcome, current workaround, pricing assumption, channel assumption, primary CTA, success criteria, and risks. The risks row is the one most teams want to skip and the one that most often saves a quarter—naming the false-positive risks up front means a clever ad headline does not get to masquerade as product-market fit.

Reflection and Improvement

The point of Reflection and Improvement is the system gets smarter. Most pipelines learn implicitly—in hallway conversations, in collective memory, in patterns that get noticed but never written down. I'm betting that explicit learning compounds and implicit learning evaporates the moment anyone joining the project has to pick it up cold.

What gets learned

NOTE

Quarterly output

The Reflection Claw runs once a quarter. It reads every postmortem from the cycle, joins each back to its original memo and scorecard and critique, recomputes each Pattern Library bundle's track record, and tests proposed scoring-weight changes against actual outcomes from the last two quarters. Output: a single recalibration packet with pattern retirements, weight changes, persona-mix observations, and an answer to "what did we believe last quarter that we believe less now?" Nothing writes to live rubrics—every change is human-approved at the Quarterly Thesis Review.

Rituals that keep the system honest

A small number of recurring meetings, each with a definite output. If a ritual is not producing a decision or a learning, it gets killed.

The history of revised thesis documents is a stack. Anyone joining can read backwards and understand how the thinking has changed and why.

One countervailing ritual sits alongside the throughput cadence:

Kill discipline

Killing an experiment is easy. Killing a beloved thesis, a politically attractive idea, a project I'm emotionally invested in, or a venture that is technically alive but not actually winning—that is hard. Four rules:

The AI capability stack

The pipeline runs on AI capability the way an early SaaS company runs on AWS. Cost, reliability, failure modes, and vendor relationships are load-bearing assumptions—"synthesis-grade model" and "fast-extraction model" need specificity, or the first vendor email is a crisis.

Model tiers: a fast-extraction tier (small, low-cost model for atomic operations—signal extraction, entity tagging, deduplication; cost target: cents per thousand operations; at least two providers maintained at all times); a synthesis-grade tier (larger model for opportunity drafting, adversarial review, qualitative coding, scorecard reading; cost target: low single-digit dollars per memo; primary + documented backup, orchestrator routes between them); a long-context tier (cross-document reasoning across a persona's corpus or a venture's full evidence pack; tens of dollars per heavy pass, used sparingly; whichever model offers the strongest large-context reasoning, evaluated quarterly). Acceptable failure modes are bounded in all three tiers—Claw output never writes a promoted record without human review.

Capability assumptions: synthesis-grade models produce memos whose evidence chains resolve to real signals at least 90% of the time (the Skeptic Claw and the curation board catch the rest); fast-extraction models tag signal types and personas with enough precision that the curation queue is usefully prioritized; model providers continue to offer commercial access on terms compatible with the operating budget.

Contingency commitments: at a 4× cost increase from any single provider, the LiteLLM proxy routes around it within one operating week—the architecture is multi-provider by design (see LLM proxy and routing), and the cost discipline of being able to switch is exercised every quarter even when no switch is required. At a capability regression (a model getting worse), the affected Claw tier degrades to the next-strongest available model in the same tier and more candidates land on the curation board with "needs human extension" tags—the pipeline slows, it does not break. At a capability jump (a new model class enabling work that wasn't possible before), the Quarterly Thesis Review is where new capability enters the model—no single capable model gets to rewrite the operating plan in a hallway conversation.

We are not forecasting which way the model market goes. We are committing not to be quietly broken by movement in any direction.

Architecture, product, measurement

Architecture

Modular and observable. The asset we're actually building is the graph—personas, signals, opportunities, evidence, decisions, and how they connect. Every Claw, every dashboard, every UI is a surface over that graph. Swap any of them out and the asset survives. Lose the graph and we have nothing.

%% Architecture Component Diagram
flowchart TB
  A["Source connectors"] --> B["Scheduler and queue"]
  B --> C["Raw content store"]
  C --> D["Operational database"]
  D --> E["Vector index"]
  D --> F["Graph layer"]
  E --> G["OpenClaw orchestration"]
  F --> G
  G --> H["Evaluation harness"]
  G --> I["Curation app"]
  I --> J["Validation loop"]
  J --> D
  K["Observability"] --- B
  K --- G
  K --- J

The headline components: source connectors and a raw content store; an operational database holding the personas, signals, trends, opportunities, and the relationships between them; a vector index for semantic search and deduplication; OpenClaw orchestrating the Claws on top of all that; an evaluation harness measuring extraction quality and hallucination risk; the curation app where humans decide; the validation loop capturing interview notes, scorecards, and postmortems.

The pilot stack is small, hosted, and built from things easy to leave. Neon Postgres (with pgvector and a relationships table) for the operational database. Cloudflare R2 for object storage. Temporal Cloud for durable workflows and for the change-data-capture subscriber that wires database writes into the Skeptic Claw. MotherDuck for the analytical layer the Reflection Claw reads against. LiteLLM as the provider-abstracted LLM proxy that makes the "4× cost spike, route around it in a week" commitment actually enforceable. Langfuse for LLM observability on top of OpenTelemetry. SvelteKit on Vercel for the web surface. Clerk for identity. Doppler for secrets. One database for the whole pipeline—Idea Farming and Idea Validation share Neon, because phases of the work shouldn't mean phases of the infrastructure.

I'm picking hosted versions because I'm not in the infrastructure business—I'm in the better-decisions business. Every hour spent patching a Temporal worker is an hour not spent on the pipeline. The infrastructure cost on day one is a few hundred dollars a month across the whole stack; the cost of self-hosting any of it is at least a quarter spent on operations. Each named tool is either vanilla open infrastructure (Postgres, S3-compatible storage, a Temporal cluster) or a thin convenience layer in front of it—the lock-in story matters more than the dashboard convenience, and every vendor on the list above has a documented swap-in in Architecture.

Six rules keep it from drifting into a mess: Postgres as the default source of truth until proven insufficient; every AI-generated claim linked to evidence; prompts, scoring rubrics, Pattern Library bundles, and extraction schemas treated as versioned assets in git; every Claw run reviewable and reversible because state lives in Postgres (see memory model); optimize for human decision quality, not autonomous volume; design the graph so new primitives can be added without destructive migrations.

The full deep dive—every named tool with its alternatives, the LLM tier assignments, the dedupe strategy, retention policies, RBAC posture, CI/CD pipeline, the cost model, and the "what I am not building" list—lives in Architecture.

Product

The product should feel like an intelligence workbench, not a chatbot. If the user opens the app and sees a text box that says "Ask me anything," we have failed.

The primary surfaces:

Measurement

A lighthouse subtly shaped like a lobster claw shining across a dark strategic sea toward sturdy ships representing validated prototype candidates, with smaller drifting rafts representing raw ideas and weak signups

We're optimizing for better prototype candidates, not more ideas. If anyone ever puts "ideas produced per week" on a dashboard, we've wandered into the wrong meeting—politely excuse ourselves and go back to the right one.

TIP

North star

Validated prototype candidates per month—opportunity hypotheses that pass curation, have credible evidence, receive a concrete validation plan, and produce useful market or prototype learning.

Three patience metrics sit alongside throughput, to prevent the throughput metric from becoming the only metric:

Supporting metrics by category:

Evaluation combines automated tests, labeled review sets, and human judgment:

Risks

The main risks here are not technical impossibility—infrastructure is approachable, models are good enough, data is reachable. The risks are bad epistemology on the discovery side (confident nonsense from the model) and seductive signals on the validation side (data that looks like demand and is not).

Idea farming risks and their mitigations:

Validation risks and their mitigations:

A thoughtful lobster beside a beautiful but clearly unfinished early-access storefront, placing an honest prototype sign while a human reviewer checks consent language and follow-up notes

Fake-door ethics deserves its own paragraph. Pretending a product exists damages trust. Use clear labels (early access, pilot, prototype, design-partner program) and follow up even when the experiment was killed—the mitigation is not optional. If a real-estate agent fills out a survey expecting access to a tool that doesn't exist and never gets a follow-up, that agent thinks less of me. The Idea Validation ethics gate covers business-model harms; this one covers experiment-design harms.

Build sequencing

Build the pipeline by hand for one quarter before automating anything. Standardize the artifacts—memos, scorecards, decision packets, postmortems—and the cadence of every ritual. Then, and only then, build the system parts of this document, in the order the manual process screams loudest, not the order the architecture diagram says.

Build the Idea Farming Claw stack (Persona Claws, the Scout Claw, the Market Analyst Claw, and the Skeptic Claw, sitting on top of the ingestion connectors and extraction plumbing) before the Idea Validation experiment factory. The most common failure mode is building the experiment factory before proving the discovery loop produces opportunities worth validating; the second most common is skipping the manual-standardization step and jumping straight from Idea Farming to automation. Automation that codifies a vague process produces vague automation.

Initial persona set

Mixed to stress-test transfer across AI readiness levels, software maturity, workflow digitization, and willingness to pay: software engineers (high AI readiness, fast feedback loops); real estate agents (revenue-driven, lead generation pressure, fragmented tooling); lawyers (high-value document workflows, strong willingness to pay, high constraints); dentists (operational complexity, insurance pain, lower AI saturation, local-business dynamics); public school teachers (high workflow burden, lower monetization clarity, policy constraints). Software engineers are easy mode. Public school teachers are hard mode. If a pattern transfers across that range, it transfers.