Update README.md

README.md

@@ -27,6 +27,34 @@ tags:
 - education
 - tensor-talk
 ---
+---
+license: other
+language:
+  - en
+  - zh
+tags:
+  - qwen3
+  - qwen3-8b
+  - lora
+  - qlora
+  - sft
+  - rag
+  - faiss
+  - dense-retrieval
+  - agent
+  - ppo
+  - rlhf
+  - rule-reward
+  - harness-engineering
+  - um-handbook
+  - question-answering
+  - chatbot
+  - education
+  - tensor-talk
+pipeline_tag: text-generation
+base_model: Qwen/Qwen3-8B
+library_name: transformers
+---
 
 # TensorTalk: UM Handbook Qwen3-8B SFT + RAG + Agent + PPO + Harness Engineering
 
@@ -612,7 +640,7 @@ It shows that retrieval grounding dramatically improves answer quality compared
 
 ## 6.1 Why an Agent Is Needed
 
-The handbook is reliable for stable academic rules, but some questions may require official web information.
+The handbook is reliable for stable academic rules, but a practical university assistant cannot depend only on static handbook text. Some user questions naturally require **official web discovery**, **source checking**, or **routing decisions**.
 
 Examples:
 
@@ -621,26 +649,87 @@ Who is the current dean?
 Where can students find residential college information?
 What official page mentions PEKOM?
 Where is the official SPeCTRUM page?
+What facilities are associated with a specific lab?
+```
+
+For these cases, TensorTalk uses an official-source web agent. The agent is not designed as an unrestricted autonomous browser. It is deliberately designed as a **constrained agent** because the domain is academic handbook QA, where factual trustworthiness is more important than open-ended exploration.
+
+In practical terms, the agent layer answers this question:
+
+> If local handbook RAG is not enough, can the system search official UM/FSKTM sources, reject weak or fake sources, and return evidence safely?
+
+---
+
+## 6.2 How This Project Relates to LangChain and LangGraph
+
+TensorTalk does **not** use LangChain, LangGraph, or LangSmith as the runtime framework. The agent and harness were implemented from scratch in the notebook.
+
+However, the design is conceptually aligned with the official LangChain ecosystem ideas:
+
+- LangChain describes agents as systems that combine language models with tools so they can reason about tasks, decide which tools to use, and iteratively work toward a result.
+- LangGraph describes agent workflows using state, nodes, and edges, where nodes perform computation and edges determine the next transition.
+- LangSmith describes evaluation as a workflow involving datasets, evaluators, and experiments to compare application versions.
+- LangChain/LangGraph documentation also distinguishes between predetermined workflows and dynamic agents; TensorTalk intentionally uses a hybrid design because the handbook QA task needs both predictable guardrails and dynamic retrieval decisions.
+
+Therefore, this project is best described as:
+
+> A from-scratch implementation of a LangChain/LangGraph-inspired agentic RAG harness, not a project built by directly calling LangChain’s prebuilt agent framework.
+
+This distinction is important. TensorTalk does not simply wrap a LangChain agent. Instead, it manually implements the major control ideas:
+
+```text
+State tracking
+→ planning
+→ retrieval/tool routing
+→ source filtering
+→ evidence normalization
+→ evaluation/judging
+→ retry/fallback
+→ final generation
+→ trace output
 ```
 
-For these cases, the system needs a controlled web agent.
+This gives the project more transparency because each part of the agent loop is visible in the notebook and UI trace.
+
+---
+
+## 6.3 Agent Design Philosophy
+
+The TensorTalk agent is built around four principles.
+
+### 1. Source-constrained autonomy
 
-However, a web agent can be dangerous if it freely browses or trusts random pages. Therefore, this project uses a restricted official-source agent.
+The agent can search and fetch information, but only from allowed official sources. It is not free to trust arbitrary search results.
+
+### 2. Evidence-first generation
+
+The model should not directly answer a web-sensitive question before evidence is collected and judged.
+
+### 3. Retry and fallback
+
+If official web evidence is weak, blocked, irrelevant, or unsafe, the system can retry with entity-aware search terms or fall back to local handbook RAG.
+
+### 4. Traceable decisions
+
+The agent does not hide its routing decisions. It records URL candidates, accepted evidence, rejected evidence, grounding decisions, and fallback decisions in trace panels.
 
 ---
 
-## 6.2 Official UM / FSKTM Web Agent
+## 6.4 Official UM / FSKTM Web Agent
 
-The web agent is constrained to official UM / FSKTM domains.
+The web agent is constrained to official UM / FSKTM domains. This is one of the most important safety and reliability choices in the project.
 
-Priority domains:
+### Priority official domains
 
 ```text
 fsktm.um.edu.my
 www.um.edu.my
