# Edison Experimentation Prover MCP > The Edison Experimentation Prover forces rigorous validation on any major project idea. It doesn't just tell you if something 'works'; it audits your entire development process, checking for alternatives that were ignored, failures that went undocumented, or viability metrics that are missing. If you build a complex system without systematically proving every step, this MCP flags the gaps. ## Overview - **Category:** complex-reasoning - **Price:** Free - **Tags:** systematic-experimentation, rapid-prototyping, iteration, product-viability, thomas-edison, failure-documentation, ecosystem-design ## Description Stop building features based on gut feeling or what 'best practice' says. This connector forces deep technical rigor into your product development cycle. It makes sure you prove why one solution beat out three others, that you planned for failure modes, and that your initial prototype can actually run at scale in the real world. When you use this MCP, it guides your agent through five mandatory checkpoints: systematically testing alternatives, measuring diminishing returns on improvements, building a full operational ecosystem, proving commercial viability with hard data, and—critically—documenting every dead end so you don't repeat mistakes later. It’s the anti-premature deployment tool. If you can't show evidence that you tested other options or that your system handles failover under stress, this MCP will catch it. You access this kind of deep process validation through the entire Vinkius catalog, making sure no critical step gets overlooked. ## Tools ### validate_edison_experimentation Checks if a solution underwent systematic experimentation by verifying alternatives tested, failures documented, viability proven, prototypes built, and iterations measured. ## Prompt Examples **Prompt:** ``` We should use the traditional filing system for our records management. It is the standard solution and best practice says physical archives are the go-to for most organizations. ``` **Response:** ``` EXPERIMENT_ABSENT — 'The standard solution,' 'best practice says,' 'the go-to solution' — three references to convention, zero experiments. Edison tested 3,000+ filament materials. How many records management alternatives did YOU test? Did you prototype a digital archive (built for rapid retrieval natively)? A hybrid approach (physical originals with digital index)? A cloud-based document system (search-driven, unlimited capacity)? What was your retrieval speed on each? Processing capacity for daily intake? Cost at 14,000 submissions per day? The traditional system may be the right choice — but you have not proven it. You have assumed it. ``` **Prompt:** ``` Tested 3 records management approaches for 14K submissions/day. (A) Traditional filing: 4,200 retrievals/day max, 380 min avg at saturation — 47h backlog. (B) Digital archive: 18K/day, 12s retrieval, native search. (C) Cloud platform: 22K/day, 8s retrieval, but 3 external dependencies. Selected digital archive — best throughput-to-complexity ratio. Iteration: V1 default 28s → V2 batch categorization 18s (↓28%) → V3 automated routing 12s (↓33%) → V4 larger batch 11s (↓8%, diminishing). Shipped V3. System: 3 regional nodes with mirrors. SOPs, monitoring dashboard, quarterly recovery plan, 47K-record transition plan (6 days), staff training guide. Viability: 72h stress test at 14K/day, zero lost. Failover: mirror promoted in 4.2h. Cost: $1,240/month. p95 retrieval: 120s (target <500s). Dead ends: (1) traditional filing bottlenecked at 4.2K/day — manual limit. (2) Cloud platform had great throughput but 3 dependencies added 2 failure modes. ``` **Response:** ``` EXPERIMENT_PROVEN — Edison Method complete. Experiment: 3 alternatives tested (traditional filing, digital archive, cloud platform) with measured criteria (throughput, retrieval time, operational complexity). Selection justified: digital archive at 18K/day capacity with native semantics. Iteration: 4 variations tested (default → batch categorization → automated routing → larger batch), diminishing returns at V4 (8%), shipped V3 at 12-second average. System complete: regional provisioning (procedures), monitoring (dashboard), disaster recovery (plan, quarterly tested), transition (47K records, 6 days), training guides (staff onboarding). Viability: 72h sustained stress test, failover in 4.2 hours, $1,240/month operating cost, 2 departments integrated, retrieval lag 120s (below 500s target). Failures documented: traditional filing bottleneck at 4.2K/day (learning: not designed for high-throughput intake), cloud platform operational complexity (learning: operational simplicity is a criterion). This is systematic invention. ``` **Prompt:** ``` Experiment: Tested digital archive vs traditional filing. Digital archive won. Iteration: it works, good enough. System: we just need the core archive — rollout and monitoring are out of scope. The design is operationally correct and should work in production. ``` **Response:** ``` ITERATION_INSUFFICIENT — Experiment passes: 2 alternatives tested, digital archive selected. But iteration fails: 'it works, good enough' is premature satisfaction. Edison ran 10,000+ battery experiments. What is your default configuration? What happens when you tune batch processing? Categorization depth? Routing strategy? How much improvement does each yield? Additionally: 'out of scope' means the system is incomplete — Edison built the grid, not just the bulb. And 'should work' is not viability — where is your stress test? Your failover test? Your cost projection? ``` ## Capabilities ### Test alternatives systematically Compares your chosen solution against multiple genuinely different approaches, measuring criteria for each one. ### Document failures as learning Requires documenting what went wrong with failed attempts and identifying the root cause to inform future decisions. ### Prove viability with metrics Checks if a solution is commercially viable by requiring quantified evidence of operation cost, adoption friction, and success criteria. ### Build the full system ecosystem Ensures that the solution includes rollout plans, monitoring dashboards, and transition guides, not just the core module. ### Measure iteration cycles Tracks improvements across versions to prevent stopping development at 'good enough' when diminishing returns are still possible. ## Use Cases ### The Legacy System Upgrade An engineering team proposes migrating 14,000 records/day to a new database. They only tested the migration process once (V1). The Prover flags this as insufficient iteration, forcing them to model batch processing and automated routing improvements before committing to deployment. ### New Product Line Launch A PM proposes a new smart device. They forget the power source or user onboarding process. The MCP immediately flags 'SYSTEM_INCOMPLETE,' forcing them to build out the entire supporting ecosystem, including training guides and regional node plans. ### Complex Workflow Design A department needs a new filing system. They only test their current digital archive against an old physical one. The Prover forces them to prototype a hybrid solution first (10% scale) and prove its viability under simulated peak load. ### Feature Replacement A team wants to replace an existing feature that 'just works.' The MCP demands they list three alternatives, comparing their actual retrieval speeds and maintenance costs before they can claim a winner. ## Benefits - It prevents 'Assumption Bias.' You don't just assume the traditional way works; this MCP forces you to test it against three genuinely different alternatives and report which one won, and why. - You stop building incomplete systems. The tool checks if you thought about the whole grid—not just the light bulb. It demands full documentation of rollout plans and monitoring setup. - It makes failure useful. Instead of saying 'we tried some things,' it forces you to document *why* those attempts failed, making every dead end a measurable learning point for the next phase. - Your code is more resilient because it’s tested under stress. The Prover requires proof of viability with quantified evidence, like failover times and actual operating costs. - You avoid premature deployment. It makes sure you measure improvements across multiple cycles, stopping 'good enough' from becoming a permanent failure point. ## How It Works The bottom line is, it turns vague ideas into verifiable, engineered plans by demanding proof at every stage. 1. First, feed the MCP your entire proposed solution—the initial design, the current metrics, and any alternatives considered. 2. The connector runs a multi-stage audit, systematically challenging assumptions about scope, scale, cost, and failure points. It forces you to prove how you tested alternatives and documented failures. 3. It returns a structured verdict: either 'EXPERIMENT_PROVEN' (meaning all rigorous criteria were met) or a detailed report pinpointing the exact experimental gap that needs addressing. ## Frequently Asked Questions **Doesn't requiring experiments slow down decision-making?** A 2-day pilot testing 3 alternatives is faster than an 8-month correction after choosing wrong. Edison's Menlo Park produced a major invention every 10 days — systematic experimentation is FASTER than guessing, because you avoid expensive dead ends. The team that picked the traditional system without testing spent 6 weeks migrating. A 3-day comparison pilot would have cost 1/30th of the migration. **What counts as sufficient iteration?** Test variations until you hit diminishing returns. At minimum 3 variations beyond the first working version. Measure the delta between each: V1 → V2 improved throughput 40%. V2 → V3 improved 12%. V3 → V4 improved 2%. Diminishing returns at V3 — ship V3. Edison tested 10,000 battery experiments but he was measuring progress. If V2 shows < 3% improvement over V1 for a non-critical metric, iteration on THAT axis is done. Move to the next constraint. **How does it differ from the Watt Efficiency Prover?** Watt validates OPTIMIZATION of existing systems — measuring waste, isolating bottlenecks, quantifying improvement. Edison validates DECISION-MAKING for new choices — testing alternatives, iterating designs, building ecosystems, proving viability. Watt asks 'where is 80% of your resources being wasted?' Edison asks 'how many alternatives did you test before choosing this one?' Use Watt when tuning a running operation. Use Edison when making a strategic choice or building a new capability. **How does using `validate_edison_experimentation` handle data sources that aren't digitized?** The tool analyzes the structured narrative you provide, not the raw files themselves. You must translate your physical or analog findings into measured criteria and documented alternatives for the MCP to process. The focus is on proving the systematic rigor of the method. **What happens if I try to run `validate_edison_experimentation` with insufficient data? ** It will trigger a specific failure pivot, highlighting exactly what's missing. For instance, if you only describe 'the best solution,' the tool flags EXPERIMENT_ABSENT because you didn't compare it against other alternatives. **Are there any performance or rate limits when running `validate_edison_experimentation`?** The usage adheres to standard Vinkius platform API rates. For high-volume, enterprise-level validation, consult the Vinkius documentation for dedicated throughput options and capacity planning. **How do I ensure my inputs are structured enough for `validate_edison_experimentation`?** You need to structure your input around measurable outcomes. Instead of general statements, include specific metrics: cost projections, throughput numbers, and clear definitions of failure causes. This allows the tool to identify genuine viability. **Does `validate_edison_experimentation` require any special setup or permissions?** No special setup is required; you just call the function through your AI client. The MCP analyzes the logic and narrative structure of your prompt to determine if the necessary experimental pivots were covered.