- 组织树支持五级结构、九种组织类型，可按各校管理口径配置落地
- 志愿者映射为认证教师身份，继承任务与组织授权，做到权责对等
- 学生主记录编号全程不变，考生转新生不换人，避免重复与档案断层
- 权限分角色、权限码、组织授权、数据范围四层，权限码共39个
- 留痕让人敢授权，也是后续让系统自动动手的准入门槛
数据进得来之后，下一步要回答三个更基础的问题：这个人是谁，他归谁管，他能干什么。 这三件事没定下来，任何"精准服务"都只能停留在全体广播。
权限与留痕还有一层更要紧的意思：它们不是合规成本，是后面敢不敢让系统自动动手的唯一前提。
8.1 五级组织、九种组织类型
学生的归属不是一条线。他属于某个学校、某个学院、某个专业、某个年级、某个班级，同时可能属于某个院系办公室、某个身份类别（比如专项计划、少数民族预科）、某个企业（订单班、现代学徒制）。
系统里的组织树支持五级结构（学校／学院／专业／年级／班级），组织类型共九种（学院、专业、年级、班级、部门、办公室、身份类别、企业等）。这一点的实际用处是：学校的真实管理口径五花八门，能表达的模型才配得上真实业务。
一所学校如果按"学院—年级—专业方向"三级管学生，另一所按"学院—专业—班级"三级管，两套都能在这套系统里落地，不需要学校为了迁就系统改自己的管理口径。这是配置化最实在的一面：让系统去贴合组织，不是让组织去迁就系统。
8.2 身份体系：一个人在系统里可以有几种身份
迎新期同时存在四类使用者：学生、教师、家长、志愿者。他们看到的界面和能办的事完全不同。
四类身份里有一条映射规则最能说明设计意图：志愿者在系统里被映射为认证教师身份，从而继承该身份的任务授权与组织授权。理由不是省事，而是权责对等——志愿者在现场代表学校办事（带路、扫码、发放、核验），他的操作必须可追溯到一个有归属的账号上，不能挂在一个临时手机号下面。
这正好接上第三章提出的"没授权"问题。系统里的身份设计不是为了分类，是为了让一线的人有权办事，同时学校知道他办过什么。
8.3 一个主键跟到底：考生转新生不换人
每个学生在系统里只有一条主记录，这条记录的编号全程不变——学生从考生身份进入、被录取、报到、注册为在校生，始终是同一个人。
这件事听起来是技术细节，实际影响三处业务判断：
避免重复。 一名学生被两个批次导入、被两个学院各自录一次，会在系统里出现两个人。主键跟到底之后，一个号码对应一条记录，冲突当场可见（第七章唯一性核验）。
进度可续。 他在预报到阶段做的事，到校当天直接接着用，不需要重头再填一遍。
档案可接。 迎新期采集的照片、身份核验结果、健康数据，都挂在同一个人身上，往后四年可查——这正是第四章所说的"学生数字档案"在数据层的落脚点。
8.4 家长身份与签名
有几类事项需要家长知情或签字：走读申请、部分资助事项、未成年相关的确认。系统里已有家长身份枚举与家长签名字段，走读申请的流程就带这一环（含家长联系方式）。
需要说明范围：家长目前的角色是"被记录、被联系、签名"，尚未提供独立的家长端入口。规划中的家长端是扫码绑定后只读查看孩子的报到进度、缴费状态与宿舍信息，属于按批次建设的内容。这是一条刻意的边界——家长看什么，要先想清楚隐私边界，再决定给不给入口。孩子已经是成年人了，他的家庭住址、健康信息、缴费金额，不该默认向家长全透明。
所以顺序是：先定"哪些可以给家长看"，再上线入口。反过来做，一定会出事。
8.5 权限四层链路：39 个权限码
第三章问的那句"敢不敢"，答案就在权限怎么配。
权限不是一句"他是管理员"，而是四层依次收窄：
角色 → 权限码 → 组织授权 → 数据范围。
- 角色决定他大致是谁（校管理员、学院迎新助理、辅导员、现场工作人员、志愿者）；
- 权限码共 39 个，把动作逐项拆开——看进度、审绿色通道、导出名单、发通知、扫码核验、指定床位，各是独立的一个码，可以单独给；
- 组织授权决定这套动作在哪个范围内有效（只看本院、只看本班、只看本批次）；
- 数据范围再收一层，把他能看到的人收窄到被授权的那一批。
四层合起来，才配得上一句真实的授权："这个学院的迎新助理，只能看本院学生的任务进度，不能导出名单。"
还有一层没合进来：同一张表里哪几列能看。家庭住址、健康明细在院级账号下应当是空白还是可见，今天的答案是"和校级一样"；按数据标签逐列裁的机制还在批次上（见第十三章）。授权要能落到"哪些人、哪几列"，只落到前两层的权限设计，最后一定退回要么全给、要么不给。
多数学校的权限表配不到这么细，结果是只有两种给法：全给或者不给。全给会出事，不给就变成第三章说的那个局面——一线只能回学生一句"这个我做不了主"。
8.6 留痕：审计不是监督，是保护
管理端的每一次改动都自动留下记录：谁、什么时候、动了哪个功能的哪个动作、从哪个地址来的。这条机制不是靠业务人员自觉填写，也不给任何一次操作留下"这次先不记"的余地——它挂在公共链路上，管理侧绕不过去。另外，少数几个会带走大量名单的查询动作也在记录范围内，看谁在什么时候导过什么，有迹可循。
同一张记录表里还存着一类安全事件：登录成功、登录失败、账户锁定、管理端登录被拒，都留得下来。对外的解释很直白：学校的数据里含几千名未成年或刚成年学生的身份证与住址，这类数据必须能回答"谁在什么时候进来过"。
留痕真正的业务价值，还是第三章那句：一个干部敢按流程给学生放行，前提是他相信万一被追问，他能拿出一条完整记录，证明自己不是随手放的。没有留痕的系统会让人保守；有留痕的系统才让人敢用。
这条尺子量别人也量自己。一条关键字段的修改历史要能答出"谁、什么时候、改成了什么"，三位缺一，说明留痕还停在记动作的层面——目前它记到人、记到时间、记到动作，改前的值与改后的值还没进这条链路，字段级变更历史与安全事件分表存放一并列在批次上。一句"改了什么"答不上来，干部敢不敢放手用这套系统就要打折扣，所以这是接下来必须补上的功能，不是写在纸上的姿态。
8.7 学院只看本院，导出要过审批
学院端的隔离是数据范围的硬要求：各学院只看得到本院学生，跨院汇总由校级账号出。这不是防学院，是防误操作——几千人的名单一旦在院级账号里可见，导出、群发、转发这些动作的影响面就不受控了。 边界也很清楚：院级账号若能查到另一个学院的学生名单，数据范围这一层就等于没做进去。
这一层还有一句实话要说在前面：把学院下面的专业、班级自动展开进来了，目前只有大屏一处做到了，其余模块要在校级授权时把这些组织一并勾上。"授权一次、逐级自动覆盖"要统一到所有模块，才算真的做完——这一段归到第十五章的数据治理里收口。
导出侧的完整要求是审批＋水印＋留痕。三样里已经落地的是"能导"：名单、宿舍、缴费、体检、任务进度各类报表都有导出入口（四十多处），学校随时导得走，格式是通用表格而非专有格式。审批与水印在批次上，留痕目前覆盖批量导出任务且保存期很短，逐条完整留痕要随审批一并补。"能导"和"管得住"不矛盾，真正该被追问的是那种"要么不给学校导，要么谁都能导"的两难设计。
学校不妨先自问一句：我院迎新助理导出本院名单时，有没有人需要批准？今天的答案是"没有"，明年应该改成"有，而且批得下来"。
8.8 留痕让人敢授权
第三章提出的三个条件——没时、没授权、没兜底——其中时间要在别处解决，授权与兜底靠的正是权限与留痕这两样：权限四层链路让学校敢把动作下放给一线，全程留痕让办过的事可还原、责任可界定。
所以落点不是"我们权限很完善"，而是一个功能性的判断：
留痕让人敢授权，授权才有人真用。 一套让一线干部什么都做不了的权限设计，最后一定退回纸质签字，那前面所有配置化、自动化省下来的时间，全部还回去。
而权限与留痕这两样，还有一层更远的用处：它们是第四篇里"能不能让系统自动动手"的准入门槛。 系统替学生提交一项申请、自动放行一个流程，前提都是出问题时查得清是谁配的规则、谁点的按钮。这件事在第二十二章会写成一条硬约束。