编号日期不是每次修订的日期
检索区块链bip资料时，先给编号、日期与版本各留一栏。BIP3把Assigned定义为提案获分配编号的日期；编号分配前使用问号。它并不是文章首次出现的日期，也不会因为后来补充了某个测试向量，就自动成为那次修订的日期。
旧截图还可能使用Created字段。BIP3的兼容说明解释，将它改名为Assigned，是为明确其值对应编号分配。整理历史材料时，应保留原字段名和当时文档版本，再注明当前字段含义，不能把旧名中的创建二字直接翻译成客户端发布或网络启用。
依赖与替代建议是不同方向的关系
Requires列出新提案依赖的已有BIP；Replaces则供作者列出希望由本提案接替、取代或使之过时的旧提案。二者都可能写着数字列表，但不能合并成一栏相关提案。依赖意味着阅读当前规则还需要对应的基础说明，替代建议则指向另一种文档关系。
Proposed-Replacement从旧提案一侧记录潜在后继：当后来提案表示想取代旧提案，其编号可写进旧文档的这个字段。因此，两份资料出现相互指向的替代字段，可以帮助沿关系查阅，却不能仅凭数字较大就认定所有内容已经替换。BIP3自身的头部就分别列有Requires和Replaces，应按各自字段解释。
文档版本要与自身变更记录配套
BIP3要求，提案达到Complete后发生的变化，以版本、日期和说明记录在Changelog中，较新版本排在前面；引入变更记录后，头部Version应指向最新文档版本。这里描述的是提案文本的修订，不能把它当成Bitcoin Core客户端的版本号，更不能据此判断本地节点已经运行了哪份代码。
它借鉴主版本、次版本、修订版本的三段结构：规范出现不兼容变化对应主版本，兼容的规范变化或扩展对应次版本，重要澄清、测试向量等其他值得记录的修改对应修订版本。正文还对成熟提案的重大变化另有限制。因此，读到版本提升，应接着看变更说明，不能从第一位数字增加直接推出一次网络分叉。
相同三段数字仍要先确定被编号对象
独立的Semantic Versioning 2.0.0规范针对声明了公共API的软件，按API兼容性解释三段版本，并要求已发布版本的内容不被原地改写。BIP3说的是借鉴这种结构，再按提案规范的变化给出自己的规则。软件包版本与提案文档版本即使恰好相同，仍不能据此认定二者有实现对应关系。
设两张虚构资料卡，一张记录某提案文档1.2.0，另一张记录某软件包1.2.0。数字相同只说明标签相同，还缺少软件实现与文档的关联证据。实际归档时，可一起保存原文件、读取日期、Assigned、关系字段及变更记录；若讨论的是客户端兼容性，再单独补其版本与实现说明，不用提案编号代替。