Data Flow: pal-e-pac
Data Flow
The runtime request flow from user input to tool execution. Answers: what happens when a user runs
pac and gives it a task?Key flows
- Happy path — User request → Router scopes to domain (5-8 tools) → Model picks tool from scoped list → ParamCorrector fixes hallucinations → SafetyNode approves → MCP executes via langchain-mcp-adapters → Model formats result → User sees response.
- Router node — The key insight from Phase 3 baselines. Qwen3-4B's cross-server confusion (calling pal-e-docs tools for Forgejo tasks) is solved by never showing it tools from the wrong server. Rule-based or model-assisted classification.
- ParamCorrector node — Fixes known failure patterns BEFORE the MCP call.
owner=pal-e→forgejo_admin.pal_e_docs__search→search_notes. Correction table driven by benchmark failure data. - Safety gate — Every tool call passes through SafetyNode before execution. Same permissions.yaml logic from Phase 2, now as a graph node instead of an MCP proxy.
- Model loop — After tool execution, the result flows back to the model for formatting. The model sees: original prompt + tool result. This is the standard LangGraph ReAct pattern.
- Deterministic flow — The graph path is fixed (route → select → model → correct → safety → call → respond). Only branching: did the model return a tool call (yes → correct+safety+call) or not (no → respond directly).
Phase 1 Finding
Without the SafetyNode, Qwen3-4B called
create_api_token unprompted when asked to list issues (Phase 1). Without the Router, Qwen3-4B confused MCP servers — calling pal_e_docs__search for Forgejo tasks (Phase 3 baseline, scored 28/100). Without the ParamCorrector, Qwen3-4B used owner=pal-e instead of forgejo_admin. Each node compensates for a specific, measured weakness.