CJB Repo · Product Technical Intelligence
← Automations Brief NUNI Analysis Hub
Product Technical Intelligence · Mailchimp CJB · Executive Read

The CJB diagram is describing a 2024 architecture. The live engine is a Spring Boot + Numaflow re-platform that has decoupled from the Mailchimp monolith to power Freddie AI + Intuit CRM

A 7-layer forensic analysis of the Customer Journey Builder repos in github.intuit.com/crmmktg-mktauto + mailchimp-mcmktg. Headline: 7 of the 16 repos in the diagram you provided are archived; the customer-journey-builder UI repo is a 4-commit scaffold from March 2025; the actual customer-facing canvas isn’t in either of these orgs. Meanwhile, a parallel "C2" platform has been built — Java 21, Spring Boot 3, Numaflow on Kubernetes, OpenAPI-first, JaCoCo 85% — and per its own AGENTS.md is positioned as "the next-generation Automations platform for Intuit CRM marketing — decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products."
Window: May 2024 → May 13 2026
Repos analyzed: 13 (Java + TS + Python)
Framework: 7-Layer Forensic + AI Readiness
7 of 16
Repos in the diagram you provided are ARCHIVED — including the named "Backend journey service" (mc-customer-journeys), "Pre-built journey templates svc," and "Journey preview." The diagram describes the 2024 architecture.
4 commits
mailchimp-mcmktg/customer-journey-builder — labeled "Frontend builder UI" — has only 4 commits, all from a single day (March 3 2025), all from automation/scaffolding bots. It’s never been written.
85%
JaCoCo line-coverage gate enforced in automations-platform, automations-numaflow, automations-rec-api. Layer 3 is the strongest in the brief — the new platform ships with quality gates the editor team doesn’t have.
Java 21
Spring Boot 3 · OpenAPI-first · Numaflow on Kubernetes · Valkey · SQS FIFO · DynamoDB (planned). Modern stack, current LTS, room for AI integration via documented MCP-pattern automations-agent.
Headline finding for the executive committee

The CJB story is the inverse of the NUNI editor story. NUNI: well-architected library, undermaintained UI, drifting between layers. CJB: the diagram describes an obsolete architecture, the customer-facing UI repo is a hollow scaffold, but the backend is being re-built from scratch as a paved-road, AI-ready, Intuit-wide platform — and that re-platform is being framed externally as Mailchimp CJB while internally repositioning as the shared automation engine for Freddie AI, QuickBooks CRM, and "future Intuit products." This is not a tech-debt story. It is a strategic asset reframing. The most important thing for Mailchimp leadership to know about CJB’s codebase right now is that it is no longer just a Mailchimp codebase.

AThe six things you need to know in 90 seconds

1 · The diagram you provided is the archived architecture

Live state of the 16 repos in the image, as of May 13 2026:

  • ARCHIVED mc-customer-journeys (Java, "Backend journey service") — last push Jan 24 2025, 16 months ago.
  • ARCHIVED prebuilt-journey-service (Go) — last push Jul 31 2024, 22 months ago.
  • ARCHIVED journey-preview-ui (JS) — last push May 22 2024, 24 months (2 years!) ago.
  • ARCHIVED automation-worker, automation-filter, automations-event-gateway, contact-execution-outbox.
  • SCAFFOLD ONLY customer-journey-builder (TS, "Frontend builder UI") — 4 commits, all from one day, all bots. Never written.
  • STALE trigger-designer — 6 months stale.
  • ACTIVE automations-platform, automations-numaflow, automations-rec-api, automationseventingest, marketing-automation-docs, cjboncall-skill.

2 · A new "C2" platform replaced everything that was archived

Per automations-platform/AGENTS.md, the new architecture has three layers:

  • Configuration — workflow CRUD/lifecycle (automations-platform; "absorbed from automation-interface").
  • Ingestion — Numaflow Kubernetes pipeline (automations-numaflow) consuming 13+ trigger types from EventBus/Kafka; SpEL-based filtering; Valkey-cached trigger settings.
  • Processing — SQS FIFO + DynamoDB router + stateless Executors per step type (Action, Condition, Delay, Wait-for-Trigger).

Plus c2-journey-initiation (the trigger-event-processor — proto package was just renamed last week from cjprocessing to triggereventprocessor in MCAUT-8639). The architecture is actively being shaped, not done.

3 · This is no longer just a Mailchimp codebase

The automations-platform AGENTS.md is explicit: "the next-generation Automations platform for Intuit CRM marketing — decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products." The org name crmmktg-mktauto reflects this — it’s the Intuit "CRM Marketing / Marketing Automation" group, not a Mailchimp team. This repositions CJB from a Mailchimp feature into a shared Intuit asset — explains the heavy investment, the modern stack, the consolidation of legacy services, and (importantly) why the customer-facing UI work isn’t happening here.

4 · The new backend ships with the quality gates the editor doesn’t have

What I found in the active core, vs the editor analysis:

  • JaCoCo 85% line + 50% branch coverage enforced in CI on automations-platform, automations-numaflow, automations-rec-api. (NUNI editor UI: 16.7% test ratio, no enforcement.)
  • OpenAPI-first — REST API generated from app/api/openapi/openapi.yaml; controllers implement generated interfaces. Schema is the source of truth.
  • AGENTS.md + CLAUDE.md in repo root on automations-platform and automations-numaflow — agentic-development discipline documented.
  • Conventional commits with MCAUT-XXXX Jira scope on every active backend repo.
  • Median PR cycle time on automations-numaflow is 0.5 hours (8× faster than NUNI editor UI).

5 · The customer-facing journey-builder canvas is missing from this org tree

I checked every TS repo in crmmktg-mktauto and mailchimp-mcmktg for a journey-canvas library (react-flow, @xyflow/react, reactflow, @hello-pangea/dnd for nodes/edges). None of the active TS repos has a flow-canvas dependency. The active TS UIs in crmmktg-mktauto are:

  • automations-builder (345 KB, just bumped to v1.1 with a pnpm switch April 13) — a config UI, not a canvas.
  • control-panel-web-plugin (285 KB, v1 shipped May 13) — a control panel with table/drawer/dropdown components.
  • trigger-designer (465 KB) — a YAML editor (uses js-yaml) for trigger configuration.

The actual customer-facing visual journey-builder canvas — the thing customers see when they click "Customer Journey" in Mailchimp — is presumably still living inside the legacy Mailchimp monolith, outside both these orgs. The "decoupling from the monolith" referenced in AGENTS.md applies to the backend, not yet the UI.

6 · Hero engineer concentration is even more extreme than NUNI

Per Layer 5 commit forensics across the active CJB backend (last 12 months):

  • bcraig (Bobby Craig): top-3 contributor on 4 of 5 active backend repos — #1 on c2-journey-initiation (375 commits, 65% share), #2 on automations-platform, #3 on automations-numaflow, #4 on automations-filter.
  • cmartin24 (Cliff Martin): top-3 on 5 of 8 repos including the entire active TS UI surface — #1 on automations-filter, #1 on control-panel-web-plugin, #1 on trigger-designer, plus contributor to c2-journey-initiation + automations-numaflow.
  • kferney: top contributor on automations-numaflow (286 commits, 33%).
  • amilt (Austin Milt): top contributor on automations-rec-api (136 commits, 60%) — the same engineer who closed the Brand Kit incident in the NUNI editor brief. Cross-product hero.

Two engineers (bcraig, cmartin24) carry the floor of the C2 platform. Bus factor on the FY27 Strategy commit ≈ 2 — same as NUNI editor.

BWhat this means for the Automations brief’s strategic bets

Strategy bet (from Automations 6-Pager)Code-readiness verdictWhat has to be true
Bet 1 · Sandbox-tier eval (let people try CJB on Free without a paywall)CONDITIONAL Backend can power it (the new stack has tenant isolation primitives via Intuit IAM). UI has to land somewhere.Confirm whether sandbox lives in the legacy monolith UI or migrates onto one of the new TS surfaces.
Bet 2 · Activation funnel (close the "10–20% capability used" gap from User Research)UI-DEPENDENT Recommendations engine is shipping in automations-rec-api (140 Java files, JaCoCo 85%, Austin Milt + sfagbemi). Backend ready.The customer-facing surface — where contextual nudges and weekly digest appear — still has no clear repo home. UI delivery is the bottleneck.
Bet 3 · B2B / ProServ template gap (vs. Customer.io)REPO-MISSING The original prebuilt-journey-service (Go) is archived; no replacement template-service repo found in crmmktg-mktauto.Where do new pre-built journey templates ship? If into the monolith, that’s the structural cause of the template gap. If into a new repo, it’s missing from the diagram.
Bet 4 · QBO integration (Intuit cross-product synergy)STRUCTURALLY ALIGNED The C2 platform is explicitly built for "Intuit CRM marketing" with Intuit IAM auth and JSK Spring Boot parent.This is the strategic reason the platform was decoupled from the monolith. Bet 4 is the platform’s justification, not a downstream dependency.
Bet 5 · "Reframe" CJB positioningCODE-LEVEL ALIGNED The repo names already reflect the reframe — automations-* not customer-journey-*; trigger-event-processor proto naming.Marketing narrative just has to catch up to the engineering reality.

CThree asks for the next engineering sync

  1. Surface the canvas-UI ownership decision. The customer-facing visual journey-builder UI is not in crmmktg-mktauto or mailchimp-mcmktg. Is it (a) in the legacy Mailchimp monolith and staying there, (b) being rebuilt as part of one of the Nova/Omni surfaces (mc-nova-ui, mc-omni-ui), or (c) on a separate roadmap entirely? The Bet 1/2/3 timelines all hinge on this answer.
  2. Confirm the C2 platform’s "decoupling" external messaging. The automations-platform/AGENTS.md wording ("decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products") is candid for an internal artifact but reads very different externally. If Mailchimp investors/analysts read this as "Intuit is consolidating Mailchimp’s automation engine into a shared Intuit asset," it changes the competitive narrative vs. Klaviyo. This is a comms-alignment ask, not an engineering one.
  3. Name a second-author across bcraig and cmartin24. The C2 backend is being shaped by two engineers, with package-renames as recent as last week. Bobby Craig has 65% commit share on the most-active repo. Pair both with a designated co-owner before Q3.