+um.edu.my
 ```
 
-Auxiliary official domains include UM-related systems such as:
+### Auxiliary official UM-related domains
+
+The project also recognizes selected UM-related service domains when they are relevant to student services, academic systems, library resources, research, career portals, or internal faculty resources:
 
 ```text
 aasd.um.edu.my
@@ -653,41 +742,202 @@ intra.fsktm.um.edu.my
 gallery.fsktm.um.edu.my
 ```
 
-The agent performs:
+The purpose of this whitelist is not to search the whole internet. The purpose is to constrain the agent to sources that are likely to be officially controlled by UM or FSKTM.
+
+---
+
+## 6.5 Domain Whitelist Design
+
+The whitelist is used as a **domain guard** before a page can become trusted evidence.
+
+The system treats URLs in three broad categories:
+
+| URL type | Handling |
+|---|---|
+| Official UM/FSKTM URL | Can be considered as candidate evidence |
+| UM-related service URL | Can be considered if relevant to the question type |
+| Non-official or synthetic URL | Rejected or downgraded |
+
+The whitelist helps prevent common LLM-agent failure cases:
 
 ```text
-query planning
-official web discovery
-URL filtering
-page fetching
-evidence extraction
-evidence scoring
-Qwen-based evidence judging
-retry if weak
-fallback to handbook RAG if needed
+hallucinated programme pages
+invented lab pages
+fake student service URLs
+misrouted search results
+random third-party pages
+SEO or unrelated pages
 ```
 
+For example, the project specifically tests that the agent should not invent or accept URLs like:
+
+```text
+programme-ccna-lab-more-detailedly
+bachelor-of-computer-science-artificial-intelligence
+```
+
+when those pages are not the correct evidence for the user’s question.
+
 ---
 
-## 6.3 Agent Is Not Fully Autonomous by Design
+## 6.6 Web Agent Workflow
 
-This project does not use a completely unrestricted autonomous agent.
+The official-source web agent follows a controlled workflow.
 
-That is intentional.
+```text
+User question
+    ↓
+Intent and entity detection
+    ↓
+Official-search query construction
+    ↓
+Candidate URL discovery
+    ↓
+Domain whitelist filtering
+    ↓
+Synthetic/fake URL rejection
+    ↓
+Fetch or static page fallback
+    ↓
+WAF/block detection
+    ↓
+Text extraction and normalization
+    ↓
+Evidence scoring
+    ↓
+Qwen evidence judge
+    ↓
+Accept evidence, retry, or fallback to handbook RAG
+```
+
+This means the agent is not only a web search function. It is a guarded evidence acquisition pipeline.
+
+---
 
-For a university handbook assistant, unrestricted autonomy is less useful than controlled evidence routing. The system needs to be:
+## 6.7 Planning Inside the Agent
+
+Planning is a visible part of the TensorTalk system.
+
+The planning layer is responsible for deciding:
 
 ```text
