隔离由数据库强制执行，而不是由应用代码。

界面里的控件在渲染前先问当前登录者是否持有某项权限。服务端的处理函数在做任何事之前断言同一项权限。随后数据库应用一条策略，决定这次查询能看到哪些行。三种机制，三处必须各自正确，其中任何一处说不，请求就结束。

• 界面检查是便利，不是边界。它隐藏一个按钮，并不保护一张表。
• 每次检查都经由同一套权限目录和同一个函数解析。没有哪个处理函数会读取角色名，然后自行决定那个角色意味着什么。
• 在组织树某个分支上授予的角色沿该分支向下级联——而数据库策略读取的是与界面相同的那棵树，因此两者不可能各说各话。

隔离是 schema，不是约定。表在创建时就启用行级安全，并配上把判断委托给服务端所调用的同一个权限函数的策略，另有一项迁移检查，会找出被授予访问权却没有对应策略的表。这个数字不是营销数据——它就是你去问数据库“你正在执行多少条策略”时返回的结果。

• 策略不内联自己的逻辑。它们调用权限函数，因此答案不会和服务端上一刻的判断产生偏差。
• 写策略除读取条件外还带有检查条件，因此插入操作无法把一行数据放进写入者没有权限的组织。
• 凡是视图暴露个人数据的地方，都逐列授予访问权。表级授权会悄悄抵消列级保护，所以我们不用它。

应用数据表位于十四个具名 schema 中——身份与访问一个、组织一个、媒体一个，依此类推。真正要紧的东西都不在默认的 public schema 里，而那正是一次误授权或一个宽松默认值最容易造成暴露的地方。私有媒体对已登录的浏览器根本没有存储策略：每一次读取都由先检查了归属行的服务端签发，每一次上传也以同样方式签发。

• 一次性令牌——邀请、密码重置、账号找回——以加盐哈希存储。原始令牌只在邮件里出现一次，此后不再出现。
• 只有品牌资产是公开的。组织的标志和站点图标必须在任何人登录之前就能显示；头像和课时媒体不需要，因此保持签名访问。

文件通过一个存储接口写入，该接口有四种实现：Supabase Storage、Amazon S3、Azure Blob Storage 和 Google Cloud Storage。对于数据驻留要求，这通常就是诚实的答案——一次部署可以把文件写进你被要求使用的那个地区的存储桶，而不必等供应商去开一个地区。请尽早告诉我们你的要求，我们会明确说明今天能否满足。

• 数据库、认证以及 API 所运行的函数由 Supabase 托管。那是你无法通过配置绕开的唯一依赖，它在 DPA 中被具名列出。
• 各组织的自定义域名通过 Cloudflare 提供服务，证书自动签发，因此贝鲁特或米兰的学习者看到的是你的域名，而不是我们的。

平台分析通过 PostHog 的欧盟区域运行，外面包了一层抽象，因此更换供应商不必改动产品。会话回放经过遮罩处理，并且从不记录学习者——学习者界面根本没有接入回放。

• 文本输入以及任何被标记为个人数据的内容，都会在浏览器中、在回放发往任何地方之前先被遮罩。
• 分析受同意管控，除非组织主动开启，否则处于关闭状态。在任何界面上，都不会对未成年人做画像。