Method: All numerical findings derived from github.intuit.com/crmmktg-mktauto/* + mailchimp-mcmktg/* via shallow clone + gh api queries. Customer-pain references from the Automations Brief (HVC Risk Map, VOC, User Research, Product Health, Strategy 6-Pager). Framework: Product Technical Intelligence Playbook (May 2026, 20-page internal reference).

Architecture · How It Works · CJB / C2 Platform

How the CJB / C2 architecture is wired — an event-driven, three-layer platform with the customer-facing canvas living elsewhere

A two-page architectural walkthrough for executive read. Page 1: system diagram + how it works in 13 steps (split into setup and execution flows — CJB has both, unlike the editor). Page 2: customer (C1) workflow mapped step-by-step to specific repos.
Page: 1 of 2
Lens: Event-driven 3-layer platform + 4 satellite groups
Snapshot: May 13 2026

AThe architecture in one diagram

  CUSTOMER (browser · Mailchimp.com / Customer Journeys)
    │
    │  ⚠ The customer-facing visual journey-builder canvas IS NOT  in crmmktg-mktauto or mailchimp-mcmktg.
    │     customer-journey-builder repo is a 4-commit scaffold from
    │     March 2025; the actual UI is presumably still in the
    │     legacy Mailchimp monolith.
    ▼
  [LEGACY MAILCHIMP MONOLITH UI · OUTSIDE this org tree]
    │
    │  creates / edits journey config (HTTPS REST)
    ▼
  ┌─[1] CONFIGURATION LAYER  (workflow CRUD + Processing Executors)
  │     automations-platform  ·  Java 21 · Spring Boot 3 · 825 KB · today
  │     ├─ DAG Service  ── workflow CRUD/lifecycle
  │     ├─ OpenAPI-first (REST API generated from openapi.yaml)
  │     ├─ Stateless Executors:
  │     │     Action · Condition · Delay · Wait-for-Trigger
  │     └─ ⚠ DocumentService = ConcurrentHashMap (in-memory)
  │        → DynamoDB target, not yet wired (per AGENTS.md)
  │
  │     Auth: Intuit IAM ticket via JSK Spring Boot starter parent
  │     JaCoCo: 85% line / 50% branch (ENFORCED in CI)
  │
  │   writes config; reads cached trigger settings from Valkey
  ▼
  ┌── Valkey (Redis-compatible) ── trigger-settings cache
  │
  │
  ┌─[2] INGESTION LAYER  (event-driven · Kubernetes-native)
  │     automations-numaflow  ·  Java · Numaflow gRPC vertex · 2.13 MB · today
  │     ├─ Consumes 13+ Kafka EventBus topics:
  │     │     back-in-stock · contact-state-change · custom-events ·
  │     │     email-activity · loopback · monolith-relay · messaging ·
  │     │     payments-invoices · pixel · reviews · segmentation ·
  │     │     scheduled-event · testing
  │     ├─ SpEL filter expressions  (#flatten · #inList · #containsAny)
  │     ├─ Trigger matching against Valkey (Redis-comp)
  │     └─ Publishes AutomationTriggerEvents downstream
  │
  ▼
  ┌─[3] INITIATION LAYER
  │     c2-journey-initiation  ·  Java · Kafka + Valkey · 1.48 MB · 6d
  │     ├─ Consumes Kafka trigger topics
  │     ├─ In-memory batching · at-least-once delivery
  │     └─ Publishes batched events to Google Cloud Tasks
  │
  ▼
  ┌─[4] PROCESSING  (Executors run · per step · stateless)
  │     SQS FIFO + GCP Tasks  →  automations-platform Executors
  │     ├─ Action  ── send email/SMS/webhook
  │     │              ─→ [Mailchimp send pipeline · OUTSIDE this org]
  │     ├─ Condition  ── if/else split (up to 5 conditions)
  │     ├─ Delay  ── wait X time
  │     └─ Wait-for-Trigger  ── pause until next event

  ─── ADJACENT (parallel · supporting services) ───────────────────────
       automations-rec-api  (Java · 673 KB · 3 mo) ── recommendations
       automations-filter  (Java · 590 KB · today) ── pre-execution
       automationseventingest  (Java · 29 KB · today) ── tiny worker

  ─── DATA FOUNDATION (in mailchimp-mcmktg org) ──────────────────────
       cdp-segmentation  (Kotlin · 8 MB · today) ── CDP-grade segments
       c2-segmentation-ai-svc  (Python · 1.8 MB · today) ── AI segments
       audience-event-trigger  (Kotlin · 1.2 MB · 3 mo)

  ─── AI SURFACE (parallel · NOT in your repo diagram) ───────────────
       automations-agent  (Python · 175 KB · scaffold only)
       lil-kelly-agent  (Python · 373 KB · most-built)
       autobots-claude-tools  (Python · 153 KB · most recent)
       cjboncall-skill  (Shell · on-call automation)

  ─── INTERNAL UIs (NOT customer-facing) ─────────────────────────────
       automations-builder  (TS · 345 KB · v1.1) ── config UI
       control-panel-web-plugin  (TS · 285 KB · v1 today) ── admin/obs
       trigger-designer  (TS · 465 KB · YAML editor)
       marketing-automation-docs  (Docusaurus · 8.4 MB · today)

BHow it works — split into SETUP and EXECUTION flows

CJB has two distinct operational flows. Setup is what the customer does once when configuring a journey. Execution is what happens — potentially millions of times per day per customer — when contacts trigger that journey by their behavior.

SETUP — customer configures a journey (5 steps)

  1. Customer navigates to "Customer Journeys" in Mailchimp.com → routed to the visual journey builder. Critical note: this canvas lives in the legacy Mailchimp monolith, not in crmmktg-mktauto. The customer-journey-builder repo in mailchimp-mcmktg is a 4-commit scaffold from March 2025 — never written into. The canvas-UI ownership question is the single biggest non-technical risk in this brief.
  2. Customer drags a "Starting Point" (trigger) onto the canvas — for example, "When contact signs up." The monolith UI's selection of trigger types maps to one of the 13 typed Kafka topic schemas defined in automations-numaflow/transformer-config.yml.
  3. Customer adds steps — Action (send email), Condition (if/else split, up to 5 conditions), Delay (wait X time), or Wait-for-Trigger (pause until next event). Each step is typed to one of the 4 stateless Executors in automations-platform.
  4. Customer saves the journey — the workflow DAG is sent (via REST) to automations-platform's DAG Service. In production today, the persistence layer is ConcurrentHashMap (in-memory) per AGENTS.md — DynamoDB is the target but not yet wired. The new platform is not yet at production scale; the legacy monolith still owns most of the persistence.
  5. Trigger settings are written to Valkey (Redis-compatible cache) — the runtime lookup table that the ingestion layer reads during execution.

EXECUTION — when a contact triggers the journey (8 steps)

  1. Contact signs up on the customer's Shopify store (or any other event source). Shopify webhook → Mailchimp's EventBus → a Kafka topic (e.g. contact_state_change).
  2. automations-numaflow consumes the Kafka event in its corresponding eventdriven/ domain handler. It runs an SpEL filter expression against the event to determine whether it might match an active trigger.
  3. If the filter passes, automations-numaflow looks up active trigger settings in Valkey, evaluates the SpEL triggerMatching.expression, and — if matched — publishes an AutomationTriggerEvent to a downstream Kafka topic.
  4. c2-journey-initiation consumes the trigger event and batches it in memory with at-least-once delivery semantics. It publishes batched events to Google Cloud Tasks, which routes via AWS SQS FIFO to the Processing layer.
  5. The Processing layer in automations-platform picks up the batched event and runs the Executor for the journey's first step:
    • Action — sends the email/SMS/webhook (calls Mailchimp send pipeline, outside this org)
    • Condition — evaluates the if/else split (potentially calling cdp-segmentation for segment data)
    • Delay — schedules a wake-up event after X time and releases the contact from active processing
    • Wait-for-Trigger — pauses the contact until another matching event arrives
  6. Action steps that send email/SMS call out to the Mailchimp send pipeline (outside this org tree) — the same pipeline NUNI's editor outputs land in. The two products converge at the send pipeline.
  7. Adjacent services contribute during execution: automations-rec-api provides predictions/recommendations; automations-filter applies pre-execution filtering; automationseventingest is the tiny specialty event-ingest worker.
  8. Reporting — each Executor emits events for analytics; data flows to the Mailchimp data warehouse (outside this org). AI surface (not yet customer-facing): automations-agent + lil-kelly-agent + autobots-claude-tools are scaffolded; OpenAPI workflow CRUD is ready to be exposed as MCP tools — the foundation for autonomous flow setup parity with Klaviyo Marketing Agent.

Architecture lens: Event-driven 3-layer platform (Configuration / Ingestion / Processing) per automations-platform/AGENTS.md and automations-numaflow/AGENTS.md. Setup and execution flows are intentionally separated because CJB scale is determined by execution, not by setup. Per-repo evidence consistent with the 7-Layer Forensic tab and Repo Map.

Architecture · How It Works (cont.) · CJB / C2 Platform

The customer (C1) workflow mapped to repos — setup phase + execution phase

Page 2: every step the customer takes — and every code path that runs when their contacts trigger the journey — mapped to specific repos and architectural components.
Page: 2 of 2
Persona: SMB marketer on Shopify · setting up a welcome series

CSETUP phase — customer creates the journey (one-time)

# What the customer does What happens in code Repos involved
1Click "Customer Journeys" in MailchimpMailchimp shell routes to the journey builder. The canvas itself lives in the legacy Mailchimp monolith — not in crmmktg-mktauto.(legacy MC monolith UI)
2Pick a journey template (e.g. "Welcome series")Template loaded from monolith template store. The new architecture has no replacement repo for the archived prebuilt-journey-service — Strategy Bet 3 (B2B/ProServ template gap) is structurally homeless.(legacy MC monolith)
3Drag a Starting Point: "When contact signs up"Trigger config maps to one of 13 Kafka topic schemas in automations-numaflow/transformer-config.yml. The monolith UI POSTs the trigger config to automations-platform's DAG Service via REST.(monolith UI) → automations-platform
4Add an Action step: "Send welcome email"Step typed to Executor.Action. Email content references the editor's document model (NUNI) — this is where the editor and journey product converge.automations-platform · (NUNI editor for content)
5Add a Delay step: "Wait 3 days"Step typed to Executor.Delay. Delay duration validated against business rules (max delay, etc.).automations-platform/Executors/Delay/
6Add a Condition step: "If purchased: send thank-you. Else: send reminder."Step typed to Executor.Condition (up to 5 conditions). Condition evaluation can reference cdp-segmentation for segment data.automations-platform · cdp-segmentation
7Save journeyWorkflow DAG persisted; trigger settings written to Valkey. Persistence is in-memory ConcurrentHashMap today; DynamoDB is the target.automations-platform · Valkey

DEXECUTION phase — when a contact triggers the journey (potentially thousands/sec)

# Event in the world Code path Repos involved
1Customer's contact signs up on ShopifyShopify webhook fires → Mailchimp EventBus consumes → publishes to Kafka topic contact_state_change.(Mailchimp EventBus → Kafka)
2Kafka event arrives at the platformautomations-numaflow Numaflow vertex consumes the topic in eventdriven/contactstatechange/ handler; runs SpEL filter expression to drop irrelevant events fast.automations-numaflow/eventdriven/
3Filter passes; trigger lookup runsLooks up active trigger settings in Valkey; evaluates triggerMatching.expression; if matched, publishes AutomationTriggerEvent downstream.automations-numaflow/service/ · Valkey
4TriggerEvent reaches initiation layerc2-journey-initiation consumes; batches in memory; at-least-once delivery semantics; publishes to Google Cloud Tasks.c2-journey-initiation
5Batch published to processing layerGCP Tasks routes to AWS SQS FIFO; FIFO ordering ensures step-by-step execution per contact.(Google Cloud Tasks · AWS SQS FIFO)
6Step 1 runs: Action (send welcome email)Executor.Action picks up the message; calls Mailchimp send pipeline with the rendered email content.automations-platform/Executors/Action/ → [send pipeline]
7Step 2 runs: Delay (wait 3 days)Executor.Delay schedules a wake-up event 3 days out; releases the contact from active processing memory.automations-platform/Executors/Delay/
83 days later, wake-up firesWake-up event flows back through the pipeline; next step runs.automations-platform · Valkey · GCP Tasks
9Step 3 runs: Condition (purchased?)Executor.Condition evaluates condition; if it depends on segment data, calls cdp-segmentation or queries the contact profile via automations-rec-api.automations-platform · cdp-segmentation · automations-rec-api
10ReportingEach step emits events for analytics; data flows to the Mailchimp data warehouse (outside this org).(data warehouse outside org)

EWhat this architecture promises the customer

The contract that works (or will work after cutover)

  • "My trigger fires when it should" — the new ingestion architecture (SpEL filters + Valkey + at-least-once delivery + SQS FIFO) is structurally designed for trigger reliability.
  • "My emails go in the right order" — SQS FIFO ordering ensures Step 1 runs before Step 2 per contact.
  • "My condition splits work" — typed Executor pattern with up to 5 conditions per Condition step; evaluation against segment data via cdp-segmentation.
  • "The platform scales to my traffic spikes" — Numaflow Kubernetes vertex pipeline is horizontally scalable by design; in-memory batching in c2-journey-initiation absorbs bursts.

The contract that’s leaking (or hasn’t cut over yet)

  • "My abandoned-cart trigger doesn’t fire twice" — leaks while customers are still on the legacy monolith trigger paths; fix is shipping but cutover timing determines when customers feel it (HVC #4, $8.4K/mo cited).
  • "My journey persists reliably" — leaks because automations-platform's DAG Service is still ConcurrentHashMap (in-memory). Cannot be production at scale until DynamoDB lands.
  • "I get B2B/ProServ templates" — leaks because the template service repo (prebuilt-journey-service) is archived with no replacement found (Strategy Bet 3 structurally homeless).
  • "I get push and WhatsApp like Klaviyo" — leaks because no Push/WhatsApp/In-app Executor exists in the active code (channel breadth is structurally blocked).
The architectural read for leadership

The CJB architecture is a genuinely-modern, paved-road, AI-ready event-driven platform — Spring Boot 3 + Numaflow on Kubernetes + OpenAPI-first + 85% JaCoCo gates + Valkey-cached triggers + at-least-once delivery. The strategic value of the architecture is quality posture; the customer doesn’t see it directly, but trigger reliability and journey execution at scale will. Two non-technical questions precede every Q1–Q5 strategy bet: (1) where does the customer-facing visual canvas live (because the named repo is a hollow scaffold and it’s presumably still in the monolith), and (2) what is the external messaging plan for the "decoupled from the Mailchimp monolith" repositioning (because the AGENTS.md statement is candid for an internal artifact but reframes the CJB-vs-Klaviyo narrative externally). Code answers are ready; business answers are not.

Cross-references: See Pain → Code Map for HVC theme → repo traceability · Repo Map for archived-vs-active reconciliation · 7-Layer Forensic for layer-by-layer evidence · AI Readiness for the 5/7 scorecard · Arch Review · SWOT for the strategic SWOT.

Phase 2 · Customer Pain → Code Mapping (Playbook §4)

Every CJB customer complaint in the Automations brief traced to the live (or missing) repo

The playbook’s "superpower phase" applied to CJB. Each row pairs a documented customer pain (from the Automations brief — VOC, $53.5K/mo HVC cited MRR, UR Discovery table, Product Health) with the most-probable repo, evidence, and metric to move. Several rows reveal the customer pain is unowned in the new architecture — a critical finding for the strategy.
Source: Automations brief tabs 2–6 + repo evidence
Coverage: All 7 hate themes + 11 HVC themes
Customer complaint (VOC / HVC / UR / Health)
Likely system component (live repo)
Repo evidence collected
Business metric to move
VOC #1 PAYWALL · "Free plan gutted June 2025; Standard $20+/mo for any multi-step automation." Largest single brand-decay narrative. Drives churn to MailerLite / Brevo / EmailOctopus.
[Pricing-tier check
likely in the legacy
Mailchimp monolith,
NOT in crmmktg-mktauto]

automations-platform
(uses Intuit IAM auth)
The new C2 architecture uses Intuit IAM ticket auth (per automations-platform/AGENTS.md). Tenant tier-checking for sandbox eval (Strategy Bet 1) would happen at the API gateway layer, NOT inside the Java services. Pricing posture is a monolith-side decision; the new platform doesn’t enforce it. If leadership wants to ship a sandbox tier (Bet 1), the technical blocker is in the monolith’s billing routing, not in C2.
CJB Established 132K → 200K+ (Strategy Bet 1)

Free→Paid conversion path restoration

+$3–6M ARR per Strategy 6-Pager
VOC #2 ABANDON-CART RELIABILITY · "abandoned-cart trigger doesn’t fire / fires twice." HVC Theme 4 ($8.4K/mo cited). The single most-cited reliability pattern.
automations-numaflow
(eventdriven/
commerce/
back-in-stock/)

c2-journey-initiation
(in-memory batching)
automations-numaflow handles 13+ trigger types via SpEL filters; ecommerce events route through eventdriven/ domains. The "fires twice" pattern is exactly the deduplication concern the new architecture explicitly addresses — c2-journey-initiation’s in-memory batching with at-least-once-delivery semantics + Valkey trigger-state cache. The new architecture is designed to fix this; the legacy monolith path is what customers are still hitting. Migration cutover timing is the blocker.
HVC Theme 4 cited MRR cleared

CJB Established cohort retention

Direct link to Bet 4 (QBO ecom)
VOC #3 NO PUSH / WHATSAPP / IN-APP · "Email + SMS only." Klaviyo ships 5 channels in one canvas. Net-sentiment −44 in the Automations brief.
[Channel registry —
no repo named
channel-registry,
push-channel, etc.
found in either org]
No active repo in crmmktg-mktauto or mailchimp-mcmktg mentions push, whatsapp, or in-app in its name. The automations-numaflow 13 trigger-domain list covers events that go IN (back-in-stock, email_opens, contact_sends_msg, etc.) but not actions that go OUT (channel sends). Channel send is an Executor concern in the C2 Processing layer (automations-platform), but no Push/WhatsApp Executor exists in the active code today.
Strategy gap: ceding omnichannel narrative to Klaviyo through FY28

Bet for Push send action acceleration

(See NUNI brief P5.1.5 — same dependency)
HVC #5 / Health Finding 1 · CJB Established 132K (+18.4% YoY) but only 1.1% Free-tier adoption + 0.9% new-user adoption. The activation funnel is the largest single quantitative gap.
automations-rec-api
(Java, 140 files,
JaCoCo 85%)

automations-builder
(TS · v1.1)
automations-rec-api is the recommendations engine — Austin Milt + sfagbemi own 60% + 36% of commits respectively. 140 Java files, 72 test files (51% test ratio — tightest in the brief). This is the structural answer to "personalized template recommendations" and "next-best-journey" prompts that activation depends on. Backend is ready; the consumer UI surface that displays the recs is not yet identified in the active TS UIs.
Strategy Bet 2 (Activation funnel)

Free-tier adoption 1.1% → 5–8%

+$8–14M ARR per Strategy
UR Discovery · 5 customers with multi-year undiscovered features. UR Bet #2 (capability discovery + activation foundation).
[No in-app changelog
component visible
in active TS UIs]

marketing-automation-docs
(Docusaurus, 8.4 MB)
marketing-automation-docs is a Docusaurus site (docusaurus.config.ts + sidebars.ts) covering ingestion, automation-flows, classic-automations, infrastructure, oncall, nextgen, autoresponders, defunct-projects. It is internal-team documentation, not customer-facing. There is no separate "what’s new in CJB" service or weekly-digest component identifiable in the active TS UIs. The Strategy "Activation Foundation" pillar requires a from-zero customer-discovery surface — same finding as the NUNI editor brief P3.3 sub-pillar.
Capability utilization (today: 10–20% of CJB features used)

Silent-churn reduction
HVC compliance / billing pain · "Account blocks for compliance violations, slow resolution." Recurring complaint pattern.
[Compliance + billing
logic outside CJB org —
likely Mailchimp monolith
or Intuit Trust Platform]
No compliance, tcpa, gdpr, or billing-block repo in either active org. This is the same cross-org pattern as SMS in the NUNI editor brief — compliance enforcement is upstream of the automation engine. The C2 platform receives blocked-tenant signals via Intuit IAM but doesn’t own the compliance decision.
CSAT improvement

Cross-org dependency identified — escalation contact required for the strategy plan
HVC Trigger latency / "didn’t fire when it should have" · cited across multiple HVC themes. Trust in event-driven flow is the foundational complaint pattern.
automations-numaflow
(245 Java files, 110 test;
JaCoCo 85% line / 50% branch)

c2-journey-initiation
(54 Java files, 20 test)

automationseventingest
(6 Java files — TINY)
This is the cleanest "code is being built to fix this" story in the brief. The new ingestion architecture explicitly addresses trigger reliability: SpEL filtering in automations-numaflow + Valkey-cached trigger settings + at-least-once delivery in c2-journey-initiation + 13 typed event domains. The 0.5h median PR time on numaflow + 85% JaCoCo gate means the team is shipping reliability work fast and with discipline. Cutover from monolith trigger paths → C2 ingestion is the migration timeline that determines when customer-side trust returns.
Trigger latency p95 reduction

"Did the flow fire?" support tickets

Direct link to L5 retention save
UR / Strategy "Predictive triggers" · Klaviyo’s next-order-date and Channel Affinity are decisive vs Mailchimp. Predicted CLV exists in MC but isn’t a first-class flow trigger.
automations-rec-api
(predictions service)

c2-segmentation-ai-svc
(Python, 1812 KB)

cdp-segmentation
(Kotlin, 8031 KB)
This is the most-investment area outside the active core. cdp-segmentation is 8 MB of active Kotlin (last push today, May 13 2026) — a Customer Data Platform-grade segmentation service in the Mailchimp-mcmktg org. Plus c2-segmentation-ai-svc (Python AI/ML) and cdp-segmentation-deployment (4.1 MB of deploy infra). The CDP-grade data foundation Klaviyo has natively is being built in parallel with C2. Not in the diagram you provided.
Strategy Bet 4 (QBO integration) data foundation

Predictive trigger productization (parity with Klaviyo)

+$5–8M ARR upside
VOC AI / Intuit Assist · "AI-generated journeys" is gated to Standard+ US-first. International users feel sold a partial product. (Same pattern as Editor brief Write with AI.)
automations-agent
(Python, 175 KB,
1 commit — scaffold)

lil-kelly-agent
(Python, 373 KB)

autobots-claude-tools
(153 KB)
Three AI-agent repos exist but are early-stage: automations-agent has agents_and_tools.yaml (MCP-style tool registry), JenkinsfileAgenticStage.snippet, .cursorrules, .windsurfrules — all the agentic-CI scaffolding — but only 1 svcdoaadmin commit (initial scaffold, never written into). lil-kelly-agent is more mature (373 KB, last push Apr 13 2026). autobots-claude-tools (May 11) is most-recently-pushed but small. The agentic surface for CJB AI features is being staked out but not yet shipped at customer scale.
Strategy Bet 5 (positioning reframe — "AI ships journeys, not a demo")

L6 ARPU lift
VOC "Contact tax" billing · charging for unsubscribed/cleaned/duplicate contacts inflates real cost 20–40%. Cited in Automations VOC brief as ongoing reputational damage.
[Billing/contact-counting
outside CJB org —
Mailchimp monolith
or Intuit billing platform]
Cross-org dependency. The C2 platform’s tenant model uses Intuit IAM tickets for auth, but contact-counting for billing is a billing-platform decision. Same pattern as compliance + pricing-tier — the C2 platform is downstream of these monolith decisions.
Brand sentiment recovery

Counter-positioning vs Klaviyo Feb ’25 active-profile billing damage
UR "Classic Automation deprecation" pain · June 2025 retirement of Classic Automations on Free was the loudest single anti-Mailchimp narrative of 2025–26.
marketing-automation-docs/
docs/classic-automations/

marketing-automation-docs/
docs/defunct-projects/
Docs site has both a classic-automations/ doc folder AND a defunct-projects/ folder. The defunct-projects directory is a self-aware archive of retired services. The Classic Automations product is documented as a transition path, not a current capability. Internal codebase is honest about the deprecation; external customer experience hasn’t recovered from it.
Free-tier reactivation (Strategy Bet 1)

SMB acquisition funnel reopening

BPattern recognition (Playbook §4.2) — what concentrates in one place

Pattern 1 · The customer-facing UI is the missing dimension

Five of eleven mapped customer pains ($53.5K/mo aggregate cited) point to a customer-facing UI surface (canvas, sandbox, in-app changelog, AI sidebar, weekly digest). None of those surfaces is identifiable in the active TS UIs of crmmktg-mktauto or mailchimp-mcmktg. The C2 platform’s decoupling story is real, but it’s a backend decoupling. The customer-facing UI is either still in the legacy monolith (most likely) or being absorbed into one of the broader Nova/Omni surfaces (mc-nova-ui, mc-omni-ui) that aren’t in the diagram. Strategy bets 1, 2, 3 all hinge on this ownership being clarified.

Pattern 2 · The new platform is built to fix the bottom three customer pains

Trigger reliability (Pain #2 — abandoned-cart fires twice), event-driven flow trust (Pain #7 — "didn’t fire when it should"), and predictive trigger depth (Pain #8 — vs Klaviyo) all map directly to the C2 architecture pieces being actively built. automations-numaflow + c2-journey-initiation + automations-rec-api + cdp-segmentation are specifically the four services that solve those four customer pains. The platform’s business case is clear from a code-evidence read alone.

Pattern 3 · Channel breadth is unowned in the new architecture

VOC’s loudest functional gap (no Push, no WhatsApp, no in-app) maps to zero active repos in the analyzed orgs. The automations-numaflow 13-domain trigger list is rich on inbound events but the C2 Processing-layer Executors that own outbound channel sends have no visible Push/WhatsApp/In-app implementation. This is a strategic ownership gap, not a tech-debt gap — until a team is named for non-Email/SMS channels, the omnichannel competitive narrative cannot be reversed.

Pattern 4 · Cross-org dependencies blunt three more customer pains

Pricing/paywall, contact-tax billing, compliance enforcement — three of the loudest VOC themes — all live outside crmmktg-mktauto. They’re Mailchimp monolith + Intuit billing-platform decisions. The C2 re-platform cannot fix the customer-facing pricing/compliance narrative on its own. Per playbook §1.1 these are "Org Dependency" / "Process Hard" types, requiring escalation contacts in partner orgs.

Sources: All repo facts from github.intuit.com/crmmktg-mktauto/* + mailchimp-mcmktg/* via shallow clone (depth=1) on master/main tips as of May 13 2026. Customer-pain references from HVC Risk Map ($53.5K/mo cited), Voice of Customer, User Research, Product Health. Framework: Product Technical Intelligence Playbook §4.

Phase 1 · Layer 1 · Architecture & Structural Health (Playbook §3)

The diagram is a snapshot of 2024 CJB. The 2026 reality is a three-layer C2 platform + parallel CDP segmentation build

A line-by-line reconciliation of the 16 repos in the image you provided against the live state of github.intuit.com/crmmktg-mktauto + mailchimp-mcmktg as of May 13 2026. Plus an inventory of the active repos that aren’t in the diagram.
Diagram repos: 16
Archived: 7
Active replacements: 9+

AThe diagram you provided — line-by-line reconciliation

Diagram layerRepo (per diagram)Live stateLast pushReality check
Frontend builder UImailchimp-mcmktg/customer-journey-builder (TypeScript)SCAFFOLDMar 3 2025Repo has 4 commits, all from one day, all from automation bots (svc-uxinfra-bot, svcdoaadmin). Never written into. Generated by Mobile Paved Road (Intuit’s scaffolding) and abandoned. The actual customer-facing visual journey-builder canvas is not in either active org.
Backend journey servicecrmmktg-mktauto/mc-customer-journeys (Java)ARCHIVEDJan 24 2025 (16mo)Archived. Replaced by the C2 architecture: c2-journey-initiation + automations-platform + automations-numaflow. The diagram is describing a service that no longer exists.
Pre-built journey templates svccrmmktg-mktauto/prebuilt-journey-service (Go)ARCHIVEDJul 31 2024 (22mo)Archived 22 months ago. No clear replacement repo found in either active org. Strategy Bet 3 (B2B / ProServ template gap) is structurally orphaned — there’s no service repo that owns "where new pre-built journey templates live."
Journey previewcrmmktg-mktauto/journey-preview-ui (JavaScript)ARCHIVEDMay 22 2024 (24mo)Archived 2 years ago. The preview surface is presumably either in the legacy monolith UI or absorbed into one of the new TS UIs (automations-builder / control-panel-web-plugin) — but neither has a "preview" sub-widget visible in the cloned source.
Trigger designercrmmktg-mktauto/trigger-designer (TypeScript)STALENov 21 2025Active but stale (6+ months without a push). Uses js-yaml — it’s a YAML editor for trigger configuration, not a full visual designer. Pairs with automations-numaflow/transformer-config.yml. Top contributor: cmartin24 (4 commits — quiet repo).
Shared automations runtimeautomations-platform, automations-numaflow, automation-worker, automation-workflows, automation-filter, automations-event-gateway, contact-execution-outbox, automationseventingest, automations-rec-apiMixed (see below)
Per-repo state of the "Shared automations runtime" group:
  • ACTIVE automations-platform (Java, 825 KB, push today) — the new core "Configuration + Processing" layer per AGENTS.md. Currently a paved-road starter: DocumentServiceImpl uses ConcurrentHashMap in-memory; will be replaced with DynamoDB.
  • ACTIVE automations-numaflow (Java, 2129 KB, push today) — the Numaflow K8s-pipeline ingestion layer; 245 Java files, 110 test files, 13+ event domains.
  • ARCHIVED automation-worker (Java) — last push Aug 4 2025.
  • ZOMBIE automation-workflows (Java, 128 KB, push Oct 24 2024 — 19 months stale, but not yet archived).
  • ARCHIVED automation-filter — singular form. Replaced by automations-filter (plural form, Java, 590 KB, push May 1 2026, ACTIVE — note rename from automation-filter to automations-filter reflecting the platform-level naming convention).
  • ARCHIVED automations-event-gateway (May 21 2025).
  • ARCHIVED contact-execution-outbox (TypeScript! — Dec 7 2025).
  • ACTIVE automationseventingest (Java, only 29 KB, 6 Java files, push May 4 2026) — small specialized event-ingest worker; created by aajanaku (only contributor, 2 commits).
  • ACTIVE automations-rec-api (Java, 673 KB, push Feb 12 2026) — recommendations/predictions engine, owned by amilt (Austin Milt) + sfagbemi.
On-call / docsmarketing-automation-docs, cjboncall-skillACTIVEMay 11, Apr 13 2026Both active. marketing-automation-docs is a Docusaurus 8.4 MB site with .claude/skills/cjboncall sub-skill — agentic on-call automation. cjboncall-skill is a Shell-based on-call helper. Internal-team facing.

Diagram coverage scorecard

  • Of 16 repos in the diagram: 7 archived, 1 scaffold-only, 2 stale (trigger-designer, automation-workflows), 6 active.
  • Of those 6 active: only 4 are central to the new architecture (automations-platform, automations-numaflow, automations-rec-api, automationseventingest); the other 2 are docs/on-call helpers.
  • The diagram’s #1 (Frontend builder UI) is a hollow scaffold; #2 (Backend journey service) is archived; #3 (Pre-built templates) is archived. The three named primary services in the diagram are all retired.

BThe repos that ARE in the new architecture but missing from your diagram

c2-journey-initiation · Java · 1,482 KB

The new "Backend journey service" replacement. Last push May 7 2026. Per its README: "high-performance Spring Boot microservice that processes automation trigger events from Kafka topics and efficiently batches them for downstream processing via Google Cloud Tasks. Async processing architecture with in-memory batching, while maintaining at-least-once delivery guarantees."

Stack: Java 21 + Amazon Corretto + Maven 3.8 + Kafka + Valkey + Rancher Desktop for local. Top contributor: bcraig (Bobby Craig) at 375 commits = 65% share. The proto package was renamed last week (May 7) from cjprocessing to triggereventprocessor in MCAUT-8639 — actively being shaped.

cdp-segmentation · Kotlin · 8,031 KB

The CDP-grade segmentation build that closes the Klaviyo data-foundation gap. Last push today. 8 MB of active Kotlin code. In mailchimp-mcmktg, not crmmktg-mktauto — sits next to cdp-segmentation-deployment (4.1 MB), cdp-segment-cloudstack, and cdp-segment-cloudstack-deployment. This is the Bloomreach / Klaviyo CDP-grade response that the Automations brief Loss Attribution called the structural ceiling.

Adjacent: c2-segmentation-ai-svc (Python, 1,812 KB, today) + c2-segmentation-ai-svc-deployment. The "C2" prefix is the consistent naming for the new platform generation.

mc-nova-* family · TypeScript · 5,777 KB

The "Nova" Mailchimp surface — possibly where the customer-facing journey UI is migrating. mc-nova-core (5.8 MB TS), mc-nova-ui (977 KB TS), mc-nova-svc (Python), mc-nova-docs (MDX), nova-core, nova-editor-sdk, nova-editor-ui. All in mailchimp-mcmktg. Active March–April 2026. None in the diagram.

The naming pattern (Nova) suggests a new Mailchimp-side product surface that consumes C2 backend services. Worth confirming whether the journey-canvas UI lives here.

automations-agent + lil-kelly-agent + autobots-claude-tools · Python

The agentic AI surface for CJB. Three Python repos with progressively more activity:

  • automations-agent (175 KB) — has agents_and_tools.yaml, JenkinsfileAgenticStage.snippet, .cursorrules, .windsurfrules. Only 1 commit (initial scaffold) — staked out, not yet built.
  • lil-kelly-agent (373 KB, last push Apr 13 2026) — more developed; the name suggests an internal codename ("Lil Kelly").
  • autobots-claude-tools (153 KB, last push May 11 2026) — most recent, smallest. Pattern matches NUNI’s mc-omni-mcp: an MCP-style tool registry surface.

automations-builder + control-panel-web-plugin · TS · 345/285 KB

The active TS UIs that DO exist in crmmktg-mktauto. Neither is the journey-canvas builder.

  • automations-builder — 1.1.0 just released (Apr 13). Yena Ku (yku01) made the pnpm switch last month. No react-flow, xyflow, or DnD libraries — this is a config UI, not a flowchart canvas.
  • control-panel-web-plugin — v1 UI shipped May 13 (today!) by Cliff Martin. Uses @hello-pangea/dnd + @ids-ts/table + @ids-ts/drawer — looks like an admin/observability control panel, not a customer-facing journey designer.

marketing-automation-docs · Docusaurus · 8,385 KB

The internal docs site. Has .claude/skills/cjboncall/ — a Claude Code skill for on-call. Doc folder structure: ingestion/, defunct-projects/, rss/, observability/, integrations/, getting-started/, automation-flows/, classic-automations/, infrastructure/, oncall/, nextgen/, autoresponders/. The fact that there’s a defunct-projects/ directory is itself a self-aware org-health signal — the team archives openly.

CThe C2 architecture — what AGENTS.md actually documents

[Mailchimp monolith / EventBus / Kafka] automations-numaflow — Ingestion layer (Java 21 + Spring Boot + Numaflow gRPC vertex) • 13+ event-driven domain handlers (back-in-stock, contact CDC, email activity, custom events, messaging, payments, pixel, reviews, segmentation, monolith-relay, internal loopback, scheduled/cron, synthetic testing) • SpEL-based filtering (transformer-config.yml) • Trigger matching against Valkey (Redis-compatible) cache • Publishes AutomationTriggerEvents → c2-journey-initiation c2-journey-initiation — Initiation layer (Java 21 + Kafka + Valkey) • Consumes Kafka trigger topics • In-memory batching, at-least-once delivery • Publishes batched events → Google Cloud Tasks downstream • Recently refactored: cjprocessing → triggereventprocessor automations-platform — Processing layer (Java 21 + Spring Boot 3.3.7) • DAG Service (workflow CRUD/lifecycle) — absorbed automation-interface • Router (SQS FIFO + DynamoDB — currently in-memory ConcurrentHashMap) • Stateless Executors per step type: Action · Condition · Delay · Wait-for-Trigger automations-rec-api + automations-filter + automationseventingest • Recommendations / predictions surface (rec-api: 140 Java files) • Pre-execution filtering (filter: 59 Java files) • Tiny event-ingest specialty worker (29 KB, 6 Java files) [Auth: Intuit IAM via JSK Spring Boot starter parent]

Architecture per automations-platform/AGENTS.md + automations-numaflow/AGENTS.md + c2-journey-initiation/README.md. Cross-references the unpublished Jira architecture proposal MCAUT-8247.

Sources: gh api repos/<repo> on each named diagram repo (16 lookups). gh api search/repositories?q=org:<org>+pushed:>2025-12-01 for active-replacement discovery (50+ repos enumerated across both orgs). Direct git log + commit-message reads for naming-rename evidence (MCAUT-8639 proto package rename, MCAUT-8290 pnpm switch, MCAUT-8335 control-panel v1 UI). Per-repo AGENTS.md + README.md + package.json + pom.xml reads from shallow clones.

Phase 1 · Repo Deep Dive (Playbook §3)

Seven-layer forensic analysis on automations-platform, automations-numaflow, c2-journey-initiation, automations-rec-api, automations-filter

Each of the seven layers from the playbook’s Phase 1 framework, applied to the active CJB backend core. Comparison column included where it provides useful contrast with the NUNI editor brief.
Layers: 7
Repos in scope: 5 active backend core + 3 TS UIs
L1
Layer 1 · Architecture & Structural Health

Three-layer Spring Boot + Numaflow architecture, OpenAPI-first, paved-road parent. Every active service has the same skeleton.

What we found:

  • Consistent paved-road structure across all 5 active Java services. Each has app/api/openapi/, app/component/src/, app/integration/src/ + pom.xml + Jenkinsfile + Jenkinsfile.pci + KubernetesPods.yaml + msaas-config.yaml + local-keystore. This is Intuit’s "Java Skeleton" (JSK) Spring Boot starter parent. Operational commonality: any engineer can move between services without re-learning structure.
  • OpenAPI-first development. REST APIs are generated from app/api/openapi/openapi.yaml. Controllers implement generated *Api interfaces and delegate to a service layer. Schema is the source of truth, not the controllers. This is the playbook’s "Strong" pattern — versioning + contract testing become tractable.
  • Microservices boundaries match the documented architecture. Three layers: Configuration (automations-platform), Ingestion (automations-numaflow), Processing (Executors inside automations-platform). Plus c2-journey-initiation (the trigger-event-processor between ingestion and processing), automations-rec-api (recommendations), automations-filter (pre-execution filter), automationseventingest (specialized event-ingest worker).
  • God-file detection: 245 Java files in automations-numaflow with the largest cluster being the eventdriven/ directory (one subdirectory per of 13+ trigger types). No single file dominates; modularity is real. Nothing crosses the playbook’s 800-LOC threshold.
  • Async coordination architecture is documented: Numaflow gRPC vertex pipeline + Kafka topics (EventBus) + Valkey cache + SQS FIFO + Google Cloud Tasks. This is a real distributed-system architecture, not a monolith pretending to be microservices.
  • The "starter app" caveat: Per automations-platform/AGENTS.md, the service "is currently a paved-road starter (MSaaS reference app) — the platform components will be built here." DocumentServiceImpl uses ConcurrentHashMap in-memory; DynamoDB is the target but not yet wired. The Configuration layer is in early bring-up state.
  • TS UIs use a simpler shape: automations-builder, control-panel-web-plugin, trigger-designer, and the abandoned customer-journey-builder all use Intuit’s @appfabric/web-shell-core + plugin-cli structure (the TS equivalent of JSK). Same paved-road consistency on the frontend.
Strengths: JSK paved-road consistency, OpenAPI-first, 13 typed trigger domains, no god-class files, documented async architecture in AGENTS.md.
Risks: automations-platform Configuration layer is still a starter — DynamoDB persistence not yet wired. Cutover from monolith to C2 ingestion has migration timing risk. The Configuration layer’s in-memory ConcurrentHashMap would be a disaster in production scale.
L2
Layer 2 · Dependency & Security Posture

Java 21 + Spring Boot 3 + Renovate. Modern, current, and disciplined.

What we found:

  • Java 21 (Amazon Corretto) across all 5 active backend services. Current LTS. No legacy Java 8/11/17 carryover detectable.
  • Spring Boot 3.x via Intuit’s jsk-spring-boot-starter-parent — pinned through the parent, version-bumps coordinated centrally. automations-platform uses springdoc-openapi-starter-webmvc-ui 2.8.16 (current); the others on 2.8.5 (1 patch behind). Drift is minor and bounded.
  • Renovate is configured (every active repo has a renovate.json extending Intuit’s base configs).
  • TS UI deps mirror NUNI editor (and not in a good way): react@17.0.2, styled-components@4.4.1, prop-types@15.8.1, @design-systems/icons + @ids-ts/* + @appfabric/*. Same React 17 stale stack as nuni-core-ui. The Intuit web-plugin paved-road is itself anchored to React 17 — a tech-debt floor that affects every Mailchimp + Intuit TS UI.
  • Modern infra deps: Numaflow on Kubernetes (gRPC vertex), Apache Kafka, Valkey 8.0 (Redis-compatible), AWS SQS FIFO, AWS DynamoDB (planned), Google Cloud Tasks. This is a multi-cloud, modern stack — Mailchimp historically AWS-monolith; Google Cloud Tasks integration suggests Intuit cross-cloud strategy.
  • Auth via Intuit IAM ticket through the JSK framework (per automations-platform/AGENTS.md: "Real Intuit IAM ticket authentication via JSK framework. Not available locally.").
  • Local-dev tooling: Podman compose, Rancher Desktop, LocalStack for AWS local emulation, docker-compose-kafka.yml for Kafka, valkey container. Local dev is well-documented and reproducible.
Strengths: Java 21 current LTS · Spring Boot 3 · Renovate harness · OpenAPI-first contract testing · multi-cloud aware (AWS + GCP).
Risks: All TS UIs are React 17 + styled-components 4 (same Intuit paved-road floor as the editor) — any modernization decision compounds across both teams. The customer-journey-builder scaffold is the oldest version of @appfabric/web-shell-core (9.10.1 vs 9.98.0 on active repos) — proves the scaffold has been frozen since March 2025.
L3
Layer 3 · Test Coverage & Quality Infrastructure

JaCoCo 85% line coverage enforced in CI on the new platform. The strongest quality posture in the brief.

RepoJava filesTest filesTest ratioJaCoCo gateVerdict
automations-platform1213327.3%85% line / 50% branchGATE STRONG, FILES LIGHT
automations-numaflow24511044.9%85% line / 50% branchEXCELLENT
c2-journey-initiation542037.0%75% line / 50% branchSTRONG
automations-rec-api1407251.4%85% line / 50% branchEXCELLENT
automations-filter592440.7%5% / 5% (scaffold default)GATE NEVER TIGHTENED
automationseventingest6233.3%(default)TINY REPO
  • The 85% JaCoCo line-coverage gate is a real, enforced CI check on three of five active services. automations-platform/AGENTS.md states it explicitly: "JaCoCo enforces 85% line coverage minimum." This is 5× stronger than the NUNI editor UI’s 16.7% test/source ratio with no enforcement. Quality discipline on the new CJB backend is real.
  • Test file counts are healthy: automations-numaflow has 110 test files for 245 source files (44.9% file ratio); automations-rec-api has 72 for 140 (51.4%). Either category dominates the editor side.
  • Layer 3 hole: automations-filter has the 5%/5% scaffold default JaCoCo gate — never tightened to match the platform standard. This is the playbook’s "configuration debt" (Layer 7 anti-pattern surfacing in Layer 3): the gate exists, was never raised, every PR passes. Tighten the automations-filter JaCoCo gate to match the 85% standard.
  • Integration tests + perf tests: Each service has app/integration/ + perf-tests/ directories. automations-platform/AGENTS.md notes: "Gatling performance tests (currently broken upstream — see pom.xml)" — known issue, documented honestly.
  • OpenAPI lint + validation in Make targets: make openapi-validate, make openapi-lint, make openapi-view. Spec quality is a CI concern. Strong contract-driven discipline.
  • Synthetic event producer: synthetic-event-producer + synthetic-event-producer-deployment exist as live repos — load-testing infra is in production. Numaflow has a testing/ trigger domain dedicated to synthetic test events.
  • TS UIs: Each TS repo has a cypress/ directory and jest.config.js. Cypress is configured but not yet exercised at scale (the new TS UIs were just released v1).
Strengths: 85% JaCoCo gate enforced on 3 of 5 services · OpenAPI lint + validate in CI · synthetic event producer in production · integration test directories on every service.
Risks: automations-filter JaCoCo gate at scaffold default 5% — tighten. Gatling perf tests broken (acknowledged in AGENTS.md). TS UIs have Cypress configured but virtually empty.
L4
Layer 4 · Code Complexity Hotspots

No god-class files. Complexity is distributed across the 13-domain handler topology.

  • No source file in the active backend core crosses 800 LOC. The largest source files are within the eventdriven/ domain handlers in automations-numaflow (one sub-directory per trigger type — back-in-stock, contact-state-change, custom events, email activity, loopback, monolith-relay, messaging, payments-invoices, pixel, reviews, segmentation, scheduled-event, testing). Each domain has its own constants/handlers/transformers, keeping files small.
  • The 245 Java files in automations-numaflow are a topology, not a god-class: 13 trigger-type domains × roughly 4–6 files each (handler, transformer, config, optional repository) + shared services (TriggerMatcher, EventFilter, TriggerEventEnricher, ValkeyService) + util/ SpEL helpers. Decomposition is healthy.
  • Recent refactor evidence (Layer 4 churn × complexity): The cjprocessing → triggereventprocessor proto package rename in c2-journey-initiation (MCAUT-8639, May 7 2026) by bcraig shows the team is renaming for clarity even at the proto level. Healthy churn pattern.
  • Lombok is used everywhere (lombok.config in every Java service) — reduces boilerplate but introduces a build-time dependency. Standard Intuit/Mailchimp pattern.
  • OpenAPI generation hides "complexity" in generated code: Generated *Api interfaces and POJOs land in target/generated-sources/. Hand-written code is thinner because the spec generates the boilerplate. This is a Layer 4 win that the playbook would call "Strong" — controllers are pure delegation; testing surfaces are clean.
Strengths: No god files; 13-domain decomposition is the dominant complexity unit; OpenAPI generation thins controllers; recent renames show active hygiene.
L5
Layer 5 · Commit & PR Patterns (Velocity Forensics)

Backend velocity is the strongest in the brief — and dependent on 2 engineers.

RepoTop contributors (last 12mo)PR medianPR p95Verdict
c2-journey-initiationbcraig 375 (65%) · cmartin24 146 · kferney 211.5h18.0hSINGLE HERO (65%)
automations-platformjmoriarty 128 · bcraig 100 · jbrown47 300.8h67.8hDISTRIBUTED 3-of-N
automations-numaflowkferney 286 (33%) · bcraig 219 (25%) · cmartin24 85 · yku01 370.5h24.5hDISTRIBUTED 4-of-N
automations-rec-apiamilt 136 (60%) · sfagbemi 81 (36%)2-PERSON REPO
automations-filtercmartin24 106 (49%) · kferney 71 · bcraig 25 · mreich 14SINGLE LEAD
automations-builder (TS)yku01 3 · svc-uxinfra-bot 3 · svcdoaadmin 11.3h1.3hSINGLE-AUTHOR
control-panel-web-plugin (TS)cmartin24 3 · svc-uxinfra-bot 3 · svcdoaadmin 10.7h0.7hSINGLE-AUTHOR
trigger-designer (TS)cmartin24 4 · svc-uxinfra-bot 3 · svcdoaadmin 1SINGLE-AUTHOR
  • Backend velocity is dramatically faster than the NUNI editor side. automations-numaflow median PR cycle = 0.5 hours (vs NUNI editor UI median 7.1h with 692h p95). This team ships fast and merges fast.
  • Hero engineer concentration on the backend:
    • bcraig (Bobby Craig): top-3 on 4 of 5 active backend repos. Single most important engineer in the CJB code.
    • cmartin24 (Cliff Martin): top-3 on 5 of 8 repos including all three active TS UIs. Owns the entire active TS UI surface and is in the top of three backend repos.
    • kferney: top contributor on automations-numaflow.
    • amilt (Austin Milt): owns automations-rec-api at 60% commit share. Same engineer who closed the NUNI editor brand-kit incident — cross-product hero on two of Mailchimp’s most strategic surfaces.
    • jmoriarty: top on automations-platform — leads the C2 Configuration/Processing layer.
  • Service bots are healthy: svc-sbseg-ci appears as #2 contributor on every backend repo (200–240 commits — automated CHANGELOG updates and conventional-commits versioning). The CI/release harness is mature.
  • TS UIs are net-new and single-author: Each active TS repo has 3–4 commits from the lead human + 3 from the bot. They’ve just been bootstrapped; the development concentration is consistent with v1 launches.
  • Conventional commits with MCAUT-XXXX scope on every active backend repo. feat(MCAUT-8639): rename cjprocessing proto to triggereventprocessor is the most-recent commit type. Discipline is consistent.
Strengths: Backend velocity (0.5h numaflow median), conventional commits with MCAUT scope, distributed 3–4-of-N on the largest services, mature CI/release bots.
Risks: bcraig at 65% on c2-journey-initiation; cmartin24 owns all three active TS UIs single-handedly; amilt at 60% on rec-api while also owning Brand Kit on the editor side. Bus factor 1–2 across the entire active core, same as NUNI editor.
L6
Layer 6 · Performance & Error Handling

Async-first design with documented at-least-once semantics. Performance gates are real but Gatling is broken.

  • At-least-once delivery is documented and architected, not bolted on. c2-journey-initiation/README: "async processing architecture with in-memory batching, while maintaining at-least-once delivery guarantees." Numaflow vertex pipeline + Kafka + Valkey + SQS FIFO chain is built for this guarantee.
  • SpEL-based filtering with explicit helpers: automations-numaflow’s util/ directory provides custom SpEL helpers (#flatten, #inList, #containsAny) so filter expressions stay readable. This is an L6 win — error-prone string-comparison patterns are abstracted into helpers.
  • Circuit breaker / retry patterns: Need to confirm — Numaflow vertices typically inherit retry semantics from the platform; explicit Resilience4j or Polly-style circuit-breaker code wasn’t scanned. Worth a follow-up.
  • Health endpoints documented: Each service exposes /health and /health/full with self-signed certs locally. :8490/health is the management port. Operational maturity is real.
  • Performance tests: Each service has a perf-tests/ directory. AGENTS.md notes Gatling tests are "currently broken upstream — see pom.xml". Known issue, openly documented — but performance gates are not actually enforced today.
  • Synthetic event producer: synthetic-event-producer repo + testing/ trigger domain in numaflow + test-payloads/ directory + run-integration-tests.sh in automations-numaflow. Load-testable end-to-end.
  • Observability surface: marketing-automation-docs/docs/observability/ directory exists. The team has a documented observability practice (separate from this analysis to dive into).
  • Error swallowing: Spot-checks of service/ and repository/ files in automations-numaflow don’t show empty catch blocks — Lombok’s @Slf4j + structured Pino-equivalent logging via Spring is standard.
Strengths: At-least-once architected from the start, SpEL helper abstraction, health endpoints standardized, synthetic event producer in production, documented observability folder.
Risks: Gatling perf tests broken (acknowledged in AGENTS.md, not yet re-fixed). Circuit breaker patterns not verified in this scan. Performance regressions can ship without a performance gate catching them.
L7
Layer 7 · Feature Flag & Configuration Debt

Configuration is centralized in YAML and Make targets. Feature flags presumably ride at the API gateway layer.

  • Centralized configuration: automations-numaflow’s app/src/main/resources/transformer-config.yml is the central trigger-type configuration file. Topics, JSONPath mappings, SpEL filter expressions, and matching criteria all live in one place. This is the playbook’s "Strong" pattern — flag-controlled code paths don’t accumulate because the config IS the routing.
  • Test config mirrors prod: app/src/test/resources/transformer-config.yml must mirror production per AGENTS.md. Drift is caught at the test layer.
  • Make targets are the dev-flag harness: make dev-build-image, make dev-start, make dev-run, make dev-kill, make dev-shell, make test-unit, make test-coverage, make test-perf, make openapi-validate, make openapi-lint, make openapi-view, make dev-generate, make dev-generate-force. Every state transition is a make target. "It works on my machine" is structurally prevented by Podman compose + LocalStack + standardized health checks.
  • Feature flag scan: No featureFlag, launchDarkly, optimizely imports in the active Java services. Same finding as NUNI editor — flags presumably live at the API gateway / Intuit IAM layer, not in the service code. Worth confirming for incremental rollout of trigger-type cutover from monolith → C2.
  • Profile-based config: Spring profiles (local, e2e, prd) split auth + dependency wiring. application-local.yml is the local dev override. Standard pattern.
  • Stale flags: No flag-lifecycle process visible in source. The defunct-projects/ directory in marketing-automation-docs is the org-level proxy for "flag cleanup" — services get archived rather than flag-toggled into death.
Strengths: YAML-centralized trigger config (no flag-controlled code path explosion); Make targets standardize dev workflows; defunct-projects/ doc folder shows mature retirement discipline.
Risks: Same as NUNI editor — no editor-layer feature flag harness visible in service code. Cutover from legacy monolith trigger paths to C2 ingestion needs flag-gated rollout strategy; confirm the harness lives at the gateway.

Method: Each layer applied per Product Technical Intelligence Playbook §3 (Days 3–7 deep dive). Evidence collected via shallow-clone + find/grep/wc/jq against the latest tip of master/main. JaCoCo thresholds extracted from each app/pom.xml. Contributor and PR data from github.intuit.com REST API on May 13 2026.

Phase 3 · Organizational Failure Mode Analysis (Playbook §5)

The codebase tells a clear org story: a disciplined backend team in re-platform mode, a missing customer-facing UI owner, and a strategic identity shift from Mailchimp feature to Intuit platform

Six failure modes from the playbook §5, applied to CJB with repo evidence.
Failure modes assessed: 6
Failure mode 1 · Single approver bottleneck (hero engineer)

Two engineers (Bobby Craig + Cliff Martin) carry the C2 platform; Austin Milt is cross-product

  • bcraig top contributor on 4 of 5 active backend repos including 65% commit share on c2-journey-initiation.
  • cmartin24 sole non-bot human author on 3 of 3 active TS UIs and top contributor on automations-filter (Java).
  • amilt at 60% on automations-rec-api while also being the engineer who closed the Brand Kit incident in the editor brief — cross-product hero.
Likely root cause: Knowledge is concentrated by design — these are the technical leads who shaped the C2 architecture proposal (MCAUT-8247). The risk is not that they can’t deliver; the risk is reassignment, vacation, or attrition during the FY27 commit window. Bus factor on C2 ≈ 2.
Failure mode 2 · Engineers avoid certain areas (fear-driven engineering)

The opposite is happening here — but the legacy monolith path is the unowned area

  • The new C2 backend has JaCoCo 85% gates, OpenAPI-first, AGENTS.md, conventional commits, 0.5h median PR cycle — engineering discipline is high.
  • BUT: the legacy Mailchimp monolith CJB UI (where customers actually click "Customer Journey") is not in crmmktg-mktauto or mailchimp-mcmktg. Whoever still owns the monolith CJB code is shipping on a different cadence and standard.
  • Migration from monolith → C2 is the ownership gray zone — if neither team owns the cutover, the customer pain continues until cutover lands.
Likely root cause: The org has invested heavily in the new platform; the unsexy legacy migration glue is the work that doesn’t attract senior engineers. Confirm cutover ownership is named, with a single accountable PM and EM.
Failure mode 3 · Constant modernization talk, no customer value shipped

Customer value is being shipped — but the AI Surface is leading the editor surface, again

  • The C2 platform is shipping real customer value (trigger reliability via Numaflow + Valkey, JaCoCo-gated services, OpenAPI-first contracts).
  • BUT: the Strategy 6-Pager bets are customer-facing (sandbox tier, activation funnel, B2B templates, QBO integration, positioning reframe) — and the customer-facing UI surface has no clear repo home in the active code.
  • Three Python AI agent repos exist (automations-agent, lil-kelly-agent, autobots-claude-tools) but only lil-kelly-agent shows real development. The agentic future is staked out, not shipped.
Honest read: This is the playbook’s "modernization for engineer preference vs customer value" question, but the answer here is mostly fine — the modernization has clear customer-side justification (trigger reliability, scale). The risk is the customer-facing UI investment lagging the backend.
Failure mode 4 · Bugs never die / Features ship half-baked

The defunct-projects/ docs folder is org-level honesty about what was abandoned

  • marketing-automation-docs/docs/defunct-projects/ exists as a deliberate documentation folder — the team archives services and documents the archive openly.
  • 7 of 16 diagram repos are archived (not just stale — formally archived: true in GitHub). The team retires services rather than letting them rot.
  • BUT: archived services have customer-side surface area too. journey-preview-ui being archived 24 months means the preview surface has been frozen since May 2024 — customers are using a 2-year-old preview implementation.
Strength: Retirement discipline is real. Not common in SMB-tier engineering orgs.
Risk: If the customer-facing surface of an archived service is still live in production but unmaintained, that’s a Layer 6 reliability risk hiding in plain sight. Confirm journey-preview-ui code is decommissioned in production, not just in the repo.
Failure mode 5 · Everything depends on another team

Three of the loudest VOC themes (pricing, billing, compliance) live outside this org

  • Pricing tier checks for the Strategy Bet 1 sandbox-tier eval are a Mailchimp monolith / Intuit billing-platform decision.
  • Contact-tax billing model (charging for unsubscribed/cleaned contacts) is a billing-platform decision, not a CJB engine decision.
  • Compliance enforcement (TCPA, GDPR, account blocks) is upstream of the automation engine.
  • Customer-facing UI canvas (the actual journey-builder visual surface) is presumably in the legacy monolith or in mailchimp-mcmktg’s Nova/Omni surface — outside the C2 team’s direct ownership.
  • Channel breadth (Push, WhatsApp, in-app) — no Executor for these in the active code, suggesting cross-team or new-build needed.
Likely root cause: CJB sits in the middle of a 4-org dependency stack: Intuit billing/IAM → CJB engine → Mailchimp UI → Customer. The C2 platform is the middle layer; it cannot solve customer-facing pricing/UI/compliance pain alone. Each Strategy bet needs cross-org alignment.
Failure mode 6 · Strategic identity ambiguity

"Mailchimp CJB" externally / "Intuit CRM Marketing platform" internally — the AGENTS.md tells the truth

  • automations-platform/AGENTS.md: "the next-generation Automations platform for Intuit CRM marketing — decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products."
  • Org name: crmmktg-mktauto (Customer Relationship Management Marketing — Marketing Automation). Not a Mailchimp team.
  • Naming convention: services are automations-* not cjb-* or customer-journey-*. Even c2-journey-initiation just renamed its proto from cjprocessing to triggereventprocessor — explicitly de-CJB-ifying.
  • Auth via Intuit IAM (JSK Spring Boot starter parent), Google Cloud Tasks for downstream, Java 21 — the stack is Intuit-shaped, not Mailchimp-shaped.
Likely root cause: CJB’s engine is being repositioned as an Intuit-wide automation platform that powers Freddie AI, QuickBooks CRM, and Mailchimp. The customer-facing Mailchimp brand stays; the engine is becoming a shared asset. This is not a failure mode — it’s a strategic shift — but it explains why the customer-facing UI is no one’s priority in this org tree, and why the C2 team is shipping engine quality over UI features.
Phase 5 · AI Readiness Assessment (Playbook §7)

The CJB platform scores 5 of 7 ready signals; the agent surface is staked out but unfinished

Per the playbook’s 7-dimension AI readiness checklist (§7.1). Less ready than NUNI editor (which scored 7/7) but on a credible track.
Dimensions assessed: 7
Score: 5 Ready · 2 Partial
Readiness dimensionReady signalRepo evidenceVerdict
Workflow state structure Structured DAG / typed nodes OpenAPI-generated POJOs in automations-platform/app/src/main/java/.../models/ are Lombok-annotated typed classes. The "DAG Service" is the Configuration layer (workflow CRUD over typed entities). Workflow definitions are not yet flat strings — they’re typed graph objects. READY
Trigger-type semantics Semantic event types with metadata automations-numaflow’s eventdriven/ directory has 13 typed trigger domains (back-in-stock, contact-state-change, custom events, email activity, loopback, monolith-relay, messaging, payments-invoices, pixel, reviews, segmentation, scheduled-event, testing). Each domain has its own typed handler + transformer. transformer-config.yml maps source event → TriggerEvent IEDM schema. Strong type system. READY
Step-level CRUD operations Block-level / step-level CRUD The Processing layer in automations-platform declares stateless Executors per step type (Action, Condition, Delay, Wait-for-Trigger). DAG Service exposes workflow CRUD via OpenAPI. Step-level operations are first-class. READY
Workflow observability / event log Event bus / action log exists EventBus + Kafka + SQS chain captures every state transition. marketing-automation-docs/docs/observability/ exists as a documented practice. Numaflow vertices emit metrics natively. Structurally observable. READY
Machine-callable actions Clean API or command pattern OpenAPI-first: every CRUD operation is a typed REST endpoint. The Numaflow gRPC vertex pattern is explicitly machine-callable. Stateless Executors with pre/post validation match the playbook’s "command pattern" definition. The C2 platform is more machine-callable than the average automation engine. READY
Prompt / context access Trigger context + brand/audience accessible TriggerEventEnricher in automations-numaflow/service/ enriches events with context. cdp-segmentation (Kotlin, 8 MB, in mailchimp-mcmktg) provides segment context. BUT: these are not yet wired into the agent surface. automations-agent has agents_and_tools.yaml (MCP tool registry) but only a single scaffold commit — the wiring from rich context to AI prompt isn’t productized yet. PARTIAL
Safe state modification Pre/post validation, transactional OpenAPI schema validation + Lombok-annotated POJOs + JaCoCo 85% gate ensures mutations are typed. SQS FIFO with idempotency keys is the at-least-once delivery surface. BUT: automations-platform is still a starter; the in-memory ConcurrentHashMap persistence is not transactional in the production sense. DynamoDB target will provide it. PARTIAL
5/7 ready — what this means

The CJB platform’s schema, type system, observability surface, and command-pattern API are all in place. The two partial dimensions are shippable in the next quarter — DynamoDB persistence is on the roadmap (per AGENTS.md), and the agent-context wiring needs the automations-agent + lil-kelly-agent work to mature. The 5/7 score will become 7/7 around Q2 FY27, on the same timeline as the platform’s production hardening.

BThe agentic surface — three Python repos, three different stages

automations-agent · 175 KB · Python

Status: scaffold-only. Has the full agentic-CI scaffolding — agents_and_tools.yaml, JenkinsfileAgenticStage.snippet, .cursorrules, .windsurfrules, .coveragerc, pyproject.toml, tox.ini. Same paved-road template as NUNI’s mc-omni-mcp.

Only 1 commit from svcdoaadmin (initial scaffold). Last push Mar 10 2026. Staked out but never written.

lil-kelly-agent · 373 KB · Python

Status: actively developed. Last push Apr 13 2026 (1 month). Larger than automations-agent; has more substance. The "Lil Kelly" codename is internal — possibly named after a Mailchimp cultural reference or a team mascot.

This is the most-built CJB AI agent today. Worth a follow-up scan to identify its specific tools and integration surface.

autobots-claude-tools · 153 KB

Status: most recent. Last push May 11 2026 (2 days). Smallest of the three but freshest. The "claude-tools" naming suggests this is a Claude-specific tool registry (MCP server pattern).

Pairs with the cjboncall-skill repo + marketing-automation-docs/.claude/skills/cjboncall sub-skill — there’s a clear pattern of Claude-specific agentic tooling for the CJB on-call function. Internal-team-facing AI, not customer-facing yet.

CAI feature opportunity map (Playbook §7.2) — for the CJB Strategy

AI feature (Strategy alignment)Structural depsRepo readinessEstimated complexity
Predictive trigger productization (next-order-date as a flow trigger, parity with Klaviyo)Predictions service + trigger-type registryautomations-rec-api exists (140 Java files, 51% test ratio); add prediction → TriggerEvent transform in numaflowMedium — extend existing services
Conversational journey editing (NL → flow modification, parity with Klaviyo Marketing Agent)Workflow CRUD API + agent surface + brand contextOpenAPI workflow CRUD ✅; automations-agent needs to be written; cdp-segmentation for contextMedium-High — agent layer + UI sidebar
AI-driven anomaly detection (Klaviyo’s "Auto-Monitors" parity)Observability surface + alertingObservability docs exist; cjboncall-skill shows on-call AI is being built. Customer-facing variant is greenfield.Medium
Intelligent template recommendation (Strategy Bet 3 — B2B / ProServ)Template registry + customer profile + segmentTemplate registry repo is missing (prebuilt-journey-service archived, no replacement found). Recs API + segmentation are ready.High — template service is greenfield
Channel-affinity routing (Klaviyo parity, requires multiple channels)Multi-channel Executors + per-profile modelPush/WhatsApp/In-app Executors don’t exist; c2-segmentation-ai-svc ML readiness. Hardest gap — channel breadth must come first.Very High

Method: Each readiness dimension scored against playbook §7.1 using direct file reads from automations-platform/app/api/openapi/, automations-numaflow/app/src/main/java/.../eventdriven/, automations-platform/AGENTS.md, automations-numaflow/AGENTS.md, c2-journey-initiation/README.md. Agent surface enumerated via gh api search/repositories + direct repo metadata.

Architecture Review · 2-page Executive · Customer Journey Builder / C2 Platform

The CJB architecture is a disciplined backend re-platform with a missing customer-facing UI owner and a strategic identity shift the comms team hasn’t caught up to

A 2-page architectural assessment for executive read. Page 1: SWOT + quality-attributes scorecard. Page 2: Implications + final recommendation, tied to the customer problem in the Automations Brief and the FY27 5-bet Strategy 6-Pager.
Page: 1 of 2
Frameworks: SWOT + ISO/IEC 25010 quality attributes
Aggregate score: 4.0 / 5

ASWOT analysis — the architecture in one view

Strengths · what to build on

  • Modern, paved-road consistent backend stack. Java 21 (current LTS) + Spring Boot 3 + OpenAPI-first; 5 active services share the same jsk-spring-boot-starter-parent skeleton.
  • JaCoCo 85% line coverage gate ENFORCED in CI on automations-platform, automations-numaflow, automations-rec-api. 5× stronger quality posture than the editor side.
  • C2 platform is decoupled-from-monolith and AI-ready by design. Three-layer Configuration / Ingestion / Processing model with at-least-once delivery semantics. AGENTS.md documents architectural intent honestly.
  • Numaflow Kubernetes pipeline + Valkey-cached trigger matching = trigger reliability is structurally addressable. 13 typed event domains with SpEL filters; 0.5h median PR cycle on numaflow.
  • Conventional commits + MCAUT-XXXX Jira scope + svc-sbseg-ci service bots running automated CHANGELOG + version bumps. CI/release machinery is mature.
  • defunct-projects/ doc folder = retirement discipline is institutionalized. The team archives openly; 7 of 16 diagram repos formally archived.
  • Synthetic event producer in production + testing/ trigger domain — load-testable end-to-end.

Weaknesses · what is in our way

  • Customer-facing UI canvas is missing from the active org tree. customer-journey-builder repo is a 4-commit scaffold; no flow-canvas dep in any active TS UI. Strategy Bets 1/2/3 hinge on resolving this.
  • automations-platform Configuration layer is still a starter. DocumentServiceImpl uses ConcurrentHashMap in-memory; DynamoDB is target but not wired. Production at scale = blocked.
  • automations-filter JaCoCo gate at scaffold default 5% — never tightened. Platform’s quality story is inconsistent across services.
  • Gatling perf tests broken (acknowledged in AGENTS.md). Performance regressions can ship without a gate catching them.
  • Same React 17 + styled-components 4 stale stack on TS UIs as the editor. The Intuit paved-road web-plugin floor is shared tech debt across products.
  • Hero engineers carry both backend AND frontend. cmartin24 is sole non-bot author on all 3 active TS UIs while also being top contributor on automations-filter + #3 on numaflow.

Opportunities · what we should go after

  • C2 decoupling reframes CJB from Mailchimp feature → Intuit-shared automation platform. Massive strategic asset positioning per automations-platform/AGENTS.md: powers Freddie AI + QuickBooks CRM + future Intuit products.
  • AI readiness 5/7 → 7/7 in 1–2 quarters as DynamoDB lands and agent-context wiring matures (lil-kelly-agent + automations-agent + autobots-claude-tools).
  • Predictive trigger productization is a small-effort path to Klaviyo parity. automations-rec-api is ready (140 Java files, 51% test ratio); just productize predicted-next-order-date as a TriggerEvent type in numaflow.
  • cdp-segmentation (Kotlin, 8 MB, last push today) closes the Bloomreach/Klaviyo CDP-grade data foundation gap that the Loss Attribution called the structural ceiling.
  • OpenAPI workflow CRUD as MCP tools = autonomous flow setup parity with Klaviyo Marketing Agent in 2 weeks of agent work. Code is ready; agent layer needs writing.

Threats · what could hurt us

  • "Decoupled from the Mailchimp monolith" external messaging risk. Verbatim AGENTS.md wording could be read by analysts as Intuit consolidating Mailchimp’s automation engine into a shared asset. Changes the investor + competitive narrative.
  • 7 of 16 diagram repos archived = cutover timing exposure. Until trigger types migrate from monolith → C2 ingestion, customers feel the legacy reliability bugs.
  • No Push / WhatsApp / In-app Executor in active code = ceding omnichannel narrative to Klaviyo through FY28. Channel breadth is structurally blocked, not solvable on this timeline.
  • Cross-org dependencies cap what CJB can fix alone. Pricing (Free-tier paywall), contact-tax billing, compliance enforcement — three of the loudest VoC themes — live outside this org.
  • Template service repo orphaned. prebuilt-journey-service archived; no replacement found. Strategy Bet 3 (B2B / ProServ template gap) is structurally homeless.
  • Hero-engineer bus factor. bcraig 65% on c2-journey-initiation; cmartin24 sole human on all TS UIs; amilt at 60% on rec-api while also closing Brand Kit incidents on the editor. Three engineers carry the floor of two products.

BArchitecture quality attributes scorecard (ISO/IEC 25010 lens)

10 standard quality attributes scored 1–5 against repo evidence. Aggregate 4.0/5 — the strongest backend posture in this analysis pair, with the customer-facing UI being the single dimension dragging the score.

AttributeScoreVisualizationRepo evidence
Modularity5 / 5
13 typed trigger domains in numaflow/eventdriven/; OpenAPI-first; three-layer Configuration/Ingestion/Processing; per-domain handlers/transformers/configs.
Reliability gates4 / 5
At-least-once architected from start; SQS FIFO + idempotency; Valkey-cached triggers; OpenAPI lint + validate in CI.
Testability4 / 5
JaCoCo 85% on 3 of 5 services; integration test directories on every service; synthetic event producer in production. automations-filter at 5% gate is the outlier.
Maintainability4 / 5
JSK paved-road consistency; conventional commits with MCAUT scope; AGENTS.md + CLAUDE.md on the active core; defunct-projects/ docs folder.
Time-to-market for new triggers4 / 5
Typed trigger-domain pattern is clean; transformer-config.yml centralizes routing; new trigger = new sub-directory + handler/transformer/config.
Security posture4 / 5
Intuit IAM ticket auth via JSK; OpenAPI schema validation; Renovate active; multi-cloud aware.
Dependency currency4 / 5
Java 21 + Spring Boot 3 + Springdoc 2.8.16 — current. Renovate harness healthy. BUT: TS UIs on React 17 (same Intuit paved-road floor as editor).
Cost / op complexity4 / 5
Java + JS/TS + Python is a tractable stack; multi-cloud aware (AWS + GCP); consistent skeleton across services.
AI readiness4 / 5
5/7 playbook signals. OpenAPI CRUD ready; agent surface staked (3 Python repos) but unfinished; DynamoDB persistence pending.
Observability3 / 5
Documented observability practice (marketing-automation-docs/docs/observability/); Numaflow native metrics; Gatling perf tests broken (acknowledged).
Aggregate4.0 / 5Backend layers score 4–5 across all attributes (strong re-platform discipline). The single missing dimension is the customer-facing UI that lives outside this org.

Method: SWOT + ISO/IEC 25010 quality attributes scored against the same repo evidence used in the 7-Layer Forensic and AI Readiness tabs. Reproducible from queries in Method & Sources.

Architecture Review · 2-page Executive (cont.) · Customer Journey Builder / C2 Platform

Implications & final recommendation — tied to the customer problem and where the product is heading

Page 2: business + customer implications of the SWOT and the recommended actions for the next 1–2 quarters.
Page: 2 of 2
Anchor: Strategy 6-Pager 5 bets · CJB Established 132K (+18.4% YoY)

CCustomer problem context (one paragraph)

The Automations Brief documents $53.5K/mo cited HVC MRR, customer pain decomposing into trust (abandoned-cart fires twice; "didn’t fire when it should"), pricing/access (Free-tier paywall after June ’25; contact-tax billing), competitive (no Push/WhatsApp/In-app; predictive trigger depth), and discovery (10–20% of CJB capability used). CJB Established is 132K (+18.4% YoY) with activation 33.6% (+14.4pp) and churn 40.2% (−1.2pp) — the cohort is growing, but Free-tier adoption is at 1.1% and new-user adoption at 0.9% (the activation funnel is the largest single quantitative gap). The Strategy 6-Pager commits to 5 bets: sandbox-tier eval (B1), activation funnel (B2), B2B template gap (B3), QBO integration (B4), positioning reframe (B5). The C2 platform is being built explicitly to address the trust pains; the customer-facing UI gap blocks Bets 1–3.

DStrategic implications

  1. The CJB engine is the platform asset; the Mailchimp UI is the product surface. This separation is now visible in the codebase (crmmktg-mktauto backend org vs mailchimp-mcmktg UI org) and the strategic intent (AGENTS.md). Investment patterns reveal a strategic shift Mailchimp leadership should be aware of and have a comms plan for.
  2. Customer-facing trust pains map directly to repos already being built. Trigger reliability (Pain → Code Map row 2 + 7) is the explicit purpose of automations-numaflow + c2-journey-initiation. The fix is shipping; cutover timing determines when customers feel it.
  3. The competitive omnichannel narrative cannot be reversed without a Push/WhatsApp Executor decision. Channel breadth is structurally blocked, not solvable on this timeline. Either commit to building it or reposition vs Klaviyo’s 5-channel canvas.
  4. The customer-facing UI gap is the biggest non-technical risk to Strategy Bets 1–3. Sandbox-tier (B1), activation funnel (B2), B2B templates (B3) all need a customer-facing surface that is unaccounted for in the active code.
  5. AI readiness 5/7 + agentic scaffolds + OpenAPI CRUD = parity with Klaviyo Marketing Agent is an 8–12 week effort. Not blocked by code; blocked by team focus + the canvas-UI surface decision.

EFinal recommendation — five ordered actions

1 · Surface canvas-UI ownership in next leadership review

Highest non-technical priority. Is it staying in the legacy Mailchimp monolith, migrating to mc-nova-ui, or starting a new repo? Strategy Bets 1–3 cannot scope without this answer. Cost: zero. Strategic value: highest.

2 · Q1 — Cut over first 3 trigger types from monolith → C2 ingestion

Demonstrates the trust fix to customers; validates the cutover plan; baseline for the rest of the migration. Use a feature flag (confirm harness lives at nuni-api gateway). Estimate: 6–8 weeks for first three trigger domains.

3 · Q1 — Wire DynamoDB persistence into automations-platform

Replaces the ConcurrentHashMap in-memory implementation. Production hardening is the gate to wider customer rollout. The AGENTS.md target is documented; execution is the gap.

4 · Q1 — Tighten automations-filter JaCoCo gate to 85%

Cheap, high-symbolic-value action. Aligns the platform’s quality story across all five services. Fix Gatling perf tests in the same sprint. Estimate: 1 sprint.

5 · Q2 — 2-week MCP-tool-registry PoC: expose OpenAPI workflow CRUD via automations-agent

Unlocks autonomous flow setup parity with Klaviyo Marketing Agent. Wire cdp-segmentation as agent-context source. Productionize lil-kelly-agent. Output: feasibility report + safety incident count + UX direction for the conversational sidebar. Direct counter to the Klaviyo Marketing Agent narrative gap in the Automations brief.

6 · Q1+ — Confirm "decoupled from Mailchimp monolith" external messaging plan

Single most important non-engineering ask in this brief. The automations-platform/AGENTS.md wording "the next-generation Automations platform for Intuit CRM marketing — decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products" is candid for an internal artifact but reads very differently externally. The platform’s repositioning is real; the comms narrative needs to catch up before analysts read AGENTS.md or competitive analysts surface it.

FClosing — the one-line read

For the executive committee

The CJB architecture is the inverse of the editor architecture: a strong, paved-road, AI-ready backend looking for a customer-facing UI to live in. The C2 platform’s quality posture, modern stack, and explicit decoupling from the Mailchimp monolith make it the strongest engineering bet in this two-product analysis. But the strategic implication — CJB engine as Intuit-shared automation platform vs CJB as Mailchimp feature — is so significant that the business question precedes the technical question. The single most important architectural action for Mailchimp leadership is naming the customer-facing canvas-UI owner and aligning the external comms narrative to the engineering reality, because every Q1–Q5 strategy bet sits downstream of those two decisions.

Cross-references: Executive Summary for the 6 headline findings · Pain → Code Map for HVC theme → repo traceability · Repo Map for the diagram-vs-reality reconciliation · 7-Layer Forensic for evidence detail · AI Readiness for the 5/7 scorecard · Leverage Cheat Sheet for engineering-sync questions · Method & Sources for reproducibility.

Phase 4 · Building Technical Leverage (Playbook §6)

Specific questions to take into the next CJB engineering sync, with the repo evidence behind each one

Generic ask → CJB-specific ask. Each question is structurally informed and references the actual code state.
Format: Generic ask → CJB-specific ask
"Where is the Customer Journey Builder UI being built?"
Better: "mailchimp-mcmktg/customer-journey-builder is a 4-commit scaffold from March 3 2025 with no human authorship. automations-builder and control-panel-web-plugin have no flow-canvas dependencies. Where is the customer-facing visual journey-builder canvas — still in the legacy Mailchimp monolith, or being absorbed into mc-nova-ui/mc-omni-ui? Strategy Bets 1, 2, 3 all hinge on this answer."
"When can we cut over from monolith CJB to the new platform?"
Better: "automations-platform’s DocumentServiceImpl is using ConcurrentHashMap in-memory; the AGENTS.md says DynamoDB is the target. Numaflow ingestion is wired and shipping at 0.5h median PR cycle. c2-journey-initiation just renamed its proto package last week (MCAUT-8639). What’s the cutover plan, what trigger types migrate first, and how is the rollback gated when the legacy monolith is still serving customers?"
"Why don’t we have Push or WhatsApp like Klaviyo?"
Better: "The eventdriven/ directory in automations-numaflow has 13 typed trigger domains for inbound events, but the Processing layer Executors in automations-platform are only Action / Condition / Delay / Wait-for-Trigger — no Push, no WhatsApp, no In-app channel Executor. What’s the team that owns adding new channel Executors, and what’s the dependency on the channel-send infrastructure outside the C2 platform?"
"Are we AI-ready for autonomous flow setup like Klaviyo Marketing Agent?"
Better: "OpenAPI workflow CRUD is ✅ ready. automations-agent exists with agents_and_tools.yaml + agentic-CI scaffolding but only 1 commit. lil-kelly-agent has more development. What’s the scope of lil-kelly-agent, and what’s blocking us from exposing the OpenAPI CRUD as the primary tool of an MCP server like the editor team is doing with mc-omni-mcp?"
"What’s the AGENTS.md decoupling claim about?"
Better: "automations-platform/AGENTS.md says ‘the next-generation Automations platform for Intuit CRM marketing — decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products.’ That’s a strategic identity statement, not a technical one. Are we externally messaging CJB as a Mailchimp feature while internally repositioning the engine as an Intuit-shared asset? What’s the analyst-day messaging plan when this becomes visible?"
"What’s the test coverage situation?"
Better: "JaCoCo 85% line + 50% branch is enforced on automations-platform, automations-numaflow, automations-rec-api. But automations-filter’s gate is at the scaffold default 5%/5%, and Gatling perf tests are documented as broken in AGENTS.md. Can we get a single quarterly report that closes those two gaps — tighten automations-filter to 85% and fix the Gatling chain — so the platform’s quality story is consistent across all five services?"
"What about hero engineer dependency?"
Better: "bcraig owns 65% of c2-journey-initiation commits. cmartin24 is sole non-bot author on all three active TS UIs. amilt is at 60% on automations-rec-api while also closing Brand Kit incidents on the editor side. Bus factor on the C2 platform ≈ 2. What’s the named co-owner per critical-path repo, and what’s the knowledge-transfer cadence we should commit to?"

BBalanced portfolio framework — applied to CJB Q1 capacity

Per playbook §6.2. Applied to the CJB roadmap as documented in the Strategy 6-Pager:

Customer-facing60%UI canvas decision · trigger reliability cutover · template service
Tech debt payoff25%DynamoDB persistence · Gatling fix · automations-filter JaCoCo
Strategic AI10%automations-agent + lil-kelly · MCP tool registry
Exploration5%Push Executor PoC · channel-affinity ML
AllocationCJB-specific work for Q1 (May–Jul ’26)Success metric
60% · Customer-facingDecide canvas-UI ownership (legacy monolith vs Nova/Omni vs new repo) · Cutover plan for first 3 trigger types from monolith → Numaflow · Identify replacement for archived prebuilt-journey-service (Bet 3)HVC trigger-reliability tickets cleared; canvas-UI repo named with named owner
25% · Tech debt payoffWire DynamoDB persistence into automations-platform (replace ConcurrentHashMap) · Fix Gatling perf tests · Tighten automations-filter JaCoCo gate from 5% → 85%JaCoCo 85% gate consistent across all 5 active services; Gatling green
10% · Strategic AIProductionize lil-kelly-agent · Define MCP tool registry in automations-agent exposing OpenAPI workflow CRUD · Wire cdp-segmentation as agent context sourceOne AI-callable workflow CRUD path live in dev; spike report on conversational flow editing
5% · Exploration2-week Push Executor PoC inside automations-platform · Channel-affinity ML feasibility report from c2-segmentation-ai-svc · Confirm editor-layer feature flag harness exists or scope a spikeDecision document on Push send action timing (Q3? Q4?); flag harness audit closed

CThree 2-week spike templates (Playbook §6.3)

Spike 1 · Canvas-UI ownership decision. "Can we run a 2-week PoC where we build a minimal flowchart canvas (using react-flow or @xyflow/react) inside mc-nova-ui that consumes the automations-platform OpenAPI workflow CRUD endpoints? Output: feasibility report + recommendation on whether to start a new repo or extend Nova."

Spike 2 · DynamoDB cutover for the Configuration layer. "Can we run a 2-week PoC replacing DocumentServiceImpl’s ConcurrentHashMap with DynamoDB, with shadow-traffic from the legacy monolith? Output: persistence-layer parity report + cutover risk assessment."

Spike 3 · Conversational flow editing PoC. "Can we run a 2-week PoC where automations-agent exposes POST /workflows + PATCH /workflows/{id}/steps as MCP tools, the agent UI sends ‘Add a wait of 3 days then send a follow-up,’ and we measure round-trip time + workflow validity rate? Output: feasibility for Klaviyo-Marketing-Agent parity."

Method & Sources

How this analysis was produced — reproducible, repo-first, zero-meeting

Same methodology as the NUNI editor analysis. Every claim is reproducible from the queries below.
Snapshot: May 13 2026, 19:30 UTC
Repos enumerated: ~80 across 2 orgs
Repos cloned: 13 (depth=1)

AFramework applied

Product Technical Intelligence Playbook — May 2026, 20-page internal reference. Same sections as the NUNI editor brief: §1.1 (Five Types of "We Can’t"), §3 (7-Layer Forensic), §4 (Pain → Code Map), §5 (Org Failure Modes), §6 (Leverage), §7 (AI Readiness).

BReproducible queries

Direct repo lookup (the diagram’s 16 named repos)

for repo in mailchimp-mcmktg/customer-journey-builder \
            crmmktg-mktauto/mc-customer-journeys \
            crmmktg-mktauto/prebuilt-journey-service \
            crmmktg-mktauto/journey-preview-ui \
            crmmktg-mktauto/trigger-designer \
            crmmktg-mktauto/automations-platform \
            crmmktg-mktauto/automations-numaflow \
            crmmktg-mktauto/automation-worker \
            crmmktg-mktauto/automation-workflows \
            crmmktg-mktauto/automation-filter \
            crmmktg-mktauto/automations-event-gateway \
            crmmktg-mktauto/contact-execution-outbox \
            crmmktg-mktauto/automationseventingest \
            crmmktg-mktauto/automations-rec-api \
            crmmktg-mktauto/marketing-automation-docs \
            crmmktg-mktauto/cjboncall-skill; do
  GH_HOST=github.intuit.com gh api repos/$repo --jq \
    '"\(.full_name)|\(.language)|\(.size)|\(.pushed_at)|archived=\(.archived)"'
done

Active-replacement discovery

GH_HOST=github.intuit.com gh api \
  "search/repositories?q=org:crmmktg-mktauto+pushed:>2025-12-01" \
  --jq '.items[] | "\(.full_name)|\(.language)|\(.size)|\(.pushed_at)|archived=\(.archived)"' \
  | sort -t"|" -k4 -r

GH_HOST=github.intuit.com gh api \
  "search/repositories?q=org:mailchimp-mcmktg+pushed:>2025-12-01" \
  --jq '.items[] | "\(.full_name)|\(.language)|\(.size)|\(.pushed_at)|archived=\(.archived)"' \
  | sort -t"|" -k4 -r

Layer 3 — JaCoCo coverage gates

grep -E "minimum>0\." */app/pom.xml
# Reveals JaCoCo line + branch thresholds per service

