PulseIQ

YES. And this time I'm going to give you the whole picture, not send you down another rabbit hole. 😂 🧠 PulseIQ — What are we actually building? PulseIQ is an AI-powered project intelligence platform. The basic idea is: > Companies already have huge amounts of project information scattered across documents, project-management tools, issue trackers, CRMs, databases, spreadsheets, etc. PulseIQ connects to those sources, understands the information, turns it into a common project representation, and then uses ML + LLMs to tell management how healthy a project is, what is likely to go wrong, why it is happening, and what they should do about it. So PulseIQ isn't simply: > "another project management dashboard." It's intended to be the intelligence layer sitting on top of existing project data. --- 1. The problem PulseIQ solves Imagine a company has 50 projects. Information is scattered across: Jira GitHub Excel PostgreSQL CRM Project documents Status reports Internal tools APIs A project manager might have to manually look through all of these to answer: > "Are we actually on track?" And even if they can see the data, raw numbers don't directly answer the important questions. For example: Open bugs: 47 Critical bugs: 8 Completion: 63% Blocked tasks: 12 Missed deadlines: 4 Requirement changes: 11 That's data. PulseIQ's job is to turn that into intelligence: > Project Health: 58/100 — At Risk and then: > Why? • Critical bugs are unusually high relative to team size. • 19% of remaining work is blocked. • Requirement changes are increasing workload pressure. • Missed deadlines indicate schedule instability. And eventually: > What should you do? Prioritize the 8 critical bugs, resolve the largest external dependency, and freeze non-essential requirement changes until the current sprint stabilizes. That's the product. --- 2. The PulseIQ pipeline The entire system we've designed is essentially: DATA SOURCES │ ┌──────────┴──────────┐ │ │ CONNECTORS DOCUMENTS │ │ ▼ ▼ Connector Information Orchestration Extraction │ │ └──────────┬──────────┘ ▼ INGESTION │ ▼ CANONICAL PROJECT DATA │ ▼ FEATURE ENGINEERING │ ▼ ML MODELS │ ┌─────────┼─────────┐ ▼ ▼ ▼ Health Delay Risk Score Risk Trends │ │ │ └─────────┼─────────┘ ▼ AI ANALYSIS │ ┌─────────┼─────────┐ ▼ ▼ ▼ Root Cause Recommendations │ ▼ Executive Summary That is the big picture. --- 3. Step one — Getting data into PulseIQ PulseIQ needs to work with different customer environments. That's why we created two primary data-entry paths. A. Connectors Suppose a customer uses Jira. PulseIQ needs to retrieve project information from Jira. Or perhaps: GitHub Salesforce PostgreSQL REST API Custom internal software Instead of writing the entire process into one giant workflow, we separated responsibilities. Connector Orchestration Agent It decides: "What connector do I need?" Then: Identify connector ↓ Load connector ↓ Execute connector ↓ Receive connector output The actual connector execution is kept in: connectors/ connector_executor.py This is deliberately separate from the LangGraph orchestration. --- 4. Documents are another input Customers may also upload: PDF DOCX TXT Markdown For example: > Weekly Project Status Report containing: Project: Alpha Team Size: 12 Completion: 72% Open Bugs: 34 Critical Bugs: 5 Blocked Tasks: 7 ... PulseIQ doesn't want someone manually entering all that. So we created: Document ↓ Document Parser ↓ Plain Text ↓ LLM Information Extraction ↓ Structured Project Records The parser handles the mechanical part. The LLM handles the understanding. --- 5. The canonical schema This is one of the most important ideas in PulseIQ. Different systems will call things different things. One system might say: employees another: developers another: team_count But PulseIQ wants one consistent representation. So we established a canonical project schema: customer_name project_name snapshot_date team_size work_completion_rate open_bugs critical_bugs blocked_tasks requirement_changes remaining_work_items missed_deadlines dependency_blockers This is essentially the common language of PulseIQ's project intelligence layer. --- 6. Why Schema Mapping exists This is particularly important for connectors. Imagine Jira gives us: issues_open critical_issue_count developers completion_percent PulseIQ wants: open_bugs critical_bugs team_size work_completion_rate That's what our LLM-powered Schema Mapper does. The flow is: Raw Connector Data ↓ LLM Schema Mapper ↓ PulseIQ Canonical Schema We deliberately chose an LLM, rather than a giant hardcoded dictionary. Why? Because different customers and systems may use different terminology and structures. The LLM can understand semantic meaning rather than simply matching exact column names. --- 7. Cleaning the data Once data is in the canonical representation, we clean it. Our ingestion pipeline is: Canonical Records ↓ Remove Empty Records ↓ Remove Duplicate Records ↓ Validation ↓ Feature Engineering Empty record removal If a record is completely empty: { "customer_name": "", "project_name": "", ... } we remove it. But if only one field is missing: { "project_name": "Alpha", "team_size": 10, "open_bugs": null } we keep it. --- 8. Duplicate handling We decided that duplicates shouldn't simply be removed based on the project name. Because PulseIQ is supposed to understand project evolution over time. So our duplicate identity is: customer_name + project_name + snapshot_date That allows: Alpha — Jan 1 Alpha — Jan 8 Alpha — Jan 15 Alpha — Jan 22 to all exist. That becomes incredibly important later for risk trends. --- 9. Validation We don't want garbage numbers entering the models. For example: team_size = -7 completion = 143% Those aren't valid. So validation checks things such as: team_size ≥ 0 counts ≥ 0 work_completion_rate between 0 and 100 snapshot_date valid Instead of deleting the whole record when one field is invalid, we decided to turn the invalid field into: None and preserve the rest of the project information. --- 10. Feature engineering This is where raw project information starts becoming ML signals. Our canonical data includes: team_size open_bugs critical_bugs blocked_tasks remaining_work_items missed_deadlines ... But models can benefit from relationships between those values. So we're engineering features such as: Bug density open_bugs / team_size How much bug load exists relative to team size? Critical bug ratio critical_bugs / open_bugs How severe is the bug population? Workload index remaining_work_items / team_size How much unfinished work exists per person? Blocked task ratio blocked_tasks / remaining_work_items How much remaining work is blocked? Completion gap 100 - work_completion_rate How far away is the project from completion? Deadline pressure missed_deadlines / remaining_work_items Requirement change pressure requirement_changes / remaining_work_items Dependency risk dependency_blockers / remaining_work_items So the ML dataset becomes richer. --- 11. And this is where we stopped This is the important part. We have built the data foundation. We've been building all the plumbing needed to reach this point. We haven't yet built the actual predictive intelligence. That's what comes next. --- 12. Health Score Model This is the first major ML component. PulseIQ should eventually be able to say: PROJECT ALPHA Health Score 72 / 100 Status Healthy or: PROJECT BETA Health Score 41 / 100 Status At Risk The model gets the project's available features: team_size completion_rate bug_density critical_bug_ratio workload_index blocked_task_ratio completion_gap deadline_pressure requirement_change_pressure dependency_risk ... And learns patterns associated with project health. Important: this is why we made the decision earlier that Health Score shouldn't be artificially limited to two features. We want the engineered feature set to be available to the models. --- 13. Delay Risk Model Health and delay aren't exactly the same thing. A project could currently be fairly healthy but still have a high probability of missing its deadline. So another model predicts something like: Delay Risk 78% or: Low / Medium / High The model can use the same rich feature set. --- 14. Risk Trend Remember those historical snapshots? Jan 1 Jan 8 Jan 15 Jan 22 Jan 29 Now PulseIQ can see: Health 82 78 71 63 55 That's much more valuable than saying: > "Health is 55." PulseIQ can say: > Health has deteriorated consistently over the last five snapshots. That is the beginning of project trajectory intelligence. --- 15. Root Cause Analysis Once PulseIQ detects: Health Score: 48 Delay Risk: 82% the user immediately asks: > WHY? That's where the LLM-based analysis comes in. It can inspect the structured project signals and explain: Primary contributors: 1. High critical-bug ratio 2. Increasing blocked work 3. Elevated deadline pressure The combination suggests that the project is experiencing both technical instability and schedule pressure. This isn't just another numerical model. It's an interpretation layer. --- 16. Recommendations Then comes: > What should I do? PulseIQ could generate: Recommended Actions 1. Prioritize the 5 critical bugs. 2. Resolve the highest-impact dependency blocker. 3. Review requirement changes before accepting additional scope. 4. Reassess the current delivery target. Eventually, recommendations should be grounded in actual project evidence rather than generic project-management advice. --- 17. Executive Summary For executives, you don't want: bug_density = 2.83 dependency_risk = 0.19 You want: > Alpha is currently at moderate risk. Health has declined 18 points over the last month, primarily due to increasing critical defects and dependency blockers. Delay risk is high unless the current blockers are resolved. So PulseIQ can turn all the underlying analysis into a concise management briefing. --- 18. Connector Learning There's one particularly interesting part of PulseIQ that we designed. What happens when a customer uses a system PulseIQ doesn't know? Instead of: > "Unsupported connector." we created the Connector Learning Agent. Conceptually: Unknown System ↓ Connector Learning Agent ↓ LLM ↓ Understand system ↓ Generate connector definition The idea is that PulseIQ can eventually become much more adaptable to new enterprise systems instead of requiring engineers to manually build every integration from scratch. This is one of the more ambitious parts of the platform. --- 19. Why LangGraph? We're using LangGraph because PulseIQ isn't just one LLM call. There are multiple distinct processes: Intake Connector orchestration Document orchestration Information extraction Ingestion Connector learning Root cause analysis Recommendations LangGraph gives us explicit state and nodes between these operations. For example: Document Orchestration ↓ Information Extraction Agent ↓ Document Data Ingestion Agent ↓ Processed Data Each agent has a relatively small responsibility. That makes the system easier to debug and extend. --- 20. The philosophy behind the architecture One of the biggest design decisions we've made is: Don't make one giant "AI agent." Instead: Small specialized agents ↓ Clear interfaces ↓ Composable workflows For example, Information Extraction doesn't know anything about ML. The ingestion agent doesn't know anything about Jira. The connector executor doesn't know anything about Health Score. The Health Score model shouldn't care whether the original data came from a PDF or Jira. That's intentional separation of concerns. --- 21. What PulseIQ ultimately looks like to a customer The customer experience could eventually be something like: PULSEIQ │ ┌──────────────┼──────────────┐ │ │ │ Projects Risks Insights │ │ │ ▼ ▼ ▼ Project Alpha Delay Risk Root Cause Project Beta Health Score Recommendations Project Gamma Risk Trend Summary They shouldn't have to care about: PyMuPDF LangGraph Ollama schema mapping feature engineering connector executors Those are implementation details. They care about: > Which projects are healthy? > Which projects are going to miss deadlines? > Why? > What should I do? > What's getting worse? > Where should management intervene? That's PulseIQ. --- 🧠 And where YOU are right now This is the part I really want you to understand because you've been feeling like we're endlessly building infrastructure. You're not starting over. You've already built the foundation required to get here. We're essentially standing at: DATA │ ▼ ┌──────────────────────────────┐ │ PULSEIQ DATA LAYER │ │ │ │ Connectors │ │ Documents │ │ Canonical Schema │ │ Cleaning │ │ Deduplication │ │ Validation │ │ Feature Engineering │ └──────────────┬───────────────┘ │ │ ← WE ARE HERE ▼ ┌──────────────────────────────┐ │ INTELLIGENCE LAYER │ │ │ │ Health Score │ │ Delay Risk │ │ Risk Trends │ │ Root Cause │ │ Recommendations │ │ Executive Summary │ └──────────────────────────────┘ So yes: we're done building the endless plumbing. Our next actual product-building step is the Health Score, and we should approach it carefully because this is where we need to decide what the model is actually learning from, what the target/label is, how we obtain training data, and how we evaluate whether the score is meaningful. That is the point where PulseIQ finally starts becoming the product we envisioned.