四大模块 + 一层合规智能体，以一条与品类无关的数据主干贯通。功能边界、流程设计与数据口径，直接对齐 42 号公告与院内管理制度。
每个模块都对应一条明确的监管要求，来源清晰、口径统一。
公告要求药企为医药代表备案、明确其院内行为规范。守正在医院侧承接：代表线上填报，上传备案信息表 / 身份证件 / 公司授权书三份材料，药学部人工核验后建档。
公告确立机构内设部门统一管理、首访登记、接待核查的"三重门槛"。守正用可配置接待日历与结构化预约，把"什么时候、见谁、为什么"变成有记录、可统计的流程。
学术会议、科室会、专家讲课等院内学术活动透明可溯。守正的活动模块提供报备、审批、签到与出席记录，并与备案数据打通。
纪委 / 行风办获得可查、可统计的监督视图。守正的监管驾驶舱从主干只读地汇聚客观统计，让接待与活动"看得见、说得清"。
依据：《医药代表管理办法》国家药监局等七部门 2026 年第 42 号公告（2026-08-01 施行）· 院内《医药代表院内管理制度》《院内管理实施细则》。
代表进院的第一道关口：身份、资质、材料一次性核验入库。
把"随到随谈"变成"按规则预约、有记录可查"。
学术会议、科室会、专家讲课的报备与追溯。
面向纪委 / 行风的横切只读视图。
与院内既有监控联动，对已备案代表未预约径直到访的情形形成客观记录与人工复核触点。支持后续扩展门禁、二维码等多种到访事件来源。
该能力为受控功能，需完成以下前置条件后方可启用：
系统内置前置检查，未完成不予开启。
依据《个人信息保护法》《数据安全法》《人脸识别技术应用安全管理办法》设计：仅识别已备案代表，非命中人员当场丢弃不留存；底库仅存特征向量、不存人脸图片；人脸图不出院；仅记录客观到访事实并触发人工复核，系统不自动处置。
产品涉及个人信息处理的功能设计，由福州信实律师事务所参与审阅，依据《个人信息保护法》《数据安全法》《人脸识别技术应用安全管理办法》等规定评估并留存记录。
同样的备案、预约、活动数据，交给合规智能体后，不只是被"存起来"，而是被主动核验、被就地答疑、被随时问询。全部本地运行，敏感数据不离开医院。
证件识别预填，并自动比对证照有效期、备案号一致性、企业名称一致性、材料缺失与重复。本地离线运行，图片与数据不出院。
审批时自动汇总客观事实：材料是否齐全、上次到院距今天数、本月来访次数、授权书有效期状态。
基于《医药代表管理办法》全文与院内制度的问答助手，回答"这种情况要不要报备""科室会算不算学术活动"这类日常咨询，减少重复答疑。
用日常语言查询客观统计，如"上月哪些科室接待代表最多""本季度多少场活动有企业赞助"。仅支持预先定义的客观统计指标；超出指标范围的问题，系统会如实告知无法回答，不做推测性作答。
智能层沉淀的是每家医院越用越准的核验与问数能力，与院内数据资产牢牢绑定——这是守正区别于"一套表单工具"的关键。
数据主干不认"药"还是"械"——它管的是"院内商业行为"这件事本身。换个品类，插上去就能复用。这决定了守正能从药代长成平台。
准入、预约、活动、监管围绕"院内商业行为"抽象，药代只是第一个接进来的品类。
三个模块负责写入，监管驾驶舱只读汇聚统计，互不干扰、权责清晰。
单库多租户、行级隔离，内建于底层；一套代码服务多院，复制边际成本低。
FastAPI ＋ PostgreSQL ＋ 服务端渲染前端，选型偏稳，业务方也能看懂、能维护。
OCR 与智能体本地离线运行，证件图片与数据全程在院内，不接云、不外传。
容器化打包，部署在医院内网或既有服务器；反向代理、证书按既有设施接入。
识别与 AI 全程本地离线，图片与数据在院内完成，不接任何云服务、不外传。
敏感信息加密存储、默认脱敏，完整信息经权限校验才可查看，每次查看都写审计日志。
不与 GCP、国家 ADR 上报等已受监管系统重复或干扰，只补医院侧尚缺的那段合规闭环。
我们连边界都想清楚了。