Realization Strategy
What it is
A Realization Strategy (canonical name Intenture Realization Strategy / IRS) is the committed, full-depth plan for HOW a specific Intenture is realized. Introduced in In++ v2.2, it is the second named stage of the Intent -> Realization chain after Intenture, and a core peer-class alongside Intenture / Knowledge Card / Service Definition / Realization Artifact (Core Entities 23 -> 24).
> Why it exists: every domain that adopts In++ (Inspark CVD, a future game-development process, etc.) needs a "strategy for realizing the intent". Without a core class, each domain would reinvent its own IRS from scratch. v2.2 lifts the universal skeleton into the language; domains inherit one structure and fill it with domain content.
Abstract base (what the core defines)
| Part | Purpose |
|---|---|
| 'realizes' | Version-pinned link to the Intenture this strategy realizes (semantic formula 23). |
| 'compass' | The OGSM-like heart of any realization strategy: Objective (the goal restated from Intent, in outcome terms) + Strategies (differentiating choices, each with an explicit trade-off) + Goals x Measures. |
| 'sections' | Role-tagged body. Each section carries a universal role + domain content (blocks). |
| lifecycle | Draft -> Review -> Approved -> Locked. Approved = signed off at the domain realization gate. |
| 'quality_gate', 'knowledge_cards', 'fields' | Domain Quality Gate result, informing Knowledge Cards, and open domain-specific structure. |
The 8 universal section roles
'compass', 'object_analysis', 'stakeholders', 'approach', 'metrics_forecast', 'resources_value', 'risks', 'operating_plan' - plus 'domain' for domain-specific sections with no universal counterpart.
The Strategy / Operations / Hygiene discipline
A core principle of the Realization Strategy: only Strategy belongs in the compass. A candidate is a Strategy only if it passes all three tests - it is a differentiator (not what any competent executor would also do), it materially changes the outcome, and it carries a conscious trade-off (chose X over Y). Operations (how we execute) belong in the operating_plan role or downstream artifacts; Hygiene (required by law/contract/standards, no choice) belongs in operating_plan setup or risks. This keeps the strategy honest.
Clean separation of layers
The core defines structure, roles, and obligations; the domain defines content. A domain specializes via a profile (allOf) that declares a 'strategy_type' (e.g. 'inspark:IRS', 'game:IRS'), maps its concrete sections onto the core roles, and adds 'domain' sections + its own Quality Gate. Same pattern as Realization Artifact Type and Service Definition.
Reference implementation
The Inspark CVD IRS ('strategy_type: inspark:IRS') is the reference profile. Its 11 sections map onto the core roles: §0 Compass -> compass, §1 Product Analysis -> object_analysis, §2 Target Audience -> stakeholders, §5 Strategic Approach -> approach, §7 KPI & Metrics -> metrics_forecast, §8 Investment & Value Return -> resources_value, §9 Risks -> risks, §10 Operating Plan -> operating_plan; §3 Pain Tree, §4 Messages, §6 Creator Archetypes -> domain. Canonical core schema: 'schemas-core/v2.2/realization-strategy.schema.json'.