-safe
-source-constrained
-traceable
-fallback-aware
-grounded
+Is this a stable handbook question?
+Is this a latest/current official-web question?
+Should local RAG be used first?
+Should official web discovery be attempted?
+Which entity should be searched?
+Which scope should be preferred: undergraduate, postgraduate, general, faculty, or university?
+What evidence type is expected: handbook chunk, official page, contact page, facility page, announcement, policy page?
 ```
 
-So the agent is better described as:
+This planning step is aligned with the idea that agentic systems should not directly jump from user question to final answer. They need a control stage that decides which tools and evidence paths are appropriate.
 
-> A constrained official-source web agent controlled by Harness Engineering.
+TensorTalk’s planning is not a free-form hidden chain-of-thought that users must trust blindly. It is operationalized through explicit routing variables, trace objects, search decisions, and UI panels.
+
+---
+
+## 6.8 Generation Inside the Agent
+
+Generation is the stage where the Qwen3-8B model produces an answer.
+
+However, generation is not allowed to operate alone. The answer generator receives controlled context:
+
+```text
+user question
+retrieved local handbook evidence
+accepted official web evidence
+scope hints
+source metadata
+harness instructions
+answer style constraints
+```
+
+The generator is expected to:
+
+```text
+answer directly
+avoid unsupported claims
+avoid fake URLs
+avoid exposing internal reasoning
+use local handbook evidence when web evidence is weak
+prefer official web evidence only when it is relevant and trusted
+```
+
+In the final stage, the generator is the PPO-trained Qwen3 actor, but it is still wrapped by the same RAG and Harness Engineering control layer.
+
+---
+
+## 6.9 Evaluation Inside the Agent
+
+Evaluation is the other core part of the agent loop. TensorTalk evaluates both evidence and answers.
+
+### Evidence evaluation
+
+The system checks:
+
+```text
+Is the source official?
+Is the URL synthetic or fake?
+Is the page blocked by WAF?
+Is the evidence relevant to the user question?
+Does the evidence mention the right entity?
+Does the evidence match the expected scope?
+```
+
+### Answer evaluation
+
+The system checks:
+
+```text
+Is the final answer grounded in accepted evidence?
+Does it answer the user’s actual question?
+Does it leak internal thinking?
+Does it invent URLs?
+Is it too vague?
+Is it incomplete enough to require fallback or rewrite?
+```
+
+This creates a full agentic loop:
+
+```text
+Planning
+→ Retrieval / tool use
+→ Generation
+→ Evaluation
+→ Retry or fallback
+→ Final answer
+```
+
+---
+
+## 6.10 Why the Agent Is Not Fully Autonomous
+
+The agent is intentionally not fully autonomous.
+
+A fully autonomous browsing agent may:
+
+```text
+search too broadly
+trust wrong sources
+follow irrelevant pages
+invent missing pages
+overuse web search
+ignore handbook evidence
+produce unsupported answers
+```
+
+TensorTalk instead uses a constrained model:
+
+```text
+Dynamic when needed
+Guarded by default
+Official-source-only for web evidence
+RAG-first for handbook-stable questions
+Fallback-aware when web evidence is weak
+Traceable for debugging and demonstration
+```
+
+This is more appropriate for a university handbook assistant.
 
 ---
 
@@ -695,35 +945,175 @@ So the agent is better described as:
 
 ## 7.1 What Harness Engineering Means Here
 
-Harness Engineering is the guardrail system around the model and agent.
+Harness Engineering is the external control system around the LLM, RAG, and agent.
 
 A simple analogy:
 
 ```text
 The LLM/agent is the car.
