Financial / Value Report

Revenue Engineering — Model Reference & Portfolio Analysis
$5,000 Monthly Revenue Allocated
300 VP Velocity Points
136 Activities Completed
1 Unprotected
1 Unattributed

Allocation Model

Every activity in the portfolio receives two scores: a dollar allocation (from Stripe-verified revenue) and a Velocity Points score (universal, revenue-independent). Both use the same weighted formula — only the base differs.

Dollar Allocation activity_$ = (client_monthly_revenue × activity_weight) / total_client_weight

Velocity Points activity_VP = (100 × activity_weight) / total_client_weight

Activity Weight weight = activity_multiplier × state_factor

Activity Multipliers

Each activity type earns a different multiplier reflecting its value contribution.

Activity TypeMultiplierRationale
Feature3.0xDirect product value — merged PRs delivering new capability
Bugfix2.0xRetention and stability — fixing client-facing issues
CSA Converted2.0xStructured specification that flowed into implementation
CSA Unconverted0.5xSpecification produced but not yet implemented downstream
Chore1.0xInfrastructure maintenance — keeps the pipeline running
Issue Opened0.25xIntent signal only — value not yet realized
Demand Gen1.5xFuture pipeline building — partially speculative

Activity States

State determines what fraction of the multiplied weight counts toward allocation. Stalled and blocked activities additionally impose VP penalties.

Completed
$ = 1.0x
VP = full
Active
$ = 0.5x
VP = full
Stalled
$ = 0
VP = −0.5x
Blocked
$ = 0
VP = −1.0x

Allocation Flow

Loading diagram...
How Stripe revenue flows through the allocation model to per-activity $ values

Revenue Flow — HHE Case Study

HHE is the only active subscription client ($5,000/month). Here's how the model distributes that revenue across 24 activities — 22 features and 2 CSA converted specs.

$5,000 Monthly Revenue
Stripe subscription, active
22 Feature PRs Merged
3.0x multiplier each
2 CSA Specs Converted
2.0x multiplier each
$227 Per Feature
$5,000 × 3.0 / 70 total weight
Loading diagram...
Revenue distribution from Stripe through activity types to allocated value
HHE Weight Breakdown 22 features × 3.0 = 66.0 weight 2 CSA converted × 2.0 = 4.0 weight Total weight = 70.0

Per feature: $5,000 × 3.0 / 70.0 = $214.29 Per CSA spec: $5,000 × 2.0 / 70.0 = $142.86

Portfolio Allocation

HHE $5,000/mo • 99 VP • 24 acts
Protected
JuxtMedia $1,200 total • 100 VP • 11 acts
Protected
SecondAct $0 Stripe • 101 VP • 104 acts
Unattributed
AAS $2,400 total • 0 VP • 0 acts
Unprotected
ClientValue TypeStripe MonthlyStripe Total$ Delivered (30d)VP (30d)ActivitiesStatus
HHEsubscription $5,000$15,000$5,000 9924Protected
JuxtMediapayment $1,200 10011Protected
SecondActrevenue_share 101104Unattributed
AASpayment $2,400 00Unprotected
Dormant Clients (8 clients, no recent activity)
ClientValue TypeStripe TotalStatus
Mojopayment$2,700Dormant
SacredSheddingpayment$900Dormant
Kaleido LifeequityDormant
beMatrixpaymentDormant
BourneLawpaymentDormant
CEO AlliancepaymentDormant
VIP RemotepaymentDormant
Immigration DashboardinternalDormant

Risk Signals

The model detects two classes of risk by cross-referencing Stripe revenue against delivery velocity.

Revenue Unprotected — AAS

$2,400 total Stripe revenue with 0 VP in last 30 days

Client has paid but receives no visible delivery velocity. If active engagement: delivery pipeline needs attention. If relationship concluded: revenue is historical, not at risk.

Velocity Unattributed — SecondAct

101 VP with $0 Stripe revenue (revenue_share model)

Highest activity volume in the portfolio but no Stripe-verified revenue. Revenue share model means $ arrives post-launch (book launch May 2026). Current velocity is investment, not burn.

Detection Logic

Loading diagram...
How the model classifies each client into protected, unprotected, unattributed, or dormant

Velocity Point Distribution

VP normalizes delivery velocity across clients regardless of revenue. 100 VP base per client, distributed by weighted activity contribution.

Loading diagram...
VP share across active clients — near-equal distribution indicates balanced delivery

Revenue × Velocity Positioning

Loading diagram...
Client positioning reveals protected (high-high), unprotected (high $, low VP), and unattributed (low $, high VP) clusters

Top Activities

By Revenue Attribution

#ClientActivityType$ Allocated
1HHERefactor 5-tier to 3-tier access modelfeature$227
2HHEAdmin ingestion pipeline for Knowledge Storefeature$227
3HHESignature chat open animationfeature$227
4HHESite-wide Kajabi embed with tier gatingfeature$227
5HHECSA: hhe-tier-refactorcsa converted$143

By Velocity Points

#ClientActivityTypeVP
1JuxtMediaEmail Tone Refinement — 3 presets + opportunityfeature19
2JuxtMediaDeal Stage Pipeline — 5 stages + cadencefeature19
3JuxtMediaGmail Integration + Morning Summaryfeature19
4JuxtMediaGmail OAuth Connect Flow + Settings Pagefeature19
5JuxtMediaCSA: juxtmedia-agent-phase3csa converted13

Calibration Notes

Current thresholds and tuning parameters. Adjust these to change signal sensitivity.

ParameterCurrent ValueEffect
Unprotected thresholdVP < 20 (30d)Stripe client flagged if VP drops below 20 in rolling 30-day window
Unattributed thresholdVP > 50 (30d)Non-Stripe client flagged if VP exceeds 50 in rolling 30-day window
Stalled cutoff> 14 daysIssues with no activity for 14+ days classified as stalled
VP base per client100 VP/monthNormalizes velocity across clients regardless of revenue
Dormant exclusionstatus: dormantDormant clients excluded from unprotected signal (historical revenue only)

Three Value Currencies

CurrencySymbolSourceUsage
Dollar$Stripe-verified onlyReal revenue attribution — never estimated
Velocity PointsVPActivity multiplier modelUniversal delivery velocity — all clients, regardless of revenue
Projected$~estimated_monthly_value frontmatterPlanning only — explicitly marked, never mixed with real $