# ADR-0003: Defer Knowledge & Context Capability
**Date:** 2026-01-22
**Status:** Accepted
**Deciders:** Architecture team
## Context
The Jana MCP Server brainstorm identified a "Knowledge & Context" capability to help users understand what environmental data means, not just retrieve it. Example use cases:
- "What is PM2.5 and why does it matter?" (educational)
- "Is 35 µg/m³ PM2.5 safe?" (threshold interpretation)
- "What's the regulatory limit for CO2 emissions?" (regulatory lookup)
- "How does this plant's emissions compare to industry average?" (benchmarking)
During design discussions, we explored implementation options:
1. **Static knowledge base** embedded in MCP server (thresholds, guidelines)
2. **Backend API endpoint** for knowledge queries
3. **LLM knowledge** relying on Claude's training data
4. **Hybrid approach** combining multiple sources
We also analyzed the regulatory data landscape:
- **Air quality thresholds** (WHO, EPA, AQI) are relatively simple and stable
- **Emissions regulations** are complex, jurisdiction-specific, and frequently changing
- **No public APIs exist** for regulatory thresholds — they're published as legal documents
- Building a comprehensive regulatory database would require significant effort (10,000+ rules globally)
## Decision Drivers
- **Scope creep risk:** Knowledge & Context adds complexity beyond core MCP functionality
- **Uncertain requirements:** Unclear which knowledge types users actually need
- **Maintenance burden:** Even a "small" static KB requires ongoing curation
- **Emissions complexity:** Regulations span 190+ countries, 50+ states, multiple sectors
- **Liability concerns:** Providing regulatory interpretation carries risk
- **MVP focus:** Core value is data access, not regulatory intelligence
- **LLM fallback:** Claude can answer many knowledge questions from training data without custom implementation
## Decision
**We defer the Knowledge & Context capability. It will not be implemented in MVP.**
The Jana MCP Server will focus on:
- Data retrieval via eko-client-python APIs
- Natural language → API translation
- Multi-step query orchestration
For knowledge questions, we rely on:
- Claude's training data for general explanations
- Users' own domain expertise for regulatory context
- Links to authoritative sources when relevant
## Consequences
### Positive
- Faster MVP delivery
- Simpler MCP server architecture
- No knowledge base maintenance burden
- No regulatory interpretation liability
- Can observe what users actually ask before building
### Negative
- Users asking "Is this safe?" won't get structured threshold comparisons
- No deterministic regulatory threshold lookups
- May appear less capable than competitors with built-in context
### Neutral
- Claude will still answer knowledge questions from training data (variable accuracy)
- Can revisit this decision based on user feedback
- Discussion document preserved for future reference
## Revisit Criteria
Consider implementing Knowledge & Context if:
1. **User demand:** Multiple users request threshold interpretation or regulatory context
2. **Competitive pressure:** Market expects this capability
3. **Specific scope emerges:** Clear, bounded set of knowledge types needed
4. **Backend support:** Jana backend adds knowledge endpoints we can leverage
## What We Preserve
The design discussion is documented in:
- [KNOWLEDGE_CONTEXT_DISCUSSION.md](../KNOWLEDGE_CONTEXT_DISCUSSION.md) — Full analysis of options, regulatory landscape, and recommendations
This can inform future implementation if we revisit the decision.
## References
- [MCP Server Brainstorm](../MCP_SERVER_BRAINSTORM.md) — Section 6: Knowledge & Context
- [KNOWLEDGE_CONTEXT_DISCUSSION.md](../KNOWLEDGE_CONTEXT_DISCUSSION.md) — Detailed design discussion
- Discussion session 2026-01-22
