Enablement Pipeline
How we generate, validate, and maintain enablement content using AI-assisted pipelines connected to live Salesforce data.
The Vision
The Enablement Pipeline is a Slack-driven workflow where @Kai mentions trigger content creation aligned with a strict artifact stack. Every request flows through research, planning, review, and publication—ensuring consistent, high-quality output.
Signal
@Kai mention in Slack
Research
Gather context from sources
Jury Review
Fact-check before publish
Publish
Deploy and notify Slack
The goal: Every piece of content aligns with the artifact stack, passes skeptical review, and resolves a real signal. No orphan content, no unvalidated claims.
The 9-Phase Workflow
Every @Kai signal flows through a structured workflow. This ensures consistent quality and traceability from request to publication.
Kai Enablement Pipeline
Fetch pending @Kai mentions from Slack
Let the user know it's in the queue
Decide: dismiss, backlog, or work?
Gather context from repos, docs, CSDs
Propose artifact-aligned changes
Create/update content
Fact-check, completeness, consistency
Deploy and reply to Slack thread
Handle feedback (high trust)
How to Execute the Workflow
The pipeline is operationalized through Cursor rules in the kaptio-gallery repository. Team members (Ragnar, Ivan, etc.) use natural language triggers to execute each phase.
⚡ Trigger Phrases
| Say this... | To do this... |
|---|---|
| "kai work queue" | Display pending @Kai mentions |
| "work on signal 1" | Start research for a specific signal |
| "acknowledge signal 1" | Send queue notification to Slack |
| "bring in the jury" | Trigger skeptical review before publish |
| "publish" | Commit, deploy, and notify Slack |
| "quick fix: [desc]" | Fast iteration on feedback |
kai-enablement-pipeline.mdc
Master workflow rule. Covers all 9 phases from queue to iteration.
artifact-stack.mdc
Reference for all artifact types. Templates and schemas for each.
jury-review.mdc
Skeptical review workflow. Fact-check, completeness, consistency.
Data Sources
Core Health API
Provides secure access to customer Salesforce orgs via KTAPI. Decrypts stored tokens and proxies metadata/query requests.
Google Drive (CSDs)
Capability Solution Designs from customer implementations. Accessed via rclone with team drive configuration.
Jira (KHELP)
Support tickets from the KHELP project. Source for understanding common questions and identifying content gaps.
Notion (via kaptio-grep)
Internal documentation and process guides. Searchable via the kaptio-grep CLI tool.
The Artifact Stack
All content MUST align with this hierarchy. Plans that don't map to these artifact types are rejected.
| # | Artifact Type | Purpose | Location | Status |
|---|---|---|---|---|
| 1-2 | 📍 Layer / Sub-Layer | Top-level categorization | Property in Outcome | Done |
| 3 | 🎯 Outcome | Business capability | src/content/outcomes/ | Done |
| 4 | 🔷 Feature | Specific capability | productMarketing.features[] | Done |
| 5 | 🎬 Showcase | Marketing/positioning | src/content/showcases/ | Done |
| 6 | 📖 Guide | User + admin documentation | src/content/guides/ | Done |
| 7 | ⚙️ Golden Config | Deployable Salesforce config | public/salesforce/golden-configs/ | Done |
| 8 | 🎯 Playbook NEW | Demo script / smoke test | src/content/playbooks/ | Done |
💡 Key Insight: Golden Config + Playbook = Testable Solution
Every golden config should have a corresponding playbook. Deploy the config, run the playbook, prove the solution works. This is the "working software" that validates product-market fit.
Golden Config Extractor
First pipeline completed!
The Golden Config Extractor pulls real configuration patterns from customer orgs and transforms them into deployable, teachable configurations. This is our first pipeline because it:
- ✓ Exercises the full stack (Core Health → Salesforce → Content)
- ✓ Delivers immediate value (deployable configs for customers)
- ✓ Reusable pattern (describe + query + transform) for other artifact types
- ✓ Validates content connectivity (every config links to an Outcome)
Pipeline Steps
Fetch Schema
Call Core Health /describe endpoint for target objects
Extract Sample Data
Query representative records via /query endpoint
Anonymize Data
Remove customer-specific identifiers and sensitive data
Generate Manifest
Create deployment-ready manifest.json with requirements
Generate Documentation
Create teaching-focused .mdx file with explanations
Link to Outcome
Update related Outcome's goldenConfigs array
📥 Input Specification
{
"sourceOrg": {
"ktapiEnv": "production",
"clientId": "tauck"
},
"targetObjects": [
"KaptioTravel__Item__c"
],
"relatedOutcome": "build-service-catalog",
"configId": "hotel-with-rooms",
"title": "Hotel with Room Types",
"description": "Standard hotel setup..."
} 📤 Output Files
The Jury Review (Phase 7)
No content publishes without passing jury review. This is a mandatory skeptical review that challenges assumptions and verifies facts.
🔍 Fact-Check
- • Verify field names against codebase
- • Check API endpoints exist
- • Confirm object relationships
- • Validate version claims
✅ Completeness
- • Does it resolve the signal?
- • Artifact stack alignment?
- • Prerequisites listed?
- • Related content linked?
🎨 Consistency
- • Terminology matches existing?
- • Style follows patterns?
- • Links work correctly?
- • Tone is appropriate?
Live Example: Hotel with Room Types
Our first golden config demonstrates the standard hotel accommodation pattern, created using this pipeline:
Hotel Service with Room Types
Standard hotel setup with room type variations, seasonal pricing, and availability tracking.
Content Health
Current status of content connectivity in the enablement hub. Run npx tsx scripts/audit-content.ts to generate a fresh report.
⚠️ Priority Gaps
- • 57 KB articles need outcome links
- • 5 guides are orphaned (not linked to outcomes)
- • More golden configs needed (target: 1-3 per core outcome)