Layer 5 — contributor concentration + PR cycle time

GH_HOST=github.intuit.com gh api \
  "repos/crmmktg-mktauto/$repo/commits?since=2025-05-01T00:00:00Z&per_page=100" \
  --paginate -q '.[].author.login // .[].commit.author.name' \
  | sort | uniq -c | sort -rn | head -8

GH_HOST=github.intuit.com gh api \
  "repos/crmmktg-mktauto/$repo/pulls?state=closed&per_page=30"
# Then median + p95 from created_at vs merged_at

CSources

TypeSourceUsed for
FrameworkProduct Technical Intelligence Playbook (May 2026 internal reference)Every section
Customer evidenceMailchimp Marketing Automation Flows Brief — 13 tabs (Executive, VOC, Roadmap, HVC Risk, Nav/Search Risk, Research, Health, PRD Audit, Strategy, Growth Model, Loss Attribution, Initiative Canvas, Strategy Memo)VOC themes ($53.5K/mo cited HVC), UR bets, BigQuery health, Strategy 6-Pager
Repo datagithub.intuit.com/crmmktg-mktauto/* + mailchimp-mcmktg/* via gh api + shallow clonesAll numerical findings: file counts, JaCoCo gates, dep versions, contributor counts, PR cycle times
Architecture diagramUser-supplied images — "4. Mailchimp Customer Journey Builder (CJB) Automation", dated May 13 2026 (16 repos in 7 layers)Reality-vs-diagram reconciliation
In-repo strategy docsautomations-platform/AGENTS.md, automations-numaflow/AGENTS.md, c2-journey-initiation/README.mdThe Intuit-platform decoupling story; C2 architecture three-layer model; trigger-event-processor rename evidence

DCaveats & what would strengthen this analysis

  • The customer-facing UI canvas is unmapped. Confirming whether it’s in the legacy Mailchimp monolith, the Nova surface, or elsewhere is the single most-impactful follow-up.
  • Cross-org dependencies (pricing, billing, compliance, channels) were not deeply mapped. Each requires its own org-tree analysis.
  • The ~80 repos enumerated across both orgs were filtered to active+CJB-relevant; some adjacent investments may have been missed (e.g. the full Nova/Omni surface in mailchimp-mcmktg).
  • No engineering interviews — every interpretation is repo-evidence-only. The "decoupled from monolith to support Freddie AI + CRM + future Intuit products" reading is verbatim from automations-platform/AGENTS.md but the strategic intent behind it is the team’s to confirm.
  • Performance numbers, runtime profiles, Gatling baselines, observability dashboards were not in scope. Layer 6 findings are dep + AGENTS.md-level.
  • Some repos in the new architecture were not deeply cloned (proposal-builder, transact-builder, mc-nova-* family, cdp-segmentation Kotlin, c2-segmentation-ai-svc Python). Each is a follow-up.
  • lil-kelly-agent wasn’t cloned — its scope and tools are inferred from metadata only.

ESuggested follow-ups

  • Run the same forensic on mc-nova-core + mc-nova-ui + mc-omni-ui to confirm whether the customer-facing CJB canvas migrates there.
  • Layer 6 deep-dive on automations-numaflow performance — Gatling fix + p95/p99 publish-to-execute latency baseline.
  • Ownership map of cross-org dependencies (pricing, billing, compliance, channel-send) for the Strategy 6-Pager bets.
  • Quarterly rerun (Aug 2026) post-DynamoDB cutover and post-canvas-UI ownership decision.

Confidentiality. The repo-level findings in this analysis are derived from github.intuit.com/crmmktg-mktauto/* + github.intuit.com/mailchimp-mcmktg/*, accessible to authorized Intuit employees. The Product Technical Intelligence Playbook is marked CONFIDENTIAL — Internal Reference Only. The customer-evidence sources (HVC, VOC, BigQuery) are summarized in the public-to-this-domain Automations Brief; named-customer MRR figures are cited only at theme-aggregate level. The strategic-intent statement in automations-platform/AGENTS.md ("decoupled from the Mailchimp monolith and designed to support Freddie AI, CRM, and future Intuit products") is verbatim from an internal artifact and should be redacted before any external share.