Concepts & Projects
Current efforts (August 2026):
KAL (Knowledge Access Layer) -- new focus. Essentially a framework-driven model for discovering DATA (datasets, attributes, and relationships), applying reasoning (knowledge) to it, and sharing it with others (collaboration).
Adding new models (very impressed with gemma3, 3 and 12 billion parameter versions). Tweaking model parameters to improve performance.. Need to develop a better way to manage models (I'm tracking 15 models now, from the 75+ I've looked at in the past year).
Localized Large Language Models (L3Ms)
L3Ms are computational models that mimic how text is understood and used to simulate human intelligence. They are based on Large Language Models (LLMs) using Generative Pre-trained Transformer (GPT). "Generative" means it creates new content, "Pre-trained" indicates it was trained on vast amounts of data before being used, and "Transformer" refers to the neural network architecture it uses to process information and understand context.
LLM-based applications such as ChatGPT, Gemini, and CoPilot are run on GPU-based architectures to support the heavy duty processing required for the models and numbers of users.
The following diagram illustrates a general view of a commercially available GPT application such as ChatGPT. Note that the processing is completed remotely on a high capacity processing platform.
Running LLMs on local machines means you're not subject to being connected all the time, have more privacy, and have the flexibility to change models as they improve.
Capabilities include responding to questions, categorization, document summarization, keyword (general, name, place) extraction, definition generator, sentiment analysis, outputting to JSON. The following diagram illustrates the difference of L3M architectures in that LLMs are downloaded to local environments and processing is conducted locally.
Capabilities include responding to questions, categorization, document summarization, keyword (general, name, place) extraction, definition generator, sentiment analysis, outputting to JSON. The following diagram illustrates the difference of L3M architectures in that LLMs are downloaded to local environments and processing is conducted locally.
The following summarizes the kinds of things you can do with LLMs and the overall pros and cons.
KAL (Knowledge Access Layer)
KAL is an evolution of the EEAV effort that I've worked on for a number of years.
KAL stands for Knowledge Access Layer. A software application for managing data-based applications that require application of knowledge and journaling. It enables you to capture the structure of data sets, define relationships, create consistent entities (views), define and apply rules to data input, generate reports, and track data changes over time.
KAL consists of four integrated frameworks: data store, dataset/attributes, structured knowledge, and collaborative negotiation. Each framework has it's own job. The data store sets up and uses a "managed" database that allows ingest of data tables (e.g., via CSV files). The dataset/attribute model tracks metadata in a separate data structure that describes the data tables in terms of ingestion, manage field structures - attributes, and relationships to other ingested datasets via common attributes. Structured knowledge allows you to create rules that can be applied to the data. Collaboration and negotiation manages the external processing: viewing and external modification of the data and tracking changes to the data.
KAL is appropriate for applications that have domains of data that require decision support. Rather than just managing the structure of data, it applies knowledge constraints to the data and tracks longer term changes to the data.
The basis of KAL is a long-term effort called EEAV (Enhanced Entity Attribute Value) which as a more limited framework for managing structure. EEAV was developed over 30 years to support rapid construction of data-driven applications.
For the record, I have extensively applied the use of ChatGPT to support the development. 80% of the code is written by me with AI-tools performing the more tedious aspects like correlating SQL structure to data modeling. More significant is the interactive use of AI to manage the development process. The result is a highly structured code set that is designed as an integration of frameworks that have separate, but dependent functionalities. This will enable expansion of the tool over time. In fact, the tool started with the dataset/attribute framework and within a few months of development expanded to the other three frameworks enabling separate, but cohesive, development. The AI process has enabled a significant set of documentation and continues to advise on best paths forward for application.
Current application development is focusing on the management of TRLs (Technology Readiness Levels), a model used by the government (DOW) and industry. The construction of TRL application was particularly useful in defining and refining the KAL functionality. It is expected that other applications will be developed.
KAL does not replace relational database applications. In fact, it is dependent on the SQL applied to building relational databases. KAL extends the relational data model by applying deeper understanding of the data structure, knowledge, and collaborative use of the data.
KAL consists of four integrated frameworks: data store, dataset/attributes, structured knowledge, and collaborative negotiation. Each framework has it's own job. The data store sets up and uses a "managed" database that allows ingest of data tables (e.g., via CSV files). The dataset/attribute model tracks metadata in a separate data structure that describes the data tables in terms of ingestion, manage field structures - attributes, and relationships to other ingested datasets via common attributes. Structured knowledge allows you to create rules that can be applied to the data. Collaboration and negotiation manages the external processing: viewing and external modification of the data and tracking changes to the data.
KAL is appropriate for applications that have domains of data that require decision support. Rather than just managing the structure of data, it applies knowledge constraints to the data and tracks longer term changes to the data.
The basis of KAL is a long-term effort called EEAV (Enhanced Entity Attribute Value) which as a more limited framework for managing structure. EEAV was developed over 30 years to support rapid construction of data-driven applications.
For the record, I have extensively applied the use of ChatGPT to support the development. 80% of the code is written by me with AI-tools performing the more tedious aspects like correlating SQL structure to data modeling. More significant is the interactive use of AI to manage the development process. The result is a highly structured code set that is designed as an integration of frameworks that have separate, but dependent functionalities. This will enable expansion of the tool over time. In fact, the tool started with the dataset/attribute framework and within a few months of development expanded to the other three frameworks enabling separate, but cohesive, development. The AI process has enabled a significant set of documentation and continues to advise on best paths forward for application.
Current application development is focusing on the management of TRLs (Technology Readiness Levels), a model used by the government (DOW) and industry. The construction of TRL application was particularly useful in defining and refining the KAL functionality. It is expected that other applications will be developed.
KAL does not replace relational database applications. In fact, it is dependent on the SQL applied to building relational databases. KAL extends the relational data model by applying deeper understanding of the data structure, knowledge, and collaborative use of the data.
Prompt Engineering
Working with Large Language Models (LLMs) is a combination of science and art. The science is a function of understanding how LLMs work. The art is understanding what you want to know and the best way to ask for it.
The following illustrates a set of reasoning strategies that I have implemented via L3M models to support Agentic AI applications.
