Inspark - Intenture Realization Strategy Specification v1.0

◆ Section 0 - Overview

Intenture Realization Strategy - the single most important operational document in Inspark's CVD pipeline. It is the Project Charter for every client engagement.

In++ 2.2 layering. Realization Strategy is now a core In++ 2.2 class (canonical: Intenture Realization Strategy / IRS), peer to Intenture / Knowledge Card / Service Definition / Realization Artifact. The Inspark IRS is its domain profile (strategy_type: inspark:IRS). The core defines the universal skeleton - realizes(Intenture), a structured Compass, role-tagged sections, and the Strategy / Operations / Hygiene discipline; Inspark fills it with influence-marketing content. Each IRS realizes a specific, version-pinned Client Intenture.

11 Inspark sections → 8 universal core roles

Inspark section	Core role	Inspark section	Core role
§0 Realization Compass	compass	§6 Creator Archetypes	domain
§1 Product Analysis	object_analysis	§7 KPI & Metrics	metrics_forecast
§2 Target Audience	stakeholders	§8 Investment & Value Return	resources_value
§3 Pain Tree	domain	§9 Risks & Mitigation	risks
§4 Messages	domain	§10 Operating Plan	operating_plan
§5 Strategic Approach	approach

Parameter	Description
What	Intenture Realization Strategy - full operational plan (Project Charter) for working with the Client. 100% depth.
Why	Single source of truth for all CVD participants (VP, CSL, Insparker, Willie, Hunter, Holmes). Every step of Phase 3-5 relies on IRS.
Who creates	Nick (AI) generates from Client Intenture. Value Partner validates.
When	Phase 2 (Blueprint). Updated in Phase 4 (iteration results) and Phase 5 (final update).
Relation to SP	SP = 30% depth (sells). IRS = 100% depth (executes). SP → contract → IRS.
Gate	G2 - Client approves IRS as the basis for work.

IRS in the CVD Pipeline

CI (Phase 0)

→

SP (Phase 1)

→

IRS (Phase 2)

→

Brief (Phase 3)

→

Execution (Phase 4-5)

Parameter	SP (Phase 1)	IRS (Phase 2)
Depth	30% - «what & why»	100% - «what, how & when»
Goal	Sell. Close the deal.	Plan. Project charter.
Audience	Client decision-maker (CEO, CMO)	Value Partner + project team + AI agents
Tone	Consultative, confident, with numbers	Operational, detailed, structured
Generation	Nick auto-generates from CI	Nick + Value Partner jointly
Volume	3-5 screens / 8-12 slides	15-25 pages

◆ Who Uses What

Each role focuses on specific sections. This matrix shows primary usage (✓) for quick reference.

Role	§0 Compass	§1 Product	§2 TA	§3 Pains	§4 Msgs	§5 Approach	§6 Creators	§7 KPI	§8 Invest.	§9 Risks	§10 Plan
VP	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
CSL	·	·	·	·	·	✓	✓	·	·	✓	·
Insparker	·	·	·	✓	✓	·	✓	·	·	·	·
Willie (AI)	·	·	·	✓	✓	✓	·	·	·	·	·
Hunter (AI)	·	·	✓	·	·	·	✓	·	·	·	·
Holmes (AI)	·	·	·	·	·	·	·	✓	✓	·	✓

◆ Section Readiness Model

Gate 2 Rule: If Core Definition CRT has passed, minimum 4 out of 11 sections must be Ready or Partial for the document to proceed through Gate 2.

Ready Data sufficient - Nick can generate section fully.

Partial Needs clarification from VP - Nick generates with [TBD] markers.

Not Ready Data missing - section blocked until CI data provided.

0

Realization Compass

§0 - Objective + Strategies (each with a trade-off) + Goals × Measures

The OGSM-like core of the strategy and the lead section of every IRS. Restates the Objective from the Client Intenture's Intent, names the differentiating Strategies, and quantifies Goals against Measures. This is the core In++ 2.2 structured compass.

