任务产出与数据交付

Submission（提交记录）保留贡献者交出的内容；Accept（采纳）形成验收结果；交付处理整理并写入可供后续使用的数据。已提交、已接受、已交付、已获授权和已实际获取是不同状态。

只看某次工作内容，从 Campaign → Reviews → Review（活动Developer 组织的一组数据工作及其相关设置的审核列表与审核详情）开始。安排字段和工作流保存时使用 Builder；程序取数使用已授权 API。

决定交付字段

ETL（字段映射）决定 API 消费方从每条已接受记录里拿到哪些字段、用什么名字。它不改动原始 Submission一次提交形成的结果记录：Campaign → Reviews → Review 里仍是贡献者交来的内容。

1. 在活动的 Builder（构建器）中，在 Accept 和 Sink（落库）之间加入 ETL，双击打开它的面板。
2. 交付字段的每一行，把左侧一个或多个表单字段读入右侧一个 API 字段。还没有改动时，表格只是默认显示：此时保存，所有表单字段原样交付，包括表单以后新增的字段。你做出第一处改动后，这张表就成了交付字段的清单。
3. 要改名，在该行的 API 字段里填新名字，例如在 answer 这一行填 category。不想交付某个字段，就删除这一行（×）。表单收集了、清单里却没有的字段会列在已采集但未交付提示中。可以用提示里的按钮把它加回清单，也可以打开本映射未列出的表单字段也一并交付，让所有未列出的字段按原名交付。
4. 展开一行的选项（⌄），可以设置必需（没有值时扣下整条记录）或为空时的默认值。要把第二个表单字段读入同一个 API 字段，用 + field 添加：两个值默认拼接；打开兜底取值后，改为取第一个有值的字段。
5. 选择试填样例，填入贡献者可能提交的内容，对照交付结构是否符合接收程序的预期。留空的样例字段按未收集处理；所有字段都留空时，预览显示的是各字段名而不是值。预览并不反映交付的全部行为：打开本映射未列出的表单字段也一并交付时，记录还会按原名带上贡献者填写的其他所有字段；必需的一行没有值也没有默认值，或者打开了取值不在上表内时，扣下整条记录而取值不在表内，整条记录都会被扣下、不予交付，预览却仍会显示这条记录。
6. 选择保存。面板里有红字说明问题时（例如某个字段没有名字，或两个字段同名），保存不可用。保存这一步就是保存活动的工作流，画布不需要另外保存。活动进行中时，保存前会先请你确认改动。

这个示意中，Review 里的 answer: "fruit" 对应合格交付记录的 data.category: "fruit"。如果 answer 为空，样例预览会省略 category，除非你设置默认值。预览只说明映射结果，实际交付还要查看 API 返回记录。

重置为表单字段会重新列出全部表单字段，但它仍是一份清单：表单以后新增的字段不会交付，除非打开了本映射未列出的表单字段也一并交付。删除全部行则回到默认。不同分支可以用样例分别检查。

已经有程序读取该数据时，改映射前先比较新旧输出字段名和缺值规则。用新交付记录验证接收程序，并确认该活动的历史记录或导出如何处理。原始 Submission 保留原值；历史交付记录是否回填，需单独确认。

Sink 与 API

Accept 的接受分支可直接连接 Sink（落库），或先经 ETL 再连接 Sink。Sink 保存工作流记录；选择 JSON / CSV 选项不等于已经生成可下载文件。需要可下载文件时，另查实际导出入口与交付结果。

API 交付采用相应 ETL 映射。活动来源的提交需要被接受并完成奖励授予，才进入可读取范围；能否返回仍取决于实际交付、订阅和筛选。因此，Sink 保存成功不能证明订阅已有可读数据；没有 Sink 也不能单独解释 API 为空。

排查一笔已知 Submission 时，按下面的顺序检查：

API 响应显示当前订阅实际取得了哪些记录。

链上记录与实际文件

链上锚定保存标识、摘要和文件引用；原始文件和元数据通常由链外存储承载。哈希用于核对内容，URI 用于定位内容。

查到链上记录，不等于已经取得原始文件或使用授权，也不能据此推断所有内容已加密或永久保存。需要查看来源与对应关系，继续溯源说明。