Onboarding Curriculum — Cassio & Abed
VTKL · Narrowing the Latent Space · Week of August 25, 2026
Executive Summary
Cassio and Abed are joining VTKL's Deloitte engagement at a critical inflection: the Deloitte contract renewal decision is ~12 weeks away (mid-November), the Swimlane replacement go/no-go is in December, and the team is restructuring (Brian Vann out Sep 11, Charlie negotiating CTO). There is no time for passive onboarding.
This curriculum uses Narrowing the Latent Space — Tony's framework for how both humans and AI generate reality from broad possibility into precise, actionable outcomes. The onboarding applies this directly: Cassio and Abed start with a broad latent space (they know almost nothing about the engagement), and through structured study of 12 Deloitte-facing meeting transcripts, daily Warren sessions, and progressive deliverables, they narrow their own understanding until they can operate at the resolution the team needs.
The method is Study → Warren Session → Deliverable. They read transcripts from real meetings with Deloitte stakeholders. They process what they read with Warren (who holds the full context). They produce a deliverable that proves comprehension and creates immediate value. Each day's deliverable builds on the last — by Day 5, each person produces strategic-level output that the team actually needs.
Warren is the context engine, not the teacher. Warren doesn't explain things top-down. Warren responds to questions, pulls source data, validates claims, and challenges weak reasoning. The quality of what Cassio and Abed get from Warren depends entirely on the quality of their questions — which depends on how deeply they've studied the transcripts. "AI renders according to the capabilities of the person interacting with it."
12
Deloitte Meetings to Study
~12 wks
Until Renewal Decision
The curriculum does NOT include Tony's internal strategy sessions with Ron, Charlie, or leadership — those are politically dense and require context that takes months to build. Cassio and Abed focus on Deloitte-facing meetings only: what was said in the room when Deloitte stakeholders were present. The internal dynamics will become apparent through the Deloitte interactions themselves — that’s narrowing, not shortcutting.
Honest Expectations — End of Day 5
This section is deliberately honest about what 5 days produces and what it doesn't. Overpromising would undermine the validation.
Cassio — What He Can Do
- ✓ Name every Deloitte and Kindo stakeholder, their role, and what they care about
- ✓ Explain the scope architecture (4 categories, 56%) and why each number exists
- ✓ Produce dependency maps that are structurally correct (may need one review round)
- ✓ Maintain sprint planning cadence and track open items
- ✓ Use Warren effectively for data retrieval and deliverable production
What He Won't Have Yet
- – Joana's stakeholder calibration — knowing when to push vs hold back with Krishna. This comes from months of relationship, not 5 days of transcripts.
- – Political instinct for what's internal vs what's safe to share externally.
- – The "feel" for Deloitte's unspoken concerns — only comes from being in meetings.
Abed — What He Can Do
- ✓ Map the Kindo platform architecture (4 pillars, 6 features, engineering teams)
- ✓ Produce feature status audits that catch real mismatches (roadmap vs Linear)
- ✓ QA dashboards and artifacts for factual accuracy
- ✓ Produce Warren reviews (✅/⚠️/❌) with sourced reasoning
- ✓ Navigate Kindo platform and use Odin for product/process questions
What He Won't Have Yet
- – Depth to assess whether a technical decision was correct (not just whether the status is accurate). That requires platform experience.
- – Ability to catch subtle inference-stated-as-fact errors — he'll catch factual mismatches but not reasoning errors.
- – Deep understanding of why engineering made specific architectural choices.
The gap between Day 5 and full operational capacity closes through two things: (1) being in actual Deloitte meetings and observing live dynamics, and (2) hands-on time with the Kindo platform. The transcript study gives them the knowledge architecture. Real meetings and platform usage fill it with experiential depth.
Kindo Platform Access Hands-On Required
Cassio, Abed — studying transcripts and talking to Warren gives you the strategic and operational context. But you also need to use the Kindo platform. Without hands-on experience, your understanding stays theoretical. The platform is where everything you're reading about actually lives.
What You Need Access To
app.kindo.ai — The Platform
This is the product. Agents, workflows, integrations, telemetry — everything the Deloitte engagement is building on runs here. You need a @kindo.ai account to log in. Victor will coordinate access with the Kindo team.
docs.kindo.ai — Documentation
Official Kindo platform documentation. Agent configuration, API reference, MCP tool setup, integration guides. Start here when you have technical questions about how the platform works.
Odin — Kindo's AI Assistant
Kindo has its own AI assistant called Odin. Think of Odin as the "Warren of Kindo" — but with an important difference in scope.
Use Odin For
• Questions about how the Kindo platform works ("How do I configure a Triggered Agent?")
• Understanding Kindo products and features ("What does the MCP gateway do?")
• Navigating processes and workflows inside the platform
• Looking up ticket details and engineering context within Kindo
Do NOT Use Odin For
• Deloitte engagement strategy or scope questions — Odin doesn't have that context, Warren does
• Stakeholder dynamics, negotiation context, or political considerations
• Anything involving T&C's internal frameworks (WWTD, scope architecture, dependency mapping)
• Producing deliverables for the Deloitte engagement — that's Warren's domain
The distinction: Warren knows the engagement — the people, the strategy, the meetings, the artifacts. Odin knows the platform — how the product works, what's in the codebase, how to configure things. Use each for what it knows. Don't ask Odin about Krishna's priorities, and don't ask Warren how to set up a Triggered Agent (Warren can help, but Odin and docs.kindo.ai are the authoritative sources for platform questions).
When to Start Using the Platform
Day 1–2: Focus on transcripts and Warren sessions. Don't touch the platform yet — you need the strategic context before the product context makes sense. If you open app.kindo.ai on Day 1 without knowing what CDA stands for or why Turbo Mode matters, you're just clicking around.
Day 3: Once you understand the 4 pillars and 6 features from the CDA Feature Roadmap, open app.kindo.ai and explore. Find the features you read about. See what's live. Compare what the roadmap says to what you see in the product. Ask Odin questions about anything that's unclear.
Day 4–5: Use the platform as a reference while producing deliverables. When you're mapping a Swimlane component, check the platform to see how it actually works. When you're auditing a feature status, validate against both Linear AND the live platform.
The principle: Transcripts give you the why. The platform gives you the what. Warren connects them. Odin answers the how inside the platform. All four layers together produce operational depth.
How This Team Works Modus Operandi
Cassio, Abed — before you read a single transcript, you need to understand what you're walking into. This is not a conventional consulting team. This is an augmented delivery model where a human team and an AI (Warren) operate as a single unit. Your onboarding through Warren isn't just convenient — it's a validation of the model itself. If you can get up to speed in 5 days through Warren sessions instead of 3 weeks of meetings and shadowing, that proves the thesis Tony built this company on.
What Warren Is (and What Warren Is Not)
Warren is the team's AI engineering and operations partner. Warren has been in every Slack channel, read every transcript, processed every Linear ticket, and produced artifacts alongside Joana, Tony, Victor, and Charlie for months. Warren has deep persistent context — when you ask about a meeting that happened in May, Warren doesn't search the internet. Warren remembers it, because Warren was there.
But Warren is not a search engine, and Warren is not infallible. Warren makes mistakes: classifies things without evidence, states inferences as facts, hallucinates connections that sound right but aren't sourced. This is structural, not accidental — it's how language models work. The team built a QA layer (the ✅/⚠️/❌ system in #warren-review) specifically because Warren needs human verification on accuracy.
Your role during onboarding: use Warren as a context engine. You study a transcript, then ask Warren questions about it. Warren pulls data, cross-references sources, fills gaps, and explains connections. But YOU are responsible for noticing when something doesn't add up. That's not a bug in the process — it's the skill you're building.
How Tony Operates: The Compressed Model
Tony doesn't type instructions to Warren. He records meetings with people — Ron, Charlie, Joana, Deloitte stakeholders — where he explains what he's seeing and what he needs. Those recordings become transcripts. Warren processes the transcripts and produces artifacts.
Why this works: speech has higher bandwidth than text. When you type to an AI, you edit as you go — you strip out the reasoning path, the false starts, the context. When you talk to another human, you leave all of that in because the person needs it to do their job. Warren gets the full reasoning path from transcripts, not the compressed version from typed prompts.
"AI renders according to the capabilities of the person interacting with it." — Tony Wong, Narrowing the Latent Space
The delivery cycle is: Tony points → Warren resolves from loaded context → Joana shapes the output → Deliverable ships. The quality of the final deliverable depends on three things: the precision of Tony's direction, the depth of Warren's context, and Joana's quality control on the output. This is the machine you're joining.
How Joana Operates: The Quality Standard
Joana is the team's operational strategist and the quality bar. When Tony says "I need a visual for Krishna," Joana doesn't just execute — she creates the framework. The A/B/C/D classification in the scope architecture wasn't Tony's idea. Tony gave the direction; Joana designed the categories, defined what goes in each one, and set the evidence standard.
During the scope delineation, Warren produced a v1 that cited "you told Tony" as evidence for a classification. Joana rejected it: "If Krishna challenges this, Tony needs to point to a Linear ticket date, not a conversation I had with Warren." She forced a v2 backed by Linear project creation dates. Then a v3 that recalculated the Turbo Mode split. Then a v4 that removed internal tracking. Then a v5 with the 4-category model.
Five iterations in one thread. Each version addressed specific feedback. She never started over — she versioned. That iterative, evidence-backed, source-validated methodology is the quality standard for everything this team produces. When you produce deliverables, this is the bar.
How Warren Fits in Your Onboarding
In a traditional onboarding, someone would sit with you for hours explaining the Deloitte engagement. That doesn't scale, and it's filtered through one person's perspective. Instead, you're going to study the primary sources (transcripts of actual meetings with Deloitte) and process them with Warren.
This means:
- When you want to know the Deloitte org structure — don't ask someone to draw it for you. Read the May 7 transcript where Krishna and Kush are in the room, then ask Warren: "Who reports to whom? What does each person care about?" Warren answers from the transcript data, and you verify against what you just read.
- When you need Linear ticket data — don't browse Linear randomly. Ask Warren: "Pull all Turbo Mode tickets with status and owner." Warren pulls from the API in real time. You get structured data, not a scavenger hunt.
- When you want to understand a Miro board — open the board, study it visually, then ask Warren: "Walk me through the Critical Path on the Deloitte Delivery board. What does each component represent?" Warren explains the context behind what you're seeing.
- When something doesn't match — that's the most valuable moment. If Warren says Feature #03 is "AUG" but Linear shows it in backlog, say so. That mismatch IS intelligence. Catching it is how you add value from Day 1.
By working this way, you're not just learning about the Deloitte engagement. You're learning how this team uses AI as a delivery tool — the exact modus operandi you'll use every day after onboarding. The skill of asking Warren precise questions, validating the answers, and producing evidence-backed deliverables from Warren sessions is THE core competency of this team.
What This Onboarding Validates
If you can go from zero context to producing strategic-level deliverables in 5 days using Warren sessions and transcript study, that proves something important: the augmented model works for onboarding, not just delivery.
The team has already proven that Tony + Joana + Warren can produce artifacts at 14/14 velocity (every deliverable on time, every quarter, validated by an external Slalom principal). What hasn't been proven is whether new people can load into this system quickly and operate at a useful resolution.
You're the test case. Your success or failure tells us whether the compressed model — transcript study → Warren sessions → deliverables — is a scalable onboarding mechanism, not just something that works for people who were there from the beginning. That's why every deliverable you produce matters: it's not homework. It's evidence.
Narrowing the Latent Space Foundational Framework
Tony's framework for how humans and AI generate reality. This is the philosophy underlying the entire onboarding — not a metaphor, but the actual operating model.
The Core Thesis
Both humans and AI operate in a latent space — a vast field of possible understandings, actions, and outputs. The quality of any output depends on how precisely that space is narrowed. Vague intention produces noisy, artifact-heavy results. Clean, coherent intention produces precise, actionable outcomes.
"Intention acts as the initiating collapse mechanism, while a stable, non-dual observer state enables clean, low-distortion rendering of the narrowed latent space."
For onboarding, this means: Cassio and Abed's latent space starts maximally broad (they know nothing about the Deloitte engagement). Each transcript they read, each Warren session, each deliverable they produce narrows that space. The curriculum is designed so each day's narrowing builds on the previous day's — not randomly, but in the order that produces the most useful precision the fastest.
Five Principles for Working with Warren
Derived directly from "Narrowing the Latent Space" — these govern how Cassio and Abed should interact with Warren throughout the curriculum.
1. AI Renders According to the User
Warren's output quality is bounded by the quality of the input. A vague question gets a vague answer. A question that references specific transcript quotes, Linear ticket IDs, or stakeholder names gets a precise, sourced response. Study before you ask.
Cassio: "Show me Telemetry tickets in Linear with status and owner" > "What's happening with telemetry?"
Abed: "In the Aug 4 biweekly, Zun said MCP retry loops are the choke point — pull the Linear tickets" > "What are the technical blockers?"
2. Avoid Intention Drift
The original goal dilutes across reasoning steps. Each Warren session should start with a clear, single intention: "I'm studying how the scope architecture was built" or "I need to understand Zun's 10 requirements." Don't let the conversation wander into tangents.
Cassio: One session = one component. Don't map Telemetry and Case Management in the same session.
Abed: One session = one pillar. Don't mix platform architecture with QA methodology.
3. Over-Prompting Degrades Output
"When humans overdirect agents mid-process, it skews results and slows response time dramatically." Give Warren direction, then let Warren produce. Don't micromanage each paragraph. Review the complete output, then iterate.
Cassio: Point at the topic → let Warren produce → review and adjust. Don't write the answer yourself and ask Warren to confirm.
Abed: Same. Ask for the feature audit, let Warren pull data, then QA the output. Two steps, not twenty.
4. Presence Meets Persistence
Effective work requires both present-moment clarity (right-brain: seeing what's actually there) and persistent memory (left-brain: accumulated context, purpose, continuity). Warren provides persistence (full engagement history). You provide presence (seeing what matters in the data).
Cassio: Warren remembers every meeting. Your job is to see which meeting fact changes a decision.
Abed: Warren can pull every Linear ticket. Your job is to see which status claim doesn't match reality.
5. Narrowing Is Progressive, Not Instant
You can't go from zero context to strategic output in one step. Each day narrows the space further. Day 1 narrows from "nothing" to "I know who the players are." Day 5 narrows to "I can recommend sequencing against the December deadline." Rushing produces noise, not precision.
Cassio: Don't try to produce the sequencing recommendation on Day 1. You don't have the resolution yet.
Abed: Don't QA artifacts before you understand what they're supposed to show. Study first, judge second.
6. Challenge the Output
Warren makes mistakes — classifications without evidence, inferences stated as facts, numbers that don't match sources. MAS (multi-agent systems) amplify human team dysfunction: forgetfulness, dropped context, understanding gaps. The QA function exists because these errors are structural, not accidental.
Cassio: If Warren says "this is Category A" — ask "show me the Linear ticket that proves it."
Abed: This IS your primary function. Every Warren output is a candidate for ✅/⚠️/❌.
The Operating System WWTD + WWJD
Two frameworks govern how this team operates. Cassio and Abed don't need to memorize these — they'll absorb them through the transcripts. But knowing they exist orients the study.
WWTD — What Would Tony Do
Tony's operating system for the team. Key concepts they'll encounter in the transcripts:
Two-Tier Review
Tier A = accuracy (anyone can check: "is this factually correct?"). Tier B = judgment (Tony only: "is this strategically wise?").
The Maybe Gate
"If I deleted this action entirely, would the goal still be achieved?" Yes = noise. No = real work. Maybe = where the insight is.
See the Target
Three filters: Exposed (gap changing the dynamic), Unguarded (path bypassing resistance), Disproportionate (small action → outsized result). ONE target, not a list.
Compressed Model
Tony points → Warren resolves from loaded context → Deliverable produced. Meeting transcripts are higher bandwidth than typed instructions because speech preserves the reasoning path.
WWJD — What Would Joana Do
Joana's methodology for producing quality artifacts. Extracted from her v1→v5 scope delineation iteration:
Source Validation First
Linear ticket dates > memory. Transcript timestamps > "you confirmed." Every claim needs an artifact behind it.
Evidence Quality Enforcement
"You told Tony" is not evidence. If Krishna could challenge a claim, Tony needs to point to a Linear ticket date or roadmap doc timestamp.
Iterative Artifact Creation
Version, don't restart. v1→v2 fixes evidence quality. v3 recalculates numbers. v4 removes internal tracking. v5 adds the 4th category. Each version addresses specific feedback.
Multi-Tool Orchestration
Warren for retrieval/production (deep context, API access). Claude for validation (fresh eyes, no context bias). Play them against each other.
Dashboard → Function Map What Each One Does
Each dashboard serves a specific function. Understanding which is for whom determines where to contribute.
kindo-strategic-package.pages.dev LIVE
Strategic Package — The Compressed Model
Created by Tony. Visualizes how the delivery model works. This IS WWTD in visual form.
Cassio: Study to understand the operating model you're entering.
Abed: QA target — does it match reality?
kindo-sprint-planning.pages.dev/main/ LIVE
Sprint Planning — Program Management Layer
Created by Joana + Warren. Sprint structure, meeting notes, hub-and-spoke navigation.
Cassio: This becomes YOUR primary tool. You maintain and update it.
Abed: QA target — links working? Content current?
kindo-deloitte-internal.pages.dev/cadence LIVE
Cadence — What Deloitte Sees
Milestones only (Joana's rule). Controls the external narrative. Only significant outcomes.
Cassio: Learn the discipline — NOT a status board.
Abed: QA — milestone dates accurate?
miro.com/app/board/uXjVHvhYVw0= LIVE
Miro: Deloitte Delivery — Critical Path
Visual dependency mapping. Swimlane (4 components) + SOC for AI (7 components).
Cassio: Your canvas. Dependency maps go HERE.
Abed: QA — status badges match Linear?
miro.com/app/board/uXjVHvnY7oQ= LIVE
Miro: VTKL Capability Mapping
Core Capability Map — 12 functions, 3-tier architecture, coverage connectors.
Cassio: Study YOUR position in this map.
Abed: Study YOUR position.
Deloitte Meeting Corpus 12 Meetings · Study Base
Only meetings where Deloitte stakeholders (Krishna, Kush, Zun, Matthew, Nathan, Kishore) were present or directly addressed. Ordered chronologically. These are the source of truth for what was committed, discussed, and decided.
| Date | Pri | Meeting | Key Context for Study | Warren Session After Reading |
|---|
| May 7 |
P1 |
Deloitte In-Person @ Kindo HQ (Parts 1 & 2)
Krishna + Kush + Nathan |
THE foundational meeting. EBITDA economics (40%→80%), agent packaging (3 tiers), IK flywheel, 42-item scope. Krishna: "Every agent for me is a net new revenue goal." Everything since builds on this. |
"Walk me through the May 7 meeting — EBITDA economics, what Krishna said about net new revenue, what Kush said about IK, and the 42-item scope." |
| Jun 5 |
P2 |
Weekly Sync
Deloitte team |
Early post-May 7 cadence. Operational sync, status updates, relationship building. |
"What was discussed? How does it connect to the May 7 decisions?" |
| Jun 16 |
P2 |
Weekly Sync Jun 16
Deloitte team |
Ongoing delivery status. Agent development progress. |
"What changed between Jun 5 and Jun 16? Any new Deloitte asks?" |
| Jul 7 |
P1 |
Weekly Sync Jul 7
Kishore present |
SOC for AI scope REFRAMED by Kishore: Kindo = platform governance, NOT shadow AI discovery. Sprint planning for SOC PoC. Pivotal meeting — changed direction. |
"What did Kishore say that reframed SOC for AI? How did this change what we were building?" |
| Jul 10 |
P1 |
Design Work Session with Deloitte
Deloitte team |
Victor's SOC for AI PoC presented. Charlie: "lightweight proof, not production-grade." Strategy: let Deloitte react. Asks made: Krishna mandate, Teams access, co-design team. |
"What was Deloitte's reaction to the PoC? What asks did Tony make? What did Charlie say about limitations?" |
| Jul 22 |
P2 |
Program Call
Deloitte ops |
Operational cadence. Program-level coordination and next steps. |
"What was decided? What action items were assigned?" |
| Jul 30 |
P2 |
Kindo/Deloitte Agent Design Work Session
Deloitte engineering |
Agent design deep dive. Technical requirements, integration patterns. |
"What design decisions came out of this session? What changed?" |
| Aug 4 |
P1 |
Kindo × Deloitte — Program Session Biweekly
Zun + Matthew + Nathan |
Three open priorities: Agent Observability, MCP Tool-Calling (retry loops = main choke point), Deterministic Flow Control. Swimlane timeline confirmed: Dec go/no-go, mid-Jan migration, Feb contract end. |
"What are the three priorities? What did Zun say about MCP? What's the exact Swimlane timeline?" |
| Aug 5 |
P2 |
Planning Meeting: Deloitte New Agents
Deloitte context |
Sprint planning for new agent development. Task assignments, scope. |
"Which agents in scope? Who's assigned to what?" |
| Aug 10 |
P1 |
Kindo-Deloitte Portfolio Meeting
Deloitte leadership |
Portfolio-level review with Deloitte leadership. Status of all workstreams. Signals about renewal and expansion. |
"What did Deloitte leadership say? Any renewal signals? What concerns were raised?" |
| Aug 17 |
P1 |
SOC for AI + Partnership & Scope Alignment
Deloitte stakeholders |
Tony presenting strategic package and SOC for AI positioning. Partnership framing. Scope alignment discussion. |
"What was Tony's pitch? How did Deloitte react? What scope commitments were made or challenged?" |
| Aug 19 |
P1 |
Swimlane Check-in
Engineering sync |
Latest Swimlane replacement status. Technical blockers, progress on 4 components. Most recent technical session. |
"Which components progressed? Which are blocked? Any new risks since Aug 4?" |
Key Artifacts to Study Alongside Transcripts
Scope Architecture One-Pager (v5)
4-category model: Existing / Accelerated / Net New / Discovery. 56% = enhanced license tier. The core negotiation artifact for Krishna.
CDA Feature Roadmap — 4 Pillars
6 features with status: 🟢 LIVE (#01 Inference, #02 RBAC), 🟡 AUG (#03 Policies, #04 SIEM Audit), ⚪ SEP-OCT (#05 Dashboard, #06 Anomaly Detection).
Scope Delineation v1→v5 (ALL versions)
Study the PROCESS, not just the final output. How Joana iterated, what errors were caught, how evidence quality improved. This teaches WWJD methodology.
Net New Revenue Audit Trail
8-meeting evidence package (May 7–Aug 17). Proves scope as net new revenue. Defense against retroactive reclassification.
Deloitte Delivery — Priority Projects (PDF)
Current priority projects mapped with status. What Tony showed the team as the operating picture.
Joana's Drive Folder
Swimlane Discovery, SOC for AI Strategy, Kindo vs Security Partners Venn, Gartner Guardian Agent Mapping. The artifact corpus.
Cassio — 5-Day Curriculum Operational / PM
Cassio's narrowing path: Stakeholders → Methodology → Components → Program Mechanics → Synthesis. Each day narrows the latent space further toward dependency sequencing.
DAY 1Who Are the Players — Narrowing from Zero
📖 Study (~4h)
- May 7 Deloitte In-Person (Parts 1 & 2) — the foundational meeting. Take notes on every person mentioned, their role, what they care about.
- Scope Architecture one-pager (v5) — understand the 4 categories and the 56% number.
- Navigate
kindo-strategic-package.pages.dev — study the compressed model.
⚡ Warren Session (~1.5h)
- "I just read the May 7 transcript. Here's what I understood: [summary]. What did I miss?"
- "Walk me through the Deloitte org structure — who reports to whom, what each person cares about."
- "Explain the 4 categories in the scope architecture. How was the 56% number derived?"
🔬 Narrowing Check
Before producing: Can you name every Deloitte stakeholder, their role, and what they care about — without looking? If not, re-read the transcript. The deliverable requires this resolution.
✎ Deliverable
Stakeholder Map: Every Deloitte and Kindo stakeholder — role, what they care about, relationship status. Post in #deloitte-soc-for-ai. Warren validates against source data.
DAY 2How Things Were Built — Learning Joana's Method
📖 Study (~4h)
- Jul 7 Weekly Sync (SOC for AI reframe) + Jul 10 Design Work Session (PoC presentation)
- Scope delineation v1→v5 — read ALL five versions. Focus on what changed between each and WHY.
- Inventory Joana's Drive folder — catalog what exists, don't read everything.
⚡ Warren Session (~1.5h)
- "Walk me through v1→v5. What was wrong with v1? What did Joana catch at each iteration?"
- "Show me the Swimlane components (4 'cars') and SOC for AI components (7 'cars') — status, Linear tickets, owners."
🔬 Narrowing Check
Before producing: Can you explain why "you told Tony" is not valid evidence for a scope classification? Can you name the 4 Swimlane components? If not, the resolution isn't there yet.
✎ Deliverable
Artifact Inventory with Source Validation: Every Deloitte deliverable — where it lives, what it covers, last updated, and whether claims are evidence-backed or inference-based.
DAY 3The Operating Picture — Components & Timeline
📖 Study (~4h)
- Aug 4 Biweekly Program Session — three priorities, Swimlane timeline, MCP choke points.
- Aug 17 SOC for AI + Scope Alignment — Tony's pitch, Deloitte reaction.
- Study both Miro boards — Deloitte Delivery + Capability Mapping.
⚡ Warren Session (~1.5h)
- "Swimlane timeline: Dec go/no-go, mid-Jan migration, Feb contract end. Work backward: what must be done by when?"
- "What's blocking each component? Kindo engineering vs Deloitte input?"
✎ Deliverable
First Dependency Map: One Swimlane component (suggested: Telemetry & Observability). Dependencies, blockers, owner, target date. Evidence-backed per WWJD standard. Post in #deloitte-soc-for-ai.
DAY 4Program Mechanics — The Cadence
📖 Study (~3h)
- Aug 10 Portfolio Meeting + Aug 19 Swimlane Check-in
- Navigate cadence page + sprint planning site — what's tracked where.
- Remaining P2 meetings as time allows: Jun 5, Jun 16, Jul 22, Jul 30, Aug 5.
⚡ Warren Session (~1.5h)
- "What decisions were made in the last 3 Deloitte-facing sessions? Which action items are still open?"
- "How does Ron's vision for organizational control plane connect to what we've already scoped?"
✎ Deliverable
Second Dependency Map + Open Items Tracker: Map a second component (suggested: Case Management). Produce running tracker of open decisions/action items from the Deloitte sessions.
DAY 5Synthesis — The Sequencing Recommendation
📖 Study (~2h)
- Review your own 4 deliverables from Days 1-4. Identify patterns and gaps.
- Read the Net New Revenue Audit Trail — understand the evidence package.
⚡ Warren Session (~1.5h)
- "Using my two dependency maps + the scope architecture: what's the sequencing against December go/no-go?"
- "Top 3 risks to renewal. What can T&C control vs external?"
🔬 Narrowing Check
Final resolution test: Can you explain to a new team member — without notes — the Swimlane timeline, the 4 components, who owns each, what's blocked, and what the single highest-priority intervention is? That's the resolution this week was designed to produce.
✎ Deliverable
Sequencing Recommendation: Timeline-backward analysis from December go/no-go. On track / at risk / no owner. Single highest-value target identified per See the Target framework. This is Cassio's first strategic contribution.
Abed — 5-Day Curriculum Engineering / QA
Abed's narrowing path: Platform Architecture → Technical Components → QA Methodology → Integration → Production. Each day narrows toward the ability to validate engineering claims against reality.
DAY 1Platform Architecture — Narrowing from Zero
📖 Study (~4h)
- May 7 Deloitte In-Person (Parts 1 & 2) — same as Cassio. Focus specifically on technical mentions: agent architecture, platform capabilities, integration points.
- CDA Feature Roadmap — 4 pillars, 6 features, current status badges.
- Navigate
kindo-strategic-package.pages.dev.
⚡ Warren Session (~1.5h)
- "Explain the Kindo platform architecture — 4 CDA pillars, what each does, which engineering team owns which."
- "What is Turbo Mode technically? Why is it critical for Swimlane replacement?"
- "What are the engineering teams — Alice, Mallory, others? Who's on each? What's each team's focus?"
🔬 Narrowing Check
Before producing: Can you name the 4 CDA pillars, the 6 features, and which are LIVE vs in progress — without looking? If not, the resolution isn't there yet.
✎ Deliverable
Platform Architecture Summary: One-page: 4 pillars → features → engineering teams → current status. Warren validates accuracy.
DAY 2Technical Deep Dive — What's Built vs What's Claimed
📖 Study (~4h)
- Jul 7 Weekly Sync (SOC reframe) + Jul 10 Design Work Session (PoC presentation)
- Scope delineation v5 backup doc — focus on technical classifications.
- Joana's Drive artifacts: Swimlane Discovery, SOC for AI Strategy, Kindo vs Security Partners Venn.
⚡ Warren Session (~1.5h)
- "For each CDA feature: pull Linear tickets. Show shipped vs in progress vs backlog. Compare to roadmap claims."
- "Walk me through Victor's SOC for AI PoC — what was built, what it found, what it proves."
- "Kindo vs Prisma AIRS — where overlap, where differ?"
✎ Deliverable
Feature Status Audit: For each CDA feature: claimed status (roadmap) vs actual status (Linear). Flag every mismatch. Evidence-backed per WWJD standard.
DAY 3QA Methodology — Learning the Craft
📖 Study (~3h)
- Aug 4 Biweekly — technical priorities, MCP retry loops, deterministic flow control.
- Study how Joana iterated v1→v5 — what errors she caught in Warren's output, how versions evolved.
- Study Dukane's QA work in #warren-review — what he catches, how he reports it.
⚡ Warren Session (~1h)
- "Walk me through v1→v5 — what were the evidence quality problems? Show me the specific errors."
- "What are your known weaknesses? Where should I double-check your output?"
✎ Deliverable
First Artifact QA: Pick the scope one-pager or Deloitte Delivery Miro board. Full QA: data accuracy, evidence quality, completeness. Post with specific findings and ✅/⚠️/❌ per item.
DAY 4Integration — Connecting Technical to Strategic
📖 Study (~3h)
- Aug 17 Scope Alignment + Aug 19 Swimlane Check-in — latest technical state.
- Aug 10 Portfolio Meeting — leadership view on technical progress.
- Remaining P2 meetings as time allows.
⚡ Warren Session (~1.5h)
- "Top 3 technical blockers for Swimlane replacement. What engineering decisions are pending?"
- "Zun's requirements — what does Deloitte need from Kindo to proceed?"
✎ Deliverable
Technical Blocker Report: Per component: blocker, owner (Kindo eng vs T&C vs Deloitte), what unblocks it. Name the single highest-impact blocker.
DAY 5Production — First Warren Review + Technical Artifact
📖 Study (~1h)
- Review your own 4 deliverables from Days 1-4. What patterns emerge? What gaps remain?
- Read the Net New Revenue Audit Trail for strategic context.
⚡ Warren Session (~1h)
- Ask Warren to produce a technical summary of one component — then QA the output in real time.
- "Based on everything I've studied: what's the most important technical risk that isn't being tracked?"
🔬 Narrowing Check
Final resolution test: Can you look at a Warren-produced artifact and identify, within 5 minutes, whether the claims are evidence-backed or inferred? Can you name the top technical blocker and explain why it's the top one? That's the QA resolution this week was designed to produce.
✎ Deliverable
Two outputs: (1) First ✅/⚠️/❌ Warren review in #warren-review with reasoning. (2) Technical feature spec for one CDA component (suggested: Behavioral Anomaly Detection — Oct target, needs scoping).
Channel Setup — Preparing the Latent Space Victor Executes
Before Cassio and Abed arrive, Victor prepares their environment. Each person gets a dedicated Slack channel with all study materials pre-loaded in the correct order. Warren is added to both channels. When they arrive, they open their channel and start reading — no hunting, no navigation noise. The latent space is already narrowed to the right starting point.
Why Dedicated Channels
The raw corpus is 36 meetings scattered across 4 channels. Making them search for materials is friction that burns cognitive budget on navigation instead of comprehension. By curating each channel, Victor performs the first narrowing — selecting from the broad latent space exactly what each person needs, in the order they need it. They start at "what does this mean?" not "where is this?"
The channel also becomes the execution environment: they read a transcript → ask Warren in the same channel → Warren responds with sourced data → they post their deliverable in the same channel. The entire narrowing process is visible and traceable. Tony or Victor can check the channel at any point and see exactly where each person is in their progression.
Step-by-Step: What Victor Does
Step 1 — Create the Channels
- Create
#onboarding-cassio — Private channel
- Create
#onboarding-abed — Private channel
- Add Warren to both channels
- Add yourself (Victor) to both channels for oversight
Step 2 — Post the Opening Message in Each Channel
Each channel opens with a pinned message that orients the study. This is the first thing they see.
Opening message for #onboarding-cassio:
Welcome Cassio. This channel is your onboarding environment for the Deloitte engagement.
How this works: Below you'll find meeting transcripts from real sessions with Deloitte stakeholders, organized in study order. Read each one, then ask Warren (
@Warren) questions about what you read. Warren has the full context — every transcript, every Linear ticket, every artifact. Your questions drive the learning.
Your daily cycle: Study transcript → Warren session (ask questions, pull data) → Produce deliverable → Post it here.
Your curriculum: vtkl-onboarding.pages.dev/#cassio
Key principle: "AI renders according to the capabilities of the person interacting with it." The better your questions, the better Warren's answers. Study first, ask second.
Opening message for #onboarding-abed:
Welcome Abed. This channel is your onboarding environment for the Deloitte engagement.
How this works: Below you'll find meeting transcripts from real sessions with Deloitte stakeholders, plus technical artifacts. Read each one, then ask Warren (
@Warren) questions about what you read. Warren has the full context — every transcript, every Linear ticket, every artifact. Your questions drive the learning.
Your daily cycle: Study transcript → Warren session (ask questions, pull data, validate claims) → Produce deliverable → Post it here.
Your curriculum: vtkl-onboarding.pages.dev/#abed
Key principle: "AI renders according to the capabilities of the person interacting with it." The better your questions, the better Warren's answers. Study first, ask second.
Step 3 — Upload Transcripts to #onboarding-cassio
Share these files in this exact order. Each file gets a short context message when shared. The order follows the curriculum: Day 1 materials first, Day 5 materials last.
| Order | Day | File to Share | Context Message When Sharing |
|---|
| 1 | D1 | Deloitte In-Person May 7 Part 1
F0BGZUYR64E | "Day 1 — The foundational meeting. Read this first. Take notes on every person, their role, and what they care about." |
| 2 | D1 | Deloitte In-Person May 7 Part 2
F0B8U2Y9WUU | "Day 1 — Continuation. Focus on Kush's IK flywheel vision and agent packaging." |
| 3 | D1 | Scope Architecture One-Pager v5
F0BRY9CFL73 | "Day 1 — The 4-category model. Understand the 56% number. This is the core negotiation artifact." |
| 4 | D2 | Weekly Sync Jul 7 (SOC for AI reframe)
F0BFWKW7JKW | "Day 2 — Kishore reframed SOC for AI. Pay attention to what changed and why." |
| 5 | D2 | Design Work Session Jul 10
F0BG5QE6P0F | "Day 2 — The PoC presentation. Study Deloitte's reaction and the asks Tony made." |
| 6 | D2 | Scope Delineation v1→v5 (all versions)
F0BRWPVV5MX → F0BRPT99YR1 | "Day 2 — Read ALL five versions. Focus on what changed between each one and why. This teaches the methodology." |
| 7 | D3 | Biweekly Program Session Aug 4
F0BNNLJJ277 | "Day 3 — Three priorities, Swimlane timeline, MCP choke points. The operating picture." |
| 8 | D3 | SOC for AI + Scope Alignment Aug 17
F0BQYHT958E | "Day 3 — Tony's pitch to Deloitte. Study how scope was framed and what commitments were made." |
| 9 | D4 | Portfolio Meeting Aug 10
F0BPAB7852P | "Day 4 — Leadership-level view. Signals about renewal and expansion." |
| 10 | D4 | Swimlane Check-in Aug 19
F0BR68U644X | "Day 4 — Latest technical status. What progressed, what's blocked." |
| 11 | D4 | Deloitte Delivery — Priority Projects
F0BRJPXCEA1 | "Day 4 — Current priority projects with status. The operating picture Tony shared with the team." |
| 12 | D5 | Net New Revenue Audit Trail
F0BR2P1NVU1 | "Day 5 — The evidence package proving scope as net new revenue. 8 meetings, May 7 → Aug 17." |
Step 4 — Upload Transcripts to #onboarding-abed
Same base corpus as Cassio (shared meetings), plus technical artifacts. Different context messages to orient toward engineering/QA.
| Order | Day | File to Share | Context Message When Sharing |
|---|
| 1 | D1 | Deloitte In-Person May 7 Part 1
F0BGZUYR64E | "Day 1 — The foundational meeting. Focus on technical mentions: agent architecture, platform capabilities, integration points." |
| 2 | D1 | Deloitte In-Person May 7 Part 2
F0B8U2Y9WUU | "Day 1 — Continuation. Focus on IK as a technical concept: how compound learning works through use." |
| 3 | D1 | CDA Feature Roadmap (from #deloitte-soc-for-ai artifacts) | "Day 1 — The 4 pillars and 6 features. This is the technical backbone. Memorize what's LIVE vs in progress." |
| 4 | D2 | Weekly Sync Jul 7 (SOC for AI reframe)
F0BFWKW7JKW | "Day 2 — SOC for AI reframed: platform governance, not shadow AI discovery. Technical pivot point." |
| 5 | D2 | Design Work Session Jul 10
F0BG5QE6P0F | "Day 2 — Victor's PoC presented. Study the technical assessment: what works, what's 'lightweight proof.'" |
| 6 | D2 | Scope Delineation v5 backup doc
F0BRPT99YR1 | "Day 2 — Focus on technical classifications: which requirements are Existing vs Accelerated vs Net New. This is what you'll audit." |
| 7 | D2 | Kindo vs Security Partners Venn Diagram
F0BPMSWQE0P | "Day 2 — Kindo = control plane. Palo Alto/CrowdStrike = inspection layer. Understand the distinction." |
| 8 | D3 | Biweekly Program Session Aug 4
F0BNNLJJ277 | "Day 3 — Technical priorities: Agent Observability, MCP retry loops, Deterministic Flow Control." |
| 9 | D3 | SOC for AI on CDA Architecture Map
F0BPZC5ARC5 | "Day 3 — How SOC for AI sits on the CDA platform architecturally." |
| 10 | D3 | Capability Comparison — SOC for AI Appendix
F0BQ0GU5N9L | "Day 3 — Kindo vs competitors side-by-side. What we do that others don't." |
| 11 | D4 | Swimlane Check-in Aug 19
F0BR68U644X | "Day 4 — Latest engineering status. What's blocked, what's progressing." |
| 12 | D4 | Deloitte Delivery — Priority Projects
F0BRJPXCEA1 | "Day 4 — Priority projects with status. Cross-reference against what you found in Linear." |
| 13 | D5 | SOC for AI — Answer First presentation
F0BQLLBD799 | "Day 5 — How Tony frames technical deliverables for Deloitte. Study the presentation format." |
Step 5 — Pin Key References
Pin these in each channel so they're always accessible:
- Both channels: Pin the opening message + link to curriculum page (
vtkl-onboarding.pages.dev)
- #onboarding-cassio: Pin the scope architecture one-pager (v5) — his core reference artifact
- #onboarding-abed: Pin the CDA Feature Roadmap — his core reference artifact
Step 6 — Notify Warren
Once channels are created and materials uploaded, tag Warren in each channel:
Message to Warren in each channel:
"@Warren — this is [Cassio/Abed]'s onboarding channel. Materials are uploaded in study order. When [he] arrives, support his learning: answer questions about transcripts, pull Linear data on request, validate deliverables, and challenge weak reasoning. Curriculum is at vtkl-onboarding.pages.dev."
Step 7 — When Cassio/Abed Join Slack
- Add Cassio to
#onboarding-cassio + the 5 team channels (see admin checklist below)
- Add Abed to
#onboarding-abed + the 5 team channels (see admin checklist below)
- Tell each person: "Start in your onboarding channel. Read the pinned message. Follow the curriculum."
- That's it. The channel does the rest.
Victor — Admin Checklist Action Required
- Google Workspace (@vtkl.ai)
- Create
cassio@vtkl.ai
- Create
abed@vtkl.ai
- Share Joana's Drive folder with both:
drive.google.com/drive/folders/1qv2wmdxE3xK6o7pSI3qY5khMJNgmJAyJ
- Slack Workspace
- Invite both with @vtkl.ai emails
- Share user IDs with Warren → Warren adds to channels via API
- Channel Assignments (Warren handles)
| Channel | ID | Cassio | Abed |
|---|
| #all-vtkl | C07JHQCGJB1 | ✓ | ✓ |
| #deloitte-soc-for-ai | C0BPAN8NG1G | ✓ | ✓ |
| #deloitte-agents-design | C0BE4FG384U | ✓ | ✓ |
| #client-kindo | C0AN2C9064F | ✓ | ✓ |
| #client-kindo-deloitte-hub | C0BQ486ENR5 | ✓ | ✓ |
| #warren-review | C0B7WNV0134 | — | ✓ |
- Linear
- Add both as viewers (SOAR/Turbo Mode, Lifecycle Hooks, SOC for AI)
- Miro
- Share both boards (Deloitte Delivery + Capability Mapping)
Framework: "Narrowing the Latent Space" — Tony Wong, August 2026. Thesis: intention acts as the initiating collapse mechanism; AI renders according to the capabilities of the person interacting with it. Applied to onboarding as progressive context narrowing through structured study.
Operating system: WWTD Protocol (Tony, May-Jun 2026). WWJD methodology (extracted from Joana's v1→v5 scope delineation, Aug 2026).
Meeting corpus: 12 Deloitte-facing meetings from #client-kindo (C0AN2C9064F), #deloitte-agents-design (C0BE4FG384U), #deloitte-soc-for-ai (C0BPAN8NG1G). May–August 2026.
Generated: August 24, 2026 · Warren (OpenClaw) · VTKL