The AI Models, Tools and Knowledge We Use
What each part does, where it runs and how we give an assistant useful information. A practical reference from our Laser TeamWork experiments.
Start with the job each part does.
A model writes or classifies. An application gives you a place to work with it. A runtime or provider makes the model available. A knowledge library supplies evidence. These pieces work together, but changing one does not necessarily mean replacing the others.
Which models are we using?
| Model | Job | Documented use |
|---|---|---|
Qwen3 4B · qwen3:4b | Generate answers on our own computer. | Installed and tested through Ollama. Useful for development experiments; the recorded test also found an invented detail. |
DeepSeek V4.1 Flash · deepseek/deepseek-v4.1-flash | Generate answers using a cloud service. | Configured through OpenRouter in the AnythingLLM pilot; initial conversations tested. |
Nomic Embed Text · nomic-embed-text | Turn text into numerical representations used to find related passages. | Runs locally to index the pilot lessons. It helps find material; it does not write the answer. |
| GLiClass large v3.0 | Classify a question before an answer is written. | Tested for topic, missing machine information and stop conditions. The surrounding routing service is not built yet. |
The recorded cloud comparison also lists Qwen 3.8 Max and Kimi K3 as options. They are not established here as the active answer model, and their licensing remains a separate verification item. A candidate list is not a recommendation.
Model references: Qwen3, DeepSeek V4.1 Flash, Nomic Embed Text and GLiClass.
Ollama, OpenRouter and AnythingLLM: different jobs.
| Tool | What it does here |
|---|---|
| Ollama | The runtime that loads and runs models locally. Ollama and Llama are different names: our setup record identifies Qwen3 as the installed answering model, not a Meta Llama model. |
| OpenRouter | The service through which our application calls a cloud model. It is the access layer; DeepSeek is the answering model selected in this pilot. |
| AnythingLLM | The application bringing together a workspace, document retrieval and a conversation with a selected model. Our pilot uses its server edition. |
| Codex and Claude Code | Assistants we use to research, build and document the system. These product names do not identify a fixed underlying model version or the model answering a visitor. |
Keeping these roles distinct makes a change easier to understand. Moving the answering model to another provider still requires checking its behavior, response format and data handling. A compatible API does not guarantee equivalent answers.
See the OpenRouter quickstart and AnythingLLM documentation for the products themselves.
Is our reference material “training data”?
For this pilot, knowledge library or reference material describes what we supply. We prepare information the assistant can consult when answering a question. The records reviewed for this page do not document a custom model-training or fine-tuning run.
| Term | Plain-language meaning |
|---|---|
| Model training | Learning patterns by adjusting a model’s internal parameters. A downloaded model has already undergone training by its maker. |
| Fine-tuning | Further training of an existing model on selected examples. This changes the model; it is a separate process from attaching documents. |
| Instructions | Directions for the task: explain clearly, name the source, disclose gaps and ask for missing context. |
| Context | The information supplied for the current response, such as the question, relevant conversation and selected source passages. |
| Retrieval / RAG | Search for relevant material, then give it to the model with the question. RAG means retrieval-augmented generation. |
| Evaluation examples | Questions and expected behavior used to check the system. Running a test does not itself train the model. |
Adding a document to a searchable workspace does not by itself retrain the answering model. Whether a cloud provider stores or uses submitted content is a separate question governed by the selected service, settings and terms. OpenAI’s explanation of prompting, retrieval and fine-tuning describes the technical distinction.
What do we supply for the basics?
- Working principles: who the resource serves, what good work means and which decisions need a person.
- Task instructions: the question to answer, the requested level of detail and how to handle uncertainty.
- Reference knowledge: concise explanations with source links, passage locations, dates and limits.
- Applicability: whether a statement is general education or applies to particular equipment or a particular audience.
- Test cases: ordinary questions, follow-ups, missing evidence, conflicting sources and requests that need a handoff.
Our project routers, standards and reusable procedures provide working instructions for development assistants. The educational library supplies subject evidence. Both are durable project material that should remain understandable outside a chat. Neither is a complete description of the original training data used by the model’s maker.
What Laser TeamWork actually demonstrates.
Laser TeamWork is our first public test project for this approach. Explore the example site and download its reference knowledge, context example and instructions in Lab 005.
There are two related pieces of work. The AnythingLLM conversation pilot has six published lessons indexed for retrieval. Separately, the portable knowledge-library work organizes source-linked records and builds searchable, audience-specific editions. The records do not establish that this newer catalog is already connected to the conversation pilot.
| Piece | Recorded state |
|---|---|
| Conversation pilot | Three initial conversations exercised teaching, clarification and refusal behavior. The record also identifies overly long answers, exposed reasoning text and an unlabeled general claim. These remain limitations, not a passing launch review. |
| Portable evidence library | Editable source records produce a SQLite search database, an offline reader and question-specific evidence packets. This component does not generate answers. |
| Question classifier | The ten-question GLiClass-large experiment missed one stop condition. That small test is not a general accuracy score, and the classifier must not be treated as the sole safety gate. |
| Public interface and answer checking | The router/checker service and custom conversation interface are planned work. No completed public assistant is claimed. |
The teaching pattern is useful beyond lasers: a learner asks a question, sees an explanation with evidence and chooses a relevant follow-up. A school, nonprofit or technical support team can adapt the structure with its own sources and review responsibilities.
How a source becomes part of an answer.
The intended complete workflow is:
- Keep the original source. Record its location, date and the part supporting the claim.
- Write a usable knowledge record. Preserve qualifications, scope and conflicting evidence.
- Select the permitted material. Exclude private records before public retrieval.
- Retrieve for the question. Supply relevant records and instructions as context.
- Generate and check. Confirm that the answer is supported, shows its sources and identifies gaps.
- Correct the library. Fix the owned record and rebuild affected indexes; do not rely on a correction buried in a chat.
A citation is an invitation to inspect evidence. It does not prove that every sentence around it is supported. The model can still misuse a relevant source.
What remains ours when the model changes?
Keep the source records, instructions, evaluation questions and correction history in portable files. A public education collection and a private business collection need separate data boundaries. Our planned private edition uses a separate installation and database; it is not mixed into Laser TeamWork’s public library.
Local document storage does not mean an entire conversation stays local. In the current pilot, embeddings run locally but selected context and questions go to the cloud answering service. Fully local answering requires a local answering model too.
Open weights, open-source software and a hosted API describe different kinds of access. Inspect the exact model and software licenses before redistributing or changing how they are used.
Use this as a reference, then inspect your own setup.
For any AI system, record the application, exact model identifier, provider or runtime, knowledge sources, instructions, data destination and last meaningful test. Update that record when one of those changes.
Continue with our AI responsibilities, keeping AI-assisted development portable or the Digital Ownership Check. Product documentation linked above was checked September 23, 2026; our usage descriptions are dated project records.