{"slug":"architecture/005-iq-hub-derived-intelligence-only","title":"ADR-005: IQ Hub Stores Derived Intelligence Only","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/005-iq-hub-derived-intelligence-only.mdx","bytes":1373,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Accepted  \n**Date:** 2026-07-21  \n**Deciders:** Nirmal (Founder)\n\n---\n\n## Context\n\nThe IQ Hub (knowledge, intelligence, signals services) needs to store derived context: topic summaries, learnings, embeddings, signal analysis. If it also stored canonical operational state, the boundary between \"fact\" and \"inference\" would blur.\n\n## Decision\n\nThe IQ Hub stores **only derived intelligence**: topic summaries, learnings, conversation summaries, embeddings, signal analysis, and recommendations. It **never stores canonical operational state** (entities, relationships, activities).\n\nCanonical state lives in the Adaptive Spine. IQ Hub reads from Spine and writes derived context to its own stores (Vectorize, D1 knowledge tables).\n\n## Consequences\n\n- **Positive:** Clean separation between facts and inferences. IQ Hub can be rebuilt from Spine without data loss.\n- **Negative:** Two storage systems to maintain. IQ Hub reads are eventually consistent with Spine.\n- **Mitigation:** Provenance tracking in SharedWorkbench timestamps show when each layer was last read.\n\n## Evidence\n\n- `services/knowledge/` — Vectorize embeddings, D1 knowledge tables\n- `services/intelligence/` — Signal analysis, recommendations\n- `contracts/shared-workbench/v1.ts` — `memory`, `knowledge`, `signals` are derived fields\n"}