一个平台，
把业务跑起来、把业务改得动、把结论说清楚
Loom（织元）不是三套拼装起来的产品，而是同一套底座上的三层能力： 业务运行时负责稳定运行，配置与建模层负责让业务能被快速改，AI 层负责把数据和结论摆到人面前。 三层共用一套业务库、一套权限与一套审计，随平台一起交付。
业务跑起来的那一套
运行时是业务的运行底座。它不硬编码任何一张业务表，而是读取业务配置， 为每张表现场生成界面、流程与权限 —— 所以「新增一张表」不需要开发介入。
读取业务配置
启动即读取元数据：表、字段、关联、枚举、动作、菜单与权限，一份配置就是运行依据。
界面随数据生成
列表列、筛选项、表单字段、按钮与校验规则全部由配置实时生成，不做二次开发。
按角色收敛边界
菜单、字段、行级数据与可改范围随角色自动收敛；看不到的东西，就不用在界面上找。
为什么这样分层
业务变的是规则和对象，不变的是底座。业务域可以换、可以加， 平台能力不重写 —— 这就是「新增业务不需二次开发」的由来。
平台规模（实测）
让业务能被改的那一层
表、字段、关联、枚举、菜单与动作都沉淀成配置。 新增一张业务表、改一条业务规则、复制到新的组织，都不必再走一次开发排期。
配置层提供的四件事
业务建模配置
表、字段、关联、枚举、菜单与动作批量建好，配完即可上线，不用写代码。
预演与落库
改之前先预演，确认影响范围后再落库，每一步都有据可查、可回溯。
数据关系与血缘
改动前先看清一张表被谁引用、一个字段流到哪里，不做盲改。
权限随配置收敛
菜单、可见字段、可见行与可改字段随角色自动收敛，边界写在配置里。
配置是唯一真相来源
平台不提供绕过元数据闸门的开关，也不靠「删掉配置」把界面修好 —— 出了问题就回到配置里改，过程留痕、可回溯。 这是我们愿意写进合同的约束，也是客户资产真正安全的前提。
把结论摆到人面前，而不是替人做决定
业务场景里最怕的不是 AI 答不上来，而是它把不知道的说得像知道。 所以我们把「来源、口径、盲区」三件事做进了产品。
问得明白
权限内取数
带来源的回答
明说算不出来
AI 不会做的事
从业务描述到可运行的一套业务
三层能力不是一次做完全部业务，而是一套可重复的推进方式： 先把口径对齐，再把界面装配好，最后让它在真实数据上跑起来。
建模
把业务拆成表、字段、关联与枚举，先把口径对齐 —— 这一步决定后面所有界面与报表是否可信。
口径先对齐装配
配好列表、表单、动作、菜单与权限，改动先预演一次，确认影响范围后再落库。
改前预演运行
上线后业务照常跑，写入与操作全程留痕；下一轮新增业务，沿用同一套方法继续扩展。
数据可回溯配置与数据从哪来
怎么部署
数据不出内网，业务库由客户自己掌控。 具体交付范围与节奏按项目实际排期确认，我们会在合同与实施计划中写清。