我做的是金融时点数据组件。历史数据常常迟到、修订或者被撤销，只按照业务发生日期关联，会让模型看到当时银行还拿不到的信息。我同时约束发生时间和可用时间，先选择当时已知的修订版本，再处理撤销与过期；使用 SQL 生成特征，用独立 Python 实现重放，并导出来源记录级证据。
构建金融多源数据时点特征组件，使用 SQLite 窗口函数处理公开/入库延迟、历史修订、撤销及特征有效期，保留记录级溯源；用独立 Python 枚举及随机历史对照验证 SQL 输出，在 45 次合成特征查询中识别事件时间基线的 11 次未来信息使用，并实现报告哈希校验与语义重放。
如果简历需要突出跨项目闭环，可以换成：
将 PITBridge 接入 CreditVintage 的可重放信贷研究链路，完成“源记录 → 决策时点特征 → 模型输入 → 留出集预测”逐条溯源；公开合成案例覆盖 480 个申请、1,440 个已选择特征和 120 个留出集预测，并通过固定依赖版本、SQL/Python 双重重放和 CI 校验防止未来信息泄漏。
这是候选表述。要能解释代码和假设；示例是合成数据，不能描述为银行线上项目。
为什么 event_at 不够？ 一月份的数据可能三月份才入库。二月份做决策时，即使数据“属于一月份”，仍然不可用。
为什么可用时间取两个时间的最大值？ 当前合同要求数据已经公开，而且系统已经拿到，两个条件都满足才可用。若真实系统的可得性规则不同，应修改源合同，不能凭空猜测。
为什么不按照最后入库时间选版本？ 旧版本可能迟到。最高已知源版本才是该观察时点的权威版本；乱序入库不应让旧版本覆盖新版本。
撤销为什么要先选版本再过滤？ 先删除撤销行再排名，会让旧版本重新变成可用，等于把已撤销的数据复活。
11 和 16 分别代表什么？ 11 次基线选择使用了未来可用信息。16 次最终选择不同，包含撤销和过期的影响；不能把 16 全部说成未来泄漏。
哈希已经匹配，为什么还要重放？ 哈希只能证明文件和记录的摘要一致。有人改了指标再更新哈希，文件仍可能逻辑错误，因此要从输入重算。
能支持多少数据？ 当前没有分布式性能验证。面试可以说明 SQL 逻辑、索引以及如何分区或优化候选连接，不应编造吞吐量。
升级展示：打开 滚动特征报告，说明 30 天现金流从 1,500 到 4,300 再到 6,300 的变化如何同时受迟到、更正与窗口移动影响；在 demo/rolling/members.csv 逐条追溯。完整口径与追问见 ROLLING.md。
先打开 demo/comparison.csv 看 SME-A-2 / tax 的未来修订；再打开 demo/snapshots.csv 看选中的 tax-a-v1；最后展示 test_historical_revision_cannot_change_old_decision 和 test_rehashed_false_metric_still_fails_semantic_replay。