-Harness Engineering is the guardrail, traffic rule, checkpoint, fallback route, and dashboard.
+Harness Engineering is the guardrail, traffic rule, checkpoint, fallback route, dashboard, and driving examiner.
 ```
 
 The model can generate fluent answers, but the harness controls:
 
-- what it is allowed to search
-- what sources it can trust
-- whether a URL is fake
-- whether evidence is useful
-- whether the answer is grounded
-- whether the system should retry
-- whether it should fall back to local handbook RAG
-- what trace should be shown to the user
+```text
+what it can search
+which domains are trusted
+which URLs are rejected
+which evidence is useful
+when to retry
+when to fallback
+whether the answer is grounded
+whether the UI should show warning traces
+whether the final response is safe enough to display
+```
+
+In TensorTalk, Harness Engineering is not just prompt engineering. Prompt engineering tells the model what to do. Harness Engineering builds the surrounding execution system that checks whether the model actually did it correctly.
 
 ---
 
-## 7.2 Harness Pipeline
+## 7.2 From Prompt Engineering to Harness Engineering
+
+Prompt engineering is like telling a driver:
 
-The standardized TensorTalk Harness Core follows this structure:
+```text
+Please drive carefully.
+```
+
+Harness Engineering is like building:
+
+```text
+lane barriers
+speed checks
+traffic rules
+navigation checkpoints
+fallback routes
+dashboards
+incident logs
+```
+
+In this project, prompt engineering alone is not enough because the model may still:
+
+```text
+invent fake URLs
+mix undergraduate and postgraduate rules
+leak internal reasoning
+trust weak web snippets
+answer without evidence
+overuse web search
+ignore local handbook RAG
+```
+
+The harness prevents or detects these failures through code-level controls, not only prompt instructions.
+
+---
+
+## 7.3 From-scratch LangChain-style Harness
+
+TensorTalk’s harness was built manually rather than by importing a prebuilt LangChain/LangGraph agent.
+
+The implementation follows the same conceptual loop used in many modern agent frameworks:
+
+```text
+Planning
+→ Tool / Retrieval Action
+→ Generation
+→ Evaluation
+→ Retry / Fallback
+→ Finalization
+```
+
+But each component is implemented explicitly:
+
+| Conceptual framework idea | TensorTalk from-scratch implementation |
+|---|---|
+| Agent state | Trace dictionaries, evidence bundles, routing flags, runtime status |
+| Tools | Local RAG retriever, official web search/fetch, URL validator, evidence judge |
+| Nodes | Planning, retrieval, web discovery, evidence filtering, judging, generation, grounding |
+| Edges / transitions | Conditional retry, weak-evidence fallback, RAG fallback, final answer route |
+| Evaluation | Qwen evidence judge, rule checks, answer grounding judge, smoke tests |
+| Observability | Collapsed UI trace panels and printed diagnostic outputs |
+
+This makes the system easier to inspect in an academic notebook because the control logic is visible.
+
+---
+
+## 7.4 Planning → Generation → Evaluation Closed Loop
+
+The most important Harness Engineering contribution in TensorTalk is the closed loop:
+
+```text
+Planning
+    ↓
+Generation
+    ↓
+Evaluation
+    ↓
+Retry / Fallback / Finalization
+```
+
+### Planning
+
+The planning layer decides how to handle the query.
+
+It considers:
+
+```text
+question type
+scope
+entity
+whether local RAG is enough
+whether official web is needed
+whether the query is dynamic/current
+whether the answer should be handbook-grounded or web-grounded
+```
+
+### Generation
+
+The generation layer produces an answer using controlled evidence.
+
+It receives:
+
+```text
+local handbook chunks
+official web evidence
+scope hints
+source metadata
+answer constraints
+```
+
+### Evaluation
+
+The evaluation layer checks the result.
+
+It evaluates:
+
+```text
+source trust
+URL validity
+evidence relevance
+answer grounding
+completeness
+process leakage
+fake URLs
+fallback need
+```
+
+If evaluation fails, the system can retry, reroute, or fall back.
+
+This is the engineering loop that makes TensorTalk more than a simple RAG chatbot.
+
+---
+
+## 7.5 Standardized Harness Core Pipeline
+
+The final standardized TensorTalk Harness Core follows this pipeline:
 
 ```text
 User Question
     ↓
+Planning Layer
+    ↓
 Local Handbook RAG
     ↓
 Official Web Discovery
@@ -742,96 +1132,271 @@ Entity-aware Retry
     ↓
 Weak Evidence Fallback
     ↓
-Answer Generator
+PPO/SFT Answer Generator
     ↓
 Answer Grounding Judge
     ↓
 Completeness Guard
     ↓
+Final Answer
+    ↓
 UI Trace
 ```
 
+This pipeline is intentionally explicit. Each part has a clear job.
+
 ---
 
-## 7.3 Harness Components
+## 7.6 Harness State and Trace Objects
 
-The notebooks include several engineering patches and layers:
+The harness keeps structured trace data so that every answer can be inspected.
 
-### V14 — WAF-aware Harness
+Typical trace information includes:
 
-Handles web pages blocked by WAF or browser failures.
+```text
+retrieved local RAG chunks
+candidate web URLs
+accepted official URLs
+rejected URLs
+web evidence bundle
+harness core route
+evidence judge result
+answer grounding result
+fallback reason
+final answer preview
+```
 
-Functions:
+This is similar in spirit to observability and tracing in agent platforms, but implemented directly in the notebook and UI.
 
-- detect WAF block pages
-- exclude blocked pages from evidence
-- provide diagnostics
-- use safe static fallback if browser click fails
-- reject query-fabricated URLs before evidence building
+---
+
+## 7.7 Domain Guard
+
+The domain guard checks whether a candidate source belongs to the allowed official domain set.
+
+It protects against:
+
+```text
+random third-party websites
+unofficial mirrors
+search result noise
+LLM-fabricated domains
+wrong university pages
+```
+
+It also makes the system explainable. If the agent rejects a page, the trace can show why.
 
 ---
 
-### V15 — Qwen Evidence Judge Loop
+## 7.8 Fake URL Guard
 
-Adds an LLM-based evidence judge.
+The fake URL guard is one of the most important parts of the project because raw LLM generations can invent plausible-looking URLs.
 
-Flow:
+Examples of risky synthetic URLs include:
 
 ```text