CI → Intent CI → Conception CI → Metrics

Field	Type	Req	Description
objective	string	req	One-sentence realization objective in outcome terms (Client's language, not Inspark-internal jargon). Restated from the Intenture's Intent.
strategies	array	req	Differentiating strategic choices (S1...Sn), each containing:
.statement	string	req	The strategic choice
.trade_off	string	req	We chose X and consciously rejected Y, because...
.rationale	string	opt	Cost/benefit reasoning behind the choice
goals_measures	array	req	Quantified Goals × Measures, each containing:
.goal	string	req	Quantified goal
.measure	string	req	How the goal is measured
.cadence	string	req	weekly \| monthly \| per-gate

Strategy / Operations / Hygiene discipline. A candidate Strategy in §0 must pass all three tests: Differentiator (distinguishes us from any competent agency running the same campaign), Outcome (removing it materially changes the result), and Trade-off (a conscious choice of X over Y). Operations (how we execute) belong in §10 or downstream Briefs; Hygiene (legal, ORD/ERID, GDPR, contracts) belongs in §10 Operating Plan or §9 Risks - never in §0 Strategies.

Ready: Objective + at least one Strategy with explicit trade-off + Goals × Measures with cadence
Partial: Objective + Strategies stated, but trade-offs or measures incomplete
Not Ready: Intent not articulated in the Client Intenture

AI Guidance (Nick): Restate the Objective from the Client Intenture's Intent. Each Strategy must survive the Differentiator + Outcome + Trade-off tests - if you cannot articulate "we chose X over Y because...", it is Operations or Hygiene, not Strategy. Quantify every Goal and attach a cadence.

VP Client Nick

1

Analysing the Product

§1 - Product Analysis

Deep understanding of the Client's product - what we sell, how it differs, how it monetizes. Foundation for all downstream sections.

CI → Object CI → Context CI → Evidence KC → Product Card KC → Competitive Card

Field	Type	Req	Description
product_name	string	req	Product or brand name
product_description	string	req	What it is, for whom, what problem it solves
usp	string[]	req	Unique selling propositions (3-5 items)
competitive_landscape	object	req	Direct/indirect competitors, their CE activity
positioning	string	req	Product positioning in the market
monetization_model	string	req	How the product earns (subscription, purchase, freemium, etc)
funnel	object	req	Current funnel: stages, conversion rates
stage	string	req	Product stage: launch \| growth \| maturity

Ready: Product Card filled + Competitive Card exists
Partial: Product described, but no funnel or competitive data
Not Ready: Object = Unknown

AI Guidance (Nick): Use Product Card + internet research. If competitive data is missing, Nick researches top 5 competitors in the niche and fills competitive_landscape with available data.

VP Nick

2

Target Audience

§2 - Segments, demographics, psychographics, needs

Who buys the Client's product. Segments with demographics, psychographics, and needs. Drives creator selection and messaging.

CI → Target Audience CI → Value KC → Market Card

Field	Type	Req	Description
segments	array	req	Min 2 segments, each containing:
.name	string	req	Segment name
.demographics	object	req	Age, geo, gender, income
.psychographics	object	req	Interests, values, lifestyle, content consumption
.needs	string[]	req	Key needs
.platforms	string[]	req	Where they spend time (Instagram, YouTube, Telegram, TikTok, etc)
.consumption_patterns	string	opt	How they consume content
primary_segment	string	req	Primary segment for first integrations

Ready: 2+ segments with demographics + psychographics + needs
Partial: 1 segment only, or demographics without psychographics
Not Ready: TA not described

AI Guidance (Nick): Build from CI Target Audience block + Market Card. If psychographics missing, Nick infers from product type and market data. Always populate platforms[] for Hunter.

VP Insparker Hunter Willie

3

Pain Tree

§3 - Structured pain map for the target audience

Structured map of TA pains. Foundation for scenarios and key messages. Drives Willie's script generation.

CI → Conception → Pain Tree CI → Value

Field	Type	Req	Description
pains	array	req	Min 3 pains, each containing:
.pain	string	req	Pain statement
.segment	string	req	Which segment this pain belongs to
.emotions	string[]	req	Emotions the pain triggers (fear, frustration, shame, etc)
.micro_pains	string[]	req	Specific manifestations (situations, triggers)
.intensity	string	req	high \| medium \| low
pain_priority	string[]	req	Priority order of pains for first integrations

Ready: 3+ pains with emotions + micro-pains per segment
Partial: Pains listed but no structure (no emotions, no micro-pains)
Not Ready: Pains not identified

AI Guidance (Nick): Structure from CI. If only high-level pains provided, Nick decomposes into emotions + micro-pains using product knowledge. Each pain must map to at least one segment from §2.

Willie Insparker VP

4

Key Messages

§4 - What the creator says on camera. Pain → Message → CTA.

What the creator says on camera. The chain: pain → message → CTA. Drives all content creation.

CI → Pain Tree CI → Intent CI → Object

Field	Type	Req	Description
messages	array	req	One per pain, each containing:
.pain_ref	string	req	Reference to pain from §3
.key_message	string	req	Key message (1-2 sentences)
.tone	string	opt	Tone: friendly \| expert \| emotional \| funny
.cta	string	req	Call to action
.proof_points	string[]	opt	Evidence / social proof
.forbidden_claims	string[]	opt	What must not be said (compliance)
message_hierarchy	string	opt	Which message is primary, which are supporting

Ready: Pain Tree Ready + Conception contains Content Approach
Partial: Pain Tree exists, but no Conception
Not Ready: Neither pains nor content approach available

AI Guidance (Nick): Generate messages from Pain Tree. Each pain → one message. Willie uses these messages as the basis for scenario scripts. Ensure forbidden_claims are populated from §9 Constraints.

Willie Insparker VP

5

Strategic Approach

§5 - Model, channels, format portfolio and Services mix (core role: approach)

The how: monetization model, channel and format portfolio, and the Services mix that operationalize the §0 Strategies. Platform selection drives creator search and investment allocation.

CI → Conception → Channel Strategy CI → Conception → Content Formats CI → Constraints → Geo

Field	Type	Req	Description
platforms	array	req	Platforms, each containing:
.name	string	req	Instagram, YouTube, Telegram, TikTok, VK, etc
.priority	string	req	primary \| secondary
.justification	string	req	Why this platform (TA match, format fit, benchmarks)
formats	array	req	Integration formats, each containing:
.type	string	req	Reels, Stories, YouTube Integration, Review, UGC, Live, etc
.description	string	req	How the integration looks
.avg_duration	string	opt	Average duration
.benchmark_cpm	number	opt	Estimated CPM benchmark
content_approach	string	req	Overall approach: native ads, reviews, storytelling, etc

Ready: Platforms + integration types + justification defined
Partial: Platforms stated, but types not defined
Not Ready: Channel Strategy = Unknown

AI Guidance (Nick): Select channels based on TA platforms (§2) + product type (§1). Pull benchmarks from Market Card. If no Market Card, use Inspark internal benchmarks.

CSL Insparker Willie

6

Creator Archetypes

§6 - What creators are needed. Profiles for Hunter and Insparker.

What creators are needed. Archetype profiles serve as search parameters for Hunter and briefing context for Insparker.

CI → Conception → Creator Archetypes CI → TA → Audience Overlap

Field	Type	Req	Description
archetypes	array	req	Creator archetypes, each containing:
.name	string	req	Archetype name (e.g. "Beauty-expert 25-35", "Lifestyle mom")
.niche	string[]	req	Niches: beauty, tech, food, parenting, etc
.audience_size	string	req	Range: micro 10K-50K \| mid 50K-300K \| macro 300K+
.audience_match	string	req	How creator's audience overlaps with client's TA
.content_style	string	req	Style: professional \| casual \| funny \| educational
.geography	string[]	req	Audience geography
.price_range	string	opt	Expected cost range
.quantity	number	req	How many creators of this archetype needed
selection_criteria	object	req	Selection criteria:
.min_er	number	req	Minimum Engagement Rate
.audience_quality	string	req	Audience quality requirements (no fakes)
.brand_safety	string[]	opt	Unacceptable content (alcohol, politics, etc)

Ready: TA Ready + channels defined → Nick proposes archetypes
Partial: TA exists, channels not defined
Not Ready: TA Not Ready

AI Guidance (Nick): Create archetypes matching TA segments (§2) + platforms (§5). Hunter uses archetypes as search parameters. Each archetype must have audience_match justification.

Hunter Insparker CSL

7

KPI & Metrics

§7 - What we measure and what we aim for. Basis for reporting and Gate 4.

What we measure and what we aim for. Foundation for reporting, Holmes monitoring, and Gate 4 evaluation.

CI → Expected Output CI → Metrics KC → Market Card (benchmarks)

Field	Type	Req	Description
mode	string	req	"target" (exact KPIs) or "pilot_discovery" (test period)
primary_kpi	object	req	Primary KPI:
.metric	string	req	Revenue \| Leads \| Installs \| Reach \| Brand Lift \| etc
.target_value	number\|"pilot"	req	Target value or "pilot" (to be determined after pilot)
.measurement_method	string	req	How measured: UTM, promo code, pixel, survey, etc
secondary_kpis	array	opt	Additional metrics (metric, target, measurement_method each)
benchmarks	object	opt	Market benchmarks:
.industry_avg	object	opt	Industry average metrics
.inspark_avg	object	opt	Inspark average for similar clients
funnel	object	opt	Expected funnel:
.steps	array	opt	Funnel stages (Reach → Clicks → Leads → Sales)
.conversion_rates	object	opt	Projected conversion rates per step
reporting_frequency	string	req	weekly \| biweekly \| monthly

Ready: Primary KPI + target values + measurement method defined
Partial: KPI defined, targets are hypothesis
Not Ready: Expected Output = Unknown

AI Guidance (Nick): Set KPIs from CI Expected Output. If mode = pilot_discovery, Nick proposes test framework: 3-5 integrations, 2-4 weeks, with clear success criteria. Holmes uses these KPIs for real-time monitoring.

VP Holmes Lori

8

Investment & Value Return

§8 - Per-Service investment and expected Value Return (core role: resources_value)

What the Client invests and the value it returns. Per-Service investment against expected Value Return - never an internal cost breakdown (no creator payouts, Inspark fees or production overhead as line items).

CI → Constraints → Budget CI → Metrics → Unit Economics CI → Expected Output → Monetization

Field	Type	Req	Description
total_budget	number	req	Total budget for the period
period	string	req	Period: 1 month \| 3 months \| etc
payment_model	string	req	fee \| success \| hybrid \| retainer
budget_allocation	object	req	Allocation breakdown:
.creator_payouts	number	req	% allocated to creator payments
.production	number	opt	% allocated to production (if applicable)
.inspark_fee	number	req	Inspark commission %
unit_economics	object	opt	Unit metrics:
.cpi / .cpl / .cpm	number	opt	Projected unit metrics
.roas	number	opt	Projected ROAS
.ltv_cac	number	opt	LTV/CAC ratio if applicable
scenarios	array	opt	Scenarios (optimistic / base / pessimistic), each with: scenario, budget, expected_kpi, roas

Ready: Budget + payment model + timeline defined
Partial: Budget exists, payment model not defined
Not Ready: Budget = Unknown

AI Guidance (Nick): Build UE model from CI Metrics. Reference JTBD-002 (service financial models) when available. Always provide at least base + pessimistic scenarios for VP approval.

VP Lori Holmes

9

Risks & Mitigation

§9 - Risk Heat Map + risks table with a Trigger per risk (core role: risks)

What could go wrong and how we respond. A Risk Heat Map plus a table where every risk carries a measurable Trigger and a Mitigation. Risks cover four categories: Brand, Market, Execution, Regulatory.

CI → Risks CI → Constraints (quality/legal/scope) CI → Evidence

Field	Type	Req	Description
heat_map	object	req	Likelihood × Impact grid positioning each risk
risks	array	req	Risks, each containing:
.category	string	req	Brand \| Market \| Execution \| Regulatory
.risk	string	req	Risk statement
.likelihood	string	req	high \| medium \| low
.impact	string	req	high \| medium \| low
.trigger	string	req	Specific measurable signal that activates the Mitigation. No naked risks.
.mitigation	string	req	Response when the Trigger fires

Hygiene factors (advertising law, ORD/ERID labeling, GDPR, contracts, brand-book and stop-words, Client approval process and exclusivity) are not Strategies and not free-standing constraints: regulatory exposure lives here as a Regulatory-category risk, and the operational setup lives in §10 Operating Plan (Phase 1 Setup). The canonical stop-words block lives in §4 Messages.

Ready: Heat Map populated; all four categories covered; every risk has a Trigger + Mitigation
Partial: Risks listed, but Triggers missing or categories incomplete
Not Ready: Risks not identified

AI Guidance (Nick): Harvey validates regulatory exposure. Every risk needs a measurable Trigger - if you cannot state the signal that activates the Mitigation, it is not ready. If industry = pharma or finance → Harvey deep compliance check is mandatory before Gate 2.

VP CSL Holmes Harvey

10

Operating Plan

§10 - Phased timeline, reporting cadence, Decision Gates, escalation, setup (core role: operating_plan)

How the work runs: phased timeline and milestones, reporting cadence, Decision Gates and escalation path. This is also where Operations and Hygiene live - the Phase 1 Setup covers compliance, ORD/ERID, contracts and the Client approval process.

CI → Constraints → Timeline CI → Expected Output → Deliverables CI → Conception → Channel Strategy

Field	Type	Req	Description
timeline	object	req	Timeline:
.start_date	date	req	Start date
.end_date	date	req	End date
.milestones	array	req	Key milestones
volumes	object	req	Volumes:
.total_integrations	number	req	Total number of integrations
.per_week	number	req	Integrations per week
.per_creator_type	object	opt	Distribution by archetypes from §6
phases	array	opt	Execution phases, each with: phase_name, start, end, deliverables
pilot	object	cond	If mode = pilot_discovery (§7):
.duration	string	cond	Pilot duration (2-4 weeks)
.test_integrations	number	cond	Number of test integrations (3-5)
.success_criteria	string	cond	Criteria for pilot success

Ready: Timeline + budget + scope defined
Partial: Timeline exists, volumes not defined
Not Ready: No timeline, no scope

AI Guidance (Nick): Create timeline from: budget (§8) / avg creator cost → number of integrations → weekly distribution. If mode = pilot_discovery → plan 2-4 week pilot first, then scale phase.

VP CSL Mr. Wolf

◆ Versioning

IRS is a living document. It evolves through the project lifecycle, gaining depth and precision at each phase.

v0.1

IRS Preview - 30% depth, Phase 1. Used in SP as a teaser of the operational plan.

v1.0

Full IRS - 100% depth, Phase 2. Approved at Gate 2 as the project charter.

v1.x

Iteration Updates - Updated during Phase 4 based on execution results and Holmes insights.

v2.0

Final Update - Phase 5 (Value Capture). Reflects actual results and learnings.

v3.0

New Cycle - New contract cycle. Fresh IRS based on previous cycle learnings.