RCP-000-000-011-HISTORICAL-INNOVATION-TRACKER

{
“recipe_id”: “RCP-000-000-011-HISTORICAL-INNOVATION-TRACKER”,
“recipe_name”: “Historical Innovation Tracker”,
“version”: “2.00b”,
“schema_version”: “1.1”,
“schema_profile”: “standalone-recipe”,
“authored_by”: “Cat (P067)”,
“source_of_truth”: “project/subprojects/SP10-recipe-build-out/phase3/recipe-11/RCP-011-EXTENDED-AI-INFO.txt”,
“audience_scope”: “AI EXECUTION GUIDANCE (NOT FOR HUMAN USERS)”,
“ai_to_ai_communication”: {
“ai_execution_guidance”: {
“type”: “prose”,
“body”: “You are executing the most complex recipe in the Historical Context series. It combines the hallucination risks of historical analysis (RCP-009, RCP-010) with an additional layer of interpretive framing — you are not just reporting what happened, you are identifying patterns in what happened. This means every failure mode from simpler historical recipes applies here, plus a new one: imposing false structure on genuinely messy history. Your primary enemies on this recipe are fabricated specifics, false precision on cycle boundaries, asymmetric era depth disguised as even coverage, and pattern imposition masquerading as pattern discovery.”
},
“cycle_boundaries_highest_risk”: {
“type”: “prose”,
“body”: “When the recipe asks you to identify distinct innovation cycles with start and end dates, you are being asked to do something fundamentally interpretive. There is no objective fact about when Cycle 2 of the software industry began. Different analysts, historians, and industry participants would draw the lines differently. Your job is not to pretend these boundaries are objective. Your job is to propose boundaries, justify them, and acknowledge alternatives. For every cycle you identify, answer: What specific event or measurable shift marks the start? What marks the end? Is this a widely recognized periodization, or your own analytical framing? Would a reasonable industry analyst draw the line in a different place? If the history does not resolve into clean cycles, say that. Common mistakes to avoid: picking round-number years as boundaries because they look clean, using product launch dates when the actual market shift happened years later, creating cycles of suspiciously equal length, forcing exactly 3 or 4 cycles because the template seems to expect it, presenting your cycle framework as the standard industry view when it is your own construction.”
},
“three_tier_confidence_system”: {
“type”: “prose”,
“body”: “This recipe uses DOCUMENTED, ANALYTICAL, and SPECULATIVE rather than the simpler VERIFIED, LIKELY, UNCERTAIN system from RCP-010. DOCUMENTED means you are stating a verifiable fact: a company was founded, a product launched, a regulation passed, a merger closed. ANALYTICAL means you are identifying a pattern, characterizing a period, proposing a causal relationship, or grouping events into a framework. Most of your cycle analysis, pattern synthesis, and structural observations will be ANALYTICAL. SPECULATIVE means you are making an inference that goes beyond the evidence. Apply these per-claim, not per-section. The user needs this granularity to know which parts of your analysis they can cite in a strategy document versus which parts require their own validation.”
},
“analysis_depth_parameter”: {
“type”: “prose”,
“body”: “FOCUSED MODE: Analyze only the dimensions listed in priority_dimensions at full depth. For the remaining dimensions, provide a 2-3 sentence acknowledgment that the dimension exists and is relevant, but explain it falls outside the focused scope. COMPREHENSIVE MODE: Analyze all four dimensions at full depth. The priority_dimensions still matter — give them additional attention, richer examples, and more detailed pattern analysis than the non-priority dimensions. During parameter confirmation (R2), preview what the user will get.”
},
“pattern_synthesis”: {
“type”: “prose”,
“body”: “The dimensional analyses (Sections 1-4) are research. The Pattern Synthesis is where you do actual strategic thinking. This section should contain insights that only emerge from looking across all the dimensions together: Did resource allocation shifts precede or follow innovation breakthroughs? Did regulatory changes enable or respond to market structure shifts? Were successful innovators concentrated in specific market structures? Did external economic conditions correlate with cycle transitions? If your Pattern Synthesis could have been written without the dimensional analyses, it is restating rather than synthesizing.”
},
“failure_patterns”: {
“type”: “prose”,
“body”: “Innovation history has severe survivorship bias. Your training data contains far more about companies that succeeded than companies that failed. Do not compensate by fabricating detailed failure narratives. Instead: name specific companies that failed with whatever detail you actually have, flag when your failure data is thinner than your success data, explain the likely cause of the gap (survivorship bias, limited documentation, smaller companies leaving less public record), provide what you can and mark its confidence level.”
},
“era_depth_asymmetry”: {
“type”: “prose”,
“body”: “This recipe deals with asymmetry across time within a single industry. Your training data almost certainly has more detail about recent decades than older ones. If the user asks for 1980 to 2020, your analysis of the 2010s will likely be significantly richer than your analysis of the 1980s. Flag this. Do not compensate by padding older eras with generic observations, reducing recent eras to match older era depth, or pretending your coverage is even when it is not. Be transparent about data density differences.”
},
“validation_summary”: {
“type”: “prose”,
“body”: “The VALIDATION SUMMARY is not a formality. Use it to genuinely audit your own output: count your cycle boundaries and verify every one is justified, count your confidence tags and check the distribution (if 90% are DOCUMENTED you are probably under-tagging interpretive content), check your depth compliance against the requested mode, and list your knowledge gaps honestly.”
}
},
“lessons_learned”: []
}

Show/Hide accordion — “Extended Information for the AI” section (AI-to-AI execution guidance, failure modes, tone calibration, common mistakes)