Collider

the problem

Normal prompting converges on the same "gaussian-mean" answer regardless of how the prompt is worded, because a single LLM call samples from the middle of its training distribution. Getting output that's actually different requires forcing structurally different inputs into the model — a different mechanism, not a better prompt — and then filtering the resulting flood of raw ideas down to the handful worth reading.

how it is built

• Nine parallel creative-collision mechanisms attack the same problem at once: forced structural analogy against a 60+ domain pool, TRIZ's inventive principles (drawn from patent analysis), five disagreeing "adversarial persona" thinkers, constraint inversion, a three-domain serendipity collision, and newer mechanisms modeled on attention leakage, default-mode/executive-control oscillation, and hypnagogic association.
• A separate evolutionary breeding pass scores every raw idea on multiple axes, keeps roughly the top half under diversity pressure that specifically penalizes ideas too similar to ones already kept, crossbreeds the survivors, and repeats for further generations.
• Output isn't forced into one shape: ideas are typed into six creative-move kinds (product, hypothesis, reframing, concept, practice, provocation), each with its own structure, its own scoring axes, and type-aware crossover in the breeding step.
• A per-session feedback loop (three ratings: more-like-this, average, seen-before) persists to Postgres and re-weights future runs — liked domains get a flat score boost, ideas similar to "more-like-this" picks get a further content-similarity boost, and breeding pulls preferentially from liked ideas.
• Results stream to the browser over Server-Sent Events as each mechanism finishes, rather than after the full run completes.
• The same pipeline is exposed as an MCP server over stdio, with a full-run tool, a fast single-mechanism tool for agents that need quick inspiration mid-task, a term-coining tool, and a resource listing recently coined terms — it can run against the caller's own LLM key or against a hosted instance.
• One LLM client wraps seven providers behind a shared interface (Groq, Gemini, OpenAI, Anthropic, DeepSeek, OpenRouter, AWS Bedrock) with a configurable fallback provider for production resilience.
• A retrieval layer runs case-study lookups over dozens of hand-curated TRIZ, scientific-leap and design-reframing precedents, so the mechanisms are grounded in real examples rather than pure model invention.
• Single Dockerfile, single service; the front end is Jinja2 templates with HTMX and Alpine.js, no build step, no node_modules.

the hard parts

• Diversity pressure is the part that actually matters and the easiest part to skip: without it, an evolutionary scorer converges on one locally-good idea and everything downstream reads as a variation of it. The breeder penalizes ideas that are too similar to survivors already kept, using an MMR-style diversity rerank specifically to counter the mode collapse that RLHF-tuned models default toward.
• Making the taste-learning loop actually change future output — not just log ratings for display — required feeding session feedback into two separate places at once: the scoring pass (a boost for liked domains and ideas) and the breeding crossover (survivors preferentially bred from liked ideas). Either alone only cosmetically reorders results instead of shifting what gets generated.
• A calibrated novelty critic measures each idea's distance from a vanilla, mechanism-free LLM response to the same problem, rather than scoring novelty in the abstract — because "sounds novel" and "actually different from what the model would have said anyway" aren't the same thing, and the second one is what the product is supposed to prove.