Kindo
Program-Level Artifact
Classification Rubric (Appendix) →
Internal · Layer 1 · August 3, 2026

Revenue Architecture.

Where value is captured, through what mechanism, at what magnitude, and who owns the decision. Three Deloitte-facing revenue mechanisms for the Swimlane replacement and SOC for AI engagement.

The Position
With displaced spend and consumption expansion on the table, the revenue position does not depend on winning a classification argument with Deloitte about whether Turbo Mode is roadmap or net new. That argument is worth less than either of the first two mechanisms alone.
Replacing Swimlane — a product Deloitte pays real money for today, under contract through February 2027 — generates revenue through three mechanisms: the spend Deloitte currently allocates to Swimlane being reallocated; the volume expansion from Kindo moving upstream to the point of entry; and co-development revenue from SOC for AI. Classification of individual capabilities (roadmap vs. net new dev) is an input to how these mechanisms are structured, not the commercial outcome itself. The classification rubric is the technical appendix.
Three Mechanisms
1
Displaced Spend
Deloitte pays for Swimlane today. That spend ends February 2027. Where does it go? Some remains as Deloitte savings; some should land with Kindo. This is the commercial anchor of the entire Swimlane conversation.
Mechanism
Kindo captures a portion of Deloitte's current Swimlane expenditure. The value proposition: Deloitte replaces a legacy SOAR platform with a platform that also provides agentic capabilities (triage agent already in production), at equal or lower total cost, while eliminating the integration seam between Swimlane and Kindo.
Magnitude
GAP — NOT DOCUMENTED
Swimlane contract value (annual license + support) is not documented in available materials. Deloitte's internal cost of running Swimlane — including Harshal and Archith's continuous playbook maintenance load (recorded in the July 27 Discovery session as a constant engineering commitment) — is also undocumented. Both figures are required to size this mechanism. Without them, the commercial anchor has no number attached.
How Charged
Increased Kindo platform fee or utilization fee that absorbs a negotiated share of the displaced Swimlane spend. Deloitte should pay less than Swimlane cost (they retain savings) and more than current Kindo fees (Kindo captures value). The exact split is a negotiation — the available figure determines the range.
Decision Owner
Tony (Kindo-side positioning) + Deloitte procurement (contract terms). Kush/Krishna own the internal business case for Deloitte.
What Must Be True
  • Turbo Mode (or equivalent deterministic layer) must be production-ready before the December go/no-go — D1 unresolved
  • Enablement tooling must exist for Deloitte to migrate independently — migration tooling and visual workflow builder are on the critical path
  • Kindo must be able to handle the alert volume currently flowing through Swimlane — volume figures undocumented
  • The Swimlane contract value must be retrieved to set a negotiation range
2
Consumption Expansion
Kindo is currently downstream of Swimlane, invoked as the triage agent after Swimlane has performed intake, normalization, deduplication, and correlation. Turbo Mode moves Kindo upstream to the point of entry, with 100% of client alert volume flowing through it. That is a change of position in the chain, with volume attached.
Mechanism
The deterministic layer reduces token spend per alert — this is precisely Zun's stated concern (July 27): "we do not want everything to be token-based; some very easy things, if API can do it, why do we need to burn tokens?" Unit price falls. But volume rises substantially because Kindo now processes 100% of alerts, not just the subset that Swimlane forwards to the triage agent. The net effect — lower unit cost × higher volume — may be the most commercially valuable element of the entire replacement. Nothing in the material to date has treated it as such.
Magnitude
GAP — VOLUME FIGURES NOT DOCUMENTED
Alert volume, concurrent execution count, and peak load were not provided in the July 27 Discovery session (Zun said the load "can be very very high"). These figures are required to model the net consumption effect. Without them: if the deterministic layer reduces per-alert token cost by X% and total alert volume is Y× what Kindo currently processes, the net consumption change is calculable — but X and Y are both unknown.

GAP — CURRENT KINDO CONSUMPTION BASELINE NOT DOCUMENTED
What Deloitte currently pays Kindo in consumption/utilization fees for the triage agent is also required to calculate the delta.
How Charged
Consumption-based pricing (tokens, agent runs, or alert volume). The deterministic layer should be priced differently from the agentic layer — deterministic processing is cheaper to run and should be priced to encourage migration from Swimlane, not penalize volume. A blended rate or tiered model may apply.
Decision Owner
Tony (pricing structure) + Charlie (capacity/cost modeling) + Kush/Krishna (volume commitment).
What Must Be True
  • Turbo Mode must handle Deloitte's alert volume at scale — 80% of their clients currently route through Swimlane
  • The per-alert cost in deterministic mode must be materially lower than current agentic processing — otherwise volume expansion is a cost center, not revenue
  • Alert volume, peak load, and current consumption baseline must be retrieved from Deloitte to model the net effect
  • Pricing model for deterministic vs. agentic processing must be defined
Two-directional model required. The honest analysis must account for both directions: consumption may increase (more volume through Kindo) or the unit economics may flip (deterministic processing is so cheap it reduces total spend). The net effect must be calculated with real figures, not assumed as positive. Retrieve volume and cost data from Deloitte before presenting this mechanism.
3
Co-Development (Track 2 — SOC for AI)
The one area where net new revenue exists at scale, and the one area where nothing is classified. SOC for AI was co-designed with Deloitte: five governance objectives confirmed, gateway architecture endorsed, tiered SOC model proposed by Krishna. Four Sprint 2 items are actively absorbing Deloitte design input right now.
Mechanism
Revenue from jointly developing SOC for AI capabilities that Kindo can then sell to the broader market. Deloitte contributes domain expertise, SOC operational requirements, and validation. Kindo contributes platform engineering and AI capability. Commercial model is open — see three options below.
Magnitude
Available reference points:
Alliance net new revenue (A.6–A.13): $1–2M+ estimated. Source: program planning materials.
Per-agent pricing range: $2,000–$8,000/month depending on agent type. Source: May 19 Tony-Joana call.
Full deployment projection (6 agents × 100 installs × $3,500/month blended): $25.2M/year. Source: May 19 revenue model.
SOC for AI has replaced deprioritized agents as the lead net new revenue play.

GAP — SOC FOR AI SPECIFIC REVENUE NOT MODELED
These figures are portfolio-level estimates, not SOC for AI-specific. No dedicated revenue model for SOC for AI co-development exists. The magnitude depends entirely on D6 (commercial model) — development fee, co-development, or revenue participation each produce different numbers.
How Charged
Three models. No position adopted. No recommendation.

A. Development Fee
Deloitte pays for development. Kindo owns IP. Deloitte gets usage rights. Revenue is immediate and bounded. Timing: negotiable per deliverable.
B. Co-Development
Shared investment. IP ownership negotiated. Both can commercialize. Revenue is deferred — realized when capability ships to market. Timing: structured over quarters.
C. Revenue Participation
Kindo builds on roadmap. Deloitte receives share when sold to wider market, reflecting their design contribution. Revenue is long-term and scales with market adoption. Timing: ongoing.
Decision Owner
D6 — unresolved. Tony and Ron on Kindo side. Kush on Deloitte side.
What Must Be True
  • D6 must be decided before the next co-design session — four Sprint 2 items are actively absorbing Deloitte design input now
  • Co-development IP terms must be established — currently no agreement exists (evidence gap)
  • What was agreed with Krishna and Kush about ownership of jointly designed capabilities must be documented — currently undocumented
  • Track 2 deliverables must be enumerated and classified by contribution (Kindo-initiated vs. Deloitte-shaped) — the D5 split provides a starting framework
Open Decisions Affecting Revenue
Carried from the classification rubric. Decisions D1–D6 are not resolved here. Only the revenue implication of each is stated.
D1 — Is deterministic workflow control on the Kindo roadmap?
Revenue implication: gates Mechanism 1 (displaced spend) and Mechanism 2 (consumption expansion). If Turbo Mode is not roadmap, Kindo has no platform to capture the displaced Swimlane spend.
D6 — What is the Track 2 commercial model?
Revenue implication: determines whether Mechanism 3 produces immediate revenue (development fee), deferred revenue (co-development), or long-term revenue (participation). Also determines whether co-design input currently being absorbed creates an obligation or an asset.
D5 — Where do Sprint 1/2 deliverables sit?
Revenue implication: determines the size of the Mechanism 3 portfolio. Platform-layer work classified as roadmap shrinks the co-development portfolio. Tony (loss leader) vs. Victor (chargeable) — not resolved.
D2 — How does Kindo address Case Management?
Revenue implication: minimal direct revenue impact. External integration (working position) means Kindo ships an integration layer (roadmap) and Deloitte configures their own ticketing system. The revenue in this area, if any, is in enablement tooling, not in the integration itself.
Data Required to Size Mechanisms 1 and 2
Every magnitude figure must carry its source. The following figures do not exist in available materials. Without them, Mechanisms 1 and 2 have no numbers attached.
Swimlane contract value — annual license + support cost. Source: Deloitte procurement or Zun/Adelina. Required to size Mechanism 1 (displaced spend).
Deloitte's internal cost of running Swimlane — engineering headcount (Harshal, Archith, and team), operational overhead. Harshal and Archith's continuous maintenance load is documented qualitatively (July 27) but not in dollar terms.
Alert volume — total alerts per day/month across all clients. Zun (July 27): "the load can be very very high." 80% of clients route through Swimlane. No figure provided.
Concurrent execution count and peak load — not documented. Required to model capacity requirements for Turbo Mode.
Current Kindo consumption baseline — what Deloitte currently pays in Kindo utilization fees for the triage agent. Required to calculate the Mechanism 2 delta.
Per-alert token cost — current cost of agentic triage per alert, and projected cost of deterministic processing per alert. Required to model the unit economics of Mechanism 2.
Relationship to Classification Rubric
The classification rubric is the technical appendix to this document. It holds the internal record of how each capability was classified (roadmap vs. net new dev vs. Deloitte scope), the five tests used to derive the classification rule, the enablement dependencies, the evidence gaps, and the unresolved internal positions on D1–D6. The rubric answers: who performs the engineering. This document answers: where does the money come from. Both are needed; this one leads.