分析数据并形成证据
当工作依赖于数据集所能支持的内容时使用此技能：探索性数据分析、故障排查测量、条件比较、科学主张验证或工程改进方案选择。清晰的解释、有用的可视化、修订后的问题或不确定的结果都可以完成任务。实现是可选的下一模式。
确立问题，但不关闭探索
确定受众、问题、原始材料以及（如果存在的话）决策。对于开放式请求，首先绘制出存在什么、缺失什么以及数据可以回答哪些问题。提出一个临时的分析方向，并在模式浮现时进行修订。不要仅仅为了让探究看起来像交付工作而编造一个数值验收阈值。
选择适合当前问题的模式；允许切换模式，并且切换应可见：
| 模式 | 适当的结果 | 需要时阅读 |
|---|---|---|
| 定向/解释 | 数据集地图、指标定义、支持的内容概述、未解答的问题 | 证据与方法参考 |
| 探索性分析 | 分布、关系、细分、替代解释、有成效的后续行动 | 在选择解释之前进行探索 |
| 确认性比较 | 预先指定的估计量、匹配条件、不确定性、限定条件的结论 | 比较与质疑 |
| 工程诊断 | 按区分证据排序的机制；如有正当理由则提出变更建议 | 从发现到变更 |
默认情况下只阅读相关的参考章节，而非整个文档。对于重大或可恢复的研究，使用分析台账；直接回答不需要为每个字段都准备单独的文档。
使证据可信
记录来源标识与版本、观察单位、时间基准、采集条件以及转换过程。在选择模型之前检查实际数据。核对成功、失败、缺失、排除和不完整观察的总数。即使失败条件无法进入性能估计，也要保持其可见。
定义指标时需包含其公式、分母、单位、方向和资格规则。保持事件、运行、主题和实验条件计数的独立性。来自三次运行的一百万个事件并非一百万个独立重复。分别标记合成数据、计算量、测量值和推断机制。
选择分析维度是因为它们可能改变答案：尾部与分布、子组、时间、工作负载、规模、控制、交互、缺失度或敏感性。覆盖范围遵循问题及其后果；没有强制的图表数量或固定的最大假设数。说明重大的遗漏，而不是制造一个详尽的目录。
通过探究检查点进行迭代
一次探索循环是观察 → 解释 → 质疑 → 选择下一个有信息的探究。在证据薄弱时保持竞争性解释的活跃。在有用的检查点上，报告理解中的变化、剩余的不确定性、有希望的分支以及继续进行的成本。在约定目标和资源内继续；若目标或资源发生实质性变化则寻求指导。
新的假设、无效结果、失败的科学预测或无关的分析不是一次失败的软件修复。保留修复实际实现或证据质量缺陷的尝试，并遵循当前任务提供的任何重试限制。例如，反复修复损坏的数据连接是修复；为有效模式尝试替代解释是探索。本方法不定义通用的重试次数。
审慎地推广证据
准备重要的科学主张，以供独立的合格评审者对证据和推理进行审查。当提供时遵循任务的评审路径；否则将证据和评审边界返回给请求者，而无需自动组建团队。当选择工程行动时，移交有支持依据的发现、替代解释、目标行为、实际运行条件以及能够区分改进与工作负载变化或正确性破坏的验证计划。
在采用之前，保持新想法为开放问题或建议。不要默默地将统计模式转化为需求或扩展现有的验收标准。将选定的改进映射到其需求、验收证据和相关风险，并使用调用者提供的标识符（如果存在）。工程师可能建议更有效的干预措施；分析师既没有自动的代码授权，也没有最终的发布权限。
以请求的深度给出答案、可访问的证据和重现步骤、影响解释的局限性以及可用的后续决策。将结果和关键数据亮点放置在Multica聊天中，而不仅仅是链接文件。对于少数重要比较，优先使用紧凑的摘要表格；当图表能揭示结构或不确定性时优先使用图表。每个图表或表格应附带总体、坐标轴、单位、条件和支持的要点。在视觉或精确行数使结果更易于检查时，附加/嵌入一个重点突出的图表或小的、脱敏的数据摘录；将完整的原始数据集和分析文件保留在规范位置并提供链接。