Microsoft IQ describes an enterprise intelligence layer — Work IQ, Fabric IQ, Foundry IQ, Web IQ — as a managed platform capability. This project asks: what does an IQ-inspired workflow look like built entirely from open-source substitutes, with no calls to those services at all, applied to a concrete task — turning spreadsheet formulas into business-readable documentation and migration drafts?
An independent experimental prototype built from public documentation and open-source components. It contains no customer data, customer code, or non-public Microsoft implementation details. It is not an official Microsoft implementation, a calculation engine, or a production migration tool. Generated explanations, requirements, and code require human review.
The core of this project isn't the code, it's being precise about where the substitute stops. Every row below states what's actually implemented and names what it does not claim to replicate.
| Microsoft capability | Implementation here | Boundary of the replacement |
|---|---|---|
| Foundry IQ knowledge retrieval | ChromaDB + Sentence Transformers; a seeded business-rules glossary and workbook comments | Local similarity search, not managed enterprise retrieval, source permissions, Purview enforcement, or guaranteed citations |
| Web IQ web grounding | ddgs search when local retrieval appears weak | External search snippets, not Microsoft's Web IQ service, infrastructure, or full citation handling |
| Work IQ collaboration context | OOXML author metadata, cell comments, optional local git log | File-local signals only; no Microsoft 365 mail, meeting, chat, or permission-aware retrieval |
| Fabric IQ business data & semantics | openpyxl extraction, formulas reference parsing, a NetworkX dependency graph | Workbook-scoped structure, not Fabric IQ, OneLake, an ontology, or a semantic model |
| Agent orchestration | LangGraph state graph | A fixed, inspectable sequence, not a general enterprise agent platform |
| API & Teams channel | FastAPI + the Microsoft Teams SDK for JS/TS | An optional Teams front end, not a replacement for the Teams service |
Given an .xlsx workbook, the pipeline extracts structure, gathers local context, documents each sheet, and compiles the result — to a CLI file or a Teams Adaptive Card with consent-based upload.
Cells, formulas, references, and a dependency graph via openpyxl + formulas + NetworkX.
Local glossary, workbook comments, author/collaboration metadata.
Retrieve local context; fall back to a web query only when retrieval looks weak.
Dependency narrative, draft migration assets, and a Markdown report — CLI file or Teams card.
The formulas parser expands supported ranges and understands cell references structurally. The graph records dependencies, not evaluated calculation results — a dependency graph is not proof of computational equivalence.
Ollama (local), an OpenAI-compatible endpoint, or Microsoft Foundry via AnthropicFoundry + DefaultAzureCredential — model choice and model licensing are kept separate from the open-source application libraries themselves.
A sequence of model calls can take minutes. POST /analyze returns a job ID immediately; the client polls GET /analyze/{job_id} instead of holding one HTTP connection open.
The Python CLI works without a Microsoft 365 tenant at all. The Teams SDK front end (@microsoft/teams.apps, pinned to 2.0.5) is an additive channel, not a dependency of the core pipeline.
Formula parsing is not complete Excel execution — macros, external references, and dynamic behavior need additional validation.
No per-user isolation or enterprise document-permission enforcement; allowed_sources is a metadata filter, not an authorization mechanism.
Search snippets ground generation, but source-linked citations in the report are not guaranteed.
The API job store and bot report cache are in-memory — restarting the process loses job state; this is not a durable queue.
Model-generated requirements and starter code are drafts — review and test before relying on them for business decisions.