与技术员的沟通陷入僵局后，沈墨做出了一个决定。他将系统开发的事情暂时交给小周和小李去琢磨基础框架，自己则拿着笔记本，搬了把椅子，直接坐到了信访接待大厅的接访窗口旁边。
他要亲身体验，亲手绘制最原始、最真实的“信访逻辑流程图”。
第一个前来咨询的是个中年妇女，反映的是小区物业擅自提高停车费的问题。沈墨一边听她情绪激动地叙述，一边在笔记本上快速勾勒：
【入口：物业纠纷】-＞ 【核心诉求：费用不合理】 -＞ 【涉及主体：物业公司、业委会（或缺位）、住建局（物业科）、街道办】 -＞ 【关键依据：《物业管理条例》、小区管理规约】 -＞ 【潜在难点：业委会不作为、部门监管界限模糊】 -＞ 【当前状态：已向社区反映，无果】。
他注意到，老孙在接待时，虽然耐心听着，但并未主动引导对方提供更具体的信息，比如物业公司的名称、收费依据文件、业委会的联系方式等，只是惯例地记录，然后告知会转交住建部门。
第二个是一位个体经营户，因隔壁餐馆油烟排放问题多次投诉环保局未解决。沈墨的笔记变成了：
【入口：环境污染投诉】-＞ 【核心诉求：停止油烟扰民】 -＞ 【涉及主体：涉事餐馆、环保局、市场监管局（营业执照）、城管局（可能涉及占道）】 -＞ 【关键依据：环保排放标准、餐饮业管理规定】 -＞ 【潜在难点：取证难、部门职责交叉（环保 vs 城管）、整改执行难】 -＞ 【当前状态：环保局检测报告显示“未超标”（存疑），陷入僵局】。
他发现，很多问题之所以复杂，在于其天然的“跨部门”属性，以及证据固定和政策适用的模糊地带。现有的信访记录，往往只记录了表面诉求和最简单的转办方向，缺乏对问题核心和难点的深度剖析。
一天下来，沈墨的笔记本上画满了各种箭头、方框和问号。这些手绘的流程图虽然粗糙，却充满了纸上系统无法呈现的细节和张力——群众的焦虑、工作人员的无奈、政策的缝隙、部门的壁垒。
下午，他主动接手了一个老上访户的案子。这位老人因多年前企业改制时的工龄计算问题，持续上访了近十年，卷宗积累了厚厚一摞。之前的处理方式基本是“转交人社局限期处理”，而人社局的回复永远是“符合当时政策规定”。
沈墨没有急于转办。他花了整整两个小时，耐心倾听老人反复的、有时甚至略显混乱的叙述，从中梳理时间线，找出关键争议点——原始档案的缺失、不同时期政策衔接的模糊性。他在笔记本上画出了长达十余个节点的复杂流程图，清晰地标出了每一个可能的核查点和责任分歧点。
“老人家，您的问题确实比较复杂，涉及历史政策衔接和原始档案查找。”沈墨将画好的流程图指给老人看，“我们会尝试联系档案馆、当时的改制领导小组遗留办公室，以及人社局，共同核查您提到的这几个关键节点。但这需要时间，您看可以吗？”
老人看着那张画满符号的纸，虽然看不太懂，但沈墨清晰的分析和诚恳的态度，让他激动情绪平复了许多。“沈主任，只要你肯认真帮俺查，等多久俺都愿意！”
送走老人，沈墨看着那张复杂的流程图，心中豁然开朗。他明白了技术团队缺失的到底是什么——是对信访工作这种高度依赖情境判断和跨领域知识整合特性的深刻理解。系统无法替代人的判断，但可以成为人脑的延伸，提供更强大的信息支持和逻辑辅助。
他将几天来绘制的几十份手绘流程图整理好，带回给技术员小周和小李。
“这就是你们需要的‘业务逻辑’。”沈墨将厚厚一叠图纸放在他们面前，“不要想着一步到位让系统自动处理所有问题。我们先定一个小目标：让系统能辅助工作人员，快速画出这样的‘问题图谱’，并自动关联可能涉及的政策和部门。这能做到吗？”
小周和小李翻看着那些充满细节的流程图，第一次对信访工作的复杂性有了直观的认识。
“如果只是辅助生成图谱和关联信息……我想可以试试！”小周的语气里有了兴奋，“我们可以设计一个可视化的拖拽界面，内置常用的信访要素模块……”
突破口，终于在沈墨沉到最基层之后，隐隐显现。