The problem
Business users often know the question they want to ask but not where the answer lives, how the underlying data is structured, or which business definitions are required to interpret it correctly. A general-purpose LLM alone cannot reliably supply proprietary business context, governed definitions, or the exact semantics of internal data.
My role
Conceived and implemented as an end-to-end individual-contributor initiative, including the knowledge architecture, structured domain definitions, conversational interaction model, custom data structures, application integration, and optional LLM handoff workflow.
The approach
- Build the core knowledge-access capability independently of an LLM.
- Represent business terminology, data definitions, and domain context in structured, reusable templates.
- Use domain-specific lexicons to connect user language with the terminology and concepts used by the underlying data.
- Separate shared conversational and analytical behavior from domain-specific business knowledge.
- Build a reusable core for common concepts such as markets, ranking, filtering, comparison, and query interpretation.
- Extend the framework through domain templates containing lexicons, measures, relationships, and proprietary business context.
- Package relevant business context into a portable Analysis Package when deeper LLM-assisted analysis is useful.
- Keep proprietary business knowledge and governed context explicit rather than expecting a general-purpose model to infer it.
Technology & capabilities
- Python-based knowledge and analysis services
- Pydantic models for structured data definition and validation
- Custom domain templates and business lexicons
- Structured context and analysis-package generation
- CPR web application integration
- Optional LLM-assisted analysis
Outcomes
- Created a conversational knowledge capability that does not depend on an LLM for its core business-context layer.
- Established a reusable template for extending the approach across additional data domains without redesigning the overall framework.
- Made proprietary terminology, data meaning, and business context explicit and portable rather than leaving them implicit in individual analysts or applications.
- Created a bridge between governed internal knowledge and external LLM reasoning through structured Analysis Packages.
The problem was context, not conversation.
The goal behind AskCJ was not simply to place a chat interface in front of business data. The harder problem was giving a system enough structured business context to understand what users were asking about and to connect those questions to the meaning of the underlying information.
Internal data carries assumptions that a general-purpose language model does not know: company-specific terminology, business definitions, relationships between measures, domain rules, and the vocabulary people actually use in conversation.
AskCJ was designed around making that context explicit.
Building the knowledge layer first
Rather than making an LLM the foundation of the system, I designed AskCJ around a home-grown knowledge layer.
Each supported domain can define its own structured template containing the terminology, concepts, business definitions, and contextual information needed to interpret questions within that subject area.
Domain-specific lexicons provide another bridge between natural user language and the terminology used by the underlying business systems.
This allows the core framework to remain reusable while the business knowledge varies by domain.
Structured by design
A major part of the implementation is the use of explicit, strongly structured data objects rather than loosely formatted conversational text.
Pydantic models are used to define and validate the structures passed through the knowledge and analysis workflow. This provides predictable contracts between components, makes errors easier to identify, and allows new domains or analytical structures to be added without relying on undocumented assumptions.
The result is a system in which business context is represented as data rather than buried inside application code or prompts.
Core intelligence, extended by domain
AskCJ was designed around a shared core that handles concepts and language patterns used across the business, then extends that foundation with domain-specific knowledge.
The core layer supports common interpretation patterns such as markets, ranking, filtering, comparison, and requests like “show me the top 10 nodes by congestion.” Those behaviors do not need to be re-created for every subject area.
Each domain then contributes its own lexicon, business definitions, measures, relationships, and structured context.
This separation allows the framework to grow into new subject areas without rebuilding the conversational engine each time. New domains can be added by extending the knowledge layer while continuing to reuse the same core interaction, validation, and analysis patterns.
Using an LLM where it adds value
AskCJ can operate without an LLM at the center of its architecture.
When deeper reasoning, synthesis, or exploratory analysis is useful, the system can generate an Analysis Package containing the relevant structured business context and carry that package into an LLM-assisted workflow.
This changes the role of the language model. Rather than asking a general-purpose model to somehow know the business, AskCJ supplies the context deliberately and uses the LLM as an analytical extension of a governed knowledge layer.
Proprietary knowledge stays explicit
One of the design principles behind AskCJ is that company-specific knowledge should not be treated as something an external model is expected to infer.
Business definitions, terminology, relationships, and contextual information are modeled explicitly so they can be reviewed, updated, and reused.
That makes the system more transparent and allows the same knowledge structures to support both deterministic application behavior and optional AI-assisted analysis.
A reusable pattern for applied AI
The most important outcome is not simply a conversational interface.
AskCJ represents a reusable architectural pattern for combining structured enterprise knowledge with natural-language interaction and optional AI reasoning.
The application remains grounded in business-owned definitions and context while still taking advantage of an LLM where broader synthesis or analysis can add value.