-Planner
-→ Search / Fetch
-→ Evidence Filter
-→ Qwen Judge
-→ Retry
-→ Final Evidence
+https://spectrum.umlms
+http://spectrux.medicum
+programme-ccna-lab-more-detailedly
+https://aasd um edu my/studetn
 ```
 
-The purpose is to avoid trusting weak web snippets blindly.
+The guard checks and rejects URLs that:
+
+```text
+are malformed
+look fabricated
+contain suspicious path patterns
+do not belong to allowed domains
+are query-fabricated rather than discovered from official search/fetch
+```
+
+The PPO reward function also penalizes hallucinated URLs, but the harness is still necessary because reward shaping does not guarantee perfect URL behavior.
 
 ---
 
-### V16 — Local-aware Judge Repair
+## 7.9 WAF Detection
 
-Improves routing and fallback.
+Some official pages can be blocked, partially loaded, or protected by web application firewalls.
 
-It handles:
+The WAF-aware harness detects cases where:
 
 ```text
-PEKOM routing
-CCNA Lab routing
-residential college routing
-local RAG fallback
-entity-aware retry
-fake URL rejection
+the page cannot be fetched normally
+the content is a block page instead of the real page
+the browser click fails
+the official site returns insufficient text
+```
+
+When this happens, the system avoids treating the blocked page as strong evidence. It can use diagnostics, retry, static fallback, or local RAG fallback.
+
+---
+
+## 7.10 Evidence Normalizer
+
+Fetched web pages and handbook chunks may be noisy.
+
+The evidence normalizer attempts to convert them into a consistent evidence structure:
+
+```text
+title
+url
+source type
+domain
+text snippet
+score
+scope
+entity
+reason
+```
+
+This makes later judging and UI display easier.
+
+---
+
+## 7.11 Qwen Evidence Judge
+
+The Qwen evidence judge is used to decide whether retrieved evidence actually helps answer the user’s question.
+
+It checks:
+
+```text
+Does the evidence mention the right entity?
+Does it answer the question directly?
+Is it only loosely related?
+Is it a wrong programme/page?
+Is it official but irrelevant?
 ```
 
+This is important because official sources can still be irrelevant. A page can be official and still be the wrong evidence.
+
 ---
 
-### V17 — Strict Entity Judge and UI Polish
+## 7.12 Entity-aware Retry
 
-Adds stricter entity matching and improves trace display.
+If the first web discovery result is weak or misrouted, the harness can retry with better query terms.
 
-This helps avoid cases where a query about one entity is answered with another related but wrong page.
+For example, if a question about PEKOM gets routed toward an AI bachelor programme page, the harness should retry using terms related to:
+
+```text
+PEKOM
+Persatuan Komputer UM
+student society
+FSKTM student association
+```
+
+This prevents the agent from accepting the first official-looking but semantically wrong page.
 
 ---
 
-### V18 — Balanced Official Reference Fallback
+## 7.13 Weak Evidence Fallback
+
+If the official web evidence is weak, TensorTalk can fall back to local handbook RAG.
+
+This prevents a common agent failure:
+
+```text
+The system found a web page, so it trusts it even though it does not answer the question.
+```
+
+Instead, TensorTalk uses:
+
+```text
+web evidence if strong
+local handbook RAG if web evidence is weak
+hybrid answer if both are useful
+refusal/uncertainty if neither is sufficient
+```
+
+---
+
+## 7.14 Answer Grounding Judge
+
+After answer generation, the answer grounding judge checks whether the final answer is supported by the accepted evidence.
+
+It helps catch cases where:
+
+```text
+retrieval was correct but generation added unsupported claims
+the model invented a URL
+the model mixed evidence from different scopes
+the answer contains a statement that does not appear in evidence
+```
+
+This is the evaluation part of the Planning → Generation → Evaluation loop.
+
+---
+
+## 7.15 Completeness Guard
+
+The completeness guard checks whether the answer is too short, vague, or incomplete.
 
-Allows the system to still provide official references when strong web evidence is not enough, while avoiding over-trusting weak pages.
+It can identify cases where the answer:
+
+```text
+only repeats the question
+does not include required details
+misses key fields
+does not answer the requested scope
+cuts off early
+```
+
+Depending on runtime settings, this can trigger a rewrite or fallback.
 
 ---
 
-### V19 — Answer Grounding Judge
+## 7.16 Smoke Tests as Harness Unit Checks
+
+The smoke tests are lightweight checks that make sure the harness pipeline still works after model or code changes.
 
-Checks whether the final generated answer is actually supported by evidence.
+Examples:
+
+```text
+PEKOM should not be routed to the AI bachelor page.
+Residential college should prefer the student-affairs residential page.
+CCNA Lab should not invent synthetic URLs.
+```
 
-This is important because even if retrieval is correct, the model may still introduce unsupported details.
+These tests check:
+
+```text
+routing
+URL filtering
+official page preference
+fake URL rejection
+answer grounding trace
+harness core route
+```
+
+They are not a full benchmark. They are fast sanity checks that the system still runs through the expected pipeline.
 
 ---
 
-### Completeness Guard
+## 7.17 Why Harness Engineering Is Central to This Project
 
-Checks whether the answer is too incomplete and whether a rewrite or fallback should be triggered.
+The final system does not rely on only one technique.
+
+```text
+SFT gives domain answer style.
+RAG gives handbook evidence.
+The web agent gives official external evidence.
+PPO improves answer behavior.
+Harness Engineering controls the whole system.
+```
+
+Without the harness, the system would still be vulnerable to:
+
+```text
+wrong source selection
+fake URLs
+weak web evidence
+scope confusion
+process leakage
+unsupported final answers
+stale artifact loading
+```
+
+Therefore, Harness Engineering is the system-level contribution that connects SFT, RAG, Agent, and PPO into one controlled workflow.
 
 ---
 
@@ -1371,7 +1936,41 @@ Non-PPO fallback is forbidden in the final Improved Model demo.
 
 ---
 
-# 18. Summary
+# 18. Relation to LangChain / LangGraph / LangSmith Concepts
+
+This project does not claim to be a LangChain implementation. Instead, it uses a from-scratch notebook implementation that follows similar engineering ideas.
+
+Official LangChain ecosystem references that influenced the design include:
+
+- [LangChain Agents documentation](https://docs.langchain.com/oss/javascript/langchain/agents): agents combine language models with tools and can iteratively work toward a goal.
+- [LangGraph Overview](https://docs.langchain.com/oss/python/langgraph/overview): LangGraph focuses on durable execution, streaming, human-in-the-loop, persistence, and orchestration for agent workflows.
+- [LangGraph Graph API](https://docs.langchain.com/oss/python/langgraph/graph-api): agent workflows can be modeled through state, nodes, and edges.
+- [LangGraph Workflows and Agents](https://docs.langchain.com/oss/python/langgraph/workflows-agents): workflows use predetermined code paths, while agents are more dynamic in tool usage and process control.
+- [LangSmith Evaluation](https://docs.langchain.com/langsmith/evaluation): evaluation can be structured around datasets, evaluators, and experiments.
+- [LangSmith Evaluation Types](https://docs.langchain.com/langsmith/evaluation-types): evaluation may include benchmarking, unit tests, regression tests, LLM-as-judge evaluators, code evaluators, and online monitoring.
+- [LangSmith Application-specific Evaluation Approaches](https://docs.langchain.com/langsmith/evaluation-approaches): autonomous agents are commonly discussed in terms of tool calling, memory, and planning.
+
+TensorTalk maps these ideas into a custom system:
+
+| LangChain ecosystem idea | TensorTalk implementation |
+|---|---|
+| Agent uses model + tools | Qwen3 model + local RAG + official web search + URL validator + evidence judge |
+| State | Trace dictionaries, evidence bundles, routing flags, model/backend status |
+| Nodes | Planning, retrieval, web discovery, filtering, judging, generation, grounding, completeness checking |
+| Edges | Conditional retry, official-web route, local-RAG fallback, weak-evidence fallback, final-answer route |
+| Planning | Query classification, scope detection, entity-aware routing, web/RAG decision |
+| Generation | SFT/PPO Qwen3 actor generates with accepted evidence |
+| Evaluation | Evidence judge, answer grounding judge, completeness guard, fake URL checks, smoke tests |
+| Observability | TensorTalk collapsed trace panels and diagnostic logs |
+| Regression/smoke testing | PEKOM route test, residential-college URL test, CCNA synthetic URL test |
+
+This is why the project can be described as:
+
+> A from-scratch LangChain/LangGraph-inspired RAG agent harness for UM Handbook QA, with a Planning → Generation → Evaluation control loop.
+
+---
+
+# 19. Summary
 
 TensorTalk demonstrates a staged LLM system development workflow: