General capability = roadmap for all customers. Enablement tooling that makes independent configuration possible = roadmap or net new dev depending on specificity. Deloitte-specific development that does not exist today and serves only Deloitte = net new dev. Customer configuration of shipped capability = Deloitte scope, not chargeable.
Deloitte owns configuration of their own environment. Kindo does not perform customer configuration work. Revenue in Track 1 sits in the tooling Deloitte needs to configure independently, not in the configuration itself. MFN-safe: general capability and enablement tooling are roadmap for all customers; Deloitte-specific development is limited to niche tool integrations and templates; customer configuration is not a commercial category at all. Derivation:
Appendix.
Track 1 (Swimlane Replacement): of ten items, seven resolve as capability-layer roadmap with implementation-layer Deloitte scope — Deloitte configuring shipped capability, no chargeable development. Items 5 and 6 carry capability-layer roadmap with chargeable enablement tooling. Item 10 is unprioritized, net new dev if Deloitte requires it on their timeline. Track 1 chargeable development is narrow: migration tooling, niche MCP servers, and Deloitte-specific templates. Net new revenue at scale is in Track 2 — which currently has no commercial classification, no IP terms, and four Sprint 2 items actively absorbing Deloitte design input. Provenance: zero CONFIRMED, five WORKING, two PROPOSED, one PENDING.
D1 · BEFORE AUG 4, 9:00 AM PT
Is deterministic workflow control on the Kindo product roadmap?
Adopted position: PROPOSED (Charlie / Greg) — Yes, roadmap at capability layer.
Basis: Turbo Mode exists and was demonstrated July 30, covering items 1–5. Greg's Jul 27 position (hybrid deterministic-plus-agentic, PoC committed) is corroborated by the artifact. Charlie's Jul 21 statement predates the demo.
Reconciliation hypothesis: The two statements may not conflict if Charlie's referred to native deterministic flow control in the agent runtime while Turbo Mode is a separate deterministic layer. Question for Charlie: confirm or deny.
If confirmed: Items 1–5 resolve at capability layer. D4 inherits. If denied: items 1–5 lose their roadmap foundation.
D6 · BEFORE NEXT CO-DESIGN SESSION
What is the Track 2 (SOC for AI) commercial model?
Track 1 chargeable development is narrow (see §2). Net new revenue at scale is in Track 2 — which has no commercial classification and four Sprint 2 items actively absorbing Deloitte design input now. Classifying after the fact appropriates their contribution or gives away Kindo's engineering.
Three models. No position adopted. No recommendation.
A. Development fee — Deloitte pays, Kindo owns IP.
B. Co-development — Shared investment, negotiated IP.
C. Revenue participation — Kindo builds, Deloitte gets share if sold wider.
Procedural recommendation only: Classify before next co-design session.
D5 · BY WED AUG 6 (BACKLOG FOR RON)
Where do Sprint 1/2 deliverables sit — Track 1 roadmap evidence or Track 2 co-development revenue?
Adopted position: PROPOSED (Tony / Victor) — Split by layer.
Tony's position: Loss leader / roadmap.
Victor's position: Defined by VTKL, therefore net new.
Proposed split: Roadmap: Agent Telemetry, Platform Compatibility Matrix, Gateway Architecture, three-standard strategy, OTel/MLflow. Track 2: five governance objectives, tier model, Discovery Menu, eval criteria, platform priority, tier validation.
Trade-off: Both tracks cannot claim the same work. Not decided.
D2 · BY WED AUG 6 (BACKLOG FOR RON)
How does Kindo address Case Management (item 7)?
Adopted position: WORKING — External integration (Option C).
Basis: Ron's stated preference for AI using primitive systems. Krishna's May 7 sequencing (Swimlane then Jira, order not fixed). Zun's phased-rollout recommendation.
Consequence: Items 3, 4, 7, 9 resolve as roadmap at integration layer, Deloitte scope at configuration layer.
D3 · BLOCKING DEPENDENCY — RAISED PRIORITY
Low-code / visual workflow builder — blocking enablement dependency
Reclassified: No longer PENDING (Adelina). Now a blocking dependency of the ownership-split model.
Basis: If Deloitte owns configuration and Kindo's direction is agentic-first with no visual builder, Deloitte structurally cannot execute their own scope. Zun (Jul 27) described needing a visual workflow builder, drag-and-drop, for constructing pipelines. Adelina indicated it would likely be a requirement. Under the ownership model these are structural, not preferences.
Classification: Capability layer ROADMAP if generalized. NET NEW DEV for Deloitte-specific templates. WORKING.
Inherited (no separate confirmation): D4 (Turbo Mode): WORKING, inherits D1. Roadmap at capability layer, Deloitte migration execution is Deloitte scope, migration tooling is net new dev.
Classification labels: ROADMAP = general capability, all customers. NET NEW DEV = chargeable development, Deloitte-specific engineering. DELOITTE SCOPE = Deloitte's own configuration of shipped capability, not chargeable. UNPRIORITIZED = Kindo does not intend to build; flagged, not assigned.
| # |
Capability |
Readiness |
Capability Layer |
Implementation Layer |
Provenance |
Basis (Test E applied) |
| 1 |
Alert Intake & Scale |
TURBO MODE |
ROADMAP |
DELOITTE SCOPE |
WORKING |
Pointing email-based intake sources at shipped ingestion capability is Deloitte configuration. No engineering cost to Kindo. Test E: specificity without engineering cost. |
| 2 |
Data Normalization |
TURBO MODE |
ROADMAP |
DELOITTE SCOPE |
WORKING |
Per-client schema mappings are Deloitte configuration of shipped normalization capability. No engineering cost to Kindo. |
| 3,4,9 |
Noise Reduction · Incident Correlation · Reporting |
TURBO MODE / SCOPING |
ROADMAP Integration layer |
DELOITTE SCOPE Jira/ticketing config |
WORKING |
Depend on #7. Under D2: Kindo ships integration layer (roadmap), Deloitte configures their Jira/ticketing system against it (Deloitte scope). No Kindo engineering for the configuration. "SOC reporting standards" still undefined. |
|
|
| 5 |
Workflow Control |
TURBO MODE |
ROADMAP Deterministic flow |
DELOITTE SCOPE Workflow migration execution |
PROPOSED |
Capability layer inherits D1. Migration of ~150 workflows is Deloitte execution, not Kindo development. The tooling that enables migration is separate — see §5 Enablement Dependencies. |
| 6 |
Response Actions |
UNDER CONSIDERATION |
ROADMAP if generalized |
No implementation to classify |
WORKING |
General action library is generalizable (Test C). No implementation exists to apply Test E. |
| 7 |
Case Management |
STRATEGIC DISCUSSION |
ROADMAP Integration layer |
DELOITTE SCOPE Jira/ticketing config |
WORKING |
D2: external integration. Kindo ships the integration layer. Deloitte configures their ticketing system. Items 3, 4, 9 inherit. |
| 8 |
Multi-Tenancy |
STRATEGIC DISCUSSION |
ROADMAP Pre-existing |
DELOITTE SCOPE Per-client tenant config |
HYPOTHESIS |
Charlie: "Kindo is literally designed for multi-tenancy." Hypothesis: the gap Deloitte cites may not be isolation but the ability to administer per-client configuration themselves. If so, this is an enablement dependency (§5), not a platform gap. To confirm: ask Deloitte what specific multi-tenancy gap they experience. |
| 10 |
Secure / Edge Deployment |
NOT PRIORITIZED |
UNPRIORITIZED |
NET NEW DEV if Deloitte requires on their timeline |
WORKING |
Kindo has not prioritized. Classifying as roadmap creates obligation Kindo cannot meet. |
If Deloitte owns configuration, Kindo must ship the tooling that makes independent configuration possible. This is where Track 1 chargeable development actually sits.
| Enablement |
Classification |
Provenance |
What Deloitte cannot do without it |
| Low-Code / Visual Workflow Builder |
ROADMAP general capability
NET NEW DEV Deloitte templates |
WORKING |
Without a visual builder, Deloitte cannot construct or modify deterministic workflows themselves. Agentic-first with no low-code option means Deloitte structurally cannot execute their own scope under the ownership model. Blocking dependency. Zun (Jul 27): "visual workflow builder, drag-and-drop." Adelina: "would likely be a requirement." |
| Migration Tooling |
NET NEW DEV |
WORKING |
Without tooling, Deloitte must paste ~150 workflow definitions one at a time. Krishna asked (Jul 30) whether the starting point always has to be an agent; Charlie mentioned possible tooling. Migration execution is Deloitte scope; the tooling that enables it is Kindo development. |
| Multi-Tenant Configuration Administration |
ROADMAP if generalizable
NET NEW DEV if Deloitte-specific |
HYPOTHESIS |
Without self-serve tenant admin, Deloitte cannot manage per-client configuration without routing through Kindo. Hypothesis: item 8's gap is this, not isolation. To confirm: ask Deloitte. |
| MCP Servers for Deloitte's Niche Tools |
NET NEW DEV |
PENDING |
Without MCP servers for their specific integrations, Deloitte cannot connect those tools to Turbo Mode. Adelina flagged webhooks and direct APIs. Widely-used platforms remain ROADMAP. Cannot classify until gap is mapped. |
D5 splits Sprint 1/2 deliverables by layer. PROPOSED (Tony / Victor). No Track 2 item has a commercial classification until D6 is decided.
Platform-Layer → Roadmap Candidate
- Agent Telemetry prototype
- Platform Compatibility Matrix
- Gateway Architecture (Pillar 2)
- Three-standard strategy
- OTel/MLflow architecture
- Governance Monitor
Co-Development Candidate
- Five governance objectives (Deloitte confirmed)
- Tier model (Krishna's Basic/Standard/Elite)
- Discovery Menu of Options (Krishna-facing)
- Eval Criteria (awaiting co-design)
- Platform Priority (awaiting co-design)
- Tier Validation (awaiting co-design)
Track 2 open question — Contribution & Ownership: SOC for AI was co-designed with Deloitte in the room. Who contributed the requirement and the design, who owns the resulting IP, and what is the commercial model? See D6. Classification must happen before co-design continues.
Item 7 (Case Management) is the keystone. Items 3, 4, and 9 depend on it. D2 resolves via external integration: Kindo ships the integration layer (ROADMAP), Deloitte configures their Jira/ticketing system (DELOITTE SCOPE). Under this resolution, dedup queries the external incident store, correlation groups against the external object, reporting queries external records. Four items move from contingent to classified. Turbo Mode's impact claim on items 3 and 4 becomes viable because the substrate exists externally.
Dependency chain under D2:
#7 → external integration → ROADMAP integration / DELOITTE SCOPE config
↳ #3, #4, #9 inherit. "SOC reporting standards" (#9) still undefined by Deloitte.
1. Classify at scope time — before development begins, not after. Does not change retroactively.
2. Disclose absorption — if net new dev is absorbed into product, Deloitte is notified and pricing impact addressed.
3. Joint decision authority — Kindo product + T&C program management classify. Unilateral reclassification not permitted.
4. Audit trail — every classification recorded with date, decision-maker, and reasoning.
5. Flagging rule — any classification that creates a delivery obligation Kindo cannot meet must be flagged, not assigned (e.g., item 10).
6. Support boundary — Deloitte-owned configuration means Deloitte-owned troubleshooting of that configuration. Without an explicit boundary, configuration failures are escalated to Kindo and absorbed as unpaid work, eroding the classification itself. The line: Kindo supports the platform and shipped capability. Deloitte supports their configuration of that capability. When a Deloitte-reported issue requires Kindo to diagnose whether it is a platform defect or a configuration error, that triage is Kindo's responsibility. Remediation of a configuration error is Deloitte's.
Program risk, not classification. The Jul 27 Discovery session recorded that Harshal and Archith constantly monitor and fix playbooks when upstream data changes — they are already fully occupied sustaining current state. If Deloitte configures ~150 workflows themselves, with migration beginning November 2026 and the Swimlane contract ending February 2027, that load falls on the same engineers. Without enablement tooling (§5 — visual workflow builder, migration tooling) the timeline does not close. Owner required.
Track 1 — Swimlane Replacement
No formal Kindo SOC for AI product roadmap document. Charlie's Aug 3 answer is retroactive. Sprint 1/2 deliverables are evidence of work, not a pre-existing roadmap artifact.
Turbo Mode origin unverified. Who requested it, under what framing, whether Deloitte-specific or general product development.
Kindo–Deloitte contract scope language not reviewed. What development is covered, whether a roadmap-inclusion clause exists.
Meta MFN clause specifics not reviewed. Guardrail rules based on Ron's Aug 3 framing and standard MFN principles.
Krishna's May 7 statement on Swimlane → Jira sequencing — referenced but not verified from primary source.
Track 2 — SOC for AI Co-Development
No co-development or IP terms exist for SOC for AI. No agreement governing ownership of jointly designed capabilities was identified. Co-design is proceeding without commercial terms.
What was agreed with Krishna and Kush about ownership of jointly designed capabilities is undocumented. Jul 10 co-design confirmed 5 governance objectives and endorsed gateway architecture. Whether these carry IP or commercial implications was not discussed on record.
Matthew's development work in SOC for AI area not documented. Charlie cited it as part of the roadmap position.
Appendix — Derivation of the Rule
Five tests evaluated. Tests B and C produce the capability-layer rule. Test E produces the implementation-layer distinction between chargeable development and customer scope.
Test A — Provenance CONTEXT ONLY
Did Deloitte request it? All ten originate from Zun's April 2026 doc. Context, not determinant.
Test B — Pre-Existence ADOPTED
Was this in Kindo's roadmap before Deloitte asked? If yes, roadmap. No formal roadmap doc exists; Sprint 1/2 deliverables serve as evidence.
Test C — Generalizability (Mid-Market Test) PRIMARY — PRODUCES CAPABILITY-LAYER RULE
Would a mid-market SOC customer want this? General capability = roadmap. Deloitte-specific variant = net new dev or Deloitte scope depending on Test E. MFN-safe.
Test E — Engineering Cost ADOPTED — TAKES PRECEDENCE OVER TEST D
Does this require engineering that does not exist today, and does that engineering serve only Deloitte? Specificity without engineering cost is customer scope (Deloitte configuration), not chargeable development. Test D identifies specificity; Test E identifies whether the specificity costs engineering. Only both together produce chargeable scope. This test produces the implementation-layer distinction: NET NEW DEV (engineering required, Deloitte-specific) vs DELOITTE SCOPE (configuration of shipped capability).
Test D — Operational Specificity TIEBREAKER — SUBORDINATE TO TEST E
Does this encode Deloitte's MSSP model specifically? Identifies specificity but not cost. Use only in conjunction with Test E to determine whether specific work is chargeable development or customer configuration.