@elevasis/ui 2.67.0 → 2.69.0

package/dist/{knowledge-search-index-6EZNBNSR.js → knowledge-search-index-LP2WVSQX.js}

@@ -3,185 +3,51 @@ import './chunk-I2KLQ2HA.js';
 // src/knowledge/_generated/knowledge-search-index.json
 var knowledge_search_index_default = [
   {
-    id: "knowledge.outreach-playbook",
-    title: "Outreach Sequence Playbook",
-    summary: "Step-by-step runbook for launching a cold outreach campaign: prospect sourcing, copy review, sending schedule, and reply handling.",
-    bodyText: "Overview\n\nThis playbook covers the end-to-end process for launching a cold outreach campaign using the Elevasis lead-gen pipeline.\n\nSteps\n\n1. Source prospects via the Lead Gen feature.\n2. Review and approve copy in the CRM campaign editor.\n3. Schedule sends using the Task Scheduler.\n4. Monitor replies in the CRM inbox and route to the appropriate deal stage."
-  },
-  {
-    id: "knowledge.lead-gen-strategy",
-    title: "Lead Gen Targeting Strategy",
-    summary: "Defines ICP signal prioritization, firmographic filters, and scoring thresholds used by the lead-gen pipeline.",
-    bodyText: "Strategy\n\nThe lead-gen pipeline targets SMBs with 10-200 employees in recession-resistant verticals (manufacturing, logistics, professional services). Firmographic filters: revenue \\>$1M, HQ in US/CA/AU, tech stack includes at least one SaaS CRM.\n\nScoring Thresholds\n\n- High priority: ICP score \\>= 80\n- Medium priority: ICP score 60-79\n- Low priority: \\< 60 (excluded from active outreach)"
-  },
-  {
-    id: "knowledge.org-model-reference",
-    title: "Organization Model Schema Reference",
-    summary: "Technical reference for the OrganizationModel Zod schema: all top-level domains, the graph contract orientation, authored primitives versus projected graph nodes, and versioning rules.",
-    bodyText: "Schema\n\nThe OrganizationModel schema is defined in packages/core/src/organization-model/schema.ts. It is versioned at version: 1 and composed from domain sub-schemas. The OM is the authoritative contract for the organization: downstream surfaces including Command View, the Knowledge Browser, and the navigation shell are all derived projections from this schema.\n\nTop-Level Domains\n\nThese are the current top-level fields on OrganizationModel. There is no live features or capabilities top-level field -- those terms are legacy wording and should not appear as authored OM primitives.\n\n- version -- schema version, currently locked at 1\n- domainMetadata -- per-domain version and lastModified tracking\n- branding -- organization name, logo, color identity\n- navigation -- surfaces, groups, and defaultSurfaceId for shell routing\n- sales -- sales domain including pipeline entity references\n- prospecting -- lead generation stages, entity references, and pipeline config\n- projects -- project, milestone, and task entity references\n- identity -- organization identity fields\n- customers -- customer segment definitions\n- offerings -- product and service definitions linked to customer segments\n- roles -- role definitions with reportsToId hierarchy and agentId holder support\n- goals -- OKR-style objectives with period ranges and system links\n- systems -- the backbone: hierarchical bounded contexts with dotted IDs and parentSystemId\n- resources -- governance descriptors for workflows, agents, integrations, triggers, and scripts; resource identity lives here, not in a separate deployment manifest\n- actions -- the invokable semantic layer; actions map to resources, affect entities, bind to knowledge, and expose invocation types (slash command, MCP tool, API endpoint, script execution)\n- entities -- business objects owned by systems, with table metadata, state catalogs, and typed entity links\n- policies -- governance rules applied to systems, actions, resources, and roles\n- statuses -- runtime semantic status registry\n- knowledge -- first-class OM content backed by inline nodes and MDX source nodes\n\nGraph Contract\n\nThe OM is projected into a typed graph by buildOrganizationGraph() in packages/core/src/organization-model/graph/build.ts.\n\nNode kinds: organization, system, role, action, entity, event, policy, stage, resource, knowledge\n\nEdge kinds: contains, references, mapsto, uses, governs, links, affects, emits, originatesfrom, triggers, appliesto, effects\n\nThe resourceType overlay on resource nodes is a separate enum: workflow, agent, trigger, integration, external, humancheckpoint, script.\n\nAuthored Primitives vs Projected Graph Nodes\n\nAuthored primitives are what you write directly in the OM: systems, roles, resources, actions, entities, policies, knowledge. The graph builder reads these and emits a richer set of typed nodes and edges. Events, for example, are not authored directly -- they are projected from resource emits declarations. Stages are projected from prospecting stage catalogs.\n\nCommand View\n\nCommand View is a derived operational projection of the OM graph. It visualizes systems, resources, actions, entities, and relationships using the same node and edge taxonomy as buildOrganizationGraph(). It does not have a separate deployment manifest model -- the OM resources domain is the single source of resource identity."
-  },
-  {
-    id: "knowledge.seo-lead-gen-playbook",
-    title: "SEO-to-Lead-Gen Handoff Playbook",
-    summary: "Runbook for promoting SEO-qualified prospects into the active lead-gen pipeline: signal capture, scoring override, and campaign assignment.",
-    bodyText: "Overview\n\nThis playbook governs the handoff from SEO-sourced traffic to the lead-gen pipeline.\n\nSteps\n\n1. SEO feature captures visitor signal (form fill or intent data).\n2. Score the lead using the standard ICP scoring thresholds.\n3. If score \\>= 60, inject into the lead-gen prospect list.\n4. Assign to the appropriate outreach campaign in the CRM."
-  },
-  {
-    id: "knowledge.outreach-campaign-playbook",
-    title: "Campaign Playbook",
-    summary: "Codified rules, benchmarks, and standard operating procedures for Instantly cold email campaigns -- testing methodology, personalization tiers, sequence structure, optimization loop, and batch readiness queries.",
-    bodyText: 'Benchmarks\n\nB2B cold email benchmarks (2025-2026). Use these as evaluation thresholds when running ist-analytics-workflow.\n\n| Metric | Bad | Needs Work | Good | Excellent |\n| --- | --- | --- | --- | --- |\n| Open Rate | \\<20% | 20-30% | 30-45% | 45%+ |\n| Reply Rate | \\<1% | 1-3% | 3-8% | 8%+ |\n| Positive Reply Rate | \\<0.5% | 0.5-1% | 1-3% | 3%+ |\n| Bounce Rate | \\>5% | 2-5% | 1-2% | \\<1% |\n\nCampaign Sizing Rules\n\n- 100-200 contacts per campaign segment -- small enough for meaningful personalization, large enough for statistical learning\n- 1-2 contacts per company -- reply rates drop from 8% to 4% when blasting 10+ people at the same company\n- 30-50 emails/day max per sending account\n- 50-100 emails/day total during testing (weeks 1-4), scaling to 500+/day once a winning formula is found\n\nTesting Priority\n\n1. Subject lines -- highest leverage, easiest to isolate\n2. Opening line / hook -- determines if they keep reading\n3. CTA type -- meeting request vs. soft question vs. value offer\n4. Body copy angle -- pain-point framing vs. benefit lead vs. social proof\n5. Send timing -- Tuesday-Thursday outperform Monday/Friday for B2B\n\nSequence Structure\n\n3 emails total (1 opener + 2 follow-ups). 87-95% of replies come within the first 3 emails.\n\n| Step | Timing | Strategy |\n| --- | --- | --- |\n| Email 1 | Day 0 | Cold read opener + EMRG social proof + interest-based CTA |\n| Email 2 | Day 3 | Short bump in same thread |\n| Email 3 | Day 5 | Breakup email. Soft close, loss aversion |\n\nAgent Optimization Loop\n\nPhase 1 (Launch): Verify batch readiness \xE2\u2020\u2019 Personalize \xE2\u2020\u2019 Create campaign \xE2\u2020\u2019 Create tracking list \xE2\u2020\u2019 Upload \xE2\u2020\u2019 Activate\n\nPhase 2 (Analyze Day 7-14): Run ist-campaign-review-workflow \xE2\u2020\u2019 Run ist-analytics-workflow \xE2\u2020\u2019 Interpret results\n\nPhase 3 (Optimize): Fix based on Phase 2 analysis (subject lines, personalization, bounce cleanup)\n\nPhase 4 (Scale): Document winning combination \xE2\u2020\u2019 Replicate to new segments \xE2\u2020\u2019 Maintain hygiene\n\nOffer Framing\n\n"We find one bottleneck, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."\n\n- Never use "free" in subject lines -- triggers spam filters\n- Frame as conditional, not charitable\n- Low-commitment CTAs get 2x more replies than direct meeting requests'
-  },
-  {
-    id: "knowledge.outreach-copy-strategy",
-    title: "Copy Strategy",
-    summary: "Reusable email copy framework, tone rules, personalization input guidance, subject line patterns, and offer framing for cold outreach campaigns.",
-    bodyText: `Base reference for writing and evaluating campaign copy. Batch-specific email text lives in each batch tracker's Campaign Strategy section.
-
-Offer
-
-Core message: "We find one bottleneck in your business, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."
-
-- Never use "free" in subject lines or body copy
-- Frame as conditional, not charitable
-- Don't mention pricing in outreach
-
-Tone
-
-- Voice: First person singular ("I" not "we")
-- Register: Conversational, direct, no jargon
-- Formatting: Plain text only. No bold, no links in body, no HTML
-
-3-Email Sequence Framework
-
-Email 1 \xE2\u20AC\u201D Hook + Offer (Day 0, 80 words)
-
-Hi {{firstName | there}},
-
-{{openingline}}
-
-{{categorypain}}
-
-I built 4 automations for a company that worked with Google and Sony Music. The first one alone saved them over $1,500 a month. I do the same thing for businesses like yours \xE2\u20AC\u201D you only pay if it actually works.
-
-Worth a quick look?
-
-{{sendingAccountFirstName}}
-
-Email 2 \xE2\u20AC\u201D Bump (Day 3, 40 words)
-
-Hi {{firstName | there}},
-
-Wanted to circle back on this \xE2\u20AC\u201D I've been helping a few companies like {{companyName}} free up their team by automating the repetitive stuff that eats up the day.
-
-Happy to take a 10-minute look \xE2\u20AC\u201D no pitch, just observations.
-
-{{sendingAccountFirstName}}
+    id: "knowledge.bounce-recovery-protocol",
+    title: "Bounce Recovery Protocol",
+    summary: `Step-by-step protocol for handling campaigns that enter Instantly's "Bounces" status, including cleanup mechanics, root cause investigation, and decision framework for continuing vs. restarting.`,
+    bodyText: `When to Use
 
-Email 3 \xE2\u20AC\u201D Breakup (Day 5, 25 words)
+A campaign enters Instantly's "Bounces" status (typically \\>5% bounce rate).
 
-Totally understand if this isn't the right time. If you ever want a second pair of eyes on what could be automated at {{companyName}}, the offer stands.
+Key Mechanics
 
-{{sendingAccountFirstName}}
+Bounce Rate Is Historical: Instantly's bounce rate = bounced / sent. Removing bounced leads does not retroactively reduce the rate.
 
-Subject Lines
+What ist-cleanup-workflow does:
+- Stop sequence: marks lead as "not interested" in Instantly
+- Mark invalid in Lead DB: excludes from all future uploads
+- Delete from Instantly (only with removeFromInstantly: true)
 
-| Variant | Subject | Pattern |
-| --- | --- | --- |
-| A | quick thought | Colleague-camo |
-| B | about {{companyName}} | Observation-trigger |
+Protocol
 
-- Target 21-40 characters
-- Personalized subjects: 46% open rate vs 35% without
-- No "free," "guaranteed," "urgent," "risk-free"`
-  },
-  {
-    id: "knowledge.personalization-strategy",
-    title: "Personalization Strategy",
-    summary: "4-tier personalization waterfall, workflow inputs, quality rules, diagnostic process, and vertical adaptation for cold outreach opening line generation.",
-    bodyText: `How we generate personalized opening lines for Email 1. The ist-personalization-workflow produces ONLY the opening line.
+Step 1: Pause the Campaign
+bash
+pnpm exec elevasis --prod exec Elevasis/ist-campaign-pause-workflow --input '{"campaignId":"<campaign-id>"}'
 
-4-Tier Waterfall
+Step 2: Dry-Run Cleanup
+bash
+pnpm exec elevasis --prod exec Elevasis/ist-cleanup-workflow --input '{"campaignIds":["<campaign-id>"],"dryRun":true}' --async
 
-| Tier | Name | Trigger | Expected Reply Rate |
-| --- | --- | --- | --- |
-| 1 | Individual Signal | contact.enrichmentData.linkedin.summary exists | 10-15% |
-| 2 | Company Signal | Company has businessDescription OR services[] | 5-10% |
-| 3 | Basic Context | Company has categoryName OR category | 3-5% |
-| 4 | Minimal | Only company name and/or contact title | 1-3% |
+Step 3: Run Cleanup
+bash
+pnpm exec elevasis --prod exec Elevasis/ist-cleanup-workflow --input '{"campaignIds":["<id>"],"removeFromInstantly":true}' --async
 
-Workflow Inputs
+Step 4: Decide -- Continue or Restart
 
-| Input | Purpose |
+| Scenario | Action |
 | --- | --- |
-| batchId | Which contacts to personalize |
-| emailBody | Rest of Email 1 after {openingline} |
-| industryContext | Audience framing for LLM |
-| creativeDirection | Override default creative guidance |
-| performanceContext | Feedback from campaign results |
-| overwrite | Re-personalize existing opening lines |
-
-Quality Rules
-
-Core principle: Wrong personalization is worse than none. Accuracy > depth.
-
-Opening Line Style: Cold Read
-
-The opening line must earn attention through recognition, not create tension through a pitch setup. Take one real fact from enrichment data and make an observation that shows you actually looked at their business.
-
-Good examples:
-- "4,400 reviews since 2018 \xE2\u20AC\u201D that kind of growth in Orange County is honestly wild."
-- "60 years family-owned with a proprietary Clean Green method \xE2\u20AC\u201D that's rare in pest control."
-
-Anti-patterns:
-- "You do termite inspections \xE2\u20AC\u201D how many follow-up calls get missed?" (Implication \xE2\u20AC\u201D signals selling)
-- "Great company you've built!" (Generic flattery)`
-  },
-  {
-    id: "knowledge.vertical-messaging-playbook",
-    title: "Vertical Messaging Playbook",
-    summary: "Research-backed messaging strategy per vertical \xE2\u20AC\u201D verified claims, owner voice, language guides, pain point framing, and copy guidelines for outreach messaging.",
-    bodyText: `Purpose
-
-Reference doc for writing and evaluating vertical-specific outreach copy. Captures verified research, owner voice and language, and per-vertical messaging strategy.
-
-Grounded Relatability Strategy
-
-Layer 1: Claim Verification
-Web-research every statistical claim. Grade each as Tier 1 (Verified), Tier 2 (Plausible), or Tier 3 (Unverified). Drop or soften anything Tier 3.
-
-Layer 2: Voice-of-Customer Research
-Search Reddit, trade forums, and industry communities for how owners actually talk about their frustrations.
-
-Layer 3: Scenario-First Copy
-Combine verified claims with owner language to write copy that sounds like a peer, not a vendor:
-1. Lead with the scenario
-2. Use their vocabulary
-3. Reinforce with stats only if they pass the "would I trust this from a stranger?" test
-4. Name concrete capabilities
-
-Universal Owner Patterns
-
-- The Identity Gap: They started the business to do the craft. Acknowledging this resonates deeply.
-- Phone = Business: The owner's phone IS the business.
-- Software Cynicism: Every vertical has been sold to aggressively by SaaS vendors.
-
-Words That Work Everywhere: "Stop losing...", "Without lifting a finger", "Less software, not more"
-
-Words That Fail Everywhere: "AI-powered", "Scale your business", "Digital transformation"
+| Most leads unsent (campaign was early) | Continue -- reactivate |
+| Most leads already received emails | Let it finish |
+| Bounce rate \\>10% or account health degraded | Restart -- fresh campaign |
 
-Copy Principles
+Step 5: Investigate Root Cause
 
-Lead with Scenarios, Not Statistics
+Common root causes: catch-all domains, stale data, verification false positives, generic/role addresses (info@, service@).
 
-| Weak (stat-first) | Strong (scenario-first) |
-| --- | --- |
-| "78% of homeowners hire the first contractor who responds." | "When you're on a job, you can't answer the phone \xE2\u20AC\u201D but the homeowner already called two other plumbers." |
+Step 6: Update Batch Tracker
 
-Claim Strength Tiers:
-- Tier 1 (Verified): Named source, specific methodology. Use confidently.
-- Tier 2 (Plausible): Widely cited, directionally correct. Use the insight, soften the specific number.
-- Tier 3 (Unverified): No credible source found. Do not use specific numbers.`
+Log bounce count, leads cleaned, root cause, and resolution in the batch tracker doc.`
   },
   {
     id: "knowledge.cold-email-research-2026",
@@ -227,51 +93,52 @@ Sequence Length
 87-95% of replies come within the first 3 emails. Additional emails triple spam complaints without meaningful reply lift (Belkins, 16.5M emails).`
   },
   {
-    id: "knowledge.bounce-recovery-protocol",
-    title: "Bounce Recovery Protocol",
-    summary: `Step-by-step protocol for handling campaigns that enter Instantly's "Bounces" status, including cleanup mechanics, root cause investigation, and decision framework for continuing vs. restarting.`,
-    bodyText: `When to Use
-
-A campaign enters Instantly's "Bounces" status (typically \\>5% bounce rate).
+    id: "knowledge.discovery-call-playbook",
+    title: "Stage 03: Discovery",
+    summary: "Discovery form submission, qualification routing, and data storage -- the pipeline endpoint",
+    bodyText: "Overview\n\nThe discovery form is filled during the call by the salesperson. On submission, the workflow stores structured data, updates the CRM, and routes based on qualification.\n\nThis is the current pipeline endpoint \xE2\u20AC\u201D qualified leads receive a HITL task for manual follow-up; no automated stages exist beyond this point.\n\nWorkflow Steps\n\n1. route-by-action \xE2\u20AC\u201D Route to submission or no-show flow\n2. compute-cost \xE2\u20AC\u201D Calculate totalAnnualCost from bottlenecks\n3. store-discovery \xE2\u20AC\u201D Save discoverydata JSONB to acqdeals\n4. find-deal \xE2\u20AC\u201D Find Attio Deal (acqdeals \xE2\u2020\u2019 URL context \xE2\u2020\u2019 Attio API)\n5. update-attio-stage \xE2\u20AC\u201D Update Deal.stage based on qualification\n6. create-summary-note \xE2\u20AC\u201D Add markdown Note to Deal\n7. create-hitl-task \xE2\u20AC\u201D Create HITL approval item for qualified leads\n\nQualification Routing\n\n- Qualified: Deal moves to qualified stage; HITL task created for admin follow-up\n- Not Qualified: Deal moves to closedlost stage; no further automation\n- No-Show: Deal moves to noshow stage; timeout checker handles re-engagement\n\nDiscovery Form Structure\n\nThe form captures: company size, current tools, 3 biggest bottlenecks, estimated time wasted per week, budget comfort range, urgency, decision-making authority."
+  },
+  {
+    id: "knowledge.inbound-booking-playbook",
+    title: "Stage 02: Booking",
+    summary: "Cal.com booking handling -- create, reschedule, and cancel discovery call bookings",
+    bodyText: 'Overview\n\nWhen a prospect books a discovery call via Cal.com, the booking handler manages CRM updates, notifications, and reminder scheduling across all booking lifecycle events.\n\nBooking Handler Workflow\n\nTriggers: Cal.com webhooks (BOOKINGCREATED, BOOKINGRESCHEDULED, BOOKINGCANCELLED)\n\nEvent Flows\n\nBOOKINGCREATED:\n1. create-contact \xE2\u20AC\u201D Create or update Attio Person record, resolve Deal via metadata or email, update Deal stage to booked, create Discovery Call Prep note, cancel brochure follow-ups\n2. notify-created \xE2\u20AC\u201D Send platform notification to admin\n3. schedule-reminders \xE2\u20AC\u201D Create absolute schedule with pre-computed -24h and -1h reminder times\n\nBOOKINGRESCHEDULED:\n1. update-schedule \xE2\u20AC\u201D Cancel existing reminders, schedule new ones at updated times\n2. finish-reschedule \xE2\u20AC\u201D Update Deal stage, notify admin\n\nBOOKINGCANCELLED:\n1. cancel-schedule \xE2\u20AC\u201D Cancel all scheduled reminders\n2. finish-cancel \xE2\u20AC\u201D Update Deal stage to cancelled, notify admin\n\nReminder Schedule\n\nTwo automated reminders per booking:\n- -24h reminder: "Looking forward to our call tomorrow"\n- -1h reminder: "See you in 1 hour" with discovery form link\n\nReminders are scheduled as absolute times (not relative), so rescheduling correctly cancels and re-schedules them.'
+  },
+  {
+    id: "knowledge.inbound-reply-handling-playbook",
+    title: "Stage 01: Reply Handling",
+    summary: "Classify email replies, create CRM contact, and send booking link to interested leads",
+    bodyText: `Overview
 
-Key Mechanics
+Classify incoming email replies, create CRM contact for interested leads, and send booking link. Uses value-first approach: offer a free one-time AI service instead of passive content.
 
-Bounce Rate Is Historical: Instantly's bounce rate = bounced / sent. Removing bounced leads does not retroactively reduce the rate.
+Classification
 
-What ist-cleanup-workflow does:
-- Stop sequence: marks lead as "not interested" in Instantly
-- Mark invalid in Lead DB: excludes from all future uploads
-- Delete from Instantly (only with removeFromInstantly: true)
+Four-way classification with confidence-based HITL routing. Auto-replies detected deterministically before any LLM call.
 
-Protocol
+| Category | Examples | Action |
+| --- | --- | --- |
+| Interested | "Yes I'm interested", "Tell me more" | CRM \xE2\u2020\u2019 HITL task with LLM-drafted follow-up |
+| Not Interested | "Unsubscribe", "Not interested" | Stop outreach sequence |
+| Bounced | mailer-daemon@, "Undeliverable" | Stop outreach \xE2\u2020\u2019 Mark Lead DB INVALID \xE2\u2020\u2019 Skip CRM |
+| Auto-Reply | Out-of-office, ticketing acknowledgments | No action \xE2\u20AC\u201D campaign continues |
 
-Step 1: Pause the Campaign
-bash
-pnpm exec elevasis --prod exec Elevasis/ist-campaign-pause-workflow --input '{"campaignId":"<campaign-id>"}'
+Auto-Reply Detection (Pre-LLM)
 
-Step 2: Dry-Run Cleanup
-bash
-pnpm exec elevasis --prod exec Elevasis/ist-cleanup-workflow --input '{"campaignIds":["<campaign-id>"],"dryRun":true}' --async
+Caught deterministically via regex:
+- Sender address prefix: noreply, no-reply, donotreply, auto, mailer
+- Subject patterns: "auto-reply", "out of office", "OOO"
+- Body patterns: "this is an automated message", vacation auto-responders
 
-Step 3: Run Cleanup
-bash
-pnpm exec elevasis --prod exec Elevasis/ist-cleanup-workflow --input '{"campaignIds":["<id>"],"removeFromInstantly":true}' --async
+Routing Notes
 
-Step 4: Decide -- Continue or Restart
+- NOTINTERESTED and BOUNCED: sequence stopped via Instantly update-interest-status
+- INTERESTED: does NOT stop sequence \xE2\u20AC\u201D proceeds to CRM creation and HITL queue
+- AUTO-REPLY: no CRM, no sequence stop, no reply
 
-| Scenario | Action |
-| --- | --- |
-| Most leads unsent (campaign was early) | Continue -- reactivate |
-| Most leads already received emails | Let it finish |
-| Bounce rate \\>10% or account health degraded | Restart -- fresh campaign |
+HITL Strategy
 
-Step 5: Investigate Root Cause
-
-Common root causes: catch-all domains, stale data, verification false positives, generic/role addresses (info@, service@).
-
-Step 6: Update Batch Tracker
-
-Log bounce count, leads cleaned, root cause, and resolution in the batch tracker doc.`
+For INTERESTED replies, an LLM drafts a follow-up response. Admin reviews and approves via Command Queue before anything sends.`
   },
   {
     id: "knowledge.lead-gen-pipeline-playbook",
@@ -280,607 +147,429 @@ Log bounce count, leads cleaned, root cause, and resolution in the batch tracker
     bodyText: "Performance Benchmarks\n\nPer-stage success rates across the 3 completed Orange County batches (vet-1, auto-1, home-1).\n\nStage 1: Scrape (Raw to Filtered)\n\n| Metric | vet-1 | auto-1 | home-1 | Benchmark |\n| --- | --- | --- | --- | --- |\n| Raw results | 480 | 800 | 1000 | -- |\n| Companies created | 393 | 566 | 701 | -- |\n| Active in DB | 322 | 428 | 640 | -- |\n\nStage 3: Company Qualification Rate\n\n| Metric | vet-1 | auto-1 | home-1 | Benchmark |\n| --- | --- | --- | --- | --- |\n| Qualified | 213 (76%) | 284 (79%) | 326 (60%) | 60-80% |\n| Disqualified | 66 (24%) | 74 (21%) | 222 (40%) | 20-40% |\n\nStage 5: Email Verification\n\nVALID rate: 33-41% of discovered emails across batches. Target bounce rate \\<2%.\n\nModel Selection\n\nAll lead-gen LLM steps run on claude-sonnet-5 (Anthropic) \u2014 qualification, extraction, and personalization alike. There is no separate cheap tier for high-volume steps.\n\nProvider Economics\n\nTomba domain search provides the best cost-per-verified-contact for local SMBs. Dual-verify (Tomba + Mails.so) catches most false positives.\n\nPipeline Stages\n\n1. Scrape (Google Maps via Apify)\n2. LLM Extract (website crawl \xE2\u2020\u2019 structured data)\n3. Company Qualification (LLM ICP scoring)\n4. Email Discovery (Tomba domain search)\n5. Email Verification (Mails.so)\n6. Opening Line Generation (ist-personalization-workflow)\n7. Campaign Upload (ist-upload-contacts-workflow)"
   },
   {
-    id: "knowledge.upwork-proposal-playbook",
-    title: "Proposal Playbook",
-    summary: "Data-backed strategies for writing winning Upwork proposals \xE2\u20AC\u201D structure, pricing, timing, client qualification, and benchmarks.",
-    bodyText: `The Numbers That Matter
-
-| Metric | Benchmark |
-| --- | --- |
-| Personalized proposals | 30% higher reply rate vs generic |
-| Proposals within first 2 hours | 3x response rate vs 24h+ |
-| First-hour proposals | 3-5x interview rate boost |
-
-Proposal Structure
-
-Keep proposals 150-200 words, mobile-scannable.
-
-The Five-Part Formula
-
-1. Hook (1-2 sentences) \xE2\u20AC\u201D Lead with what you do and why it's relevant. Never use "caught my attention" \xE2\u20AC\u201D overused clich\xC3\xA9.
-2. Proof (1-2 sentences) \xE2\u20AC\u201D One concrete metric from past work.
-3. Plan (2-3 lines) \xE2\u20AC\u201D Maximum 3 steps.
-4. Discovery Questions (exactly 2) \xE2\u20AC\u201D Smart, role-specific questions. End with a binary CTA.
-5. Sample (optional) \xE2\u20AC\u201D Loom video (2-3 min).
-
-Opening Lines
-
-The first line decides 80% of reply outcomes. Always use the client's name or company name.
-
-Good openers: "Hi \xE2\u20AC\u201D I build {whattheyneed} for a living and run my own business on them daily."
-
-Never open with: "The part that caught my attention..." / "What stood out..."
-
-Elevasis-Specific Positioning
-
-Dogfooding (Strongest Differentiator): We run our own 7-stage client acquisition pipeline on the platform: Scrape \xE2\u2020\u2019 Extract \xE2\u2020\u2019 Qualify \xE2\u2020\u2019 Email Discovery \xE2\u2020\u2019 Verify \xE2\u2020\u2019 Personalize \xE2\u2020\u2019 Outreach.
-
-The 4 Principles (Use in Discovery Questions):
-1. Integrated \xE2\u20AC\u201D Works with existing tools
-2. Improving \xE2\u20AC\u201D Learns from every human decision
-3. Observable \xE2\u20AC\u201D Real-time visibility
-4. Governed \xE2\u20AC\u201D Humans approve what matters`
-  },
-  {
-    id: "knowledge.upwork-response-templates",
-    title: "Response Templates",
-    summary: "Templates and guidelines for responding to Upwork messages, offers, and client communications.",
-    bodyText: `Offer Acceptance Response
-
-When a client sends an offer and invites a call:
-1. Thank them for the offer (brief, no flattery)
-2. Confirm the call with a specific day/time and timezone
-3. Ask 2-3 qualifying questions to show engagement
-4. Sign off with first name (Alex, not Alexander)
-
-Template
-
-Hi {name},
-
-Thanks for the offer and for reaching out, I'll book a time for {day} {time} ({timezone}). I look forward to learning more about your setup!
-
-Just a few questions:
-1. {qualifying question about current tools/stack}
-2. {qualifying question about current process/pain}
-3. {qualifying question about scope/direction}
-
-Thanks!
-Alex
-
-Qualifying Question Bank
-
-- Current stack: "What do you currently use for workflows / automation?"
-- Pain points: "What's the most time-consuming repetitive task right now?"
-- Approval flow: "What do you currently use for approval control?"
-- Consolidation: "Are you using multiple tools or interested in custom software?"
-- Team size: "How many people will be using these workflows?"
-- Priority: "What's the first workflow you'd want built?"
-
-Style Rules
-
-- Tone: Warm but concise. No filler, no over-enthusiasm.
-- Length: 3-6 sentences max.
-- Timezone: Always specify timezone when confirming times (PDT/PST).
-- No selling: The call is for learning, not pitching.`
-  },
-  {
-    id: "knowledge.seo-playbook",
-    title: "SEO Playbook",
-    summary: "Operational playbook for the SEO/AEO system \xE2\u20AC\u201D vertical launch workflow, content quality gates, AEO formatting rules, stale content management, metrics interpretation, and rollout phases.",
-    bodyText: "Vertical Launch Workflow\n\nEnd-to-end process for launching a new vertical (e.g., hvac-contractors):\n\nStep 1: Research vertical data\n\nFind real, citable industry statistics: pain points, automation ROI, market context. Sources: trade associations, industry surveys, government data (BLS, Census).\n\nStep 2: Generate pages\n\nbash\nPillar page\npnpm tsx scripts/seo/generate-pages.ts --vertical hvac-contractors --type pillar --dry-run\npnpm tsx scripts/seo/generate-pages.ts --vertical hvac-contractors --type pillar\n\nCluster pages\npnpm tsx scripts/seo/generate-pages.ts --vertical hvac-contractors --type cluster\n\nStep 3: Backfill chart data\n\nCharts require post-generation patching. Write chart patch files using Step 1 research, then apply via content.ts patch.\n\nStep 4: AEO optimization\n\nEvery section must be self-contained. AI engines extract individual passages, not full pages.\n- Lead with a 30-50 word standalone answer in the first sentence of each section\n- 78% of AI Overview answers use list format\n- Frame headings as questions when possible\n\nStep 5: Post-publish distribution\n\nUpdate llms.txt, ping IndexNow, submit sitemap segments to Search Console.\n\nData Sourcing Rules\n\n- Tier 1 (Verified): Named source, specific methodology. Use confidently.\n- Tier 2 (Plausible): Widely cited, directionally correct. Soften the specific number.\n- Tier 3 (Unverified): No credible source. Do not use specific numbers."
-  },
-  {
-    id: "knowledge.seo-content-guide",
-    title: "SEO Content Writing Guide",
-    summary: "Tactical guide for writing SEO and AEO-optimized content \xE2\u20AC\u201D page structure, keyword strategy, AI engine citation optimization, E-E-A-T signals, and CTA patterns.",
-    bodyText: 'Overview\n\nThis guide covers how to write SEO content that ranks in traditional search AND gets cited by AI answer engines \xE2\u20AC\u201D ChatGPT, Perplexity, Google AI Overviews, and Gemini.\n\nThe distribution channel is split: 69% of Google searches result in zero clicks, while AI platforms generated 1.13 billion referral visits in June 2025 alone.\n\nPage Structure\n\nSection Architecture\n\nEvery section must be self-contained. AI engines extract individual passages, not full pages.\n\n- Lead with a 30-50 word standalone answer in the first sentence of each section\n- Paragraphs: 2-4 sentences max\n- 78% of AI Overview answers use list format -- use bullets and numbered lists extensively\n- Heading hierarchy: one H1 (page title), H2 for major sections, H3 for subsections\n- Frame headings as questions when possible\n\nSection Length\n\n- Pillar pages: 2,000-3,000 words total\n- Cluster pages: 1,000-2,000 words total\n- Each major section: 150-300 words\n\nConciseness Rules\n\n1. Two-paragraph intro max\n2. No stat duplication between intro and problem section\n3. Section character budget: Intro 450-600 chars, Problem 250-400 chars, Solution 300-550 chars\n\nE-E-A-T Signals\n\n- Brand name "Elevasis" must appear explicitly minimum 3x per page\n- Vertical names used as proper noun concepts\n- Organization + Service + SoftwareApplication schema markup reinforces entity recognition'
-  },
-  {
-    id: "knowledge.seo-distribution-playbook",
-    title: "Distribution & Citation Building",
-    summary: "Post-publish distribution playbook \xE2\u20AC\u201D AI crawler discovery, directory citations, Google Business Profile, community seeding, monitoring cadence, and AEO optimization tactics.",
-    bodyText: 'Overview\n\nEverything that happens after pages are published and sitemap/IndexNow pings are sent. Evergreen reference for maximizing visibility across traditional search, AI answer engines, and buyer-intent directories.\n\nAI Crawler Discovery\n\nllms.txt\n\nA plain-text Markdown file at the domain root that gives LLMs a structured map of key content. Location: apps/website/public/llms.txt.\n\nUpdate whenever pillar or cluster pages are published.\n\nSitemap Segmentation\n\n| Segment ID | Contents | Priority |\n| --- | --- | --- |\n| 0 | Static pages | Default |\n| 1 | Pillar pages (9) | 0.9 |\n| 2 | Cluster pages (52) | 0.8 |\n\nEntity Density Rules\n\nPages with 15+ recognized entities show 4.8x higher selection probability for AI citations.\n- Brand name "Elevasis" must appear explicitly (minimum 3x per page)\n- Stat density target: one statistic every 150-200 words\n\nDirectory Citations\n\nTier 1 (Buyer Intent): G2, Capterra, Product Hunt, AppSumo (direct buyer intent, high domain authority)\n\nTier 2 (Authority): Crunchbase, AngelList, LinkedIn company page, industry association directories\n\nGoogle Business Profile\n\nClaim and verify GBP listing. Category: "Software Company". Keep NAP (Name, Address, Phone) consistent across all citations.'
-  },
-  {
-    id: "knowledge.content-playbook",
-    title: "Content Playbook",
-    summary: "Content creation guide \xE2\u20AC\u201D pillars, platform rules, format specs, repurposing chain, and metrics benchmarks for multi-platform distribution",
-    bodyText: 'Content Pillars\n\nEvery content piece maps to one of five pillars.\n\n| Pillar | What It Is | Target Frequency |\n| --- | --- | --- |\n| dogfooding | How we run Elevasis using our own platform | 1-2x/week |\n| education | 4 Pattern Framework and AI orchestration concepts | 1x/week |\n| demo | "Watch AI Work" \xE2\u20AC\u201D showing the platform in action | 1x/2 weeks |\n| pain-point | SMB pain points backed by data | 1x/week |\n| founder-journey | Solo founder building with AI | 1x/week |\n\nThe 90-10 Rule\n\n90% educational value, 10% promotional. Keeping promotional content to \\<15% ensures your audience stays receptive when you do make an offer.\n\nContent Creation Workflow\n\n1. Capture the Idea \xE2\u20AC\u201D Insert into acqcontent with status: idea\n2. Draft the Source Content \xE2\u20AC\u201D Write core idea in acqcontent.body. LinkedIn first.\n3. Adapt for Platforms \xE2\u20AC\u201D Repurpose from LinkedIn to YouTube, Instagram, X\n4. Schedule and Publish \xE2\u20AC\u201D Use platform-native scheduling\n5. Track Performance \xE2\u20AC\u201D Monitor in acqcontent via Command Center\n\nPlatform Priority\n\n1. LinkedIn \xE2\u20AC\u201D #1 priority, 3x/week\n2. YouTube \xE2\u20AC\u201D #2 priority, 1x/week + Shorts\n3. Instagram \xE2\u20AC\u201D #3 priority, 2-3x/week, repurpose from LinkedIn/YouTube\n4. X \xE2\u20AC\u201D #4 priority, 2-3x/week, threads from LinkedIn'
+    id: "knowledge.lead-gen-strategy",
+    title: "Lead Gen Targeting Strategy",
+    summary: "Defines ICP signal prioritization, firmographic filters, and scoring thresholds used by the lead-gen pipeline.",
+    bodyText: "Strategy\n\nThe lead-gen pipeline targets SMBs with 10-200 employees in recession-resistant verticals (manufacturing, logistics, professional services). Firmographic filters: revenue \\>$1M, HQ in US/CA/AU, tech stack includes at least one SaaS CRM.\n\nScoring Thresholds\n\n- High priority: ICP score \\>= 80\n- Medium priority: ICP score 60-79\n- Low priority: \\< 60 (excluded from active outreach)"
   },
   {
-    id: "knowledge.inbound-reply-handling-playbook",
-    title: "Stage 01: Reply Handling",
-    summary: "Classify email replies, create CRM contact, and send booking link to interested leads",
+    id: "knowledge.new-vertical-launch-playbook",
+    title: "New Vertical Launch Playbook",
+    summary: "Zero-to-first-campaign workflow for launching a new acquisition vertical: batch definition, tracker setup, lead generation stages, campaign launch, and monitoring.",
     bodyText: `Overview
 
-Classify incoming email replies, create CRM contact for interested leads, and send booking link. Uses value-first approach: offer a free one-time AI service instead of passive content.
-
-Classification
-
-Four-way classification with confidence-based HITL routing. Auto-replies detected deterministically before any LLM call.
-
-| Category | Examples | Action |
-| --- | --- | --- |
-| Interested | "Yes I'm interested", "Tell me more" | CRM \xE2\u2020\u2019 HITL task with LLM-drafted follow-up |
-| Not Interested | "Unsubscribe", "Not interested" | Stop outreach sequence |
-| Bounced | mailer-daemon@, "Undeliverable" | Stop outreach \xE2\u2020\u2019 Mark Lead DB INVALID \xE2\u2020\u2019 Skip CRM |
-| Auto-Reply | Out-of-office, ticketing acknowledgments | No action \xE2\u20AC\u201D campaign continues |
-
-Auto-Reply Detection (Pre-LLM)
-
-Caught deterministically via regex:
-- Sender address prefix: noreply, no-reply, donotreply, auto, mailer
-- Subject patterns: "auto-reply", "out of office", "OOO"
-- Body patterns: "this is an automated message", vacation auto-responders
-
-Routing Notes
-
-- NOTINTERESTED and BOUNCED: sequence stopped via Instantly update-interest-status
-- INTERESTED: does NOT stop sequence \xE2\u20AC\u201D proceeds to CRM creation and HITL queue
-- AUTO-REPLY: no CRM, no sequence stop, no reply
-
-HITL Strategy
-
-For INTERESTED replies, an LLM drafts a follow-up response. Admin reviews and approves via Command Queue before anything sends.`
-  },
-  {
-    id: "knowledge.inbound-booking-playbook",
-    title: "Stage 02: Booking",
-    summary: "Cal.com booking handling -- create, reschedule, and cancel discovery call bookings",
-    bodyText: 'Overview\n\nWhen a prospect books a discovery call via Cal.com, the booking handler manages CRM updates, notifications, and reminder scheduling across all booking lifecycle events.\n\nBooking Handler Workflow\n\nTriggers: Cal.com webhooks (BOOKINGCREATED, BOOKINGRESCHEDULED, BOOKINGCANCELLED)\n\nEvent Flows\n\nBOOKINGCREATED:\n1. create-contact \xE2\u20AC\u201D Create or update Attio Person record, resolve Deal via metadata or email, update Deal stage to booked, create Discovery Call Prep note, cancel brochure follow-ups\n2. notify-created \xE2\u20AC\u201D Send platform notification to admin\n3. schedule-reminders \xE2\u20AC\u201D Create absolute schedule with pre-computed -24h and -1h reminder times\n\nBOOKINGRESCHEDULED:\n1. update-schedule \xE2\u20AC\u201D Cancel existing reminders, schedule new ones at updated times\n2. finish-reschedule \xE2\u20AC\u201D Update Deal stage, notify admin\n\nBOOKINGCANCELLED:\n1. cancel-schedule \xE2\u20AC\u201D Cancel all scheduled reminders\n2. finish-cancel \xE2\u20AC\u201D Update Deal stage to cancelled, notify admin\n\nReminder Schedule\n\nTwo automated reminders per booking:\n- -24h reminder: "Looking forward to our call tomorrow"\n- -1h reminder: "See you in 1 hour" with discovery form link\n\nReminders are scheduled as absolute times (not relative), so rescheduling correctly cancels and re-schedules them.'
-  },
-  {
-    id: "knowledge.discovery-call-playbook",
-    title: "Stage 03: Discovery",
-    summary: "Discovery form submission, qualification routing, and data storage -- the pipeline endpoint",
-    bodyText: "Overview\n\nThe discovery form is filled during the call by the salesperson. On submission, the workflow stores structured data, updates the CRM, and routes based on qualification.\n\nThis is the current pipeline endpoint \xE2\u20AC\u201D qualified leads receive a HITL task for manual follow-up; no automated stages exist beyond this point.\n\nWorkflow Steps\n\n1. route-by-action \xE2\u20AC\u201D Route to submission or no-show flow\n2. compute-cost \xE2\u20AC\u201D Calculate totalAnnualCost from bottlenecks\n3. store-discovery \xE2\u20AC\u201D Save discoverydata JSONB to acqdeals\n4. find-deal \xE2\u20AC\u201D Find Attio Deal (acqdeals \xE2\u2020\u2019 URL context \xE2\u2020\u2019 Attio API)\n5. update-attio-stage \xE2\u20AC\u201D Update Deal.stage based on qualification\n6. create-summary-note \xE2\u20AC\u201D Add markdown Note to Deal\n7. create-hitl-task \xE2\u20AC\u201D Create HITL approval item for qualified leads\n\nQualification Routing\n\n- Qualified: Deal moves to qualified stage; HITL task created for admin follow-up\n- Not Qualified: Deal moves to closedlost stage; no further automation\n- No-Show: Deal moves to noshow stage; timeout checker handles re-engagement\n\nDiscovery Form Structure\n\nThe form captures: company size, current tools, 3 biggest bottlenecks, estimated time wasted per week, budget comfort range, urgency, decision-making authority."
-  },
-  {
-    id: "knowledge.pipeline-management-playbook",
-    title: "Pipeline Management",
-    summary: "Automated pipeline maintenance workflows for the inbound pipeline, covering timeout monitoring, stale deal handling, unsubscribe cleanup, and full contact reset.",
-    bodyText: "Overview\n\nPipeline management keeps the inbound pipeline clean without manual intervention.\n\n- Timeout monitoring \xE2\u20AC\u201D Detecting deals that have gone stale in a stage\n- Unsubscribe cleanup \xE2\u20AC\u201D Closing deals and cancelling automation when a contact opts out\n- Full cleanup \xE2\u20AC\u201D Complete removal of all pipeline data for a contact\n\nNo timeout action transitions a deal automatically. All stage changes from the timeout system require admin approval via a HITL Command Queue item.\n\nTimeout System\n\nTimeout Checker (inb-pipeline-timeout-checker-workflow)\n\nScans all active pipeline stages. For each stale deal, creates a HITL approval item in the Command Queue. Never modifies deal records directly.\n\nTimeout rules by stage:\n\n| Stage | Condition | Timeout |\n| --- | --- | --- |\n| interested | No activity | 30 days |\n| booked | Meeting time has passed | 3 hours after meeting |\n| discovery | No form submission | 24 hours after call |\n\nAction Workflows\n\n4 action workflows triggered by admin approval:\n- Nurture: Move to nurture sequence\n- Close-Lost: Mark deal closed, stop all automation\n- No-Show: Re-send booking link with personal note\n- Follow-Up: Send soft re-engagement email\n\nUnsubscribe Cleanup\n\nWhen a contact opts out:\n1. Find all active automation for the contact\n2. Cancel scheduled reminders\n3. Update Deal stage to unsubscribed\n4. Mark contact as unsubscribed in Attio"
-  },
-  {
-    id: "knowledge.communications-map",
-    title: "Communications Map",
-    summary: "All lead-facing messages across the active client acquisition pipeline (stages 01-03). Stages 04-08 communications are archived.",
-    bodyText: 'Overview\n\nEvery message sent to a lead across the active acquisition pipeline \xE2\u20AC\u201D outreach, follow-ups, reminders, and event-triggered emails. 10 total active messages (3 outreach + 1 reply + 2 subsequent reply + 2 discovery reminders + 1 timeout follow-up + 1 timeout re-engagement).\n\nStages 04-08 communications (proposal follow-ups, payment reminders, nurture sequences) are archived.\n\nActive Pipeline Phases\n\n1. Outreach (Instantly)  2. Reply Handling     3. Discovery Reminders\n 3 emails                 1 email + 2 HITL      2 reminders\n Day 0/3/7                On reply              -24h/-1h\n\nPhase 1: Outreach (Instantly)\n\n| # | Day | Subject | Angle | Purpose |\n| --- | --- | --- | --- | --- |\n| 1 | 0 | idea for {{companyName}} | Earn attention | Personal, specific |\n| 2 | 3 | where do business hours actually go? | New angle | Peer-level, intriguing |\n| 3 | 7 | the offer (whenever useful) | Permission to close | Warm, zero pressure |\n\nPhase 2: Reply Handling (Resend)\n\nSent only to INTERESTED replies. LLM drafts; admin approves via HITL before sending.\n\nPhase 3: Discovery Reminders (Resend)\n\nTwo automated reminders per booking:\n- -24h: "Looking forward to our call tomorrow"\n- -1h: "See you in 1 hour" with discovery form link\n\nAll scheduled/event emails signed "Alex". Plain text.'
-  },
-  {
-    id: "knowledge.reddit-monitoring-playbook",
-    title: "Social Monitoring",
-    summary: "Automated Reddit monitoring pipeline \xE2\u20AC\u201D 4-step workflow (search, LLM score, LLM draft, store) with tiered subreddit scraping via Apify, claude-sonnet-5 scoring and response drafting, and lead-gen optimized responses via the AlexElevasis account.",
-    bodyText: "Overview\n\nSocial monitoring surfaces Reddit posts where business owners discuss operational challenges, manual processes, and automation needs.\n\nCron Trigger (3x/day: 16:00, 22:00, 04:00 UTC)\n    \xE2\u2020\u2019 mnt-reddit-monitor-workflow (4-step pipeline)\n        \xE2\u2020\u2019 Step 1: Search \xE2\u20AC\u201D 4 sequential Apify actors (one per tier)\n        \xE2\u2020\u2019 Step 2: Score \xE2\u20AC\u201D claude-sonnet-5 (concurrency 5)\n        \xE2\u2020\u2019 Step 3: Draft \xE2\u20AC\u201D claude-sonnet-5 (high-score only)\n        \xE2\u2020\u2019 Step 4: Report \xE2\u20AC\u201D Store to acqsocialposts, log breakdown\n    \xE2\u2020\u2019 Command Center: /acquisition/monitoring\n\nStatus: Paused until further notice (2026-03-31). Pipeline technically validated but ROI is low without deep vertical expertise.\n\nVelocity Batches\n\nSubreddits grouped by posting velocity, each with its own maxPostsPerSource.\n\n| Batch | Subs | Posts/Source | Example Subreddits |\n| --- | --- | --- | --- |\n| Medium Velocity | 2 | 5 | Accounting, Plumbing |\n| Buyer Low-Volume | 10 | 3 | CRM, EntrepreneurRideAlong, sweatystartup |\n| Trade Niche | 10 | 2 | electricians, Dentists, InsuranceAgent |\n| Decision Niche | 3 | 2 | logistics, FreightBrokers, healthIT |\n\nScoring\n\nPosts scored 0-100 by claude-sonnet-5 for business automation opportunity relevance. Posts scoring \\>= 60 get response drafts via claude-sonnet-5.\n\nAlexElevasis Account\n\nAll responses posted via the AlexElevasis Reddit account. See Reddit Account strategy doc for warmup playbook and karma thresholds."
-  },
-  {
-    id: "knowledge.reddit-account-strategy",
-    title: "Reddit Account",
-    summary: "AlexElevasis Reddit account strategy \xE2\u20AC\u201D warm-up playbook, karma thresholds, posting rules, and lead generation approach for the social monitoring pipeline.",
-    bodyText: 'Account Details\n\n| Field | Value |\n| --- | --- |\n| Username | AlexElevasis |\n| Created | 2026-03-26 |\n| Purpose | Lead generation via Reddit monitoring pipeline |\n| Persona | Alexander, founder of an AI automation company |\n\nThe username serves double duty: every helpful comment puts "Elevasis" in front of the reader.\n\nWarm-Up Playbook\n\nDays 1-3 \xE2\u20AC\u201D Cold Start:\n- Browse, upvote, follow target subs\n- 1 comment per day max\n- No links, no self-promotion, no CTAs\n\nDays 4-14 \xE2\u20AC\u201D Gradual Ramp:\n- Increase to 2-3 comments/day\n- Genuine, helpful answers \xE2\u20AC\u201D no copy-paste across threads\n- Still no links or CTAs\n\nAfter 30 Days + 100 Karma \xE2\u20AC\u201D Activation:\n- Most automod filters cleared\n- Start using monitoring pipeline drafts\n- 300+ karma unlocks more restrictive subs (r/Entrepreneur, r/startups)\n\nKarma Thresholds\n\n| Karma | Access Level |\n| --- | --- |\n| 100 | Bypasses most automod filters |\n| 300+ | Access to restrictive subs |\n| 1,000+ | Considered established community member |\n\nPosting Rules\n\n- Genuine value first \xE2\u20AC\u201D no pitching without established reputation\n- 30-day account age required before using pipeline drafts\n- Open questions in responses (not CTAs) per pipeline draft conventions'
-  },
-  {
-    id: "knowledge.linkedin-strategy",
-    title: "LinkedIn Strategy",
-    summary: "LinkedIn posting strategy \xE2\u20AC\u201D algorithm deep dive, format rankings, hook techniques, carousel optimization, newsletter strategy, engagement tactics, profile optimization, and growth playbook for B2B SaaS (2025-2026)",
-    bodyText: 'Overview\n\nLinkedIn is the #1 priority platform. The algorithm heavily favors personal profiles over company pages. In 2025-2026, LinkedIn shifted from viral reach to depth and authority \xE2\u20AC\u201D topical consistency is now the single biggest strategic lever.\n\nCadence: 3-5x/week (Wed/Thu/Fri strongest, Monday weakest)\n\nAlgorithm Deep Dive\n\nRanking Signals (by weight)\n\n| Signal | Weight | Notes |\n| --- | --- | --- |\n| Comments | Highest | 15x more valuable than likes |\n| Saves and sends | Very high | Added to analytics in late 2025 |\n| Dwell time | High | 15+ seconds = meaningful |\n| "See more" clicks | High | Whether people expand the full post |\n| Reactions/likes | Lowest | Significantly de-emphasized |\n\nTopical Authority\n\nThe algorithm rewards consistent publishing within a defined area of expertise. Pick a lane (AI automation) and stay in it.\n\nPost Formats\n\n1. Carousels \xE2\u20AC\u201D Highest avg engagement; 10-slide with text + data\n2. Text posts \xE2\u20AC\u201D Quick takes, contrarian observations, founder stories\n3. Documents/PDFs \xE2\u20AC\u201D In-depth guides, playbooks, frameworks\n4. Videos \xE2\u20AC\u201D Native upload outperforms external links by 5x\n\nHook Techniques\n\n- Lead with the most surprising/counterintuitive insight\n- Use "I" not "we" \xE2\u20AC\u201D personal profile posts outperform company pages\n- 3 lines max before "...see more" break\n- Questions outperform statements for comments engagement'
-  },
-  {
-    id: "knowledge.instagram-strategy",
-    title: "Instagram Strategy",
-    summary: "Comprehensive Instagram posting strategy for B2B SaaS founder content \xE2\u20AC\u201D algorithm deep dive, Reels, carousels, Stories, SEO, hashtags, captions, profile optimization, growth tactics, and analytics benchmarks (2025-2026)",
-    bodyText: 'Overview\n\nInstagram is the #3 priority platform. Carousels repurpose easily from LinkedIn, and Reels come directly from YouTube Shorts.\n\nCadence: 3-5x/week feed posts + daily Stories\n\nB2B Reality Check: Instagram is a complementary channel for B2B SaaS, not a primary lead gen tool. Decision-makers are on Instagram (76% of B2B companies use it), but they are in consumer mode.\n\nAlgorithm Deep Dive (2025-2026)\n\nReels Algorithm (Most Important for Reach)\n\nReels are designed for discovery: 55% of Reels views come from non-followers.\n\nThree priority signals:\n| Signal | Weight | How to Optimize |\n| --- | --- | --- |\n| Watch time | #1 | Hook in first 1.7s; optimize for completion |\n| Sends per reach | Highest for new audiences | "Send this to someone" content |\n| Likes per reach | Highest for followers | Valuable content followers engage with |\n\nContent Strategy\n\n- Repurpose from LinkedIn: Carousel slides \xE2\u2020\u2019 Instagram carousel\n- Repurpose from YouTube: Long-form \xE2\u2020\u2019 Reels (cut 30-60s clips)\n- Stories: Daily touchpoints, polls, Q&A, behind-the-scenes\n\nCarousel Optimization\n\n- Slide 1: Hook (bold claim or question)\n- Slides 2-9: Value delivery (one point per slide)\n- Slide 10: CTA (follow, DM, link in bio)'
-  },
-  {
-    id: "knowledge.x-strategy",
-    title: "X (Twitter) Strategy",
-    summary: "X/Twitter posting strategy \xE2\u20AC\u201D algorithm signals, thread tactics, engagement weights, Premium ROI, video specs, growth playbook, and B2B SaaS niche tactics",
-    bodyText: "Overview\n\nX is the #4 priority platform. Most content is repurposed from LinkedIn text posts as threads.\n\nCadence: 3-5 posts/day (mix of original posts + replies + quote tweets), 2-3 threads/week\n\nPrerequisite: Get X Premium ($8/mo) \xE2\u20AC\u201D verified accounts get 10x more impressions. Non-Premium accounts posting links receive near-zero engagement as of 2026.\n\nAlgorithm Deep Dive\n\nEngagement Weight Scoring\n\n| Signal | Weight | vs. Like |\n| --- | --- | --- |\n| Reply engaged by author | +75 | 150x |\n| Reply | +13.5 | 27x |\n| Profile click + engagement | +12.0 | 24x |\n| Bookmark | +10.0 | 20x |\n| Retweet | +1.0 | 2x |\n| Like | +0.5 | 1x |\n\nCritical takeaway: Replying to your own replies is worth 150x a like.\n\nPenalties\n\n- External links: 30-50% reach reduction\n- Multiple hashtags: 40% penalty\n\nThread Strategy\n\n- First tweet = hook (bold claim or surprising stat)\n- 5-10 tweets per thread\n- Last tweet = CTA (follow for more, link to extended content)\n- Reply to your own threads within the first hour to boost algorithmic velocity"
-  },
-  {
-    id: "knowledge.youtube-channel-strategy",
-    title: "Channel Strategy",
-    summary: 'Unified YouTube channel strategy \xE2\u20AC\u201D channel setup, content pipeline, differentiation positioning, launch queue, and production workflow for "Alexander Le | Elevasis" channel',
-    bodyText: `Objective
-
-Build the "Alexander Le | Elevasis" YouTube channel as an evergreen discovery engine for Elevasis. YouTube is the #1 content priority \xE2\u20AC\u201D evergreen discovery, SEO compounding, and 53% of B2B buyers watch video before requesting demos.
-
-Channel Identity
+Use this playbook when launching a new acquisition vertical from zero to first campaign. A vertical launch turns an audience hypothesis such as independent dental practices, auto repair shops, or bookkeeping firms into a tracked lead generation batch, qualified contacts, a draft Instantly campaign, and an active monitoring loop.
 
-- Name: "Alexander Le | Elevasis" \xE2\u20AC\u201D personal-brand hybrid with clear business association
-- Handle: @AlexanderElevasis
-- Why personal-brand hybrid: People subscribe to people. Algorithm favors creator-branded channels over faceless brands.
+The workflow has five phases:
 
-Content Format: Face Bubble Intro \xE2\u2020\u2019 Screen Recording
+1. Define the batch and qualification rules.
+2. Create the batch tracker.
+3. Run the lead generation pipeline.
+4. Launch the outreach campaign.
+5. Monitor replies and campaign quality.
 
-Primary format: Quick face-cam intro (circle overlay, 15-30s) to build trust, then full-screen recording.
+Define the Batch
 
-Why this works:
-- 40%+ of YouTube's top 1,000 channels never show a presenter \xE2\u20AC\u201D faceless works
-- Screen recording tutorials rank extremely well on YouTube + Google
-- Face in thumbnails gets 921K more views on average
+Choose a batch ID using the acquisition naming convention: {vertical}-{number}, for example dental-1, auto-1, or home-1.
 
-Differentiation
+Record the batch configuration in the tracker before running pipeline stages. At minimum, capture:
 
-Compete on substance, not production quality:
-- Real execution data, real costs, real results (not simulations)
-- "Document the build" format: record while building, editing, deploying
-- Show Command Center in action \xE2\u20AC\u201D no equivalent content exists
+- Target description, such as "independent dental practices in Orange County, California".
+- Search queries for the initial source pull.
+- Region: county, state, country, or other geography accepted by the scraper workflow.
+- Minimum review count and minimum rating, when Google Maps quality thresholds matter.
+- Custom disqualification rules, such as excluding chains, franchises, pediatric-only practices, or irrelevant subcategories.
+- Website crawl keywords, such as about, team, staff, contact, services, or vertical-specific service pages.
 
-Launch Queue
+Use packages/elevasis/operations/src/sales/prospecting/constants.ts as the batch registry. Current launch work should keep the tracker as the human-readable source and pass qualification criteria through the workflow input, list qualification metadata, or the registered batch config for the stage being run.
 
-3 priority video types for channel launch:
-1. Platform demo walkthroughs (Command Center, workflow execution)
-2. Founder journey episodes (building in public)
-3. Educational explainers (AI orchestration concepts)`
-  },
-  {
-    id: "knowledge.youtube-tactics",
-    title: "YouTube Strategy",
-    summary: "YouTube posting strategy \xE2\u20AC\u201D upload optimization, Shorts tactics, algorithm signals, SEO, first-48-hour playbook, faceless content tips, and small channel growth for B2B SaaS",
-    bodyText: `Overview
+Create the Batch Tracker
 
-YouTube is the #2 priority platform and the only one with true evergreen discovery. Videos keep gaining views months/years after posting.
+Create a tracker from the acquisition batch template:
 
-Cadence: 1 long-form/week + 3-5 Shorts/week
+text
+apps/docs/content/docs/operations/client-acquisition/outreach/batches/template.mdx
 
-Upload Checklist
+Place the new tracker in the pending batch directory:
 
-Title
-- Keep meaningful part in first 60 chars (mobile truncation)
-- Front-load primary keyword: "AI Automation for Veterinary Clinics (Full Walkthrough)"
-- Long-tail titles outperform generic for small channels
+text
+apps/docs/content/docs/operations/client-acquisition/outreach/batches/pending/{batch-id}.mdx
 
-Thumbnail
-- 1280x720px, 16:9, max 2MB
-- 4 words max of bold, high-contrast text
-- Use YouTube's Test & Compare \xE2\u20AC\u201D upload 3 thumbnails, YouTube A/B tests and reports CTR
+Fill in the frontmatter with status: in-progress, then complete the batch configuration table before running pipeline work. The tracker should make it possible to reconstruct the vertical, region, search inputs, disqualification rules, and campaign state without reading execution logs.
 
-Description
-- First 125 chars = what shows in search results
-- Add timestamps/chapters \xE2\u20AC\u201D improve retention + create extra search ranking hooks
+Run Lead Generation
 
-Shorts Strategy
+Run the lead generation stages with the platform CLI from the monorepo root so .env.development and .env.production resolve correctly.
 
-- Cut 30-60s clips from long-form: best moments, surprising reveals, "before/after"
-- Repurpose from YouTube to Instagram Reels and TikTok
-- Hook in first 1-2 seconds: start with the payoff, not the setup
+Stage 01: Google Maps Scrape
 
-First-48-Hour Playbook
+Use the Google Maps scrape workflow to acquire initial companies:
 
-1. Publish during peak hours (12pm-3pm ET Tuesday-Thursday)
-2. Post about the video on LinkedIn immediately after upload
-3. Reply to every comment within the first 24 hours
-4. Share in relevant communities (not spam \xE2\u20AC\u201D genuine value)`
-  },
-  {
-    id: "knowledge.youtube-growth-playbook",
-    title: "YouTube Growth Playbook",
-    summary: "Practical YouTube optimization guide for Elevasis screen-recorded demos, founder-led walkthroughs, Shorts, SEO, and launch review loops",
-    bodyText: 'Overview\n\nThis playbook maps YouTube growth tactics to the current Elevasis content format: screen recordings, Command Center walkthroughs, founder commentary, proof assets, and short clips cut from real demos.\n\nThe goal is to make real AI orchestration visible enough that buyers and technical peers understand what Elevasis does.\n\nCore Format\n\n| Format | Use For | Notes |\n| --- | --- | --- |\n| Face intro \xE2\u2020\u2019 screen recording | Flagship demos, founder-led walkthroughs | 15-30 second intro, then full-screen product work |\n| Screen recording only | Tutorials, Shorts source material | Fastest to produce |\n| Data walkthrough | Campaign metrics, cost tracking, workflow results | Use only real data |\n| Concept explainer | AI agents, orchestration, human oversight | Keep tied to concrete business workflows |\n\nCTR Optimization\n\nThumbnails should show the result or system, not abstract concepts:\n1. Command Center, workflow graph, campaign analytics, or visible output\n2. Optional face overlay when it improves trust\n3. Three to five words of context. High contrast, readable at mobile size.\n\nTitle rules:\n- Front-load the topic\n- Use real numbers only when current and verifiable\n- Prefer "Watch", "Real", "Live", "Actual", "Walkthrough" over hype language\n- Make the title and thumbnail say different things\n\nRetention\n\nOpen with the payoff:\n1. Show the final dashboard, result, or workflow output\n2. Explain what the viewer is about to see\n3. Switch into the walkthrough quickly\n\nFirst-24-Hour Workflow\n\nAlgorithm watches first 30-60 minutes closely. A video getting 10 replies in 15 minutes dramatically outperforms one getting 10 replies over 24 hours.'
-  },
-  {
-    id: "knowledge.youtube-mental-prep",
-    title: "Mental Preparation \xE2\u20AC\u201D Creator Anxiety Playbook",
-    summary: "Research-backed strategies for overcoming publishing anxiety, the spotlight effect, graduated exposure, and building comfort on camera \xE2\u20AC\u201D practical guide for a technical founder starting YouTube",
-    bodyText: `Why This Exists
+bash
+pnpm exec elevasis exec Elevasis/lgn-01a-google-maps-scrape-workflow --input '{"searchQueries":["dentist","dental clinic"],"county":"Orange County","state":"California"}' --async
 
-Recording yourself and putting your ideas out publicly is genuinely uncomfortable. This doc captures the research and practical strategies so you can reference them when the anxiety spikes \xE2\u20AC\u201D not as motivation, but as evidence that the discomfort is normal, finite, and navigable.
+After the execution starts, record the execution ID and source counts in the batch tracker.
 
-The Core Insight
+Local Website Crawl
 
-Readiness is a product of exposure, not a prerequisite for it. You don't stop feeling afraid and then start. You start, and the fear gradually recedes.
+Run the local website crawler against the batch:
 
-What You're Actually Afraid Of
+bash
+pnpm -C scripts/web-scraper run crawl -- {batch-id}
 
-The Spotlight Effect (Gilovich et al., 2000)
+The crawl should capture relevant sub-pages for LLM extraction. If vertical-specific keywords are not available in the active code path, use the default crawl coverage and note any manual crawl gaps in the tracker before extraction.
 
-People overestimate how much others notice and judge them by roughly 2x. Early videos get almost zero views \xE2\u20AC\u201D you're practicing in an empty room.
+Stage 02: Website Extract
 
-The Five Common Fears (in order of prevalence)
+Extract structured company profile data from crawl output:
 
-1. Judgment from people you know \xE2\u20AC\u201D not strangers. The #1 blocker.
-2. Perfectionism as procrastination \xE2\u20AC\u201D "I'll start when I have better equipment." This is avoidance.
-3. Impostor syndrome \xE2\u20AC\u201D "Who am I to teach this?"
-4. Permanence anxiety \xE2\u20AC\u201D "This will be on the internet forever"
-5. Voice/face aversion \xE2\u20AC\u201D Most people dislike their recorded voice (bone conduction gap)
+bash
+pnpm exec elevasis exec Elevasis/lgn-02-website-extract-workflow --input '{"batchId":"{batch-id}"}' --async
 
-The Real Fear: Cringe
+Stage 03: Company Qualification
 
-People tolerate a video that flops quietly. What they can't tolerate is creating something they later find embarrassing.
+Qualify companies using the target description, review thresholds, rating thresholds, and custom rules captured in the tracker. If the workflow does not resolve criteria automatically for the batch, pass the criteria explicitly in the input or attach them through the list qualification surface before running the stage.
 
-Graduated Exposure Protocol
+bash
+pnpm exec elevasis exec Elevasis/lgn-03-company-qualification-workflow --input '{"batchId":"{batch-id}","criteria":{"targetDescription":"Independent dental practices in Orange County, California","minimumReviewCount":5,"minimumRating":3,"customRules":"Disqualify franchises and chains. Disqualify orthodontics-only and pediatric-only practices."}}' --async
 
-1. Screen recording only (no face, no voice) \xE2\u20AC\u201D 2 videos
-2. Screen recording + voiceover (no face) \xE2\u20AC\u201D 5 videos
-3. Face bubble intro (15-30s) + screen recording \xE2\u20AC\u201D ongoing
+For list-oriented runs, use listId instead of batchId; list configuration takes priority over the batch registry unless an explicit criteria override is provided.
 
-Each stage desensitizes one fear at a time. Never skip ahead. The goal is consistency, not perfection.`
-  },
-  {
-    id: "knowledge.what-is-elevasis",
-    title: "What is Elevasis",
-    summary: "Company overview, positioning, value proposition, and pricing for the AI orchestration platform",
-    bodyText: 'Executive Summary\n\nCompany: Bootstrapped AI orchestration platform for done-for-you business automation\n\nFounder: Solo (Alex, 34), bootstrapped\n\nMarket: Service-based SMBs that need practical AI automation without building internal AI teams\n\nGTM: Content-led marketing, proof assets, consultative sales, and land-and-expand pricing\n\nCompany Overview\n\nCurrent Status\n\nThe platform core is production-ready enough to support client-facing demonstrations and implementation work. Current business focus is client acquisition, proof-building, and turning the platform into a repeatable service delivery system.\n\nFounder Profile\n\nAlex, 34 \xE2\u20AC\u201D Solo founder with software engineering background (BSCS degree). Previous: Ecommerce platforms, Streaming technology. No formal AI background \xE2\u20AC\u201D practitioner, not academic.\n\nWhat We Are\n\nOperating layer for AI automation. We help SMBs operate with closed-loop feedback, decision capture, and continuous learning \xE2\u20AC\u201D at SMB pricing with done-for-you implementation (NOT self-service).\n\nTarget Market\n\nICP: Service-based SMBs (2-50 employees, USA, $200K-$5M revenue)\n\nCore Pain: Capacity crisis, pipeline problems, operational chaos, growth blockers \xE2\u20AC\u201D too busy serving clients to grow their own business.\n\nPricing (Land-and-Expand)\n\n- Tier 1 \xE2\u20AC\u201D Foundation (1-2 workflows): $500-2k/mo\n- Tier 2 \xE2\u20AC\u201D Scaled Operations (3-5 workflows): $2k-5k/mo\n- Tier 3 \xE2\u20AC\u201D AI-Powered Systems (6+ workflows): $5k-15k+/mo\n\nAdditional workflows cost less due to shared infrastructure.\n\nValue Proposition\n\n"We find one bottleneck in your business, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."'
-  },
-  {
-    id: "knowledge.platform-systems-overview",
-    title: "Platform Systems Overview",
-    summary: "Authoritative overview of the Elevasis AI Orchestration Platform systems -- what's built, what each system does, and how the pieces fit together",
-    bodyText: "Overview\n\nElevasis is a production AI orchestration platform that coordinates workflows, autonomous agents, and human approvals into a unified operating layer for SMBs. Everything described below is implemented and running in production.\n\nCore Architecture:\n\n| Layer | What It Does | Key Components |\n| --- | --- | --- |\n| Execution | Runs workflows and agents with schema validation | Workflow Engine, Agent Framework, Execution Runner |\n| Control | Human oversight, approvals, and decision capture | Command Queue (HITL), Dynamic Forms, Action System |\n| Intelligence | Autonomous reasoning, tool use, and memory management | ReAct Agents, Knowledge Map, Session Memory |\n| Observability | Real-time visibility into cost, performance, and health | Cost Tracking, Metrics, Activity Log, SSE Streaming |\n| Platform | Multi-tenancy, security, scheduling, integrations | Registry, RLS, Scheduler, Credential Vault, SDK |\n\nExecution Engine\n\nAI Workflows\n\nGraph-based workflow execution with schema-validated steps and conditional routing. Steps define explicit routing: linear, conditional (rule-based branching), or terminal. Context flows through the entire workflow.\n\nAutonomous Agents\n\nProduction-grade ReAct-style agents with tool use, memory management, and security hardening.\n\nLLM Provider Support: Anthropic (claude-sonnet-5), OpenAI (GPT-5), OpenRouter (GLM-5)\n\nHuman-in-the-Loop (HITL)\n\nThe Command Queue surfaces pending approvals as structured tasks. Admin reviews, approves or edits, and the workflow continues. Every critical decision \xE2\u20AC\u201D sending emails to prospects, updating customer records, publishing content \xE2\u20AC\u201D requires human approval.\n\nIntegrations (12 active)\n\nAttio CRM, Cal.com, Instantly (cold email), Resend, Apify, Google Maps, Tomba, Mails.so, Supabase, Stripe, OpenAI, Anthropic Claude.\n\nSDK\n\nTypeScript-based resource development with local testing, validation, and deployment pipeline. External consumers define workflows and agents in their own repos and deploy via elevasis-sdk deploy."
-  },
-  {
-    id: "knowledge.client-testimonials",
-    title: "Testimonials",
-    summary: "Customer testimonials and case study permissions from previous client work",
-    bodyText: `Status: 4 testimonials from 2 clients | Source: Upwork client work (2024)
+Stage 04: Email Discovery
 
-Testimonials
+Discover contacts for qualified companies:
 
-Xero Automation \xE2\u20AC\u201D The Invoice Chase That Disappeared
+bash
+pnpm exec elevasis exec Elevasis/lgn-04-email-discovery-workflow --input '{"batchId":"{batch-id}"}' --async
 
-Client: Word of Mouth Agency
+Stage 05: Email Verification
 
-Result: 10+ hours/week saved. Zero manual follow-up emails.
+Verify discovered emails before campaign upload:
 
-> "Working with Alex at Elevasis to automate our Xero follow-ups has been a game-changer. We're set to save over 5 hours a week, but more importantly, it has completely removed the stress of chasing invoices. The process was smooth and professional."
+bash
+pnpm exec elevasis exec Elevasis/lgn-05-email-verification-workflow --input '{"batchId":"{batch-id}"}' --async
 
-Permission: Case study approved with company name.
+When verification completes, update the tracker with company counts, contact counts, usable email counts, and set the batch status to ready if campaign launch prerequisites are satisfied.
 
-Influencer Discovery \xE2\u20AC\u201D From Spreadsheet Hell to Strategic Decisions
+Launch the Campaign
 
-Client: Word of Mouth Agency (Perth, Australia)
+Use the acquisition outreach workflow to move a ready batch into Instantly:
 
-Result: 10+ hours/week saved. Research scope: 50 to 200+ influencers. Team focus shifted from data to strategy.
+1. Check account inventory with ist-account-inventory-workflow.
+2. Personalize contacts with ist-personalization-workflow.
+3. Create a draft campaign with ist-campaign-create-workflow and activate: false.
+4. Create the tracking list with ist-campaign-list-workflow.
+5. Upload contacts with ist-upload-contacts-workflow, dry run first and then real.
+6. Activate with ist-campaign-activate-workflow.
+7. Update the tracker to status: active and fill in campaign metadata.
 
-> "Working with Alex at Elevasis to automate our Influencer Discovery has been a game-changer. We're set to save over 5 hours a week..."
+Keep the first campaign small enough to evaluate copy and deliverability. Prefer 100-200 contacts per segment, 1-2 contacts per company, and conservative sending volume until benchmarks are visible.
 
-Permission: Case study approved with company name.
+Monitor and Optimize
 
-EMRG Media \xE2\u20AC\u201D 4 Automations for NYC's Premier Events Firm
+After launch, monitor both campaign metrics and inbound replies:
 
-Client: EMRG Media (NYC, est. 2001). Clients include Google, YouTube, Sony Music, Fiverr, Equinox.
+- Use /om acquisition outreach for campaign review and analytics.
+- Use /om acquisition inbound status for reply handling and active deal state.
+- Watch open rate, reply rate, positive reply rate, and bounce rate.
+- Pause or repair the campaign if bounce rate rises above the accepted threshold.
+- Rework subject lines, personalization, or offer framing when reply rate is below target.
 
-What We Built:
-1. Case Study Generator \xE2\u20AC\u201D 7-10 hours \xE2\u2020\u2019 2 hours. Publication rate: 1/quarter \xE2\u2020\u2019 2/month.
-2. EMRG Follow-Up Generator \xE2\u20AC\u201D Automated post-event follow-ups with signature management.
-3. Event Sponsor Tracker \xE2\u20AC\u201D Automated sponsor pipeline tracking and communications.
-4. Lead Scraper \xE2\u20AC\u201D Automated discovery of event planning prospects.
+Every optimization pass should write back to the tracker: what changed, why it changed, and what result would justify scaling the vertical.
 
-Fame Stats:
-- 3,500+ attendees at The Event Planner Expo
-- 25+ year track record
-- Fortune 500 client roster
+Launch Checklist
 
-Permission: Case study approved with company name.`
-  },
-  {
-    id: "knowledge.understanding-elevasis",
-    title: "Understanding Elevasis Overview",
-    summary: "Company overview, product positioning, and platform systems context for Elevasis AI orchestration platform",
-    bodyText: "Lean documentation explaining what Elevasis is and what the platform can do. This section provides the foundational context for business conversations and technical evaluation.\n\nElevasis is a done-for-you AI automation service backed by a production-grade platform. The company targets service-based SMBs (2-50 employees, $200K-$5M revenue) who are too busy serving clients to grow their own business.\n\nKey Facts\n\n- Stage: Pre-revenue, platform 100% complete, client acquisition active\n- Offer: Done-for-you AI automation -- we build and maintain the workflows, no coding required\n- ICP: Service-based SMBs (2-50 employees, $200K-$5M revenue, USA)\n- Pricing: $500-$2k/mo (Foundation) \xE2\u2020\u2019 $2k-$5k/mo (Scaled) \xE2\u2020\u2019 $5k-$15k+/mo (AI-Powered)\n- Market: Early Adopters stage, $23.77B TAM growing to $87.7B by 2032\n- Competitive position: No dominant done-for-you SMB AI provider exists; blue ocean\n\nWhen to Use Each Document\n\n| Situation | Document |\n| --- | --- |\n| First conversation with any audience | What is Elevasis |\n| Technical evaluation or demo prep | Platform Systems Overview |\n\nDocumentation\n\n- What is Elevasis \xE2\u20AC\u201D AI orchestration platform overview, company stage, value proposition, and pricing tiers\n- Platform Systems Overview \xE2\u20AC\u201D Authoritative overview of what is built, what each system does, and how the pieces fit together"
+- Batch ID selected with {vertical}-{number} naming.
+- Batch tracker created from the template.
+- Target description, geography, search queries, thresholds, and custom rules recorded.
+- Stage 01 scrape execution complete.
+- Website crawl complete or crawl gaps documented.
+- Stage 02 extraction complete.
+- Stage 03 qualification complete with explicit criteria source.
+- Stage 04 email discovery complete.
+- Stage 05 email verification complete.
+- Tracker status set to ready.
+- Draft Instantly campaign created.
+- Tracking list created and contacts uploaded.
+- Campaign activated.
+- Tracker status set to active with campaign metadata.`
   },
   {
-    id: "knowledge.marketing-overview",
-    title: "Marketing Overview",
-    summary: "Marketing documentation for Elevasis - strategy, website infrastructure, and content systems",
-    bodyText: "Welcome to the Elevasis marketing documentation. This section covers marketing strategy, website implementation, and content systems.\n\nDocumentation\n\nStrategy\n\n- Overview \xE2\u20AC\u201D Channel strategy, inbound content system, and proof-led demand generation\n\nWebsite\n\nThe marketing website's technical infrastructure, setup, and SEO docs now live under Architecture \xE2\u2020\u2019 Website."
+    id: "knowledge.outreach-campaign-playbook",
+    title: "Campaign Playbook",
+    summary: "Codified rules, benchmarks, and standard operating procedures for Instantly cold email campaigns -- testing methodology, personalization tiers, sequence structure, optimization loop, and batch readiness queries.",
+    bodyText: 'Benchmarks\n\nB2B cold email benchmarks (2025-2026). Use these as evaluation thresholds when running ist-analytics-workflow.\n\n| Metric | Bad | Needs Work | Good | Excellent |\n| --- | --- | --- | --- | --- |\n| Open Rate | \\<20% | 20-30% | 30-45% | 45%+ |\n| Reply Rate | \\<1% | 1-3% | 3-8% | 8%+ |\n| Positive Reply Rate | \\<0.5% | 0.5-1% | 1-3% | 3%+ |\n| Bounce Rate | \\>5% | 2-5% | 1-2% | \\<1% |\n\nCampaign Sizing Rules\n\n- 100-200 contacts per campaign segment -- small enough for meaningful personalization, large enough for statistical learning\n- 1-2 contacts per company -- reply rates drop from 8% to 4% when blasting 10+ people at the same company\n- 30-50 emails/day max per sending account\n- 50-100 emails/day total during testing (weeks 1-4), scaling to 500+/day once a winning formula is found\n\nTesting Priority\n\n1. Subject lines -- highest leverage, easiest to isolate\n2. Opening line / hook -- determines if they keep reading\n3. CTA type -- meeting request vs. soft question vs. value offer\n4. Body copy angle -- pain-point framing vs. benefit lead vs. social proof\n5. Send timing -- Tuesday-Thursday outperform Monday/Friday for B2B\n\nSequence Structure\n\n3 emails total (1 opener + 2 follow-ups). 87-95% of replies come within the first 3 emails.\n\n| Step | Timing | Strategy |\n| --- | --- | --- |\n| Email 1 | Day 0 | Cold read opener + EMRG social proof + interest-based CTA |\n| Email 2 | Day 3 | Short bump in same thread |\n| Email 3 | Day 5 | Breakup email. Soft close, loss aversion |\n\nAgent Optimization Loop\n\nPhase 1 (Launch): Verify batch readiness \xE2\u2020\u2019 Personalize \xE2\u2020\u2019 Create campaign \xE2\u2020\u2019 Create tracking list \xE2\u2020\u2019 Upload \xE2\u2020\u2019 Activate\n\nPhase 2 (Analyze Day 7-14): Run ist-campaign-review-workflow \xE2\u2020\u2019 Run ist-analytics-workflow \xE2\u2020\u2019 Interpret results\n\nPhase 3 (Optimize): Fix based on Phase 2 analysis (subject lines, personalization, bounce cleanup)\n\nPhase 4 (Scale): Document winning combination \xE2\u2020\u2019 Replicate to new segments \xE2\u2020\u2019 Maintain hygiene\n\nOffer Framing\n\n"We find one bottleneck, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."\n\n- Never use "free" in subject lines -- triggers spam filters\n- Frame as conditional, not charitable\n- Low-commitment CTAs get 2x more replies than direct meeting requests'
   },
   {
-    id: "knowledge.ai-orchestration-principles",
-    title: "AI Orchestration Principles",
-    summary: "The 4 principles that separate production AI from toy automation",
-    bodyText: `Most AI automation fails. Not because the technology is bad, but because it's implemented without the principles that make AI systems work in production.
+    id: "knowledge.outreach-copy-strategy",
+    title: "Copy Strategy",
+    summary: "Reusable email copy framework, tone rules, personalization input guidance, subject line patterns, and offer framing for cold outreach campaigns.",
+    bodyText: `Base reference for writing and evaluating campaign copy. Batch-specific email text lives in each batch tracker's Campaign Strategy section.
 
-These four principles separate toy automation from AI systems that actually run businesses.
+Offer
 
-The 4 Principles
+Core message: "We find one bottleneck in your business, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."
 
-1. Integrated: Works With Your Existing Systems
+- Never use "free" in subject lines or body copy
+- Frame as conditional, not charitable
+- Don't mention pricing in outreach
 
-Principle: AI must work with your existing tools, not replace them.
+Tone
 
-AI that doesn't connect to your CRM, your email, your calendar, your existing workflows is a toy. Real AI automation works WITH what you already have \xE2\u20AC\u201D not instead of it.
+- Voice: First person singular ("I" not "we")
+- Register: Conversational, direct, no jargon
+- Formatting: Plain text only. No bold, no links in body, no HTML
 
-- Your 50 Zapier workflows keep running
-- Your CRM stays your CRM
-- AI adds intelligence on top, not a rip-and-replace
+3-Email Sequence Framework
 
-The anti-pattern: "Use our AI instead of everything else." Creates vendor lock-in and throws away your existing investment.
+Email 1 \xE2\u20AC\u201D Hook + Offer (Day 0, 80 words)
 
-2. Improving: Gets Smarter Over Time
+Hi {{firstName | there}},
 
-Principle: AI must learn from every decision and improve continuously.
+{{openingline}}
 
-Static automation is just fancy if-then logic. Real AI captures every approval, rejection, and edit \xE2\u20AC\u201D then uses that data to get smarter.
+{{categorypain}}
 
-The anti-pattern: "Set it and forget it." Systems that don't learn stay dumb forever.
+I built 4 automations for a company that worked with Google and Sony Music. The first one alone saved them over $1,500 a month. I do the same thing for businesses like yours \xE2\u20AC\u201D you only pay if it actually works.
 
-3. Observable: You See What AI Is Doing
+Worth a quick look?
 
-Principle: You must be able to see what AI systems are doing in real-time.
+{{sendingAccountFirstName}}
 
-Black-box automation is unacceptable for business operations. You need to see every action, every decision, every cost \xE2\u20AC\u201D as it happens.
+Email 2 \xE2\u20AC\u201D Bump (Day 3, 40 words)
 
-- Real-time activity feeds showing what's executing
-- Cost tracking per workflow, per execution
-- Token usage visibility
-- Execution logs for debugging
+Hi {{firstName | there}},
 
-The anti-pattern: "It just works, trust us." Systems without observability create anxiety and prevent adoption.
+Wanted to circle back on this \xE2\u20AC\u201D I've been helping a few companies like {{companyName}} free up their team by automating the repetitive stuff that eats up the day.
 
-4. Governed: Humans Control What Matters
+Happy to take a 10-minute look \xE2\u20AC\u201D no pitch, just observations.
 
-Principle: Humans must approve important actions before execution.
+{{sendingAccountFirstName}}
 
-AI should handle the grunt work. But critical decisions \xE2\u20AC\u201D sending emails to prospects, updating customer records, publishing content \xE2\u20AC\u201D require human approval.
+Email 3 \xE2\u20AC\u201D Breakup (Day 5, 25 words)
 
-- AI researches 50 prospects and drafts personalized emails
-- Before anything sends, it lands in your approval queue
-- You spend 10 minutes reviewing, approve or tweak
-- Only then does it execute
+Totally understand if this isn't the right time. If you ever want a second pair of eyes on what could be automated at {{companyName}}, the offer stands.
 
-The anti-pattern: "Fully autonomous AI." Systems without governance create risk and erode trust.`
-  },
-  {
-    id: "knowledge.new-vertical-launch-playbook",
-    title: "New Vertical Launch Playbook",
-    summary: "Zero-to-first-campaign workflow for launching a new acquisition vertical: batch definition, tracker setup, lead generation stages, campaign launch, and monitoring.",
-    bodyText: `Overview
+{{sendingAccountFirstName}}
 
-Use this playbook when launching a new acquisition vertical from zero to first campaign. A vertical launch turns an audience hypothesis such as independent dental practices, auto repair shops, or bookkeeping firms into a tracked lead generation batch, qualified contacts, a draft Instantly campaign, and an active monitoring loop.
+Subject Lines
 
-The workflow has five phases:
+| Variant | Subject | Pattern |
+| --- | --- | --- |
+| A | quick thought | Colleague-camo |
+| B | about {{companyName}} | Observation-trigger |
 
-1. Define the batch and qualification rules.
-2. Create the batch tracker.
-3. Run the lead generation pipeline.
-4. Launch the outreach campaign.
-5. Monitor replies and campaign quality.
+- Target 21-40 characters
+- Personalized subjects: 46% open rate vs 35% without
+- No "free," "guaranteed," "urgent," "risk-free"`
+  },
+  {
+    id: "knowledge.outreach-playbook",
+    title: "Outreach Sequence Playbook",
+    summary: "Step-by-step runbook for launching a cold outreach campaign: prospect sourcing, copy review, sending schedule, and reply handling.",
+    bodyText: "Overview\n\nThis playbook covers the end-to-end process for launching a cold outreach campaign using the Elevasis lead-gen pipeline.\n\nSteps\n\n1. Source prospects via the Lead Gen feature.\n2. Review and approve copy in the CRM campaign editor.\n3. Schedule sends using the Task Scheduler.\n4. Monitor replies in the CRM inbox and route to the appropriate deal stage."
+  },
+  {
+    id: "knowledge.personalization-strategy",
+    title: "Personalization Strategy",
+    summary: "4-tier personalization waterfall, workflow inputs, quality rules, diagnostic process, and vertical adaptation for cold outreach opening line generation.",
+    bodyText: `How we generate personalized opening lines for Email 1. The ist-personalization-workflow produces ONLY the opening line.
 
-Define the Batch
+4-Tier Waterfall
 
-Choose a batch ID using the acquisition naming convention: {vertical}-{number}, for example dental-1, auto-1, or home-1.
+| Tier | Name | Trigger | Expected Reply Rate |
+| --- | --- | --- | --- |
+| 1 | Individual Signal | contact.enrichmentData.linkedin.summary exists | 10-15% |
+| 2 | Company Signal | Company has businessDescription OR services[] | 5-10% |
+| 3 | Basic Context | Company has categoryName OR category | 3-5% |
+| 4 | Minimal | Only company name and/or contact title | 1-3% |
 
-Record the batch configuration in the tracker before running pipeline stages. At minimum, capture:
+Workflow Inputs
 
-- Target description, such as "independent dental practices in Orange County, California".
-- Search queries for the initial source pull.
-- Region: county, state, country, or other geography accepted by the scraper workflow.
-- Minimum review count and minimum rating, when Google Maps quality thresholds matter.
-- Custom disqualification rules, such as excluding chains, franchises, pediatric-only practices, or irrelevant subcategories.
-- Website crawl keywords, such as about, team, staff, contact, services, or vertical-specific service pages.
+| Input | Purpose |
+| --- | --- |
+| batchId | Which contacts to personalize |
+| emailBody | Rest of Email 1 after {openingline} |
+| industryContext | Audience framing for LLM |
+| creativeDirection | Override default creative guidance |
+| performanceContext | Feedback from campaign results |
+| overwrite | Re-personalize existing opening lines |
 
-Use packages/elevasis-operations/src/sales/prospecting/constants.ts as the batch registry. Current launch work should keep the tracker as the human-readable source and pass qualification criteria through the workflow input, list qualification metadata, or the registered batch config for the stage being run.
+Quality Rules
 
-Create the Batch Tracker
+Core principle: Wrong personalization is worse than none. Accuracy > depth.
 
-Create a tracker from the acquisition batch template:
+Opening Line Style: Cold Read
 
-text
-apps/docs/content/docs/operations/client-acquisition/outreach/batches/template.mdx
+The opening line must earn attention through recognition, not create tension through a pitch setup. Take one real fact from enrichment data and make an observation that shows you actually looked at their business.
 
-Place the new tracker in the pending batch directory:
+Good examples:
+- "4,400 reviews since 2018 \xE2\u20AC\u201D that kind of growth in Orange County is honestly wild."
+- "60 years family-owned with a proprietary Clean Green method \xE2\u20AC\u201D that's rare in pest control."
 
-text
-apps/docs/content/docs/operations/client-acquisition/outreach/batches/pending/{batch-id}.mdx
+Anti-patterns:
+- "You do termite inspections \xE2\u20AC\u201D how many follow-up calls get missed?" (Implication \xE2\u20AC\u201D signals selling)
+- "Great company you've built!" (Generic flattery)`
+  },
+  {
+    id: "knowledge.pipeline-management-playbook",
+    title: "Pipeline Management",
+    summary: "Automated pipeline maintenance workflows for the inbound pipeline, covering timeout monitoring, stale deal handling, unsubscribe cleanup, and full contact reset.",
+    bodyText: "Overview\n\nPipeline management keeps the inbound pipeline clean without manual intervention.\n\n- Timeout monitoring \xE2\u20AC\u201D Detecting deals that have gone stale in a stage\n- Unsubscribe cleanup \xE2\u20AC\u201D Closing deals and cancelling automation when a contact opts out\n- Full cleanup \xE2\u20AC\u201D Complete removal of all pipeline data for a contact\n\nNo timeout action transitions a deal automatically. All stage changes from the timeout system require admin approval via a HITL Command Queue item.\n\nTimeout System\n\nTimeout Checker (inb-pipeline-timeout-checker-workflow)\n\nScans all active pipeline stages. For each stale deal, creates a HITL approval item in the Command Queue. Never modifies deal records directly.\n\nTimeout rules by stage:\n\n| Stage | Condition | Timeout |\n| --- | --- | --- |\n| interested | No activity | 30 days |\n| booked | Meeting time has passed | 3 hours after meeting |\n| discovery | No form submission | 24 hours after call |\n\nAction Workflows\n\n4 action workflows triggered by admin approval:\n- Nurture: Move to nurture sequence\n- Close-Lost: Mark deal closed, stop all automation\n- No-Show: Re-send booking link with personal note\n- Follow-Up: Send soft re-engagement email\n\nUnsubscribe Cleanup\n\nWhen a contact opts out:\n1. Find all active automation for the contact\n2. Cancel scheduled reminders\n3. Update Deal stage to unsubscribed\n4. Mark contact as unsubscribed in Attio"
+  },
+  {
+    id: "knowledge.seo-lead-gen-playbook",
+    title: "SEO-to-Lead-Gen Handoff Playbook",
+    summary: "Runbook for promoting SEO-qualified prospects into the active lead-gen pipeline: signal capture, scoring override, and campaign assignment.",
+    bodyText: "Overview\n\nThis playbook governs the handoff from SEO-sourced traffic to the lead-gen pipeline.\n\nSteps\n\n1. SEO feature captures visitor signal (form fill or intent data).\n2. Score the lead using the standard ICP scoring thresholds.\n3. If score \\>= 60, inject into the lead-gen prospect list.\n4. Assign to the appropriate outreach campaign in the CRM."
+  },
+  {
+    id: "knowledge.upwork-calibration-strategy",
+    title: "Upwork Calibration Strategy",
+    summary: "Deep calibration process for Upwork queries, including scan parameters, scoring, duplicate handling, output format, verdict criteria, and current calibration results.",
+    bodyText: "Overview\n\nUse this playbook when running a deep calibration scan for one or more Upwork queries. Calibration is separate from daily scanning: it evaluates query quality, competition, uniqueness, and noise patterns so the active saved-query set stays healthy.\n\nUse calibration when:\n\n- Testing a new query candidate before adding it to active scans.\n- Re-evaluating an active query whose health score has declined.\n- Running periodic re-calibration of the full active query set. Quarterly is the default cadence.\n\nUse knowledge.upwork-query-strategy for the active query table and knowledge.upwork-scanning-playbook for the daily scan workflow.\n\nScan Parameters\n\n| Parameter       | Value                  | Rationale                                                                               |\n| --------------- | ---------------------- | --------------------------------------------------------------------------------------- |\n| Max posts       | 20 per query           | Enough for confidence without turning calibration into an archive.                      |\n| Max age         | 2 weeks                | Captures 2 full hiring cycles; older posts are stale.                                   |\n| Filters         | U.S. only, Most Recent | Matches the standard scan surface while preserving full competition visibility.         |\n| Proposal filter | None                   | Calibration needs to see competition levels, not hide them.                             |\n| Extraction      | Search page script     | Capture title, snippet, budget, proposals, and client info without click-in enrichment. |\n\nCalibration Process\n\n1. Check the Upwork query registry for the exact candidate query and close variants.\n2. Re-test a dropped query only if the search terms or market conditions have changed.\n3. Navigate to https://www.upwork.com/nx/search/jobs/.\n4. Enter the query and apply U.S. only plus Most Recent sort.\n5. Run the search-card extraction script from the operations docs.\n6. If more than 20 results are visible, analyze only the first 20.\n7. If fewer than 20 results are visible, analyze all visible posts.\n8. Record the exact result count shown by Upwork in the search header.\n9. Score each extracted post with the calibration relevance rubric.\n10. For each post scoring 50+, check whether it appears in other query calibration docs.\n11. Write the per-query calibration doc and update the summary results.\n\nRelevance Rubric\n\nFor each extracted post, assign a relevance score from 0 to 100. The core question is whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Score Range | Tier         | Meaning                                                                                   |\n| ----------- | ------------ | ----------------------------------------------------------------------------------------- |\n| 75-100      | Strong fit   | Clear build intent, named platforms or tools, business context, and specific deliverable. |\n| 50-74       | Possible fit | Some build signals, but scope or domain is ambiguous.                                     |\n| 25-49       | Weak fit     | Marginally related and mostly noise.                                                      |\n| 0-24        | Irrelevant   | Hiring posts, marketing or design work, personal projects, manual work, or VA work.       |\n\nAuto-score disqualifiers in the 0-10 range even if they contain automation language:\n\n- Hiring for a role.\n- Marketing, design, or funnel work.\n- Manual or VA tasks.\n- Personal, non-business projects.\n\nDuplicate Handling\n\nFor each post scoring 50+, check whether the same job appeared in another query's calibration output. Mark it with DUPE: Q{N} when found.\n\nTrack total relevance and unique relevance separately. A query with 60% relevance but 0% unique relevance is usually not worth keeping because it adds scan time without adding opportunity coverage.\n\nOutput Format\n\nPer-query calibration docs use this naming pattern:\n\ntext\nq{NN}-{slug}.mdx\ncandidate-{slug}.mdx\nsummary.mdx\n\nUse active-query filenames such as q15-system-nouns.mdx and candidate filenames such as candidate-pipedrive.mdx.\n\nEach per-query doc should include:\n\n- Frontmatter with title, exact query, scan date, total Upwork result count, analyzed post count, relevant count, and verdict.\n- A ## Posts section with post-level scoring.\n- A ## Summary section with relevance rate, high-relevance count, perfect fits, low-competition gems, unique posts, noise patterns, why the query works or fails, and final verdict.\n\nKeep irrelevant posts short. Relevant posts should include budget, proposals, posted age, client signal, description snippet, relevance rationale, and uniqueness or duplicate marker.\n\nVerdict Criteria\n\n| Verdict           | Criteria                                                                                                                  |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------- |\n| KEEP (strong)     | More than 40% relevance, more than 20% unique relevance, more than 2 low-competition gems, and fresh posts within 1 week. |\n| KEEP (borderline) | 25-40% relevance, or low unique relevance but useful low-competition gems. Trial for 3 scans.                             |\n| MONITOR           | Relevant posts exist but are flooded with 20-50 proposals. Cherry-pick only; do not treat as a core saved search.         |\n| DROP              | Less than 20% relevance, 0 low-competition gems, dead volume under 5 results, or all stale posts older than 2 weeks.      |\n\nQuick vs Deep Calibration\n\n| Aspect          | Quick Screening                           | Deep Calibration                                       |\n| --------------- | ----------------------------------------- | ------------------------------------------------------ |\n| Purpose         | Fast keep/drop triage for new candidates. | Full analysis for active-query management.             |\n| Posts           | All visible, no hard max.                 | Max 20, max 2 weeks old.                               |\n| Scoring         | Inline summary table.                     | Per-post entries with rationale.                       |\n| Output          | Task notes or conversation.               | Dedicated calibration MDX document.                    |\n| Duplicate check | Informal overlap note.                    | Formal cross-reference with post numbers.              |\n| Use case        | Bulk screening 5+ candidates.             | Promotion, quarterly review, or declined health score. |\n\nCurrent Calibration Results\n\nLast full calibration: 2026-03-29.\n\nDeep scan results exist as original scan session notes. Formal per-query calibration files have not yet been written.\n\n| Current Q# | Query             | Total | Rel | Unique Rel | Calibration Status                             |\n| ---------- | ----------------- | ----- | --- | ---------- | ---------------------------------------------- |\n| Q1         | System nouns      | 47    | 60% | 30%        | Not yet written: q15-system-nouns.mdx.       |\n| Q2         | GHL               | 111   | 50% | 45%        | Not yet written: q16-ghl.mdx.                |\n| Q3         | AR/AP/Collections | 66    | 40% | 30%        | Not yet written: q01-ar-ap-collections.mdx.  |\n| Q4         | Inventory         | 69    | 40% | 35%        | Not yet written: q06-inventory.mdx.          |\n| Q5         | Invoice/billing   | 67    | 55% | 30%        | Not yet written: q04-invoice-billing.mdx.    |\n| Q6         | CRM               | 370   | 40% | 20%        | Not yet written: q08-crm.mdx.                |\n| Q7         | API integration   | 298   | 40% | 15%        | Not yet written: q14-api-integrate.mdx.      |\n| Q8         | Pipedrive         | 10    | 40% | 30%       | Quick scan only; no deep calibration file yet. |\n\nThe current query numbers match knowledge.upwork-query-strategy. The older calibration filenames reflect original 16-query scan numbering.\n\nNoise Patterns\n\nCommon noise patterns across calibrated queries:\n\n- Hiring posts: the top noise source across all queries, especially CRM and API searches.\n- Marketing and funnel work: especially common in GHL-adjacent searches.\n- Bookkeeper and accountant roles: common in AR/AP and invoice searches.\n- BI and analytics specialist work: common in invoice/billing and API searches.\n- High competition: broad CRM and API queries often attract 20-50+ proposals.\n\nCross-Query Overlap\n\nThe highest-overlap pairs from calibration:\n\n- Q3 AR/AP and Q5 Invoice/billing overlap heavily on financial automation posts.\n- Q6 CRM and Q7 API catch many of each other's broad integration posts.\n- Q1 System nouns produces the most unique gems and remains the strongest standalone query."
+  },
+  {
+    id: "knowledge.upwork-proposal-playbook",
+    title: "Proposal Playbook",
+    summary: "Data-backed strategies for writing winning Upwork proposals \xE2\u20AC\u201D structure, pricing, timing, client qualification, and benchmarks.",
+    bodyText: `The Numbers That Matter
 
-Fill in the frontmatter with status: in-progress, then complete the batch configuration table before running pipeline work. The tracker should make it possible to reconstruct the vertical, region, search inputs, disqualification rules, and campaign state without reading execution logs.
+| Metric | Benchmark |
+| --- | --- |
+| Personalized proposals | 30% higher reply rate vs generic |
+| Proposals within first 2 hours | 3x response rate vs 24h+ |
+| First-hour proposals | 3-5x interview rate boost |
 
-Run Lead Generation
+Proposal Structure
 
-Run the lead generation stages with the platform CLI from the monorepo root so .env.development and .env.production resolve correctly.
+Keep proposals 150-200 words, mobile-scannable.
 
-Stage 01: Google Maps Scrape
+The Five-Part Formula
 
-Use the Google Maps scrape workflow to acquire initial companies:
+1. Hook (1-2 sentences) \xE2\u20AC\u201D Lead with what you do and why it's relevant. Never use "caught my attention" \xE2\u20AC\u201D overused clich\xC3\xA9.
+2. Proof (1-2 sentences) \xE2\u20AC\u201D One concrete metric from past work.
+3. Plan (2-3 lines) \xE2\u20AC\u201D Maximum 3 steps.
+4. Discovery Questions (exactly 2) \xE2\u20AC\u201D Smart, role-specific questions. End with a binary CTA.
+5. Sample (optional) \xE2\u20AC\u201D Loom video (2-3 min).
 
-bash
-pnpm exec elevasis exec Elevasis/lgn-01a-google-maps-scrape-workflow --input '{"searchQueries":["dentist","dental clinic"],"county":"Orange County","state":"California"}' --async
+Opening Lines
 
-After the execution starts, record the execution ID and source counts in the batch tracker.
+The first line decides 80% of reply outcomes. Always use the client's name or company name.
 
-Local Website Crawl
+Good openers: "Hi \xE2\u20AC\u201D I build {whattheyneed} for a living and run my own business on them daily."
 
-Run the local website crawler against the batch:
+Never open with: "The part that caught my attention..." / "What stood out..."
 
-bash
-pnpm -C scripts/web-scraper run crawl -- {batch-id}
+Elevasis-Specific Positioning
 
-The crawl should capture relevant sub-pages for LLM extraction. If vertical-specific keywords are not available in the active code path, use the default crawl coverage and note any manual crawl gaps in the tracker before extraction.
+Dogfooding (Strongest Differentiator): We run our own 7-stage client acquisition pipeline on the platform: Scrape \xE2\u2020\u2019 Extract \xE2\u2020\u2019 Qualify \xE2\u2020\u2019 Email Discovery \xE2\u2020\u2019 Verify \xE2\u2020\u2019 Personalize \xE2\u2020\u2019 Outreach.
 
-Stage 02: Website Extract
+The 4 Principles (Use in Discovery Questions):
+1. Integrated \xE2\u20AC\u201D Works with existing tools
+2. Improving \xE2\u20AC\u201D Learns from every human decision
+3. Observable \xE2\u20AC\u201D Real-time visibility
+4. Governed \xE2\u20AC\u201D Humans approve what matters`
+  },
+  {
+    id: "knowledge.upwork-query-strategy",
+    title: "Upwork Query Strategy",
+    summary: "Active saved-query set, tiering, calibration outcomes, query-design principles, and failure modes for the Upwork acquisition channel.",
+    bodyText: 'Overview\n\nUse this reference to choose which Upwork saved searches to scan, understand why each query is active, and avoid repeating failed discovery work. The active query set targets niche operations and business-process automation jobs rather than broad "AI automation" searches, which are usually saturated.\n\nUse knowledge.upwork-scanning-playbook for the scan workflow and knowledge.upwork-calibration-strategy for deep query calibration.\n\nActive Saved Queries\n\nThe active saved-query set has 14 queries as of 2026-03-31. Q1-Q7 were kept after the full calibration scan of the original 16 queries. Q8 Pipedrive was added after SaaS platform calibration. Q9-Q14 are formerly monitor-tier queries moved into active scanning with stricter freshness and competition discipline.\n\n| Tier | #   | Query                                                                                                                                                                                                     | Relevance | Unique Rel | Rationale                                                                                                                  |\n| ---- | --- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ---------- | -------------------------------------------------------------------------------------------------------------------------- |\n| T1   | 1   | ("booking system" OR "intake form" OR "scheduling system" OR "ticketing system" OR "tracking system" OR "reservation system" OR "billing system" OR "payment system") AND (build OR automate OR custom) | 60%       | 30%        | Best query. SMB owners describe systems they need built. Lowest competition and highest ROI per connect.                   |\n| T1   | 2   | ("GoHighLevel" OR "GHL") AND (build OR setup OR integration OR workflow OR automate)                                                                                                                    | 50%       | 45%        | GHL niche with high unique relevance. "Funnel" was removed because it pulled marketing noise; "automate" replaced it.      |\n| T2   | 3   | ("accounts receivable" OR "accounts payable" OR "collections") AND automate                                                                                                                             | 40%       | 30%        | "Automate" catches real builds and maps to the Xero testimonial. Some overlap with Q1 and Q7.                              |\n| T2   | 4   | "inventory" AND ("automation" OR "integration" OR "sync")                                                                                                                                               | 40%       | 35%        | Inventory system builds are unique to this query. Low cross-query overlap.                                                 |\n| T3   | 5   | ("invoice" OR "billing") AND ("automate" OR "integration")                                                                                                                                              | 55%       | 30%        | Finds healthcare EDI, Stripe Connect, and Power Automate AP work. Heavy Q3 overlap.                                        |\n| T3   | 6   | "CRM" AND ("integration" OR "automate" OR "migrate")                                                                                                                                                    | 40%       | 20%        | Finds Twenty CRM, HubSpot Service Hub, and Zoho automation. Noisy and high-volume.                                         |\n| T3   | 7   | "integrate" AND "API" AND (build OR develop OR custom)                                                                                                                                                  | 40%       | 15%        | Finds strong integration work such as Authorize.Net webhooks and Email-to-ERP pipelines. Competition is often high.        |\n| T3   | 8   | "Pipedrive" AND (build OR setup OR integration OR workflow OR automate)                                                                                                                                 | 40%       | 30%       | CRM setup and automation builds. Only platform query besides GHL to pass calibration. Trial query; evaluate after 3 scans. |\n| T4   | 9   | ("Zapier" OR "Make.com" OR "n8n") AND (automate OR build OR workflow)                                                                                                                                   | Very high | --         | High relevance but competition risk. Apply only to posts with fewer than 10 proposals.                                     |\n| T4   | 10  | "SaaS" AND ("MVP" OR "prototype") AND (build OR develop)                                                                                                                                                | High      | --         | Bimodal competition: some low-proposal gems, some flooded posts. Skip flooded posts.                                       |\n| T4   | 11  | "Google Sheets" AND (automate OR app OR dashboard OR replace)                                                                                                                                           | 40%      | --         | Fresh and even competition spread. Good posts get flooded quickly, so prioritize speed.                                    |\n| T4   | 12  | "chatbot" AND (build OR custom OR develop)                                                                                                                                                              | 25%      | --         | Low relevance baseline. Pulls AI engineering hiring and chat UI work, but occasional SMB gems exist.                       |\n| T4   | 13  | ("voice agent" OR "AI receptionist") AND (build OR develop OR custom)                                                                                                                                   | High      | --         | Very low volume, often 1-2 results. High quality when fresh posts appear.                                                  |\n| T4   | 14  | "sales funnel" AND (automate OR build OR system OR custom)                                                                                                                                              | 40%      | --         | Fresh GHL integrations and CRM builds mixed with affiliate-funnel noise. Filter hard.                                      |\n\nAll active queries use the Upwork proposal-count filters "Less than 5" and "5 to 10". Tier 1 queries are the primary scan focus. Tier 2 queries are solid contributors. Tier 3 queries are borderline and should be dropped if health scores decline across 3 or more scans. Tier 4 queries have higher competition risk and should only be applied to fresh, low-proposal posts.\n\nQuery Design Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches when system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, and inventory sync.\n- The Q1 pattern: specific system noun plus action verb. This catches clients describing the thing they need built.\n- The proposal-count filter from 0-10 proposals. Competition control is non-negotiable.\n\nAvoid:\n\n- Vertical keywords such as clinic, contractor, salon, or real estate. On Upwork these usually pull marketing or hiring posts for that industry, not system buyers from that industry.\n- Pain-signal phrases such as "hours per week", "manual", "repetitive", or "bottleneck". On Upwork these usually mean the client is hiring humans to perform the work.\n- Migration terms such as migrate, replace, or switch unless tied to a concrete platform or system. Generic migration queries pull website and email platform changes.\n- Broad tool or category nouns such as portal, dashboard, tool, or custom without a specific system type.\n- Solution-first keywords such as AI automation, AI agent, and workflow automation. They attract the saturated AI freelancer crowd.\n- Revenue-proximity service terms such as cold email, outbound, nurture, appointment setting, and qualify leads. These are proposal-positioning angles, not good Upwork query filters.\n- Professional-service terms such as contract review, due diligence, or reputation management. They pull human professionals rather than system builds.\n\nQuery Evolution\n\nDiscovery is complete for the current strategy: 127 queries were tested across 18 rounds and calibrated to 14 active queries. The current ROI lever is execution quality: faster scans, stronger proposal targeting, and query-health monitoring.\n\nQ1 has 8 proven system nouns:\n\n- Booking system.\n- Intake form.\n- Scheduling system.\n- Ticketing system.\n- Tracking system.\n- Reservation system.\n- Billing system.\n- Payment system.\n\nTwenty-three other system nouns were tested and failed. Before testing any new query, check the Upwork query registry in the operations docs for prior verdicts and failure modes.\n\nKnown Limitations\n\n- The "U.S. only" checkbox does not persist with saved searches. It is a session-only filter and must be manually checked each time a saved search loads.\n- Upwork search is not strict phrase matching. A quoted phrase such as "client portal" can still match posts containing the words separately.\n- Relevance percentages are from the expanded 2026-03-29 evaluation: 147 jobs across 15 queries plus 32-query discovery analysis. Re-evaluate monthly as job mix shifts.\n\nLive Reference Docs\n\nPreserve these operations docs because they remain live working references rather than migrated Knowledge Map content:\n\n- apps/docs/content/docs/operations/client-acquisition/upwork/query-registry.mdx tracks all 127 tested queries, verdicts, and failure modes.\n- apps/docs/content/docs/operations/client-acquisition/upwork/scripts.mdx stores runnable browser extraction scripts and current Upwork DOM notes.'
+  },
+  {
+    id: "knowledge.upwork-response-templates",
+    title: "Response Templates",
+    summary: "Templates and guidelines for responding to Upwork messages, offers, and client communications.",
+    bodyText: `Offer Acceptance Response
 
-Extract structured company profile data from crawl output:
+When a client sends an offer and invites a call:
+1. Thank them for the offer (brief, no flattery)
+2. Confirm the call with a specific day/time and timezone
+3. Ask 2-3 qualifying questions to show engagement
+4. Sign off with first name (Alex, not Alexander)
 
-bash
-pnpm exec elevasis exec Elevasis/lgn-02-website-extract-workflow --input '{"batchId":"{batch-id}"}' --async
+Template
 
-Stage 03: Company Qualification
+Hi {name},
 
-Qualify companies using the target description, review thresholds, rating thresholds, and custom rules captured in the tracker. If the workflow does not resolve criteria automatically for the batch, pass the criteria explicitly in the input or attach them through the list qualification surface before running the stage.
+Thanks for the offer and for reaching out, I'll book a time for {day} {time} ({timezone}). I look forward to learning more about your setup!
 
-bash
-pnpm exec elevasis exec Elevasis/lgn-03-company-qualification-workflow --input '{"batchId":"{batch-id}","criteria":{"targetDescription":"Independent dental practices in Orange County, California","minimumReviewCount":5,"minimumRating":3,"customRules":"Disqualify franchises and chains. Disqualify orthodontics-only and pediatric-only practices."}}' --async
+Just a few questions:
+1. {qualifying question about current tools/stack}
+2. {qualifying question about current process/pain}
+3. {qualifying question about scope/direction}
 
-For list-oriented runs, use listId instead of batchId; list configuration takes priority over the batch registry unless an explicit criteria override is provided.
+Thanks!
+Alex
 
-Stage 04: Email Discovery
+Qualifying Question Bank
 
-Discover contacts for qualified companies:
+- Current stack: "What do you currently use for workflows / automation?"
+- Pain points: "What's the most time-consuming repetitive task right now?"
+- Approval flow: "What do you currently use for approval control?"
+- Consolidation: "Are you using multiple tools or interested in custom software?"
+- Team size: "How many people will be using these workflows?"
+- Priority: "What's the first workflow you'd want built?"
 
-bash
-pnpm exec elevasis exec Elevasis/lgn-04-email-discovery-workflow --input '{"batchId":"{batch-id}"}' --async
+Style Rules
 
-Stage 05: Email Verification
+- Tone: Warm but concise. No filler, no over-enthusiasm.
+- Length: 3-6 sentences max.
+- Timezone: Always specify timezone when confirming times (PDT/PST).
+- No selling: The call is for learning, not pitching.`
+  },
+  {
+    id: "knowledge.upwork-scanning-playbook",
+    title: "Upwork Scanning Playbook",
+    summary: "Stable scanning, scoring, freshness, and query-health workflow for the Upwork acquisition channel.",
+    bodyText: 'Overview\n\nUse this playbook to run the Upwork acquisition scanning loop. The goal is to find fresh, low-competition jobs where Elevasis can deliver a real business system, score them consistently, and turn the best opportunities into proposals through the Upwork proposal playbook.\n\nThe scanning loop has six phases:\n\n1. Confirm browser and login readiness.\n2. Run saved search queries with the right filters.\n3. Extract fresh job cards.\n4. Deduplicate, score, and enrich strong candidates.\n5. Write the scan output.\n6. Review query health before the next scan.\n\nProposal copy and response handling are intentionally separate. Use knowledge.upwork-proposal-playbook for proposal strategy and knowledge.upwork-response-templates for client replies.\n\nPreconditions\n\nBefore scanning, verify the browser automation surface is available and Upwork is logged in.\n\n- Chrome tooling must be available through the active browser automation tools.\n- The Upwork search page must load at https://www.upwork.com/nx/search/jobs/.\n- The page must show the job search interface, not a login prompt.\n- If login is required, stop and log in manually before scanning again.\n\nDo not try to work around a missing browser session by inventing scan results. The scan depends on live Upwork search pages, current saved-search filters, and the visible result cards.\n\nScan Surface\n\nRun scans from the Upwork search page:\n\ntext\nhttps://www.upwork.com/nx/search/jobs/\n\nEach saved query is run individually. Apply the filters every time, because Upwork search state is session-dependent and not always persisted across queries.\n\n| Filter    | Value       | Reason                                                                 |\n| --------- | ----------- | ---------------------------------------------------------------------- |\n| U.S. only | Checked     | Higher-quality clients, stronger timezone fit, more verified payments. |\n| Sort by   | Most Recent | Freshness is the strongest conversion lever.                           |\n| Proposals | \\<5, 5-10 | Low competition is required before spending connects.                  |\n\nUse saved queries as the primary scan source. The strategy targets operational system-build terms, not generic "AI automation" searches that attract high competition.\n\nFreshness Rule\n\nOnly collect posts from the last 12 hours. Results should be sorted by Most Recent, so stop extracting for a query once the visible posts are older than 12 hours. Do not do catch-up windows.\n\nFreshness priority:\n\n| Post age   | Action                                                           |\n| ---------- | ---------------------------------------------------------------- |\n| 0-1 hour   | Highest priority. Client is most likely active and shortlisting. |\n| 1-12 hours | Valid scan window. Still worth scoring if competition is low.    |\n| 12+ hours  | Skip. The client has usually already formed the shortlist.       |\n\nRecord the scan timestamp as lastscanned in the daily scan doc frontmatter. This timestamp helps avoid reprocessing posts from prior scans, but the hard 12-hour cap still applies.\n\nRun Each Query\n\nFor each active saved query:\n\n1. Clear the search box.\n2. Enter the query string and submit.\n3. Apply U.S. only, Most Recent, and proposal-count filters.\n4. Wait for results to render.\n5. Extract visible job cards from the search page.\n6. Stop once a post exceeds the freshness cutoff.\n7. Tag each job with the source query.\n\nThe first page of most-recent, low-proposal results is the high-value slice. Do not paginate unless a specific investigation requires it.\n\nWhile scanning the API integration query, flag custom dashboard opportunities where a custom build is likely better than Power BI, Looker, Tableau, or a spreadsheet. Strong signs include 3+ data sources, live dashboard requirements, AI-generated summaries, anomaly detection, or workflow triggers.\n\nExtract Job Card Data\n\nThe search-card extraction should capture the fields needed for initial triage:\n\n- Title.\n- Upwork job URL path.\n- Posted age.\n- Proposal count.\n- Budget or hourly range.\n- Payment verification.\n- Client rating.\n- Total client spend.\n- Description snippet.\n- Source query.\n\nDeduplicate by Upwork job URL path after all queries finish. If a job appears under multiple queries, keep one row and note the overlap.\n\nScore and Enrich\n\nScoring has two stages.\n\nStage 1: Relevance\n\nScore relevance from 0 to 100 by asking whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Range  | Label        | Criteria                                                                  |\n| ------ | ------------ | ------------------------------------------------------------------------- |\n| 75-100 | Strong fit   | Clear build intent, specific business workflow, named tools or outputs.   |\n| 50-74  | Possible fit | Some build signals, but scope or buyer intent is ambiguous.               |\n| 25-49  | Weak fit     | Marginally related, mostly noise, low business-system signal.             |\n| 0-24   | Irrelevant   | Hiring, marketing, design, manual VA work, personal projects, or errands. |\n\nDisqualify posts that are clearly hiring a role, outsourcing manual work, asking for generic marketing/design help, or describing a personal/non-business project.\n\nStage 2: Application Priority\n\nApply tactical modifiers after relevance scoring. The final score determines whether to draft a proposal.\n\n| Signal         | Positive indicators                                  | Negative indicators                         |\n| -------------- | ---------------------------------------------------- | ------------------------------------------- |\n| Freshness      | \\<1h or same-session post.                         | 8-12h old, or outside the scan window.      |\n| Competition    | \\<5 proposals, or 5-10 with strong fit.            | 10+ proposals, especially 20+.              |\n| Client quality | Payment verified, spend history, good rating, hires. | Unverified, no history, 0% hire rate.       |\n| Budget         | Fixed \\>$5K or hourly \\>$75/hr.                  | Fixed \\<$1K or hourly \\<$40/hr.         |\n| Fit            | Workflow, integration, dashboard, CRM, operations.   | Copywriting, funnels, ads, hiring, support. |\n\nOnly enrich posts with a strong enough relevance score to matter, usually 65+. For those posts, open the job detail view and capture:\n\n- Hire rate.\n- Jobs posted.\n- Member since.\n- Company size.\n- Last viewed by client.\n- Interviewing count.\n\nUse this data to avoid over-ranking stale or low-quality clients that have a good-sounding job description but weak application ROI.\n\nWrite the Scan Output\n\nWrite scan docs under:\n\ntext\napps/docs/content/docs/operations/client-acquisition/upwork/scans/{YYYY-MM-DD}.mdx\n\nIf a scan doc already exists for the day, append the new scan as a later section instead of creating a second daily file.\n\nEach scan output should include:\n\n- Date and timestamp.\n- Freshness cutoff.\n- Queries scanned.\n- Total posts collected.\n- Deduplicated count.\n- Top opportunities only.\n- Comparison table.\n- Query health table.\n- Draft proposals section, when proposals are generated.\n\nKeep scan docs as decision tools, not archives. Include the top 10 ranked opportunities rather than every collected post.\n\nQuery Health\n\nAfter scoring, compute a query-health score so weak searches can be removed over time.\n\n| Metric          | Measurement                                                       | Weight |\n| --------------- | ----------------------------------------------------------------- | ------ |\n| Fresh posts     | Count within cutoff, normalized against 5 posts.                  | 25%    |\n| Low competition | Percent with fewer than 10 proposals.                             | 25%    |\n| Relevance       | Percent actionable after deduplication and disqualification.      | 30%    |\n| Client quality  | Percent with verified payment and useful spend or rating signals. | 20%    |\n\nQueries that score 0 across 3+ consecutive scans are drop candidates. Compare the latest query-health table with the previous scan before changing the active query set.\n\nActive Query Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches where system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, or inventory sync.\n\nAvoid:\n\n- Broad solution-first terms such as AI automation, AI agent, workflow automation, portal, dashboard, tool, or custom without a specific system noun.\n- Vertical keywords such as clinic, contractor, salon, or real estate unless paired with concrete system intent.\n- Pain-signal phrases that usually mean the client is hiring a human to perform manual work.\n- Revenue-proximity service terms such as cold email, appointment setting, outbound specialist, or funnel work.\n\nBefore testing a new query, read knowledge.upwork-query-strategy and check the Upwork query registry in the operations docs so old failure modes are not repeated. Use knowledge.upwork-calibration-strategy when promoting, dropping, or re-evaluating saved searches.\n\nProposal Handoff\n\nAfter the scan, draft proposals only for opportunities that remain strong after relevance, tactical modifiers, and client-quality checks.\n\nFor proposal drafting:\n\n1. Load knowledge.upwork-proposal-playbook.\n2. Read the top opportunities from the latest scan doc.\n3. Select the right proposal template by scope, budget, and relevance.\n4. Tailor the opening, proof point, plan, and two discovery questions.\n5. Append draft proposals to the scan doc under ## Draft Proposals.\n\nUse knowledge.upwork-response-templates after a client replies or sends an offer.\n\nScan Checklist\n\n- Browser tooling available.\n- Upwork logged in.\n- Search page loaded.\n- U.S. only filter applied.\n- Sort set to Most Recent.\n- Proposal-count filters applied.\n- All active saved queries scanned.\n- Posts older than 12 hours skipped.\n- Jobs deduplicated by URL path.\n- Relevance scores assigned.\n- Strong candidates enriched from detail view.\n- Final scores sorted descending.\n- Daily scan doc created or appended.\n- Query health table written.\n- Top proposal candidates handed to knowledge.upwork-proposal-playbook.'
+  },
+  {
+    id: "knowledge.vertical-messaging-playbook",
+    title: "Vertical Messaging Playbook",
+    summary: "Research-backed messaging strategy per vertical \xE2\u20AC\u201D verified claims, owner voice, language guides, pain point framing, and copy guidelines for outreach messaging.",
+    bodyText: `Purpose
 
-Verify discovered emails before campaign upload:
+Reference doc for writing and evaluating vertical-specific outreach copy. Captures verified research, owner voice and language, and per-vertical messaging strategy.
 
-bash
-pnpm exec elevasis exec Elevasis/lgn-05-email-verification-workflow --input '{"batchId":"{batch-id}"}' --async
+Grounded Relatability Strategy
 
-When verification completes, update the tracker with company counts, contact counts, usable email counts, and set the batch status to ready if campaign launch prerequisites are satisfied.
+Layer 1: Claim Verification
+Web-research every statistical claim. Grade each as Tier 1 (Verified), Tier 2 (Plausible), or Tier 3 (Unverified). Drop or soften anything Tier 3.
 
-Launch the Campaign
+Layer 2: Voice-of-Customer Research
+Search Reddit, trade forums, and industry communities for how owners actually talk about their frustrations.
 
-Use the acquisition outreach workflow to move a ready batch into Instantly:
+Layer 3: Scenario-First Copy
+Combine verified claims with owner language to write copy that sounds like a peer, not a vendor:
+1. Lead with the scenario
+2. Use their vocabulary
+3. Reinforce with stats only if they pass the "would I trust this from a stranger?" test
+4. Name concrete capabilities
 
-1. Check account inventory with ist-account-inventory-workflow.
-2. Personalize contacts with ist-personalization-workflow.
-3. Create a draft campaign with ist-campaign-create-workflow and activate: false.
-4. Create the tracking list with ist-campaign-list-workflow.
-5. Upload contacts with ist-upload-contacts-workflow, dry run first and then real.
-6. Activate with ist-campaign-activate-workflow.
-7. Update the tracker to status: active and fill in campaign metadata.
+Universal Owner Patterns
 
-Keep the first campaign small enough to evaluate copy and deliverability. Prefer 100-200 contacts per segment, 1-2 contacts per company, and conservative sending volume until benchmarks are visible.
+- The Identity Gap: They started the business to do the craft. Acknowledging this resonates deeply.
+- Phone = Business: The owner's phone IS the business.
+- Software Cynicism: Every vertical has been sold to aggressively by SaaS vendors.
 
-Monitor and Optimize
+Words That Work Everywhere: "Stop losing...", "Without lifting a finger", "Less software, not more"
 
-After launch, monitor both campaign metrics and inbound replies:
+Words That Fail Everywhere: "AI-powered", "Scale your business", "Digital transformation"
 
-- Use /om acquisition outreach for campaign review and analytics.
-- Use /om acquisition inbound status for reply handling and active deal state.
-- Watch open rate, reply rate, positive reply rate, and bounce rate.
-- Pause or repair the campaign if bounce rate rises above the accepted threshold.
-- Rework subject lines, personalization, or offer framing when reply rate is below target.
+Copy Principles
 
-Every optimization pass should write back to the tracker: what changed, why it changed, and what result would justify scaling the vertical.
+Lead with Scenarios, Not Statistics
 
-Launch Checklist
+| Weak (stat-first) | Strong (scenario-first) |
+| --- | --- |
+| "78% of homeowners hire the first contractor who responds." | "When you're on a job, you can't answer the phone \xE2\u20AC\u201D but the homeowner already called two other plumbers." |
 
-- Batch ID selected with {vertical}-{number} naming.
-- Batch tracker created from the template.
-- Target description, geography, search queries, thresholds, and custom rules recorded.
-- Stage 01 scrape execution complete.
-- Website crawl complete or crawl gaps documented.
-- Stage 02 extraction complete.
-- Stage 03 qualification complete with explicit criteria source.
-- Stage 04 email discovery complete.
-- Stage 05 email verification complete.
-- Tracker status set to ready.
-- Draft Instantly campaign created.
-- Tracking list created and contacts uploaded.
-- Campaign activated.
-- Tracker status set to active with campaign metadata.`
-  },
-  {
-    id: "knowledge.upwork-calibration-strategy",
-    title: "Upwork Calibration Strategy",
-    summary: "Deep calibration process for Upwork queries, including scan parameters, scoring, duplicate handling, output format, verdict criteria, and current calibration results.",
-    bodyText: "Overview\n\nUse this playbook when running a deep calibration scan for one or more Upwork queries. Calibration is separate from daily scanning: it evaluates query quality, competition, uniqueness, and noise patterns so the active saved-query set stays healthy.\n\nUse calibration when:\n\n- Testing a new query candidate before adding it to active scans.\n- Re-evaluating an active query whose health score has declined.\n- Running periodic re-calibration of the full active query set. Quarterly is the default cadence.\n\nUse knowledge.upwork-query-strategy for the active query table and knowledge.upwork-scanning-playbook for the daily scan workflow.\n\nScan Parameters\n\n| Parameter       | Value                  | Rationale                                                                               |\n| --------------- | ---------------------- | --------------------------------------------------------------------------------------- |\n| Max posts       | 20 per query           | Enough for confidence without turning calibration into an archive.                      |\n| Max age         | 2 weeks                | Captures 2 full hiring cycles; older posts are stale.                                   |\n| Filters         | U.S. only, Most Recent | Matches the standard scan surface while preserving full competition visibility.         |\n| Proposal filter | None                   | Calibration needs to see competition levels, not hide them.                             |\n| Extraction      | Search page script     | Capture title, snippet, budget, proposals, and client info without click-in enrichment. |\n\nCalibration Process\n\n1. Check the Upwork query registry for the exact candidate query and close variants.\n2. Re-test a dropped query only if the search terms or market conditions have changed.\n3. Navigate to https://www.upwork.com/nx/search/jobs/.\n4. Enter the query and apply U.S. only plus Most Recent sort.\n5. Run the search-card extraction script from the operations docs.\n6. If more than 20 results are visible, analyze only the first 20.\n7. If fewer than 20 results are visible, analyze all visible posts.\n8. Record the exact result count shown by Upwork in the search header.\n9. Score each extracted post with the calibration relevance rubric.\n10. For each post scoring 50+, check whether it appears in other query calibration docs.\n11. Write the per-query calibration doc and update the summary results.\n\nRelevance Rubric\n\nFor each extracted post, assign a relevance score from 0 to 100. The core question is whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Score Range | Tier         | Meaning                                                                                   |\n| ----------- | ------------ | ----------------------------------------------------------------------------------------- |\n| 75-100      | Strong fit   | Clear build intent, named platforms or tools, business context, and specific deliverable. |\n| 50-74       | Possible fit | Some build signals, but scope or domain is ambiguous.                                     |\n| 25-49       | Weak fit     | Marginally related and mostly noise.                                                      |\n| 0-24        | Irrelevant   | Hiring posts, marketing or design work, personal projects, manual work, or VA work.       |\n\nAuto-score disqualifiers in the 0-10 range even if they contain automation language:\n\n- Hiring for a role.\n- Marketing, design, or funnel work.\n- Manual or VA tasks.\n- Personal, non-business projects.\n\nDuplicate Handling\n\nFor each post scoring 50+, check whether the same job appeared in another query's calibration output. Mark it with DUPE: Q{N} when found.\n\nTrack total relevance and unique relevance separately. A query with 60% relevance but 0% unique relevance is usually not worth keeping because it adds scan time without adding opportunity coverage.\n\nOutput Format\n\nPer-query calibration docs use this naming pattern:\n\ntext\nq{NN}-{slug}.mdx\ncandidate-{slug}.mdx\nsummary.mdx\n\nUse active-query filenames such as q15-system-nouns.mdx and candidate filenames such as candidate-pipedrive.mdx.\n\nEach per-query doc should include:\n\n- Frontmatter with title, exact query, scan date, total Upwork result count, analyzed post count, relevant count, and verdict.\n- A ## Posts section with post-level scoring.\n- A ## Summary section with relevance rate, high-relevance count, perfect fits, low-competition gems, unique posts, noise patterns, why the query works or fails, and final verdict.\n\nKeep irrelevant posts short. Relevant posts should include budget, proposals, posted age, client signal, description snippet, relevance rationale, and uniqueness or duplicate marker.\n\nVerdict Criteria\n\n| Verdict           | Criteria                                                                                                                  |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------- |\n| KEEP (strong)     | More than 40% relevance, more than 20% unique relevance, more than 2 low-competition gems, and fresh posts within 1 week. |\n| KEEP (borderline) | 25-40% relevance, or low unique relevance but useful low-competition gems. Trial for 3 scans.                             |\n| MONITOR           | Relevant posts exist but are flooded with 20-50 proposals. Cherry-pick only; do not treat as a core saved search.         |\n| DROP              | Less than 20% relevance, 0 low-competition gems, dead volume under 5 results, or all stale posts older than 2 weeks.      |\n\nQuick vs Deep Calibration\n\n| Aspect          | Quick Screening                           | Deep Calibration                                       |\n| --------------- | ----------------------------------------- | ------------------------------------------------------ |\n| Purpose         | Fast keep/drop triage for new candidates. | Full analysis for active-query management.             |\n| Posts           | All visible, no hard max.                 | Max 20, max 2 weeks old.                               |\n| Scoring         | Inline summary table.                     | Per-post entries with rationale.                       |\n| Output          | Task notes or conversation.               | Dedicated calibration MDX document.                    |\n| Duplicate check | Informal overlap note.                    | Formal cross-reference with post numbers.              |\n| Use case        | Bulk screening 5+ candidates.             | Promotion, quarterly review, or declined health score. |\n\nCurrent Calibration Results\n\nLast full calibration: 2026-03-29.\n\nDeep scan results exist as original scan session notes. Formal per-query calibration files have not yet been written.\n\n| Current Q# | Query             | Total | Rel | Unique Rel | Calibration Status                             |\n| ---------- | ----------------- | ----- | --- | ---------- | ---------------------------------------------- |\n| Q1         | System nouns      | 47    | 60% | 30%        | Not yet written: q15-system-nouns.mdx.       |\n| Q2         | GHL               | 111   | 50% | 45%        | Not yet written: q16-ghl.mdx.                |\n| Q3         | AR/AP/Collections | 66    | 40% | 30%        | Not yet written: q01-ar-ap-collections.mdx.  |\n| Q4         | Inventory         | 69    | 40% | 35%        | Not yet written: q06-inventory.mdx.          |\n| Q5         | Invoice/billing   | 67    | 55% | 30%        | Not yet written: q04-invoice-billing.mdx.    |\n| Q6         | CRM               | 370   | 40% | 20%        | Not yet written: q08-crm.mdx.                |\n| Q7         | API integration   | 298   | 40% | 15%        | Not yet written: q14-api-integrate.mdx.      |\n| Q8         | Pipedrive         | 10    | 40% | 30%       | Quick scan only; no deep calibration file yet. |\n\nThe current query numbers match knowledge.upwork-query-strategy. The older calibration filenames reflect original 16-query scan numbering.\n\nNoise Patterns\n\nCommon noise patterns across calibrated queries:\n\n- Hiring posts: the top noise source across all queries, especially CRM and API searches.\n- Marketing and funnel work: especially common in GHL-adjacent searches.\n- Bookkeeper and accountant roles: common in AR/AP and invoice searches.\n- BI and analytics specialist work: common in invoice/billing and API searches.\n- High competition: broad CRM and API queries often attract 20-50+ proposals.\n\nCross-Query Overlap\n\nThe highest-overlap pairs from calibration:\n\n- Q3 AR/AP and Q5 Invoice/billing overlap heavily on financial automation posts.\n- Q6 CRM and Q7 API catch many of each other's broad integration posts.\n- Q1 System nouns produces the most unique gems and remains the strongest standalone query."
-  },
-  {
-    id: "knowledge.upwork-query-strategy",
-    title: "Upwork Query Strategy",
-    summary: "Active saved-query set, tiering, calibration outcomes, query-design principles, and failure modes for the Upwork acquisition channel.",
-    bodyText: 'Overview\n\nUse this reference to choose which Upwork saved searches to scan, understand why each query is active, and avoid repeating failed discovery work. The active query set targets niche operations and business-process automation jobs rather than broad "AI automation" searches, which are usually saturated.\n\nUse knowledge.upwork-scanning-playbook for the scan workflow and knowledge.upwork-calibration-strategy for deep query calibration.\n\nActive Saved Queries\n\nThe active saved-query set has 14 queries as of 2026-03-31. Q1-Q7 were kept after the full calibration scan of the original 16 queries. Q8 Pipedrive was added after SaaS platform calibration. Q9-Q14 are formerly monitor-tier queries moved into active scanning with stricter freshness and competition discipline.\n\n| Tier | #   | Query                                                                                                                                                                                                     | Relevance | Unique Rel | Rationale                                                                                                                  |\n| ---- | --- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ---------- | -------------------------------------------------------------------------------------------------------------------------- |\n| T1   | 1   | ("booking system" OR "intake form" OR "scheduling system" OR "ticketing system" OR "tracking system" OR "reservation system" OR "billing system" OR "payment system") AND (build OR automate OR custom) | 60%       | 30%        | Best query. SMB owners describe systems they need built. Lowest competition and highest ROI per connect.                   |\n| T1   | 2   | ("GoHighLevel" OR "GHL") AND (build OR setup OR integration OR workflow OR automate)                                                                                                                    | 50%       | 45%        | GHL niche with high unique relevance. "Funnel" was removed because it pulled marketing noise; "automate" replaced it.      |\n| T2   | 3   | ("accounts receivable" OR "accounts payable" OR "collections") AND automate                                                                                                                             | 40%       | 30%        | "Automate" catches real builds and maps to the Xero testimonial. Some overlap with Q1 and Q7.                              |\n| T2   | 4   | "inventory" AND ("automation" OR "integration" OR "sync")                                                                                                                                               | 40%       | 35%        | Inventory system builds are unique to this query. Low cross-query overlap.                                                 |\n| T3   | 5   | ("invoice" OR "billing") AND ("automate" OR "integration")                                                                                                                                              | 55%       | 30%        | Finds healthcare EDI, Stripe Connect, and Power Automate AP work. Heavy Q3 overlap.                                        |\n| T3   | 6   | "CRM" AND ("integration" OR "automate" OR "migrate")                                                                                                                                                    | 40%       | 20%        | Finds Twenty CRM, HubSpot Service Hub, and Zoho automation. Noisy and high-volume.                                         |\n| T3   | 7   | "integrate" AND "API" AND (build OR develop OR custom)                                                                                                                                                  | 40%       | 15%        | Finds strong integration work such as Authorize.Net webhooks and Email-to-ERP pipelines. Competition is often high.        |\n| T3   | 8   | "Pipedrive" AND (build OR setup OR integration OR workflow OR automate)                                                                                                                                 | 40%       | 30%       | CRM setup and automation builds. Only platform query besides GHL to pass calibration. Trial query; evaluate after 3 scans. |\n| T4   | 9   | ("Zapier" OR "Make.com" OR "n8n") AND (automate OR build OR workflow)                                                                                                                                   | Very high | --         | High relevance but competition risk. Apply only to posts with fewer than 10 proposals.                                     |\n| T4   | 10  | "SaaS" AND ("MVP" OR "prototype") AND (build OR develop)                                                                                                                                                | High      | --         | Bimodal competition: some low-proposal gems, some flooded posts. Skip flooded posts.                                       |\n| T4   | 11  | "Google Sheets" AND (automate OR app OR dashboard OR replace)                                                                                                                                           | 40%      | --         | Fresh and even competition spread. Good posts get flooded quickly, so prioritize speed.                                    |\n| T4   | 12  | "chatbot" AND (build OR custom OR develop)                                                                                                                                                              | 25%      | --         | Low relevance baseline. Pulls AI engineering hiring and chat UI work, but occasional SMB gems exist.                       |\n| T4   | 13  | ("voice agent" OR "AI receptionist") AND (build OR develop OR custom)                                                                                                                                   | High      | --         | Very low volume, often 1-2 results. High quality when fresh posts appear.                                                  |\n| T4   | 14  | "sales funnel" AND (automate OR build OR system OR custom)                                                                                                                                              | 40%      | --         | Fresh GHL integrations and CRM builds mixed with affiliate-funnel noise. Filter hard.                                      |\n\nAll active queries use the Upwork proposal-count filters "Less than 5" and "5 to 10". Tier 1 queries are the primary scan focus. Tier 2 queries are solid contributors. Tier 3 queries are borderline and should be dropped if health scores decline across 3 or more scans. Tier 4 queries have higher competition risk and should only be applied to fresh, low-proposal posts.\n\nQuery Design Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches when system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, and inventory sync.\n- The Q1 pattern: specific system noun plus action verb. This catches clients describing the thing they need built.\n- The proposal-count filter from 0-10 proposals. Competition control is non-negotiable.\n\nAvoid:\n\n- Vertical keywords such as clinic, contractor, salon, or real estate. On Upwork these usually pull marketing or hiring posts for that industry, not system buyers from that industry.\n- Pain-signal phrases such as "hours per week", "manual", "repetitive", or "bottleneck". On Upwork these usually mean the client is hiring humans to perform the work.\n- Migration terms such as migrate, replace, or switch unless tied to a concrete platform or system. Generic migration queries pull website and email platform changes.\n- Broad tool or category nouns such as portal, dashboard, tool, or custom without a specific system type.\n- Solution-first keywords such as AI automation, AI agent, and workflow automation. They attract the saturated AI freelancer crowd.\n- Revenue-proximity service terms such as cold email, outbound, nurture, appointment setting, and qualify leads. These are proposal-positioning angles, not good Upwork query filters.\n- Professional-service terms such as contract review, due diligence, or reputation management. They pull human professionals rather than system builds.\n\nQuery Evolution\n\nDiscovery is complete for the current strategy: 127 queries were tested across 18 rounds and calibrated to 14 active queries. The current ROI lever is execution quality: faster scans, stronger proposal targeting, and query-health monitoring.\n\nQ1 has 8 proven system nouns:\n\n- Booking system.\n- Intake form.\n- Scheduling system.\n- Ticketing system.\n- Tracking system.\n- Reservation system.\n- Billing system.\n- Payment system.\n\nTwenty-three other system nouns were tested and failed. Before testing any new query, check the Upwork query registry in the operations docs for prior verdicts and failure modes.\n\nKnown Limitations\n\n- The "U.S. only" checkbox does not persist with saved searches. It is a session-only filter and must be manually checked each time a saved search loads.\n- Upwork search is not strict phrase matching. A quoted phrase such as "client portal" can still match posts containing the words separately.\n- Relevance percentages are from the expanded 2026-03-29 evaluation: 147 jobs across 15 queries plus 32-query discovery analysis. Re-evaluate monthly as job mix shifts.\n\nLive Reference Docs\n\nPreserve these operations docs because they remain live working references rather than migrated Knowledge Map content:\n\n- apps/docs/content/docs/operations/client-acquisition/upwork/query-registry.mdx tracks all 127 tested queries, verdicts, and failure modes.\n- apps/docs/content/docs/operations/client-acquisition/upwork/scripts.mdx stores runnable browser extraction scripts and current Upwork DOM notes.'
-  },
-  {
-    id: "knowledge.upwork-scanning-playbook",
-    title: "Upwork Scanning Playbook",
-    summary: "Stable scanning, scoring, freshness, and query-health workflow for the Upwork acquisition channel.",
-    bodyText: 'Overview\n\nUse this playbook to run the Upwork acquisition scanning loop. The goal is to find fresh, low-competition jobs where Elevasis can deliver a real business system, score them consistently, and turn the best opportunities into proposals through the Upwork proposal playbook.\n\nThe scanning loop has six phases:\n\n1. Confirm browser and login readiness.\n2. Run saved search queries with the right filters.\n3. Extract fresh job cards.\n4. Deduplicate, score, and enrich strong candidates.\n5. Write the scan output.\n6. Review query health before the next scan.\n\nProposal copy and response handling are intentionally separate. Use knowledge.upwork-proposal-playbook for proposal strategy and knowledge.upwork-response-templates for client replies.\n\nPreconditions\n\nBefore scanning, verify the browser automation surface is available and Upwork is logged in.\n\n- Chrome tooling must be available through the active browser automation tools.\n- The Upwork search page must load at https://www.upwork.com/nx/search/jobs/.\n- The page must show the job search interface, not a login prompt.\n- If login is required, stop and log in manually before scanning again.\n\nDo not try to work around a missing browser session by inventing scan results. The scan depends on live Upwork search pages, current saved-search filters, and the visible result cards.\n\nScan Surface\n\nRun scans from the Upwork search page:\n\ntext\nhttps://www.upwork.com/nx/search/jobs/\n\nEach saved query is run individually. Apply the filters every time, because Upwork search state is session-dependent and not always persisted across queries.\n\n| Filter    | Value       | Reason                                                                 |\n| --------- | ----------- | ---------------------------------------------------------------------- |\n| U.S. only | Checked     | Higher-quality clients, stronger timezone fit, more verified payments. |\n| Sort by   | Most Recent | Freshness is the strongest conversion lever.                           |\n| Proposals | \\<5, 5-10 | Low competition is required before spending connects.                  |\n\nUse saved queries as the primary scan source. The strategy targets operational system-build terms, not generic "AI automation" searches that attract high competition.\n\nFreshness Rule\n\nOnly collect posts from the last 12 hours. Results should be sorted by Most Recent, so stop extracting for a query once the visible posts are older than 12 hours. Do not do catch-up windows.\n\nFreshness priority:\n\n| Post age   | Action                                                           |\n| ---------- | ---------------------------------------------------------------- |\n| 0-1 hour   | Highest priority. Client is most likely active and shortlisting. |\n| 1-12 hours | Valid scan window. Still worth scoring if competition is low.    |\n| 12+ hours  | Skip. The client has usually already formed the shortlist.       |\n\nRecord the scan timestamp as lastscanned in the daily scan doc frontmatter. This timestamp helps avoid reprocessing posts from prior scans, but the hard 12-hour cap still applies.\n\nRun Each Query\n\nFor each active saved query:\n\n1. Clear the search box.\n2. Enter the query string and submit.\n3. Apply U.S. only, Most Recent, and proposal-count filters.\n4. Wait for results to render.\n5. Extract visible job cards from the search page.\n6. Stop once a post exceeds the freshness cutoff.\n7. Tag each job with the source query.\n\nThe first page of most-recent, low-proposal results is the high-value slice. Do not paginate unless a specific investigation requires it.\n\nWhile scanning the API integration query, flag custom dashboard opportunities where a custom build is likely better than Power BI, Looker, Tableau, or a spreadsheet. Strong signs include 3+ data sources, live dashboard requirements, AI-generated summaries, anomaly detection, or workflow triggers.\n\nExtract Job Card Data\n\nThe search-card extraction should capture the fields needed for initial triage:\n\n- Title.\n- Upwork job URL path.\n- Posted age.\n- Proposal count.\n- Budget or hourly range.\n- Payment verification.\n- Client rating.\n- Total client spend.\n- Description snippet.\n- Source query.\n\nDeduplicate by Upwork job URL path after all queries finish. If a job appears under multiple queries, keep one row and note the overlap.\n\nScore and Enrich\n\nScoring has two stages.\n\nStage 1: Relevance\n\nScore relevance from 0 to 100 by asking whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Range  | Label        | Criteria                                                                  |\n| ------ | ------------ | ------------------------------------------------------------------------- |\n| 75-100 | Strong fit   | Clear build intent, specific business workflow, named tools or outputs.   |\n| 50-74  | Possible fit | Some build signals, but scope or buyer intent is ambiguous.               |\n| 25-49  | Weak fit     | Marginally related, mostly noise, low business-system signal.             |\n| 0-24   | Irrelevant   | Hiring, marketing, design, manual VA work, personal projects, or errands. |\n\nDisqualify posts that are clearly hiring a role, outsourcing manual work, asking for generic marketing/design help, or describing a personal/non-business project.\n\nStage 2: Application Priority\n\nApply tactical modifiers after relevance scoring. The final score determines whether to draft a proposal.\n\n| Signal         | Positive indicators                                  | Negative indicators                         |\n| -------------- | ---------------------------------------------------- | ------------------------------------------- |\n| Freshness      | \\<1h or same-session post.                         | 8-12h old, or outside the scan window.      |\n| Competition    | \\<5 proposals, or 5-10 with strong fit.            | 10+ proposals, especially 20+.              |\n| Client quality | Payment verified, spend history, good rating, hires. | Unverified, no history, 0% hire rate.       |\n| Budget         | Fixed \\>$5K or hourly \\>$75/hr.                  | Fixed \\<$1K or hourly \\<$40/hr.         |\n| Fit            | Workflow, integration, dashboard, CRM, operations.   | Copywriting, funnels, ads, hiring, support. |\n\nOnly enrich posts with a strong enough relevance score to matter, usually 65+. For those posts, open the job detail view and capture:\n\n- Hire rate.\n- Jobs posted.\n- Member since.\n- Company size.\n- Last viewed by client.\n- Interviewing count.\n\nUse this data to avoid over-ranking stale or low-quality clients that have a good-sounding job description but weak application ROI.\n\nWrite the Scan Output\n\nWrite scan docs under:\n\ntext\napps/docs/content/docs/operations/client-acquisition/upwork/scans/{YYYY-MM-DD}.mdx\n\nIf a scan doc already exists for the day, append the new scan as a later section instead of creating a second daily file.\n\nEach scan output should include:\n\n- Date and timestamp.\n- Freshness cutoff.\n- Queries scanned.\n- Total posts collected.\n- Deduplicated count.\n- Top opportunities only.\n- Comparison table.\n- Query health table.\n- Draft proposals section, when proposals are generated.\n\nKeep scan docs as decision tools, not archives. Include the top 10 ranked opportunities rather than every collected post.\n\nQuery Health\n\nAfter scoring, compute a query-health score so weak searches can be removed over time.\n\n| Metric          | Measurement                                                       | Weight |\n| --------------- | ----------------------------------------------------------------- | ------ |\n| Fresh posts     | Count within cutoff, normalized against 5 posts.                  | 25%    |\n| Low competition | Percent with fewer than 10 proposals.                             | 25%    |\n| Relevance       | Percent actionable after deduplication and disqualification.      | 30%    |\n| Client quality  | Percent with verified payment and useful spend or rating signals. | 20%    |\n\nQueries that score 0 across 3+ consecutive scans are drop candidates. Compare the latest query-health table with the previous scan before changing the active query set.\n\nActive Query Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches where system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, or inventory sync.\n\nAvoid:\n\n- Broad solution-first terms such as AI automation, AI agent, workflow automation, portal, dashboard, tool, or custom without a specific system noun.\n- Vertical keywords such as clinic, contractor, salon, or real estate unless paired with concrete system intent.\n- Pain-signal phrases that usually mean the client is hiring a human to perform manual work.\n- Revenue-proximity service terms such as cold email, appointment setting, outbound specialist, or funnel work.\n\nBefore testing a new query, read knowledge.upwork-query-strategy and check the Upwork query registry in the operations docs so old failure modes are not repeated. Use knowledge.upwork-calibration-strategy when promoting, dropping, or re-evaluating saved searches.\n\nProposal Handoff\n\nAfter the scan, draft proposals only for opportunities that remain strong after relevance, tactical modifiers, and client-quality checks.\n\nFor proposal drafting:\n\n1. Load knowledge.upwork-proposal-playbook.\n2. Read the top opportunities from the latest scan doc.\n3. Select the right proposal template by scope, budget, and relevance.\n4. Tailor the opening, proof point, plan, and two discovery questions.\n5. Append draft proposals to the scan doc under ## Draft Proposals.\n\nUse knowledge.upwork-response-templates after a client replies or sends an offer.\n\nScan Checklist\n\n- Browser tooling available.\n- Upwork logged in.\n- Search page loaded.\n- U.S. only filter applied.\n- Sort set to Most Recent.\n- Proposal-count filters applied.\n- All active saved queries scanned.\n- Posts older than 12 hours skipped.\n- Jobs deduplicated by URL path.\n- Relevance scores assigned.\n- Strong candidates enriched from detail view.\n- Final scores sorted descending.\n- Daily scan doc created or appended.\n- Query health table written.\n- Top proposal candidates handed to knowledge.upwork-proposal-playbook.'
+Claim Strength Tiers:
+- Tier 1 (Verified): Named source, specific methodology. Use confidently.
+- Tier 2 (Plausible): Widely cited, directionally correct. Use the insight, soften the specific number.
+- Tier 3 (Unverified): No credible source found. Do not use specific numbers.`
   },
   {
     id: "knowledge.client-cli-overview",
@@ -890,7 +579,7 @@ Launch Checklist
 
 The client: commands expose the clients hub through the SDK CLI. Use them to paginate clients, inspect individual client lineage, check org-wide status rollups, resolve a fuzzy name to a client ID, and mutate clients with create, update, and delete operations.
 
-All examples below use the canonical monorepo invocation pattern. Tenant projects inside their own operations/ directory drop the -C packages/elevasis-operations prefix and run pnpm exec elevasis-sdk <cmd> directly.
+All examples below use the canonical monorepo invocation pattern. Tenant projects inside their own operations/ directory drop the -C packages/elevasis/operations prefix and run pnpm exec elevasis-sdk <cmd> directly.
 
 client:list
 
@@ -901,7 +590,7 @@ Purpose: Paginate all clients or narrow by status or search term to find the rig
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:list
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:list
 
 Tenant invocation (from inside operations/):
 
@@ -931,7 +620,7 @@ Purpose: Inspect one client in detail -- its associated deal, primary company, p
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:get <clientId>
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:get <clientId>
 
 Tenant invocation:
 
@@ -959,7 +648,7 @@ Purpose: High-level health check -- how many clients are active, how many are in
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:status
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:status
 
 Tenant invocation:
 
@@ -985,7 +674,7 @@ Purpose: Convert a partial or approximate name to the canonical UUID before pass
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:resolve "<query>"
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:resolve "<query>"
 
 Tenant invocation:
 
@@ -1011,7 +700,7 @@ Purpose: Provision a client directly from the CLI -- useful for scripted onboard
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:create --name "Acme Corp"
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:create --name "Acme Corp"
 
 Tenant invocation (from inside operations/):
 
@@ -1044,7 +733,7 @@ Purpose: Rename a client, change its status, swap or clear relationship IDs, or
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:update <id> --status active
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:update <id> --status active
 
 Tenant invocation:
 
@@ -1081,7 +770,7 @@ Purpose: Remove a client that was created in error or is no longer relevant. The
 Monorepo invocation:
 
 bash
-pnpm -C packages/elevasis-operations exec elevasis-sdk client:delete <id>
+pnpm -C packages/elevasis/operations exec elevasis-sdk client:delete <id>
 
 Tenant invocation:
 
@@ -1116,6 +805,111 @@ A common session combining read and write commands:
 7. client:update <id> --status active --pretty -- transition a client to active.
 8. client:delete <id> --pretty -- remove a client (API rejects with 409 if linked rows exist).`
   },
+  {
+    id: "knowledge.client-testimonials",
+    title: "Testimonials",
+    summary: "Customer testimonials and case study permissions from previous client work",
+    bodyText: `Status: 4 testimonials from 2 clients | Source: Upwork client work (2024)
+
+Testimonials
+
+Xero Automation \xE2\u20AC\u201D The Invoice Chase That Disappeared
+
+Client: Word of Mouth Agency
+
+Result: 10+ hours/week saved. Zero manual follow-up emails.
+
+> "Working with Alex at Elevasis to automate our Xero follow-ups has been a game-changer. We're set to save over 5 hours a week, but more importantly, it has completely removed the stress of chasing invoices. The process was smooth and professional."
+
+Permission: Case study approved with company name.
+
+Influencer Discovery \xE2\u20AC\u201D From Spreadsheet Hell to Strategic Decisions
+
+Client: Word of Mouth Agency (Perth, Australia)
+
+Result: 10+ hours/week saved. Research scope: 50 to 200+ influencers. Team focus shifted from data to strategy.
+
+> "Working with Alex at Elevasis to automate our Influencer Discovery has been a game-changer. We're set to save over 5 hours a week..."
+
+Permission: Case study approved with company name.
+
+EMRG Media \xE2\u20AC\u201D 4 Automations for NYC's Premier Events Firm
+
+Client: EMRG Media (NYC, est. 2001). Clients include Google, YouTube, Sony Music, Fiverr, Equinox.
+
+What We Built:
+1. Case Study Generator \xE2\u20AC\u201D 7-10 hours \xE2\u2020\u2019 2 hours. Publication rate: 1/quarter \xE2\u2020\u2019 2/month.
+2. EMRG Follow-Up Generator \xE2\u20AC\u201D Automated post-event follow-ups with signature management.
+3. Event Sponsor Tracker \xE2\u20AC\u201D Automated sponsor pipeline tracking and communications.
+4. Lead Scraper \xE2\u20AC\u201D Automated discovery of event planning prospects.
+
+Fame Stats:
+- 3,500+ attendees at The Event Planner Expo
+- 25+ year track record
+- Fortune 500 client roster
+
+Permission: Case study approved with company name.`
+  },
+  {
+    id: "knowledge.content-playbook",
+    title: "Content Playbook",
+    summary: "Content creation guide \xE2\u20AC\u201D pillars, platform rules, format specs, repurposing chain, and metrics benchmarks for multi-platform distribution",
+    bodyText: 'Content Pillars\n\nEvery content piece maps to one of five pillars.\n\n| Pillar              | What It Is                                         | Target Frequency |\n| ------------------- | -------------------------------------------------- | ---------------- |\n| dogfooding      | How we run Elevasis using our own platform         | 1-2x/week        |\n| education       | 4 Pattern Framework and AI orchestration concepts  | 1x/week          |\n| demo            | "Watch AI Work" \xE2\u20AC\u201D showing the platform in action | 1x/2 weeks       |\n| pain-point      | SMB pain points backed by data                     | 1x/week          |\n| founder-journey | Solo founder building with AI                      | 1x/week          |\n\nThe 90-10 Rule\n\n90% educational value, 10% promotional. Keeping promotional content to \\<15% ensures your audience stays receptive when you do make an offer.\n\nContent Creation Workflow\n\n1. Capture the Idea \xE2\u20AC\u201D Insert into contentitems with status: idea\n2. Draft the Source Content \xE2\u20AC\u201D Write core idea in contentitems.body. LinkedIn first.\n3. Adapt for Platforms \xE2\u20AC\u201D Repurpose from LinkedIn to YouTube, Instagram, X\n4. Schedule and Publish \xE2\u20AC\u201D Use platform-native scheduling\n5. Track Performance \xE2\u20AC\u201D Monitor in contentitems via Command Center\n\nPlatform Priority\n\n1. LinkedIn \xE2\u20AC\u201D #1 priority, 3x/week\n2. YouTube \xE2\u20AC\u201D #2 priority, 1x/week + Shorts\n3. Instagram \xE2\u20AC\u201D #3 priority, 2-3x/week, repurpose from LinkedIn/YouTube\n4. X \xE2\u20AC\u201D #4 priority, 2-3x/week, threads from LinkedIn'
+  },
+  {
+    id: "knowledge.instagram-strategy",
+    title: "Instagram Strategy",
+    summary: "Comprehensive Instagram posting strategy for B2B SaaS founder content \xE2\u20AC\u201D algorithm deep dive, Reels, carousels, Stories, SEO, hashtags, captions, profile optimization, growth tactics, and analytics benchmarks (2025-2026)",
+    bodyText: 'Overview\n\nInstagram is the #3 priority platform. Carousels repurpose easily from LinkedIn, and Reels come directly from YouTube Shorts.\n\nCadence: 3-5x/week feed posts + daily Stories\n\nB2B Reality Check: Instagram is a complementary channel for B2B SaaS, not a primary lead gen tool. Decision-makers are on Instagram (76% of B2B companies use it), but they are in consumer mode.\n\nAlgorithm Deep Dive (2025-2026)\n\nReels Algorithm (Most Important for Reach)\n\nReels are designed for discovery: 55% of Reels views come from non-followers.\n\nThree priority signals:\n| Signal | Weight | How to Optimize |\n| --- | --- | --- |\n| Watch time | #1 | Hook in first 1.7s; optimize for completion |\n| Sends per reach | Highest for new audiences | "Send this to someone" content |\n| Likes per reach | Highest for followers | Valuable content followers engage with |\n\nContent Strategy\n\n- Repurpose from LinkedIn: Carousel slides \xE2\u2020\u2019 Instagram carousel\n- Repurpose from YouTube: Long-form \xE2\u2020\u2019 Reels (cut 30-60s clips)\n- Stories: Daily touchpoints, polls, Q&A, behind-the-scenes\n\nCarousel Optimization\n\n- Slide 1: Hook (bold claim or question)\n- Slides 2-9: Value delivery (one point per slide)\n- Slide 10: CTA (follow, DM, link in bio)'
+  },
+  {
+    id: "knowledge.linkedin-strategy",
+    title: "LinkedIn Strategy",
+    summary: "LinkedIn posting strategy \xE2\u20AC\u201D algorithm deep dive, format rankings, hook techniques, carousel optimization, newsletter strategy, engagement tactics, profile optimization, and growth playbook for B2B SaaS (2025-2026)",
+    bodyText: 'Overview\n\nLinkedIn is the #1 priority platform. The algorithm heavily favors personal profiles over company pages. In 2025-2026, LinkedIn shifted from viral reach to depth and authority \xE2\u20AC\u201D topical consistency is now the single biggest strategic lever.\n\nCadence: 3-5x/week (Wed/Thu/Fri strongest, Monday weakest)\n\nAlgorithm Deep Dive\n\nRanking Signals (by weight)\n\n| Signal | Weight | Notes |\n| --- | --- | --- |\n| Comments | Highest | 15x more valuable than likes |\n| Saves and sends | Very high | Added to analytics in late 2025 |\n| Dwell time | High | 15+ seconds = meaningful |\n| "See more" clicks | High | Whether people expand the full post |\n| Reactions/likes | Lowest | Significantly de-emphasized |\n\nTopical Authority\n\nThe algorithm rewards consistent publishing within a defined area of expertise. Pick a lane (AI automation) and stay in it.\n\nPost Formats\n\n1. Carousels \xE2\u20AC\u201D Highest avg engagement; 10-slide with text + data\n2. Text posts \xE2\u20AC\u201D Quick takes, contrarian observations, founder stories\n3. Documents/PDFs \xE2\u20AC\u201D In-depth guides, playbooks, frameworks\n4. Videos \xE2\u20AC\u201D Native upload outperforms external links by 5x\n\nHook Techniques\n\n- Lead with the most surprising/counterintuitive insight\n- Use "I" not "we" \xE2\u20AC\u201D personal profile posts outperform company pages\n- 3 lines max before "...see more" break\n- Questions outperform statements for comments engagement'
+  },
+  {
+    id: "knowledge.marketing-overview",
+    title: "Marketing Overview",
+    summary: "Marketing documentation for Elevasis - strategy, website infrastructure, and content systems",
+    bodyText: "Welcome to the Elevasis marketing documentation. This section covers marketing strategy, website implementation, and content systems.\n\nDocumentation\n\nStrategy\n\n- Overview \xE2\u20AC\u201D Channel strategy, inbound content system, and proof-led demand generation\n\nWebsite\n\nThe marketing website's technical infrastructure, setup, and SEO docs now live under Architecture \xE2\u2020\u2019 Website."
+  },
+  {
+    id: "knowledge.reddit-account-strategy",
+    title: "Reddit Account",
+    summary: "AlexElevasis Reddit account strategy \xE2\u20AC\u201D warm-up playbook, karma thresholds, posting rules, and lead generation approach for the social monitoring pipeline.",
+    bodyText: 'Account Details\n\n| Field | Value |\n| --- | --- |\n| Username | AlexElevasis |\n| Created | 2026-03-26 |\n| Purpose | Lead generation via Reddit monitoring pipeline |\n| Persona | Alexander, founder of an AI automation company |\n\nThe username serves double duty: every helpful comment puts "Elevasis" in front of the reader.\n\nWarm-Up Playbook\n\nDays 1-3 \xE2\u20AC\u201D Cold Start:\n- Browse, upvote, follow target subs\n- 1 comment per day max\n- No links, no self-promotion, no CTAs\n\nDays 4-14 \xE2\u20AC\u201D Gradual Ramp:\n- Increase to 2-3 comments/day\n- Genuine, helpful answers \xE2\u20AC\u201D no copy-paste across threads\n- Still no links or CTAs\n\nAfter 30 Days + 100 Karma \xE2\u20AC\u201D Activation:\n- Most automod filters cleared\n- Start using monitoring pipeline drafts\n- 300+ karma unlocks more restrictive subs (r/Entrepreneur, r/startups)\n\nKarma Thresholds\n\n| Karma | Access Level |\n| --- | --- |\n| 100 | Bypasses most automod filters |\n| 300+ | Access to restrictive subs |\n| 1,000+ | Considered established community member |\n\nPosting Rules\n\n- Genuine value first \xE2\u20AC\u201D no pitching without established reputation\n- 30-day account age required before using pipeline drafts\n- Open questions in responses (not CTAs) per pipeline draft conventions'
+  },
+  {
+    id: "knowledge.reddit-monitoring-playbook",
+    title: "Social Monitoring",
+    summary: "Automated Reddit monitoring pipeline \xE2\u20AC\u201D 4-step workflow (search, LLM score, LLM draft, store) with tiered subreddit scraping via Apify, claude-sonnet-5 scoring and response drafting, and lead-gen optimized responses via the AlexElevasis account.",
+    bodyText: "Overview\n\nSocial monitoring surfaces Reddit posts where business owners discuss operational challenges, manual processes, and automation needs.\n\nCron Trigger (3x/day: 16:00, 22:00, 04:00 UTC)\n    \xE2\u2020\u2019 mnt-reddit-monitor-workflow (4-step pipeline)\n        \xE2\u2020\u2019 Step 1: Search \xE2\u20AC\u201D 4 sequential Apify actors (one per tier)\n        \xE2\u2020\u2019 Step 2: Score \xE2\u20AC\u201D claude-sonnet-5 (concurrency 5)\n        \xE2\u2020\u2019 Step 3: Draft \xE2\u20AC\u201D claude-sonnet-5 (high-score only)\n        \xE2\u2020\u2019 Step 4: Report \xE2\u20AC\u201D Store to acqsocialposts, log breakdown\n    \xE2\u2020\u2019 Command Center: /acquisition/monitoring\n\nStatus: Paused until further notice (2026-03-31). Pipeline technically validated but ROI is low without deep vertical expertise.\n\nVelocity Batches\n\nSubreddits grouped by posting velocity, each with its own maxPostsPerSource.\n\n| Batch | Subs | Posts/Source | Example Subreddits |\n| --- | --- | --- | --- |\n| Medium Velocity | 2 | 5 | Accounting, Plumbing |\n| Buyer Low-Volume | 10 | 3 | CRM, EntrepreneurRideAlong, sweatystartup |\n| Trade Niche | 10 | 2 | electricians, Dentists, InsuranceAgent |\n| Decision Niche | 3 | 2 | logistics, FreightBrokers, healthIT |\n\nScoring\n\nPosts scored 0-100 by claude-sonnet-5 for business automation opportunity relevance. Posts scoring \\>= 60 get response drafts via claude-sonnet-5.\n\nAlexElevasis Account\n\nAll responses posted via the AlexElevasis Reddit account. See Reddit Account strategy doc for warmup playbook and karma thresholds."
+  },
+  {
+    id: "knowledge.seo-content-guide",
+    title: "SEO Content Writing Guide",
+    summary: "Tactical guide for writing SEO and AEO-optimized content \xE2\u20AC\u201D page structure, keyword strategy, AI engine citation optimization, E-E-A-T signals, and CTA patterns.",
+    bodyText: 'Overview\n\nThis guide covers how to write SEO content that ranks in traditional search AND gets cited by AI answer engines \xE2\u20AC\u201D ChatGPT, Perplexity, Google AI Overviews, and Gemini.\n\nThe distribution channel is split: 69% of Google searches result in zero clicks, while AI platforms generated 1.13 billion referral visits in June 2025 alone.\n\nPage Structure\n\nSection Architecture\n\nEvery section must be self-contained. AI engines extract individual passages, not full pages.\n\n- Lead with a 30-50 word standalone answer in the first sentence of each section\n- Paragraphs: 2-4 sentences max\n- 78% of AI Overview answers use list format -- use bullets and numbered lists extensively\n- Heading hierarchy: one H1 (page title), H2 for major sections, H3 for subsections\n- Frame headings as questions when possible\n\nSection Length\n\n- Pillar pages: 2,000-3,000 words total\n- Cluster pages: 1,000-2,000 words total\n- Each major section: 150-300 words\n\nConciseness Rules\n\n1. Two-paragraph intro max\n2. No stat duplication between intro and problem section\n3. Section character budget: Intro 450-600 chars, Problem 250-400 chars, Solution 300-550 chars\n\nE-E-A-T Signals\n\n- Brand name "Elevasis" must appear explicitly minimum 3x per page\n- Vertical names used as proper noun concepts\n- Organization + Service + SoftwareApplication schema markup reinforces entity recognition'
+  },
+  {
+    id: "knowledge.seo-distribution-playbook",
+    title: "Distribution & Citation Building",
+    summary: "Post-publish distribution playbook \xE2\u20AC\u201D AI crawler discovery, directory citations, Google Business Profile, community seeding, monitoring cadence, and AEO optimization tactics.",
+    bodyText: 'Overview\n\nEverything that happens after pages are published and sitemap/IndexNow pings are sent. Evergreen reference for maximizing visibility across traditional search, AI answer engines, and buyer-intent directories.\n\nAI Crawler Discovery\n\nllms.txt\n\nA plain-text Markdown file at the domain root that gives LLMs a structured map of key content. Location: apps/website/public/llms.txt.\n\nUpdate whenever pillar or cluster pages are published.\n\nSitemap Segmentation\n\n| Segment ID | Contents | Priority |\n| --- | --- | --- |\n| 0 | Static pages | Default |\n| 1 | Pillar pages (9) | 0.9 |\n| 2 | Cluster pages (52) | 0.8 |\n\nEntity Density Rules\n\nPages with 15+ recognized entities show 4.8x higher selection probability for AI citations.\n- Brand name "Elevasis" must appear explicitly (minimum 3x per page)\n- Stat density target: one statistic every 150-200 words\n\nDirectory Citations\n\nTier 1 (Buyer Intent): G2, Capterra, Product Hunt, AppSumo (direct buyer intent, high domain authority)\n\nTier 2 (Authority): Crunchbase, AngelList, LinkedIn company page, industry association directories\n\nGoogle Business Profile\n\nClaim and verify GBP listing. Category: "Software Company". Keep NAP (Name, Address, Phone) consistent across all citations.'
+  },
+  {
+    id: "knowledge.seo-playbook",
+    title: "SEO Playbook",
+    summary: "Operational playbook for the SEO/AEO system \xE2\u20AC\u201D vertical launch workflow, content quality gates, AEO formatting rules, stale content management, metrics interpretation, and rollout phases.",
+    bodyText: "Vertical Launch Workflow\n\nEnd-to-end process for launching a new vertical (e.g., hvac-contractors):\n\nStep 1: Research vertical data\n\nFind real, citable industry statistics: pain points, automation ROI, market context. Sources: trade associations, industry surveys, government data (BLS, Census).\n\nStep 2: Generate pages\n\nbash\nPillar page\npnpm tsx scripts/seo/generate-pages.ts --vertical hvac-contractors --type pillar --dry-run\npnpm tsx scripts/seo/generate-pages.ts --vertical hvac-contractors --type pillar\n\nCluster pages\npnpm tsx scripts/seo/generate-pages.ts --vertical hvac-contractors --type cluster\n\nStep 3: Backfill chart data\n\nCharts require post-generation patching. Write chart patch files using Step 1 research, then apply via content.ts patch.\n\nStep 4: AEO optimization\n\nEvery section must be self-contained. AI engines extract individual passages, not full pages.\n- Lead with a 30-50 word standalone answer in the first sentence of each section\n- 78% of AI Overview answers use list format\n- Frame headings as questions when possible\n\nStep 5: Post-publish distribution\n\nUpdate llms.txt, ping IndexNow, submit sitemap segments to Search Console.\n\nData Sourcing Rules\n\n- Tier 1 (Verified): Named source, specific methodology. Use confidently.\n- Tier 2 (Plausible): Widely cited, directionally correct. Soften the specific number.\n- Tier 3 (Unverified): No credible source. Do not use specific numbers."
+  },
+  {
+    id: "knowledge.x-strategy",
+    title: "X (Twitter) Strategy",
+    summary: "X/Twitter posting strategy \xE2\u20AC\u201D algorithm signals, thread tactics, engagement weights, Premium ROI, video specs, growth playbook, and B2B SaaS niche tactics",
+    bodyText: "Overview\n\nX is the #4 priority platform. Most content is repurposed from LinkedIn text posts as threads.\n\nCadence: 3-5 posts/day (mix of original posts + replies + quote tweets), 2-3 threads/week\n\nPrerequisite: Get X Premium ($8/mo) \xE2\u20AC\u201D verified accounts get 10x more impressions. Non-Premium accounts posting links receive near-zero engagement as of 2026.\n\nAlgorithm Deep Dive\n\nEngagement Weight Scoring\n\n| Signal | Weight | vs. Like |\n| --- | --- | --- |\n| Reply engaged by author | +75 | 150x |\n| Reply | +13.5 | 27x |\n| Profile click + engagement | +12.0 | 24x |\n| Bookmark | +10.0 | 20x |\n| Retweet | +1.0 | 2x |\n| Like | +0.5 | 1x |\n\nCritical takeaway: Replying to your own replies is worth 150x a like.\n\nPenalties\n\n- External links: 30-50% reach reduction\n- Multiple hashtags: 40% penalty\n\nThread Strategy\n\n- First tweet = hook (bold claim or surprising stat)\n- 5-10 tweets per thread\n- Last tweet = CTA (follow for more, link to extended content)\n- Reply to your own threads within the first hour to boost algorithmic velocity"
+  },
   {
     id: "knowledge.youtube-obs-recording-setup",
     title: "YouTube OBS Recording Setup",
@@ -1366,6 +1160,126 @@ Pre-Recording Checklist
 - OBS mic meter peaks in green or yellow, never red.
 - A 10-second test recording has been played back for audio, video quality, and facecam position.
 - The 12-minute warm-up from knowledge.youtube-mental-prep is complete when recording on camera.`
+  },
+  {
+    id: "knowledge.youtube-channel-strategy",
+    title: "Channel Strategy",
+    summary: 'Unified YouTube channel strategy \xE2\u20AC\u201D channel setup, content pipeline, differentiation positioning, launch queue, and production workflow for "Alexander Le | Elevasis" channel',
+    bodyText: `Objective
+
+Build the "Alexander Le | Elevasis" YouTube channel as an evergreen discovery engine for Elevasis. YouTube is the #1 content priority \xE2\u20AC\u201D evergreen discovery, SEO compounding, and 53% of B2B buyers watch video before requesting demos.
+
+Channel Identity
+
+- Name: "Alexander Le | Elevasis" \xE2\u20AC\u201D personal-brand hybrid with clear business association
+- Handle: @AlexanderElevasis
+- Why personal-brand hybrid: People subscribe to people. Algorithm favors creator-branded channels over faceless brands.
+
+Content Format: Face Bubble Intro \xE2\u2020\u2019 Screen Recording
+
+Primary format: Quick face-cam intro (circle overlay, 15-30s) to build trust, then full-screen recording.
+
+Why this works:
+- 40%+ of YouTube's top 1,000 channels never show a presenter \xE2\u20AC\u201D faceless works
+- Screen recording tutorials rank extremely well on YouTube + Google
+- Face in thumbnails gets 921K more views on average
+
+Differentiation
+
+Compete on substance, not production quality:
+- Real execution data, real costs, real results (not simulations)
+- "Document the build" format: record while building, editing, deploying
+- Show Command Center in action \xE2\u20AC\u201D no equivalent content exists
+
+Launch Queue
+
+3 priority video types for channel launch:
+1. Platform demo walkthroughs (Command Center, workflow execution)
+2. Founder journey episodes (building in public)
+3. Educational explainers (AI orchestration concepts)`
+  },
+  {
+    id: "knowledge.youtube-growth-playbook",
+    title: "YouTube Growth Playbook",
+    summary: "Practical YouTube optimization guide for Elevasis screen-recorded demos, founder-led walkthroughs, Shorts, SEO, and launch review loops",
+    bodyText: 'Overview\n\nThis playbook maps YouTube growth tactics to the current Elevasis content format: screen recordings, Command Center walkthroughs, founder commentary, proof assets, and short clips cut from real demos.\n\nThe goal is to make real AI orchestration visible enough that buyers and technical peers understand what Elevasis does.\n\nCore Format\n\n| Format | Use For | Notes |\n| --- | --- | --- |\n| Face intro \xE2\u2020\u2019 screen recording | Flagship demos, founder-led walkthroughs | 15-30 second intro, then full-screen product work |\n| Screen recording only | Tutorials, Shorts source material | Fastest to produce |\n| Data walkthrough | Campaign metrics, cost tracking, workflow results | Use only real data |\n| Concept explainer | AI agents, orchestration, human oversight | Keep tied to concrete business workflows |\n\nCTR Optimization\n\nThumbnails should show the result or system, not abstract concepts:\n1. Command Center, workflow graph, campaign analytics, or visible output\n2. Optional face overlay when it improves trust\n3. Three to five words of context. High contrast, readable at mobile size.\n\nTitle rules:\n- Front-load the topic\n- Use real numbers only when current and verifiable\n- Prefer "Watch", "Real", "Live", "Actual", "Walkthrough" over hype language\n- Make the title and thumbnail say different things\n\nRetention\n\nOpen with the payoff:\n1. Show the final dashboard, result, or workflow output\n2. Explain what the viewer is about to see\n3. Switch into the walkthrough quickly\n\nFirst-24-Hour Workflow\n\nAlgorithm watches first 30-60 minutes closely. A video getting 10 replies in 15 minutes dramatically outperforms one getting 10 replies over 24 hours.'
+  },
+  {
+    id: "knowledge.youtube-mental-prep",
+    title: "Mental Preparation \xE2\u20AC\u201D Creator Anxiety Playbook",
+    summary: "Research-backed strategies for overcoming publishing anxiety, the spotlight effect, graduated exposure, and building comfort on camera \xE2\u20AC\u201D practical guide for a technical founder starting YouTube",
+    bodyText: `Why This Exists
+
+Recording yourself and putting your ideas out publicly is genuinely uncomfortable. This doc captures the research and practical strategies so you can reference them when the anxiety spikes \xE2\u20AC\u201D not as motivation, but as evidence that the discomfort is normal, finite, and navigable.
+
+The Core Insight
+
+Readiness is a product of exposure, not a prerequisite for it. You don't stop feeling afraid and then start. You start, and the fear gradually recedes.
+
+What You're Actually Afraid Of
+
+The Spotlight Effect (Gilovich et al., 2000)
+
+People overestimate how much others notice and judge them by roughly 2x. Early videos get almost zero views \xE2\u20AC\u201D you're practicing in an empty room.
+
+The Five Common Fears (in order of prevalence)
+
+1. Judgment from people you know \xE2\u20AC\u201D not strangers. The #1 blocker.
+2. Perfectionism as procrastination \xE2\u20AC\u201D "I'll start when I have better equipment." This is avoidance.
+3. Impostor syndrome \xE2\u20AC\u201D "Who am I to teach this?"
+4. Permanence anxiety \xE2\u20AC\u201D "This will be on the internet forever"
+5. Voice/face aversion \xE2\u20AC\u201D Most people dislike their recorded voice (bone conduction gap)
+
+The Real Fear: Cringe
+
+People tolerate a video that flops quietly. What they can't tolerate is creating something they later find embarrassing.
+
+Graduated Exposure Protocol
+
+1. Screen recording only (no face, no voice) \xE2\u20AC\u201D 2 videos
+2. Screen recording + voiceover (no face) \xE2\u20AC\u201D 5 videos
+3. Face bubble intro (15-30s) + screen recording \xE2\u20AC\u201D ongoing
+
+Each stage desensitizes one fear at a time. Never skip ahead. The goal is consistency, not perfection.`
+  },
+  {
+    id: "knowledge.youtube-tactics",
+    title: "YouTube Strategy",
+    summary: "YouTube posting strategy \xE2\u20AC\u201D upload optimization, Shorts tactics, algorithm signals, SEO, first-48-hour playbook, faceless content tips, and small channel growth for B2B SaaS",
+    bodyText: `Overview
+
+YouTube is the #2 priority platform and the only one with true evergreen discovery. Videos keep gaining views months/years after posting.
+
+Cadence: 1 long-form/week + 3-5 Shorts/week
+
+Upload Checklist
+
+Title
+- Keep meaningful part in first 60 chars (mobile truncation)
+- Front-load primary keyword: "AI Automation for Veterinary Clinics (Full Walkthrough)"
+- Long-tail titles outperform generic for small channels
+
+Thumbnail
+- 1280x720px, 16:9, max 2MB
+- 4 words max of bold, high-contrast text
+- Use YouTube's Test & Compare \xE2\u20AC\u201D upload 3 thumbnails, YouTube A/B tests and reports CTR
+
+Description
+- First 125 chars = what shows in search results
+- Add timestamps/chapters \xE2\u20AC\u201D improve retention + create extra search ranking hooks
+
+Shorts Strategy
+
+- Cut 30-60s clips from long-form: best moments, surprising reveals, "before/after"
+- Repurpose from YouTube to Instagram Reels and TikTok
+- Hook in first 1-2 seconds: start with the payoff, not the setup
+
+First-48-Hour Playbook
+
+1. Publish during peak hours (12pm-3pm ET Tuesday-Thursday)
+2. Post about the video on LinkedIn immediately after upload
+3. Reply to every comment within the first 24 hours
+4. Share in relevant communities (not spam \xE2\u20AC\u201D genuine value)`
   },
   {
     id: "knowledge.finance-operations-playbook",
@@ -1373,6 +1287,68 @@ Pre-Recording Checklist
     summary: "Operating playbook for Elevasis finance: Xero as the system of record, Stripe payment collection and payout reconciliation, invoicing and AR cadence, tax estimates, deductions, 1099s, and annual filing prep.",
     bodyText: "Overview\n\nElevasis finance operations run through Xero, with Stripe handling payment collection. Xero is the single source of truth for financial records: business checking bank feeds, Stripe payouts, contractor payments, expenses, invoices, receivables, and year-end exports.\n\nThe finance loop has three connected parts:\n\n1. Invoicing captures client revenue through monthly retainers and Stripe Checkout.\n2. Accounting records and reconciles bank transactions, Stripe payouts, contractor payments, and operating expenses.\n3. Taxes use accurate Xero records for quarterly estimates, deductions, 1099s, and annual filing.\n\nAccounting and Reconciliation\n\nReconcile bank transactions in Xero weekly. Match each bank feed entry to its real-world source before month end.\n\n- Stripe payouts should match against Stripe bank feed activity.\n- Contractor payments should match checking account transfers.\n- Software subscriptions such as Railway, Vercel, Supabase, WorkOS, and OpenAI should be categorized as operating expenses.\n- Unmatched or ambiguous transactions should be flagged for manual review before monthly close.\n\nMaintain the core chart of accounts around revenue, cost of sales, operating expenses, and owner draws. Revenue includes client retainers and one-time project fees. Cost of sales covers contractor labor directly tied to client work. Operating expenses cover SaaS tools, hosting, banking fees, and professional services. Owner draws track business distributions.\n\nConfigure Xero with the connected business checking account, the default tax rate for the business jurisdiction, and the correct financial year end in organization settings.\n\nInvoicing and Accounts Receivable\n\nClient billing runs on a monthly retainer model. Create invoices in Xero at the start of each billing period, send them by Xero email or Stripe Checkout link, record payment after Stripe confirms checkout completion, and reconcile the Stripe payout in Xero.\n\nUse Xero repeating invoices for monthly retainers:\n\n- Frequency: monthly.\n- Start date: billing cycle start date.\n- Approval: automatic approval where the billing terms are stable.\n\nConfigure invoice reminders around the due date: a courtesy reminder 3 days before due date, an overdue notice 1 day after due date, and an escalation notice 7 days after due date.\n\nFor invoices more than 14 days overdue, contact the client directly through the active communication channel, pause active work pending payment confirmation, and resolve the balance before the next billing cycle.\n\nTaxes\n\nTax work depends on accurate Xero records throughout the year. As a pass-through entity, Elevasis business income flows to the owner personal return, so quarterly estimates reduce underpayment risk and year-end exports should be clean enough for a CPA or tax preparer.\n\nQuarterly estimated payment targets:\n\n- Q1: April 15.\n- Q2: June 15.\n- Q3: September 15.\n- Q4: January 15 of the following year.\n\nEstimate payments as roughly 25-30% of net profit for the quarter and pay via IRS Direct Pay or EFTPS.\n\nTrack deductible expenses in Xero during the year: SaaS subscriptions, contractor payments, home office expenses where applicable, professional development, courses, and business banking fees. Keep digital receipts organized by year in the business records folder.\n\nIssue 1099-NEC forms to US-based contractors paid more than $600 in a calendar year. Collect a W-9 before first payment, track annual contractor totals in Xero, file 1099-NEC forms by January 31 of the following year, and file the 1096 summary with the IRS when required.\n\nAt year end, export the Xero profit and loss statement and balance sheet. Provide them to the CPA or tax preparer with issued 1099s, bank statements for the business year, mileage logs if applicable, and home office documentation if applicable."
   },
+  {
+    id: "knowledge.ai-orchestration-principles",
+    title: "AI Orchestration Principles",
+    summary: "The 4 principles that separate production AI from toy automation",
+    bodyText: `Most AI automation fails. Not because the technology is bad, but because it's implemented without the principles that make AI systems work in production.
+
+These four principles separate toy automation from AI systems that actually run businesses.
+
+The 4 Principles
+
+1. Integrated: Works With Your Existing Systems
+
+Principle: AI must work with your existing tools, not replace them.
+
+AI that doesn't connect to your CRM, your email, your calendar, your existing workflows is a toy. Real AI automation works WITH what you already have \xE2\u20AC\u201D not instead of it.
+
+- Your 50 Zapier workflows keep running
+- Your CRM stays your CRM
+- AI adds intelligence on top, not a rip-and-replace
+
+The anti-pattern: "Use our AI instead of everything else." Creates vendor lock-in and throws away your existing investment.
+
+2. Improving: Gets Smarter Over Time
+
+Principle: AI must learn from every decision and improve continuously.
+
+Static automation is just fancy if-then logic. Real AI captures every approval, rejection, and edit \xE2\u20AC\u201D then uses that data to get smarter.
+
+The anti-pattern: "Set it and forget it." Systems that don't learn stay dumb forever.
+
+3. Observable: You See What AI Is Doing
+
+Principle: You must be able to see what AI systems are doing in real-time.
+
+Black-box automation is unacceptable for business operations. You need to see every action, every decision, every cost \xE2\u20AC\u201D as it happens.
+
+- Real-time activity feeds showing what's executing
+- Cost tracking per workflow, per execution
+- Token usage visibility
+- Execution logs for debugging
+
+The anti-pattern: "It just works, trust us." Systems without observability create anxiety and prevent adoption.
+
+4. Governed: Humans Control What Matters
+
+Principle: Humans must approve important actions before execution.
+
+AI should handle the grunt work. But critical decisions \xE2\u20AC\u201D sending emails to prospects, updating customer records, publishing content \xE2\u20AC\u201D require human approval.
+
+- AI researches 50 prospects and drafts personalized emails
+- Before anything sends, it lands in your approval queue
+- You spend 10 minutes reviewing, approve or tweak
+- Only then does it execute
+
+The anti-pattern: "Fully autonomous AI." Systems without governance create risk and erode trust.`
+  },
+  {
+    id: "knowledge.communications-map",
+    title: "Communications Map",
+    summary: "All lead-facing messages across the active client acquisition pipeline (stages 01-03). Stages 04-08 communications are archived.",
+    bodyText: 'Overview\n\nEvery message sent to a lead across the active acquisition pipeline \xE2\u20AC\u201D outreach, follow-ups, reminders, and event-triggered emails. 10 total active messages (3 outreach + 1 reply + 2 subsequent reply + 2 discovery reminders + 1 timeout follow-up + 1 timeout re-engagement).\n\nStages 04-08 communications (proposal follow-ups, payment reminders, nurture sequences) are archived.\n\nActive Pipeline Phases\n\n1. Outreach (Instantly)  2. Reply Handling     3. Discovery Reminders\n 3 emails                 1 email + 2 HITL      2 reminders\n Day 0/3/7                On reply              -24h/-1h\n\nPhase 1: Outreach (Instantly)\n\n| # | Day | Subject | Angle | Purpose |\n| --- | --- | --- | --- | --- |\n| 1 | 0 | idea for {{companyName}} | Earn attention | Personal, specific |\n| 2 | 3 | where do business hours actually go? | New angle | Peer-level, intriguing |\n| 3 | 7 | the offer (whenever useful) | Permission to close | Warm, zero pressure |\n\nPhase 2: Reply Handling (Resend)\n\nSent only to INTERESTED replies. LLM drafts; admin approves via HITL before sending.\n\nPhase 3: Discovery Reminders (Resend)\n\nTwo automated reminders per booking:\n- -24h: "Looking forward to our call tomorrow"\n- -1h: "See you in 1 hour" with discovery form link\n\nAll scheduled/event emails signed "Alex". Plain text.'
+  },
   {
     id: "knowledge.org-model-actions",
     title: "Organization Model Actions",
@@ -1442,25 +1418,25 @@ Actions follow a five-stage lifecycle: draft, beta, active, deprecated, archived
     id: "knowledge.org-model-events",
     title: "Organization Model Events",
     summary: "Events are projected signals -- the OM has no authored event domain. They emit from resources and originate from entity state catalogs.",
-    bodyText: "Overview\n\nEvents are projected graph nodes. The Organization Model has no OM.events domain map that authors edit directly. Instead, events are derived by buildOrganizationGraph() from two sources: EventEmissionDescriptor entries on workflow and agent resources, and state catalog entries on entities.\n\nEvery event node carries a unique ID formed as \\<ownerId\\>:\\<eventKey\\>, a human-readable label, and an edge that connects it back to the node that produced it.\n\nProjection logic: packages/core/src/organization-model/graph/build.ts\n\nAuthored vs. Projected\n\nThe distinction matters because it determines where you change event data.\n\nEvents are never edited in a standalone events file. To change an event you must change its source:\n\n- To change a resource-emitted event, update the emits array on the workflow or agent entry in OM.resources.\n- To change an entity state-transition event, update the entity's stateCatalogId or the underlying ontology status/stage catalog on the owning System.\n\nThe graph builder projects these into event graph nodes automatically on the next call to buildOrganizationGraph().\n\nEventEmissionDescriptor on Resources\n\nWorkflow and agent resource entries can declare an emits array. Each element is an EventEmissionDescriptor:\n\n| Field           | Type            | Description                                                   |\n| --------------- | --------------- | ------------------------------------------------------------- |\n| eventKey      | ModelIdSchema | Short key scoped to the owner resource (e.g. enrolled)      |\n| label         | string          | Human-readable label for the event                            |\n| payloadSchema | ModelIdSchema | Optional reference to a schema that describes the payload     |\n| lifecycle     | lifecycle enum  | Optional: draft, beta, active, deprecated, archived |\n\nThe graph builder constructs the full EventDescriptor by combining ownerId (the resource ID), ownerKind: 'resource', and the emission descriptor fields. The resulting event ID is \\<resourceId\\>:\\<eventKey\\>.\n\nAn emits edge is then projected from the resource node to the event node.\n\nOnly workflow and agent resource kinds support emits. integration and script resources do not.\n\noriginatesfrom Edges from Entity State Catalogs\n\nWhen an entity declares a stateCatalogId, the graph builder projects one event node per state transition available to that entity. These events use ownerKind: 'entity' and the resulting event ID is \\<entityId\\>:\\<eventKey\\>.\n\nA reversed originatesfrom edge is projected from the event node pointing back to the entity node. This edge direction is the opposite of emits: it signals that the event represents a state change that originates from the entity, not that the entity actively fires the event.\n\nThe builder resolves state catalogs as follows:\n\n- General status catalogs: status data lives in System.ontology.catalogTypes; direct OM.statuses reads are legacy.\n- crm.pipeline: walks pipeline catalog records via the pipeline migration helper.\n- delivery.task: walks project task status catalog records via the project-status helper.\n- lead-gen.company and lead-gen.contact: walks the LEADGENSTAGECATALOG constant, filtering by entity type.\n\ntriggers Edges to Policies\n\nWhen a policy declares trigger.kind: 'event', the graph builder looks up the projected event node by event ID and emits a triggers edge from the event node to the policy node. This edge is only emitted if the event node was already projected by the time the policy loop runs.\n\nPolicy triggers are the primary way events connect to downstream behavior. No triggers edge is emitted for events that no policy references.\n\nEventDescriptor Full Shape\n\nEventDescriptor is the resolved type used internally by the graph builder. It extends EventEmissionDescriptor with identity fields:\n\n| Field           | Type                       | Description                                           |\n| --------------- | -------------------------- | ----------------------------------------------------- |\n| id            | EventIdSchema            | Composite: \\<ownerId\\>:\\<eventKey\\>                 |\n| ownerId       | resource ID or model ID    | ID of the resource or entity that is the event source |\n| ownerKind     | 'resource' or 'entity' | Discriminates between the two projection paths        |\n| eventKey      | ModelIdSchema            | Short key, unique within the owner                    |\n| label         | string                     | Human-readable label                                  |\n| payloadSchema | ModelIdSchema (opt)      | Schema reference for payload shape                    |\n| lifecycle     | lifecycle enum (opt)       | Lifecycle state from the emission descriptor          |\n\nEventDescriptor is not stored in the graph node itself -- it is used transiently during graph construction to build the node and emit edges. The graph node stores id, kind: 'event', label, and sourceId.\n\nGraph Summary\n\n| Edge kind         | Direction                   | When emitted                                 |\n| ----------------- | --------------------------- | -------------------------------------------- |\n| emits           | resource node -> event node | Resource emits[] array is non-empty        |\n| originatesfrom | event node -> entity node   | Entity has a stateCatalogId                |\n| triggers        | event node -> policy node   | Policy trigger.kind === 'event' matches ID |"
+    bodyText: "Overview\n\nEvents are projected graph nodes. The Organization Model has no OM.events domain map that authors edit directly. Instead, events are derived by buildOrganizationGraph() from two sources: EventEmissionDescriptor entries on workflow and agent resources, and state catalog entries on entities.\n\nEvery event node carries a unique ID formed as \\<ownerId\\>:\\<eventKey\\>, a human-readable label, and an edge that connects it back to the node that produced it.\n\nProjection logic: packages/core/src/organization-model/graph/build.ts\n\nAuthored vs. Projected\n\nThe distinction matters because it determines where you change event data.\n\nEvents are never edited in a standalone events file. To change an event you must change its source:\n\n- To change a resource-emitted event, update the emits array on the workflow or agent entry in OM.resources.\n- To change an entity state-transition event, update the entity's stateCatalogId or the underlying ontology status/stage catalog on the owning System.\n\nThe graph builder projects these into event graph nodes automatically on the next call to buildOrganizationGraph().\n\nEventEmissionDescriptor on Resources\n\nWorkflow and agent resource entries can declare an emits array. Each element is an EventEmissionDescriptor:\n\n| Field           | Type            | Description                                                   |\n| --------------- | --------------- | ------------------------------------------------------------- |\n| eventKey      | ModelIdSchema | Short key scoped to the owner resource (e.g. enrolled)      |\n| label         | string          | Human-readable label for the event                            |\n| payloadSchema | ModelIdSchema | Optional reference to a schema that describes the payload     |\n| lifecycle     | lifecycle enum  | Optional: draft, beta, active, deprecated, archived |\n\nThe graph builder constructs the full EventDescriptor by combining ownerId (the resource ID), ownerKind: 'resource', and the emission descriptor fields. The resulting event ID is \\<resourceId\\>:\\<eventKey\\>.\n\nAn emits edge is then projected from the resource node to the event node.\n\nOnly workflow and agent resource kinds support emits. integration and script resources do not.\n\noriginatesfrom Edges from Entity State Catalogs\n\nWhen an entity declares a stateCatalogId, the graph builder projects one event node per state transition available to that entity. These events use ownerKind: 'entity' and the resulting event ID is \\<entityId\\>:\\<eventKey\\>.\n\nA reversed originatesfrom edge is projected from the event node pointing back to the entity node. This edge direction is the opposite of emits: it signals that the event represents a state change that originates from the entity, not that the entity actively fires the event.\n\nThe builder resolves state catalogs as follows:\n\n- General status catalogs: status data lives in System.ontology.catalogTypes; direct OM.statuses reads are legacy.\n- crm.pipeline: walks pipeline catalog records via the pipeline migration helper.\n- delivery.task: walks project task status catalog records via the project-status helper.\n- lead-gen.company and lead-gen.contact: walks the LEADGENSTAGECATALOG constant, filtering by entity type.\n\nEventDescriptor Full Shape\n\nEventDescriptor is the resolved type used internally by the graph builder. It extends EventEmissionDescriptor with identity fields:\n\n| Field           | Type                       | Description                                           |\n| --------------- | -------------------------- | ----------------------------------------------------- |\n| id            | EventIdSchema            | Composite: \\<ownerId\\>:\\<eventKey\\>                 |\n| ownerId       | resource ID or model ID    | ID of the resource or entity that is the event source |\n| ownerKind     | 'resource' or 'entity' | Discriminates between the two projection paths        |\n| eventKey      | ModelIdSchema            | Short key, unique within the owner                    |\n| label         | string                     | Human-readable label                                  |\n| payloadSchema | ModelIdSchema (opt)      | Schema reference for payload shape                    |\n| lifecycle     | lifecycle enum (opt)       | Lifecycle state from the emission descriptor          |\n\nEventDescriptor is not stored in the graph node itself -- it is used transiently during graph construction to build the node and emit edges. The graph node stores id, kind: 'event', label, and sourceId.\n\nGraph Summary\n\n| Edge kind         | Direction                   | When emitted                          |\n| ----------------- | --------------------------- | ------------------------------------- |\n| emits           | resource node -> event node | Resource emits[] array is non-empty |\n| originatesfrom | event node -> entity node   | Entity has a stateCatalogId         |"
   },
   {
     id: "knowledge.org-model-graph-contract",
     title: "Organization Model Graph Contract",
     summary: "The canonical graph node and edge contract -- authored and projected node kinds, edge kinds, and the resource-type overlay derived from the Organization Model.",
-    bodyText: "Overview\n\nThe Organization Model graph contract defines the typed node and edge taxonomy emitted by buildOrganizationGraph(). Every surface that reads or visualizes the OM -- including Command View -- works against this contract.\n\nThe graph has two categories of nodes: authored nodes derived directly from OM domain maps, and projected nodes derived by the graph builder from authored content. Events and stages are projected; all other node kinds are authored.\n\nSource schema: packages/core/src/organization-model/graph/schema.ts\nProjection logic: packages/core/src/organization-model/graph/build.ts\n\nNode Kinds\n\nThe graph vocabulary includes authored semantic nodes and projected operational/navigation nodes.\n\n| Kind           | Authored / Projected | Source                                                  |\n| -------------- | -------------------- | ------------------------------------------------------- |\n| organization | Projected            | Root node; always present; id is organization-model   |\n| system       | Authored             | OM.systems domain map                                 |\n| role         | Authored             | OM.roles domain map                                   |\n| action       | Authored             | OM.actions domain map                                 |\n| entity       | Authored             | OM.entities domain map                                |\n| event        | Projected            | Derived from resource emits and entity state catalogs |\n| policy       | Authored             | OM.policies domain map                                |\n| stage        | Projected            | Derived from ontology-backed stage catalog helpers |\n| resource     | Authored             | OM.resources domain map                               |\n| knowledge    | Authored             | OM.knowledge id-keyed map                             |\n| customer-segment | Authored         | OM.customers domain map                               |\n| offering     | Authored             | OM.offerings domain map                               |\n| goal         | Authored             | OM.goals domain map                                   |\n| surface      | Projected            | Routeable leaves from OM.navigation.sidebar           |\n| navigation-group | Projected        | Groups from OM.navigation.sidebar                     |\n\nEdge Kinds\n\nTwelve edge kinds are valid in the graph.\n\n| Kind              | Direction                             | Meaning                                                       |\n| ----------------- | ------------------------------------- | ------------------------------------------------------------- |\n| contains        | parent -> child                       | Containment: organization to system, system to resource, etc. |\n| references      | source -> target                      | Cross-reference: role reports-to, agent invokes action        |\n| mapsto         | action -> resource                    | Action is implemented by a resource                           |\n| uses            | system -> action, stage -> action     | System or stage uses an action                                |\n| governs         | knowledge -> target, role -> system   | Knowledge node or role governs a target                       |\n| links           | entity -> entity                      | Typed entity relationship (belongs-to, has-many, etc.)        |\n| affects         | action -> entity                      | Action modifies or reads an entity                            |\n| emits           | resource -> event                     | Resource produces an observable event                         |\n| originatesfrom | event -> entity                       | Event originates from an entity state transition              |\n| triggers        | event -> policy, action -> policy     | Event or action invocation triggers a policy evaluation       |\n| appliesto      | policy -> system/action/resource/role | Policy governs the target                                     |\n| effects         | policy -> action/role                 | Policy effect invokes an action or notifies a role            |\n\nResource Type Overlay\n\nResource nodes carry an optional resourceType field that is a separate enum from kind. It is set by the graph builder from the OM resource kind field or from Command View data.\n\n| Value              | Description                       |\n| ------------------ | --------------------------------- |\n| workflow         | Deterministic automation pipeline |\n| agent            | LLM-driven reasoning resource     |\n| trigger          | Event-driven entry point          |\n| integration      | External service connector        |\n| external         | Third-party system reference      |\n| humancheckpoint | Human-in-the-loop review gate     |\n| script           | One-shot executable script        |\n\nAuthored vs. Projected Fields\n\nAuthored nodes\n\nSystem, role, action, entity, policy, resource, knowledge, customer-segment, offering, and goal nodes are authored in the OM domain maps. Ontology catalog nodes are authored inside System.ontology.catalogTypes and projected with ontology graph IDs. Their id, label, description, and domain-specific fields are set from OM source data.\n\nProjected nodes\n\n- Organization node: always present; id is always organization-model.\n- Event nodes: derived from two sources. Resource events come from resource.emits declarations on workflow and agent resources. Entity events come from the entity's stateCatalogId -- the builder walks compatible pipeline, project-status, or lead-gen stage helpers to generate one event node per transition.\n- Stage nodes: derived from ontology-backed prospecting and lead-gen stage helpers.\n- Surface and navigation-group nodes: derived from navigation.sidebar.\n\nProjected nodes are never authored directly. To add an event, declare emits on a resource or assign stateCatalogId to an entity.\n\nGraph Node Shape\n\nEach node has: id (graph-unique string), kind (one of the 10 kinds), label (display name), optional sourceId (OM domain ID), optional description, optional icon, optional enabled flag, and optional resourceType (resource nodes only).\n\nEach edge has: id (graph-unique string), kind (one of the 12 kinds), sourceId, targetId, optional label, and optional relationshipType (triggers, uses, or approval)."
+    bodyText: "Overview\n\nThe Organization Model graph contract defines the typed node and edge taxonomy emitted by buildOrganizationGraph(). Every surface that reads or visualizes the OM -- including Command View -- works against this contract.\n\nThe graph has two categories of nodes: authored nodes derived directly from OM domain maps, and projected nodes derived by the graph builder from authored content. Events and stages are projected; all other node kinds are authored.\n\nSource schema: packages/core/src/organization-model/graph/schema.ts\nProjection logic: packages/core/src/organization-model/graph/build.ts\n\nNode Kinds\n\nThe graph vocabulary includes authored semantic nodes and projected operational/navigation nodes.\n\n| Kind               | Authored / Projected | Source                                                  |\n| ------------------ | -------------------- | ------------------------------------------------------- |\n| organization     | Projected            | Root node; always present; id is organization-model   |\n| system           | Authored             | OM.systems domain map                                 |\n| role             | Authored             | OM.roles domain map                                   |\n| action           | Authored             | OM.actions domain map                                 |\n| entity           | Authored             | OM.entities domain map                                |\n| event            | Projected            | Derived from resource emits and entity state catalogs |\n| stage            | Projected            | Derived from ontology-backed stage catalog helpers      |\n| resource         | Authored             | OM.resources domain map                               |\n| client           | Authored             | OM.clients domain map                                 |\n| knowledge        | Authored             | OM.knowledge id-keyed map                             |\n| customer-segment | Authored             | OM.customers domain map                               |\n| offering         | Authored             | OM.offerings domain map                               |\n| goal             | Authored             | OM.goals domain map                                   |\n| ontology         | Projected            | Compiled from System.ontology scopes                  |\n| surface          | Projected            | Routeable leaves from OM.navigation.sidebar           |\n| navigation-group | Projected            | Groups from OM.navigation.sidebar                     |\n\nEdge Kinds\n\nSeventeen edge kinds are valid in the graph.\n\n| Kind              | Direction                                                          | Meaning                                                                        |\n| ----------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------ |\n| contains        | parent -> child                                                    | Containment: organization to system, system to resource, etc.                  |\n| references      | source -> target                                                   | Cross-reference: role reports-to, agent invokes action                         |\n| mapsto         | action -> resource                                                 | Action is implemented by a resource                                            |\n| uses            | system -> action, stage -> action                                  | System or stage uses an action                                                 |\n| governs         | knowledge -> target, role -> system                                | Knowledge node or role governs a target                                        |\n| links           | entity -> entity                                                   | Typed entity relationship (belongs-to, has-many, etc.)                         |\n| affects         | action -> entity                                                   | Action modifies or reads an entity                                             |\n| emits           | resource -> event                                                  | Resource produces an observable event                                          |\n| originatesfrom | event -> entity                                                    | Event originates from an entity state transition                               |\n| triggers        | topology source -> target                                          | topology.relationships entry with kind: 'triggers'                         |\n| approval        | topology source -> target                                          | topology.relationships entry with kind: 'approval'                         |\n| appliesto      | ontology catalog -> object, offering -> segment, surface -> system | Scoping: what a catalog, offering, or surface targets                          |\n| actions         | resource -> ontology action                                        | resource.ontology.actions binding                                            |\n| reads           | resource -> ontology object                                        | resource.ontology.reads binding                                              |\n| writes          | resource -> ontology object                                        | resource.ontology.writes binding                                             |\n| usescatalog    | resource -> ontology catalog                                       | resource.ontology.usesCatalogs binding                                       |\n| effects         | (none)                                                             | Declared in the schema; nothing emits it since the policies domain was removed |\n\nTopology relationships are the source of triggers and approval edges; the third relationship kind, uses, reuses the uses edge above.\n\nResource Type Overlay\n\nResource nodes carry an optional resourceType field that is a separate enum from kind. It is set by the graph builder from the OM resource kind field or from Command View data.\n\n| Value              | Description                       |\n| ------------------ | --------------------------------- |\n| workflow         | Deterministic automation pipeline |\n| agent            | LLM-driven reasoning resource     |\n| trigger          | Event-driven entry point          |\n| integration      | External service connector        |\n| external         | Third-party system reference      |\n| humancheckpoint | Human-in-the-loop review gate     |\n| script           | One-shot executable script        |\n\nAuthored vs. Projected Fields\n\nAuthored nodes\n\nSystem, role, action, entity, resource, client, knowledge, customer-segment, offering, and goal nodes are authored in the OM domain maps. Ontology catalog nodes are authored inside System.ontology.catalogTypes and projected with ontology graph IDs. Their id, label, description, and domain-specific fields are set from OM source data.\n\nProjected nodes\n\n- Organization node: always present; id is always organization-model.\n- Event nodes: derived from two sources. Resource events come from resource.emits declarations on workflow and agent resources. Entity events come from the entity's stateCatalogId -- the builder walks compatible pipeline, project-status, or lead-gen stage helpers to generate one event node per transition.\n- Stage nodes: derived from ontology-backed prospecting and lead-gen stage helpers.\n- Surface and navigation-group nodes: derived from navigation.sidebar.\n\nProjected nodes are never authored directly. To add an event, declare emits on a resource or assign stateCatalogId to an entity.\n\nGraph Node Shape\n\nEach node has: id (graph-unique string), kind (one of the 10 kinds), label (display name), optional sourceId (OM domain ID), optional description, optional icon, optional enabled flag, and optional resourceType (resource nodes only).\n\nEach edge has: id (graph-unique string), kind (one of the 12 kinds), sourceId, targetId, optional label, and optional relationshipType (triggers, uses, or approval)."
   },
   {
-    id: "knowledge.org-model-policies",
-    title: "Organization Model Policies",
-    summary: "Policies govern systems, actions, resources, and roles -- with discriminated triggers, predicates, and effects.",
-    bodyText: "Overview\n\nPolicies are cross-cutting governance rules in the Organization Model. They declare what should happen when a trigger fires, under what conditions, and with what effect. Policies are authored in the OM.policies domain map and projected as policy graph nodes by buildOrganizationGraph().\n\nEvery policy emits a contains edge from the organization root and appliesto edges to each system, action, resource, or role it governs. When the trigger is event-based or action-based, an additional triggers edge connects the source node to the policy.\n\nSource schema: packages/core/src/organization-model/domains/policies.ts\n\nPolicyTrigger\n\nThe trigger is a discriminated union on kind that defines what activates the policy.\n\n| Kind                | Required fields | Description                                               |\n| ------------------- | --------------- | --------------------------------------------------------- |\n| event             | eventId       | Fires when the referenced event is projected in the graph |\n| action-invocation | actionId      | Fires when the referenced action is invoked               |\n| schedule          | cron          | Fires on a cron schedule (max 120 chars)                  |\n| manual            | none            | Fires only when explicitly triggered by a user or process |\n\nFor event triggers, the graph builder looks up the projected event node by eventId and emits a triggers edge from that event node to the policy node. For action-invocation triggers, a triggers edge is emitted from the action node to the policy node. Schedule and manual triggers produce no additional graph edges.\n\nPolicyPredicate\n\nThe predicate is a discriminated union on kind that defines the condition under which the policy effect is applied.\n\n| Kind         | Required fields                 | Description                                                |\n| ------------ | ------------------------------- | ---------------------------------------------------------- |\n| always     | none                            | Condition is unconditionally true; effect always fires     |\n| expression | expression (string, max 2000) | Arbitrary expression evaluated at runtime                  |\n| threshold  | metric, operator, value   | Numeric threshold check: lt, lte, eq, gte, or gt |\n\nThe default predicate if not specified is { kind: 'always' }.\n\nPolicyEffect\n\nThe actions field holds an ordered array of effects (PolicyEffect[]). At least one effect is required. Effects are a discriminated union on kind.\n\n| Kind               | Required fields     | Description                                                 |\n| ------------------ | ------------------- | ----------------------------------------------------------- |\n| require-approval | roleId (optional) | Blocks execution until a human approves; routes to the role |\n| invoke-action    | actionId          | Invokes the referenced action as a consequence              |\n| notify-role      | roleId            | Sends a notification to the specified role                  |\n| block            | none                | Stops execution entirely; no approval path                  |\n\nFor invoke-action effects, the graph builder emits an effects edge from the policy node to the referenced action node. For notify-role and require-approval effects that include a roleId, an effects edge is emitted from the policy node to the role node.\n\nappliesTo\n\nThe appliesTo field declares which OM entities the policy governs. It contains four ID arrays, all defaulting to empty:\n\n| Field         | Target kind | Graph edge emitted                        |\n| ------------- | ----------- | ----------------------------------------- |\n| systemIds   | system    | appliesto from policy to system node   |\n| actionIds   | action    | appliesto from policy to action node   |\n| resourceIds | resource  | appliesto from policy to resource node |\n| roleIds     | role      | appliesto from policy to role node     |\n\nA policy can apply to any combination of these targets simultaneously. A policy with all four arrays empty is valid but produces no appliesto edges.\n\nLifecycle\n\nPolicies follow the same five-stage lifecycle as systems and actions: draft, beta, active, deprecated, archived. The default is active. Lifecycle is authored on the policy entry and is reflected in the graph node.\n\nThe order field controls domain-map iteration order. The convention is multiples of 10 (10, 20, 30, ...) to allow easy insertion between existing entries.\n\nGraph Summary\n\n| Edge kind    | Direction                                  | When emitted                                                                       |\n| ------------ | ------------------------------------------ | ---------------------------------------------------------------------------------- |\n| contains   | organization root -> policy node           | Always; every policy is contained by the organization root                         |\n| appliesto | policy node -> system/action/resource/role | For each non-empty appliesTo.Ids entry                                          |\n| triggers   | event or action node -> policy node        | When trigger.kind is event or action-invocation                              |\n| effects    | policy node -> action or role node         | For invoke-action, notify-role, and require-approval effects with a roleId |"
+    id: "knowledge.org-model-reference",
+    title: "Organization Model Schema Reference",
+    summary: "Technical reference for the OrganizationModel Zod schema: all top-level domains, the graph contract orientation, authored primitives versus projected graph nodes, and versioning rules.",
+    bodyText: "Schema\n\nThe OrganizationModel schema is defined in packages/core/src/organization-model/schema.ts. It is versioned at version: 1 and composed from domain sub-schemas. The OM is the authoritative contract for the organization: downstream surfaces including Command View, the Knowledge Browser, and the navigation shell are all derived projections from this schema.\n\nTop-Level Domains\n\nThese are the current top-level fields on OrganizationModel. There is no live features or capabilities top-level field -- those terms are legacy wording and should not appear as authored OM primitives.\n\n- version -- schema version, currently locked at 1\n- domainMetadata -- per-domain version and lastModified tracking\n- branding -- organization name, logo, color identity\n- navigation -- surfaces, groups, and defaultSurfaceId for shell routing\n- sales -- sales domain including pipeline entity references\n- prospecting -- lead generation stages, entity references, and pipeline config\n- projects -- project, milestone, and task entity references\n- identity -- organization identity fields\n- customers -- customer segment definitions\n- offerings -- product and service definitions linked to customer segments\n- roles -- role definitions with reportsToId hierarchy and agentId holder support\n- goals -- OKR-style objectives with period ranges and system links\n- systems -- the backbone: hierarchical bounded contexts with dotted IDs and parentSystemId\n- resources -- governance descriptors for workflows, agents, integrations, triggers, and scripts; resource identity lives here, not in a separate deployment manifest\n- actions -- the invokable semantic layer; actions map to resources, affect entities, bind to knowledge, and expose invocation types (slash command, MCP tool, API endpoint, script execution)\n- entities -- business objects owned by systems, with table metadata, state catalogs, and typed entity links\n- topology -- durable operational wiring between systems, resources, ontology nodes, roles, triggers, and human checkpoints; the three relationship kinds are triggers, uses, and approval\n- statuses -- runtime semantic status registry\n- knowledge -- first-class OM content backed by inline nodes and MDX source nodes\n\nGraph Contract\n\nThe OM is projected into a typed graph by buildOrganizationGraph() in packages/core/src/organization-model/graph/build.ts.\n\nNode kinds: organization, system, client, role, action, entity, event, stage, resource, knowledge, customer-segment, offering, goal, surface, navigation-group, ontology\n\nEdge kinds: contains, references, mapsto, uses, governs, links, affects, emits, originatesfrom, triggers, approval, appliesto, effects, actions, reads, writes, usescatalog\n\nThe resourceType overlay on resource nodes is a separate enum: workflow, agent, trigger, integration, external, humancheckpoint, script.\n\nAuthored Primitives vs Projected Graph Nodes\n\nAuthored primitives are what you write directly in the OM: systems, roles, resources, actions, entities, topology, knowledge. The graph builder reads these and emits a richer set of typed nodes and edges. Events, for example, are not authored directly -- they are projected from resource emits declarations. Stages are projected from prospecting stage catalogs.\n\nCommand View\n\nCommand View is a derived operational projection of the OM graph. It visualizes systems, resources, actions, entities, and relationships using the same node and edge taxonomy as buildOrganizationGraph(). It does not have a separate deployment manifest model -- the OM resources domain is the single source of resource identity."
   },
   {
     id: "knowledge.platform-command-view",
     title: "Platform Command View",
-    summary: "Reference for Command View, the visual Organization Model graph surface that projects systems, resources, actions, entities, events, and policies into an explorable operational view.",
-    bodyText: "Overview\n\nCommand View is the visual surface for the Organization Model graph. It projects the OM -- systems, resources, actions, entities, events, and policies -- into an explorable graph using the same node and edge taxonomy emitted by buildOrganizationGraph().\n\nIt answers operational questions such as:\n\n- What systems own which resources?\n- What does this agent map to in the OM?\n- Which actions affect which entities?\n- If a resource goes offline, what policies or actions reference it?\n- What events originate from this entity or resource?\n\nAccess Command View through the Knowledge area at /knowledge/command-view.\n\nHow Command View Works\n\nCommand View is a projection of the Organization Model graph, not a separate deployment manifest.\n\nThe OM resources domain is the single source of resource identity. The actions domain is the invokable semantic layer. The systems domain is the backbone. Command View merges the graph emitted by buildOrganizationGraph() with optional live Command View data (deployed resource metadata) to render a unified operational picture.\n\nGraph projection pipeline:\n\n1. Organization Model is authored in packages/elevasis-core/src/organization-model/.\n2. buildOrganizationGraph() projects the OM into typed nodes and edges.\n3. Command View data (deployed resource metadata) is optionally merged as an overlay.\n4. The merged graph is serialized and cached.\n5. The frontend visualizes the cached graph.\n\nCommand View does not own resource identity. It reads what the OM declares.\n\nNode Kinds\n\nCommand View renders the same node kinds as the OM graph:\n\n| Kind           | Source         | Description                                                                |\n| -------------- | -------------- | -------------------------------------------------------------------------- |\n| organization | Root           | The organization-model root node                                           |\n| system       | OM.systems   | Bounded contexts with dotted IDs and parentSystemId hierarchy              |\n| role         | OM.roles     | Named roles with hierarchy and holder assignments                          |\n| action       | OM.actions   | Invokable operations with invocation type metadata                         |\n| entity       | OM.entities  | Business objects owned by systems                                          |\n| event        | Projected      | Derived from resource emits declarations and entity state catalogs       |\n| policy       | OM.policies  | Governance rules applied to systems, actions, resources, and roles         |\n| stage        | Projected      | Derived from prospecting stage catalogs                                    |\n| resource     | OM.resources | Workflows, agents, integrations, triggers, scripts, and external resources |\n| knowledge    | OM.knowledge | Knowledge nodes governed by systems                                        |\n\nThe resourceType overlay on resource nodes is a separate enum: workflow, agent, trigger, integration, external, humancheckpoint, script.\n\nEdge Kinds\n\n| Kind              | Meaning                                                                        |\n| ----------------- | ------------------------------------------------------------------------------ |\n| contains        | Parent-to-child containment (organization to system, system to resource, etc.) |\n| references      | Cross-reference between nodes (role reports-to, agent invokes action)          |\n| mapsto         | Action mapped to a resource implementation                                     |\n| uses            | System or stage uses an action                                                 |\n| governs         | Knowledge node or role governs a system or target                              |\n| links           | Entity links to another entity                                                 |\n| affects         | Action affects an entity                                                       |\n| emits           | Resource or entity emits an event                                              |\n| originatesfrom | Event originates from an entity                                                |\n| triggers        | Event or action triggers a policy                                              |\n| appliesto      | Policy applies to a system, action, resource, or role                          |\n| effects         | Policy effect invokes an action or notifies a role                             |\n\nVisualization Modes\n\nCommand View uses Cytoscape graph modes:\n\n- Map: preserves organization structure and honors hidden-resource visibility.\n- Trace: resolves directed paths and reveals resources for the active trace.\n- Impact: pivots around the selected node and reveals related resources for impact review.\n\nFilter panel:\n\n- Search across nodes, relationships, and IDs.\n- Filter by node kind, resource type, environment, topology presence, integrations, and resource facets.\n- Toggle resource visibility and diagnostic/testing resource visibility.\n- Show visible and hidden resource counts in the same control surface.\n\nHidden resource behavior:\n\n- Resource nodes are hidden by default so the organization structure remains readable.\n- Structural nodes remain visible as the navigation skeleton.\n- Selecting a visible node can reveal directly connected hidden resources.\n- Diagnostic and testing resources are hidden by default and can be revealed from the filter panel.\n\nExpand Around behavior:\n\n- Select a node, open Details, and use Expand Around to preview nearby graph context before revealing it.\n- Semantic presets cover coverage, operational dependencies, organization context, and impact paths.\n- System and entity nodes default to Coverage.\n- Resource nodes default to Operational Dependencies.\n- Preview counts show hidden resources before Apply reveals the graph patch.\n\nRead-only constraints:\n\n- No drag and drop.\n- No connection editing.\n- No graph mutation from the visualization layer.\n\nOrganization Model as the Source of Truth\n\nResource identity lives in OM.resources, not in a separate manifest. To add a resource to Command View:\n\n1. Add the resource to OM.resources in the organization model.\n2. Link it to a system via systemPath.\n3. Optionally link actions to the resource via action.resourceId.\n4. Deploy the organization model. Command View reflects the new resource automatically.\n\nThere is no separate DeploymentSpec.relationships declaration required for OM-declared resources. The graph builder derives containment and relationship edges directly from the OM contract.\n\nLive resource metadata (deployed name, description, runtime status) can be overlaid from Command View data when available, but the OM contract is primary.\n\nUsing Command View\n\nSystem Understanding\n\nUseful exploration questions:\n\n- What systems own which resources and entities?\n- What actions does this system expose, and what do they map to?\n- Which knowledge nodes govern this system?\n- What policies apply to this system?\n- What events originate from this entity?\n- What roles are responsible for this system?\n\nVisual patterns:\n\n- Hub nodes with many edges indicate central resources or pivotal systems.\n- Linear chains show sequential workflow pipelines.\n- Branching shows conditional routing or multiple action paths.\n- Isolated nodes may indicate unused or draft resources.\n\nManifest Debugging\n\nUse Command View to verify:\n\n1. Resources appear as nodes under the correct system.\n2. Actions map to the expected resources.\n3. Entities link to the correct systems and each other.\n4. Policies apply to the correct systems, actions, or resources.\n5. Events appear for resources with emits declarations.\n6. Orphaned resources are intentional.\n\nCommon issues:\n\n- Resource declared in OM but assigned to the wrong systemPath.\n- Action resourceId points to a resource ID that does not exist.\n- Entity ownedBySystemId references an unknown system.\n- Policy appliesTo references a system, action, or resource that was removed.\n\nTroubleshooting\n\nEmpty Graph\n\nLikely causes:\n\n- Organization has no systems or resources defined.\n- Search, node kind, or resource type filters hide all graph elements.\n- Command View resources are hidden and no structural nodes match current filters.\n\nCheck:\n\n1. OM systems and resources domains have entries.\n2. Filter panel visibility and filter state.\n3. API response for the /api/command-view endpoint.\n\nFix:\n\n- Add systems and resources to the organization model.\n- Reveal resources or reset graph filters.\n\nMissing Nodes\n\nLikely causes:\n\n- Resource, action, or entity is defined in OM but omitted from the relevant domain map.\n- Node is hidden by visibility controls.\n- Status, resource type, or topology filters exclude the node.\n\nCheck:\n\n1. OM domain map includes the ID as a key and as id in the entry.\n2. Filter panel visibility and filter state.\n3. Node lifecycle or enabled field.\n\nFix by adding the entry to the correct domain map or revealing hidden nodes.\n\nMissing Edges\n\nLikely causes:\n\n- Action resourceId does not match any OM resource ID.\n- Entity ownedBySystemId references an unknown system.\n- Policy appliesTo references IDs that do not exist.\n- Knowledge node link uses a nodeId that has no matching OM node.\n\nCheck:\n\n1. Cross-reference IDs across OM domains.\n2. Run pnpm --filter @repo/core check-types to surface Zod validation errors.\n\nFix the OM entry to reference the correct ID.\n\nBest Practices\n\nKeep the OM up to date as systems and resources evolve:\n\n1. Add new resources to OM.resources with the correct systemPath.\n2. Map actions to resources via action.resourceId when the action calls a specific resource.\n3. Update entity.ownedBySystemId when entities move between systems.\n4. Update policy.appliesTo when systems, actions, or resources are renamed or removed.\n5. Declare resource.emits for workflows and agents that produce observable events.\n\nUse the OM graph as the authoritative reference for Command View structure. The graph builder derives the visualization from the OM contract -- do not expect Command View to show connections that are not declared in the OM.\n\nRelated References\n\n- /knowledge read knowledge.org-model-reference\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-integration-patterns"
+    summary: "Reference for Command View, the visual Organization Model graph surface that projects systems, resources, actions, entities, and events into an explorable operational view.",
+    bodyText: "Overview\n\nCommand View is the visual surface for the Organization Model graph. It projects the OM -- systems, resources, actions, entities, and events -- into an explorable graph using the same node and edge taxonomy emitted by buildOrganizationGraph().\n\nIt answers operational questions such as:\n\n- What systems own which resources?\n- What does this agent map to in the OM?\n- Which actions affect which entities?\n- If a resource goes offline, what actions or topology relationships reference it?\n- What events originate from this entity or resource?\n\nAccess Command View through the Knowledge area at /knowledge/command-view.\n\nHow Command View Works\n\nCommand View is a projection of the Organization Model graph, not a separate deployment manifest.\n\nThe OM resources domain is the single source of resource identity. The actions domain is the invokable semantic layer. The systems domain is the backbone. Command View merges the graph emitted by buildOrganizationGraph() with optional live Command View data (deployed resource metadata) to render a unified operational picture.\n\nGraph projection pipeline:\n\n1. Organization Model is authored in packages/elevasis/core/config/organization-model/.\n2. buildOrganizationGraph() projects the OM into typed nodes and edges.\n3. Command View data (deployed resource metadata) is optionally merged as an overlay.\n4. The merged graph is serialized and cached.\n5. The frontend visualizes the cached graph.\n\nCommand View does not own resource identity. It reads what the OM declares.\n\nNode Kinds\n\nCommand View renders the same node kinds as the OM graph:\n\n| Kind           | Source         | Description                                                                |\n| -------------- | -------------- | -------------------------------------------------------------------------- |\n| organization | Root           | The organization-model root node                                           |\n| system       | OM.systems   | Bounded contexts with dotted IDs and parentSystemId hierarchy              |\n| role         | OM.roles     | Named roles with hierarchy and holder assignments                          |\n| action       | OM.actions   | Invokable operations with invocation type metadata                         |\n| entity       | OM.entities  | Business objects owned by systems                                          |\n| event        | Projected      | Derived from resource emits declarations and entity state catalogs       |\n| stage        | Projected      | Derived from prospecting stage catalogs                                    |\n| resource     | OM.resources | Workflows, agents, integrations, triggers, scripts, and external resources |\n| knowledge    | OM.knowledge | Knowledge nodes governed by systems                                        |\n\nThe resourceType overlay on resource nodes is a separate enum: workflow, agent, trigger, integration, external, humancheckpoint, script.\n\nEdge Kinds\n\n| Kind              | Meaning                                                                        |\n| ----------------- | ------------------------------------------------------------------------------ |\n| contains        | Parent-to-child containment (organization to system, system to resource, etc.) |\n| references      | Cross-reference between nodes (role reports-to, agent invokes action)          |\n| mapsto         | Action mapped to a resource implementation                                     |\n| uses            | System or stage uses an action                                                 |\n| governs         | Knowledge node or role governs a system or target                              |\n| links           | Entity links to another entity                                                 |\n| affects         | Action affects an entity                                                       |\n| emits           | Resource or entity emits an event                                              |\n| originatesfrom | Event originates from an entity                                                |\n| triggers        | Topology relationship with kind: 'triggers'                                  |\n| approval        | Topology relationship with kind: 'approval'                                  |\n| appliesto      | Ontology catalog, offering, or surface scoped to its target                    |\n| actions         | Resource bound to an ontology action                                           |\n| reads           | Resource reads an ontology object                                              |\n| writes          | Resource writes an ontology object                                             |\n| usescatalog    | Resource uses an ontology catalog                                              |\n\nVisualization Modes\n\nCommand View uses Cytoscape graph modes:\n\n- Map: preserves organization structure and honors hidden-resource visibility.\n- Trace: resolves directed paths and reveals resources for the active trace.\n- Impact: pivots around the selected node and reveals related resources for impact review.\n\nFilter panel:\n\n- Search across nodes, relationships, and IDs.\n- Filter by node kind, resource type, environment, topology presence, integrations, and resource facets.\n- Toggle resource visibility and diagnostic/testing resource visibility.\n- Show visible and hidden resource counts in the same control surface.\n\nHidden resource behavior:\n\n- Resource nodes are hidden by default so the organization structure remains readable.\n- Structural nodes remain visible as the navigation skeleton.\n- Selecting a visible node can reveal directly connected hidden resources.\n- Diagnostic and testing resources are hidden by default and can be revealed from the filter panel.\n\nExpand Around behavior:\n\n- Select a node, open Details, and use Expand Around to preview nearby graph context before revealing it.\n- Semantic presets cover coverage, operational dependencies, organization context, and impact paths.\n- System and entity nodes default to Coverage.\n- Resource nodes default to Operational Dependencies.\n- Preview counts show hidden resources before Apply reveals the graph patch.\n\nRead-only constraints:\n\n- No drag and drop.\n- No connection editing.\n- No graph mutation from the visualization layer.\n\nOrganization Model as the Source of Truth\n\nResource identity lives in OM.resources, not in a separate manifest. To add a resource to Command View:\n\n1. Add the resource to OM.resources in the organization model.\n2. Link it to a system via systemPath.\n3. Optionally link actions to the resource via action.resourceId.\n4. Deploy the organization model. Command View reflects the new resource automatically.\n\nThere is no separate DeploymentSpec.relationships declaration required for OM-declared resources. The graph builder derives containment and relationship edges directly from the OM contract.\n\nLive resource metadata (deployed name, description, runtime status) can be overlaid from Command View data when available, but the OM contract is primary.\n\nUsing Command View\n\nSystem Understanding\n\nUseful exploration questions:\n\n- What systems own which resources and entities?\n- What actions does this system expose, and what do they map to?\n- Which knowledge nodes govern this system?\n- What topology relationships wire this system to others?\n- What events originate from this entity?\n- What roles are responsible for this system?\n\nVisual patterns:\n\n- Hub nodes with many edges indicate central resources or pivotal systems.\n- Linear chains show sequential workflow pipelines.\n- Branching shows conditional routing or multiple action paths.\n- Isolated nodes may indicate unused or draft resources.\n\nManifest Debugging\n\nUse Command View to verify:\n\n1. Resources appear as nodes under the correct system.\n2. Actions map to the expected resources.\n3. Entities link to the correct systems and each other.\n4. Topology relationships connect the correct source and target nodes.\n5. Events appear for resources with emits declarations.\n6. Orphaned resources are intentional.\n\nCommon issues:\n\n- Resource declared in OM but assigned to the wrong systemPath.\n- Action resourceId points to a resource ID that does not exist.\n- Entity ownedBySystemId references an unknown system.\n- Topology relationship references a node that was removed.\n\nTroubleshooting\n\nEmpty Graph\n\nLikely causes:\n\n- Organization has no systems or resources defined.\n- Search, node kind, or resource type filters hide all graph elements.\n- Command View resources are hidden and no structural nodes match current filters.\n\nCheck:\n\n1. OM systems and resources domains have entries.\n2. Filter panel visibility and filter state.\n3. API response for the /api/command-view endpoint.\n\nFix:\n\n- Add systems and resources to the organization model.\n- Reveal resources or reset graph filters.\n\nMissing Nodes\n\nLikely causes:\n\n- Resource, action, or entity is defined in OM but omitted from the relevant domain map.\n- Node is hidden by visibility controls.\n- Status, resource type, or topology filters exclude the node.\n\nCheck:\n\n1. OM domain map includes the ID as a key and as id in the entry.\n2. Filter panel visibility and filter state.\n3. Node lifecycle or enabled field.\n\nFix by adding the entry to the correct domain map or revealing hidden nodes.\n\nMissing Edges\n\nLikely causes:\n\n- Action resourceId does not match any OM resource ID.\n- Entity ownedBySystemId references an unknown system.\n- Topology relationship source or target references an ID that does not exist.\n- Knowledge node link uses a nodeId that has no matching OM node.\n\nCheck:\n\n1. Cross-reference IDs across OM domains.\n2. Run pnpm --filter @repo/core check-types to surface Zod validation errors.\n\nFix the OM entry to reference the correct ID.\n\nBest Practices\n\nKeep the OM up to date as systems and resources evolve:\n\n1. Add new resources to OM.resources with the correct systemPath.\n2. Map actions to resources via action.resourceId when the action calls a specific resource.\n3. Update entity.ownedBySystemId when entities move between systems.\n4. Update topology.relationships when the nodes they wire are renamed or removed.\n5. Declare resource.emits for workflows and agents that produce observable events.\n\nUse the OM graph as the authoritative reference for Command View structure. The graph builder derives the visualization from the OM contract -- do not expect Command View to show connections that are not declared in the OM.\n\nRelated References\n\n- /knowledge read knowledge.org-model-reference\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-integration-patterns"
   },
   {
     id: "knowledge.platform-composition-patterns",
@@ -1472,7 +1448,13 @@ Actions follow a five-stage lifecycle: draft, beta, active, deprecated, archived
     id: "knowledge.platform-integration-patterns",
     title: "Platform Integration Patterns",
     summary: "Reference for connecting Elevasis agents and workflows to external services through adapters, OAuth, API keys, tenant-isolated credentials, retries, and tests.",
-    bodyText: "Overview\n\nIntegration patterns define how Elevasis agents and workflows connect to external services such as Gmail, Attio, Google Sheets, and custom APIs. The platform uses a standardized adapter pattern with OAuth 2.0 and API key authentication backed by tenant-isolated credentials.\n\nCore patterns:\n\n- Direct integration, where a resource uses integration tools directly.\n- Integration workflow, where a workflow coordinates multiple integrations.\n- Shared integration, where multiple resources use the same credential set.\n- Multi-account integration, where the same provider has separate credentials for different contexts.\n\nDirect Integration Pattern\n\nPattern: Resource uses an integration tool.\n\nUse direct integration tools when an agent or workflow performs frequent operations against a provider.\n\nCharacteristics:\n\n- Tools are always available to the resource.\n- There is no additional navigation overhead.\n- The pattern is optimized for frequent read-heavy operations.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories use createIntegrationTool() with a credentialName parameter. Example: createAttioCreateRecordTool(credentialName).\n\nIntegration Workflow Pattern\n\nPattern: Agent invokes a workflow, and the workflow uses integrations.\n\nUse an integration workflow for complex multi-step operations that need deterministic orchestration.\n\nExample lead capture flow:\n\n1. Webhook trigger receives the event.\n2. Workflow creates an Attio contact.\n3. Workflow sends a Gmail notification.\n4. Workflow returns confirmation.\n\nCharacteristics:\n\n- Deterministic execution order.\n- Step-level error handling and retry.\n- Multiple integrations coordinated in one place.\n- Built-in audit trail through workflow execution.\n\nShared Integration Pattern\n\nPattern: Multiple resources share the same integration.\n\nUse shared integrations for organization-wide providers that should use one credential set.\n\nExample:\n\ntext\npackages/elevasis-operations/src/index.ts\n\nCharacteristics:\n\n- One credential per integration.\n- Centralized credential management.\n- Shared across agents and workflows.\n\nMulti-Account Pattern\n\nPattern: Same provider, different credentials.\n\nUse this pattern for department-specific provider instances or separate dev/prod environments.\n\nExample:\n\ntypescript\nconst salesTool = createAttioCreateRecordTool('attio-sales')\nconst supportTool = createAttioCreateRecordTool('attio-support')\n\nDisambiguate multi-account tools with explicit tool names:\n\ntypescript\nconst tool = createAttioToolNamed(\n  'attiosalescreaterecord',\n  'attio-sales',\n  'createRecord'\n)\n\nAuthentication Patterns\n\nOAuth 2.0 vs API Key\n\n| Aspect | OAuth 2.0 | API key |\n| --- | --- | --- |\n| Auth flow | Browser redirect plus token exchange | Direct API key |\n| Setup complexity | High: client ID, secret, redirect URL | Low: single API key |\n| Token refresh | Automatic refresh token rotation | Manual key rotation |\n| Scope control | Granular permission scopes | Full access or none |\n| User context | Per-user authorization | Service-level access |\n| Revocation | User can revoke anytime | Manual key deletion |\n\nOAuth 2.0 Pattern\n\nProviders include Gmail and Google Sheets.\n\nCredential format:\n\ntypescript\ninterface OAuthToken {\n  provider: string\n  accessToken: string\n  refreshToken: string\n  expiresAt: string\n  tokenType: 'Bearer'\n  scope?: string\n}\n\nexpiresAt is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\n\nAPI Key Pattern\n\nProviders include Attio and custom APIs.\n\nCredential format:\n\ntypescript\ninterface APIKeyCredentials {\n  apiKey: string\n}\n\nProvider-specific validation belongs in the adapter. For Attio, see:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\n\nCredential Management\n\nCredentials are stored in the credentials table.\n\nKey columns:\n\n- organizationid for tenant isolation.\n- name, such as elevasis-attio.\n- provider, such as gmail or attio.\n- encryptedvalue containing encrypted JSON.\n\nSecurity rules:\n\n- RLS policies enforce tenant isolation.\n- Values are encrypted at rest.\n- Credentials do not cross organization boundaries.\n\nBest practices:\n\n- Store credentials encrypted in the database.\n- Use tenant-isolated credential names.\n- Validate credentials before API calls.\n- Rotate API keys regularly.\n- Use least-privilege OAuth scopes.\n\nDo not:\n\n- Hardcode credentials in code.\n- Share credentials across organizations.\n- Log credential values.\n- Store provider API keys in environment variables for tenant integrations.\n- Reuse the same credential name for dev and prod.\n\nCredential resolution flow:\n\n1. Tool requests a credential by name.\n2. Platform queries credentials with the current organizationid.\n3. Platform decrypts the credential.\n4. Adapter validates the credential against the provider schema.\n5. Tool passes the credential to the provider adapter.\n6. Usage is logged without credential values.\n\nImplementation reference:\n\ntext\npackages/core/src/execution/engine/tools/integration/tool.ts\n\nError Handling Patterns\n\nAdapters should convert provider errors into platform tooling errors.\n\nCommon error categories:\n\n- credentialsinvalid for invalid or missing credentials.\n- apierror for provider API errors.\n- networkerror for network or timeout failures.\n- validationerror for invalid parameters.\n- methodnotfound for unknown adapter methods.\n\nRetry strategy:\n\n- Network errors: retry with exponential backoff, commonly 1, 2, and 4 seconds.\n- Auth errors: fail immediately because the credential needs attention.\n- Validation errors: fail immediately because the input needs correction.\n- Rate limits: retry after reset when the provider exposes a reset time.\n- Workflow-level retries: commonly 3 attempts with 1, 4, and 9 minute delays.\n\nAdapter Development\n\nAdapter class location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\n\nAdapter classes implement BaseIntegrationAdapter and contain call() and validateCredentials() methods.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories export create{Provider}{Operation}Tool(credentialName) functions.\n\nTests belong under:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/tests/\n\nRegistration happens in:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/index.ts\n\nTesting Strategies\n\nUnit testing:\n\n- Mock external APIs.\n- Cover credential validation.\n- Cover API call construction.\n- Cover response parsing.\n- Cover error handling.\n\nIntegration testing:\n\n- Use real API calls only with test accounts or test workspaces.\n- Clean up test data after tests.\n- Run in CI only when secret credentials are available.\n- Keep provider behavior mocked in unit tests.\n\nAgent testing:\n\n- Test agents using integration tools at the resource boundary.\n- Tenant project agent tests normally live under external/{org}/src/agents/{agent}/tests/.\n\nRelated References\n\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-command-view\n- /knowledge read knowledge.platform-systems-overview"
+    bodyText: "Overview\n\nIntegration patterns define how Elevasis agents and workflows connect to external services such as Gmail, Attio, Google Sheets, and custom APIs. The platform uses a standardized adapter pattern with OAuth 2.0 and API key authentication backed by tenant-isolated credentials.\n\nCore patterns:\n\n- Direct integration, where a resource uses integration tools directly.\n- Integration workflow, where a workflow coordinates multiple integrations.\n- Shared integration, where multiple resources use the same credential set.\n- Multi-account integration, where the same provider has separate credentials for different contexts.\n\nDirect Integration Pattern\n\nPattern: Resource uses an integration tool.\n\nUse direct integration tools when an agent or workflow performs frequent operations against a provider.\n\nCharacteristics:\n\n- Tools are always available to the resource.\n- There is no additional navigation overhead.\n- The pattern is optimized for frequent read-heavy operations.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories use createIntegrationTool() with a credentialName parameter. Example: createAttioCreateRecordTool(credentialName).\n\nIntegration Workflow Pattern\n\nPattern: Agent invokes a workflow, and the workflow uses integrations.\n\nUse an integration workflow for complex multi-step operations that need deterministic orchestration.\n\nExample lead capture flow:\n\n1. Webhook trigger receives the event.\n2. Workflow creates an Attio contact.\n3. Workflow sends a Gmail notification.\n4. Workflow returns confirmation.\n\nCharacteristics:\n\n- Deterministic execution order.\n- Step-level error handling and retry.\n- Multiple integrations coordinated in one place.\n- Built-in audit trail through workflow execution.\n\nShared Integration Pattern\n\nPattern: Multiple resources share the same integration.\n\nUse shared integrations for organization-wide providers that should use one credential set.\n\nExample:\n\ntext\npackages/elevasis/operations/src/index.ts\n\nCharacteristics:\n\n- One credential per integration.\n- Centralized credential management.\n- Shared across agents and workflows.\n\nMulti-Account Pattern\n\nPattern: Same provider, different credentials.\n\nUse this pattern for department-specific provider instances or separate dev/prod environments.\n\nExample:\n\ntypescript\nconst salesTool = createAttioCreateRecordTool('attio-sales')\nconst supportTool = createAttioCreateRecordTool('attio-support')\n\nDisambiguate multi-account tools with explicit tool names:\n\ntypescript\nconst tool = createAttioToolNamed(\n  'attiosalescreaterecord',\n  'attio-sales',\n  'createRecord'\n)\n\nAuthentication Patterns\n\nOAuth 2.0 vs API Key\n\n| Aspect | OAuth 2.0 | API key |\n| --- | --- | --- |\n| Auth flow | Browser redirect plus token exchange | Direct API key |\n| Setup complexity | High: client ID, secret, redirect URL | Low: single API key |\n| Token refresh | Automatic refresh token rotation | Manual key rotation |\n| Scope control | Granular permission scopes | Full access or none |\n| User context | Per-user authorization | Service-level access |\n| Revocation | User can revoke anytime | Manual key deletion |\n\nOAuth 2.0 Pattern\n\nProviders include Gmail and Google Sheets.\n\nCredential format:\n\ntypescript\ninterface OAuthToken {\n  provider: string\n  accessToken: string\n  refreshToken: string\n  expiresAt: string\n  tokenType: 'Bearer'\n  scope?: string\n}\n\nexpiresAt is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\n\nAPI Key Pattern\n\nProviders include Attio and custom APIs.\n\nCredential format:\n\ntypescript\ninterface APIKeyCredentials {\n  apiKey: string\n}\n\nProvider-specific validation belongs in the adapter. For Attio, see:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\n\nCredential Management\n\nCredentials are stored in the credentials table.\n\nKey columns:\n\n- organizationid for tenant isolation.\n- name, such as elevasis-attio.\n- provider, such as gmail or attio.\n- encryptedvalue containing encrypted JSON.\n\nSecurity rules:\n\n- RLS policies enforce tenant isolation.\n- Values are encrypted at rest.\n- Credentials do not cross organization boundaries.\n\nBest practices:\n\n- Store credentials encrypted in the database.\n- Use tenant-isolated credential names.\n- Validate credentials before API calls.\n- Rotate API keys regularly.\n- Use least-privilege OAuth scopes.\n\nDo not:\n\n- Hardcode credentials in code.\n- Share credentials across organizations.\n- Log credential values.\n- Store provider API keys in environment variables for tenant integrations.\n- Reuse the same credential name for dev and prod.\n\nCredential resolution flow:\n\n1. Tool requests a credential by name.\n2. Platform queries credentials with the current organizationid.\n3. Platform decrypts the credential.\n4. Adapter validates the credential against the provider schema.\n5. Tool passes the credential to the provider adapter.\n6. Usage is logged without credential values.\n\nImplementation reference:\n\ntext\npackages/core/src/execution/engine/tools/integration/tool.ts\n\nError Handling Patterns\n\nAdapters should convert provider errors into platform tooling errors.\n\nCommon error categories:\n\n- credentialsinvalid for invalid or missing credentials.\n- apierror for provider API errors.\n- networkerror for network or timeout failures.\n- validationerror for invalid parameters.\n- methodnotfound for unknown adapter methods.\n\nRetry strategy:\n\n- Network errors: retry with exponential backoff, commonly 1, 2, and 4 seconds.\n- Auth errors: fail immediately because the credential needs attention.\n- Validation errors: fail immediately because the input needs correction.\n- Rate limits: retry after reset when the provider exposes a reset time.\n- Workflow-level retries: commonly 3 attempts with 1, 4, and 9 minute delays.\n\nAdapter Development\n\nAdapter class location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\n\nAdapter classes implement BaseIntegrationAdapter and contain call() and validateCredentials() methods.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories export create{Provider}{Operation}Tool(credentialName) functions.\n\nTests belong under:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/tests/\n\nRegistration happens in:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/index.ts\n\nTesting Strategies\n\nUnit testing:\n\n- Mock external APIs.\n- Cover credential validation.\n- Cover API call construction.\n- Cover response parsing.\n- Cover error handling.\n\nIntegration testing:\n\n- Use real API calls only with test accounts or test workspaces.\n- Clean up test data after tests.\n- Run in CI only when secret credentials are available.\n- Keep provider behavior mocked in unit tests.\n\nAgent testing:\n\n- Test agents using integration tools at the resource boundary.\n- Tenant project agent tests normally live under external/{org}/src/agents/{agent}/tests/.\n\nRelated References\n\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-command-view\n- /knowledge read knowledge.platform-systems-overview"
+  },
+  {
+    id: "knowledge.platform-systems-overview",
+    title: "Platform Systems Overview",
+    summary: "Authoritative overview of the Elevasis AI Orchestration Platform systems -- what's built, what each system does, and how the pieces fit together",
+    bodyText: "Overview\n\nElevasis is a production AI orchestration platform that coordinates workflows, autonomous agents, and human approvals into a unified operating layer for SMBs. Everything described below is implemented and running in production.\n\nCore Architecture:\n\n| Layer | What It Does | Key Components |\n| --- | --- | --- |\n| Execution | Runs workflows and agents with schema validation | Workflow Engine, Agent Framework, Execution Runner |\n| Control | Human oversight, approvals, and decision capture | Command Queue (HITL), Dynamic Forms, Action System |\n| Intelligence | Autonomous reasoning, tool use, and memory management | ReAct Agents, Knowledge Map, Session Memory |\n| Observability | Real-time visibility into cost, performance, and health | Cost Tracking, Metrics, Activity Log, SSE Streaming |\n| Platform | Multi-tenancy, security, scheduling, integrations | Registry, RLS, Scheduler, Credential Vault, SDK |\n\nExecution Engine\n\nAI Workflows\n\nGraph-based workflow execution with schema-validated steps and conditional routing. Steps define explicit routing: linear, conditional (rule-based branching), or terminal. Context flows through the entire workflow.\n\nAutonomous Agents\n\nProduction-grade ReAct-style agents with tool use, memory management, and security hardening.\n\nLLM Provider Support: Anthropic (claude-sonnet-5), OpenAI (GPT-5), OpenRouter (GLM-5)\n\nHuman-in-the-Loop (HITL)\n\nThe Command Queue surfaces pending approvals as structured tasks. Admin reviews, approves or edits, and the workflow continues. Every critical decision \xE2\u20AC\u201D sending emails to prospects, updating customer records, publishing content \xE2\u20AC\u201D requires human approval.\n\nIntegrations (12 active)\n\nAttio CRM, Cal.com, Instantly (cold email), Resend, Apify, Google Maps, Tomba, Mails.so, Supabase, Stripe, OpenAI, Anthropic Claude.\n\nSDK\n\nTypeScript-based resource development with local testing, validation, and deployment pipeline. External consumers define workflows and agents in their own repos and deploy via elevasis-sdk deploy."
   },
   {
     id: "knowledge.system-building",
@@ -1517,7 +1499,7 @@ The sequenced build journey (once available at /om build) walks:
 5. Author knowledge nodes (governs: system:<id> via links frontmatter)
 6. Register the UI manifest (SystemModule keyed to systemId)
 7. Mark system.apiInterface when the system is ready for cross-system use
-8. Run pnpm exec elevasis om:doctor to verify coherence
+8. Run pnpm elevasis-sdk om:doctor to verify coherence
 
 Permanent Guide
 
@@ -1529,7 +1511,7 @@ Read it for step-by-step authoring instructions, code examples, and common mista
 
 Key Source Files
 
-- packages/elevasis-core/src/organization-model/systems.ts -- SystemEntry master abstraction; every buildable slot lives here
+- packages/elevasis/core/config/organization-model/systems.ts -- SystemEntry master abstraction; every buildable slot lives here
 - packages/core/src/organization-model/ontology.ts -- ontology ID scheme (system.path:kind/local-id)
 - packages/core/src/organization-model/helpers.ts -- getSystem / getResourcesForSystem / listAllSystems
 - packages/core/src/organization-model/domains/resources.ts -- ResourceEntry, systemPath, ontology bindings
@@ -1539,6 +1521,18 @@ Related References
 
 - /om read knowledge.platform-composition-patterns
 - /om read knowledge.org-model-graph-contract`
+  },
+  {
+    id: "knowledge.understanding-elevasis",
+    title: "Understanding Elevasis Overview",
+    summary: "Company overview, product positioning, and platform systems context for Elevasis AI orchestration platform",
+    bodyText: "Lean documentation explaining what Elevasis is and what the platform can do. This section provides the foundational context for business conversations and technical evaluation.\n\nElevasis is a done-for-you AI automation service backed by a production-grade platform. The company targets service-based SMBs (2-50 employees, $200K-$5M revenue) who are too busy serving clients to grow their own business.\n\nKey Facts\n\n- Stage: Pre-revenue, platform 100% complete, client acquisition active\n- Offer: Done-for-you AI automation -- we build and maintain the workflows, no coding required\n- ICP: Service-based SMBs (2-50 employees, $200K-$5M revenue, USA)\n- Pricing: $500-$2k/mo (Foundation) \xE2\u2020\u2019 $2k-$5k/mo (Scaled) \xE2\u2020\u2019 $5k-$15k+/mo (AI-Powered)\n- Market: Early Adopters stage, $23.77B TAM growing to $87.7B by 2032\n- Competitive position: No dominant done-for-you SMB AI provider exists; blue ocean\n\nWhen to Use Each Document\n\n| Situation | Document |\n| --- | --- |\n| First conversation with any audience | What is Elevasis |\n| Technical evaluation or demo prep | Platform Systems Overview |\n\nDocumentation\n\n- What is Elevasis \xE2\u20AC\u201D AI orchestration platform overview, company stage, value proposition, and pricing tiers\n- Platform Systems Overview \xE2\u20AC\u201D Authoritative overview of what is built, what each system does, and how the pieces fit together"
+  },
+  {
+    id: "knowledge.what-is-elevasis",
+    title: "What is Elevasis",
+    summary: "Company overview, positioning, value proposition, and pricing for the AI orchestration platform",
+    bodyText: 'Executive Summary\n\nCompany: Bootstrapped AI orchestration platform for done-for-you business automation\n\nFounder: Solo (Alex, 34), bootstrapped\n\nMarket: Service-based SMBs that need practical AI automation without building internal AI teams\n\nGTM: Content-led marketing, proof assets, consultative sales, and land-and-expand pricing\n\nCompany Overview\n\nCurrent Status\n\nThe platform core is production-ready enough to support client-facing demonstrations and implementation work. Current business focus is client acquisition, proof-building, and turning the platform into a repeatable service delivery system.\n\nFounder Profile\n\nAlex, 34 \xE2\u20AC\u201D Solo founder with software engineering background (BSCS degree). Previous: Ecommerce platforms, Streaming technology. No formal AI background \xE2\u20AC\u201D practitioner, not academic.\n\nWhat We Are\n\nOperating layer for AI automation. We help SMBs operate with closed-loop feedback, decision capture, and continuous learning \xE2\u20AC\u201D at SMB pricing with done-for-you implementation (NOT self-service).\n\nTarget Market\n\nICP: Service-based SMBs (2-50 employees, USA, $200K-$5M revenue)\n\nCore Pain: Capacity crisis, pipeline problems, operational chaos, growth blockers \xE2\u20AC\u201D too busy serving clients to grow their own business.\n\nPricing (Land-and-Expand)\n\n- Tier 1 \xE2\u20AC\u201D Foundation (1-2 workflows): $500-2k/mo\n- Tier 2 \xE2\u20AC\u201D Scaled Operations (3-5 workflows): $2k-5k/mo\n- Tier 3 \xE2\u20AC\u201D AI-Powered Systems (6+ workflows): $5k-15k+/mo\n\nAdditional workflows cost less due to shared infrastructure.\n\nValue Proposition\n\n"We find one bottleneck in your business, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."'
   }
 ];