根拠と未確認事項を保存

分からない理由を先に書く

読みを保存するとき、「信頼度は低い」とだけ書いても、次に何を調べるべきかは分かりません。出生時刻の資料がないのか、二つの記録が食い違うのか、ツールの設定が非公開なのか、それとも象徴の解釈が分かれているのか。理由によって確認の方法が変わります。

「日付は原資料で確認した。日付の切り替え方式はまだ分からない」と書けば、確定した部分と保留した部分が同時に残ります。一つの不明点から全体を否定する必要も、一つの確認済み項目から全文を保証する必要もありません。

NISTの定量的手法の説明では、統計的検定と不確実性の数量化が扱われます。しかし、個人的な納得を百分率にしても、その統計的意味が生まれるわけではありません。適切なデータやモデルがないなら、未確認の理由を普通の言葉で具体的に記す方が伝わります。

原資料と自分の書き込みを分ける

後で答えが見つかったときに備え、当初の出力や引用箇所を残します。画面なら関連する設定と取得日、書籍なら版と章・ページを添えます。結論だけ切り抜くと、その言葉がどの条件で述べられたのか失われることがあります。

原資料はそのまま保存し、注釈は別の作業用コピーに書きます。後から判明した正しい値を原画像に上書きすると、当時の出力なのか訂正後の説明なのか区別できません。保存する範囲は主張を理解できる程度でよく、無関係な個人情報まで集める必要はありません。

一つの文から根拠へ戻る

次に、確認したい一文を選びます。誰について、いつの範囲で、何を述べているかを明らかにし、対応する項目や出典へつなぎます。サイトのトップページだけでは、その一文の根拠を探し直せない場合があります。

W3CのPROV概説は、情報を生み出す対象、活動、関与者を通じて来歴を捉えます。個人のノートで技術形式を実装する必要はありませんが、「何から、どの処理を経て、この説明になったか」という視点は役立ちます。来歴が分かることと、内容が正しいことは別です。

画面に出た宮の番号、伝統的な象徴の説明、自分が考えた行動案は分けて残します。最初の画面は「この条件でこう表示された」という証拠にはなっても、行動案の妥当性までは証明しません。事実と推論の整理も、この段階を見分ける手助けになります。

訂正は履歴としてつなぐ

元の図を開いて拡大する

BaZiFlow独自の版管理図。枝は訂正の履歴であり、予測精度の上昇を示しません。

図では元の記録が時間軸に残り、修正版を枝で結んでいます。新しい版だから必ず正しいという意味ではありません。白抜きの印は、修正後も未確認事項が残り得ることを示します。

タイムゾーンの設定を直したなら、旧値、新値、変更理由と日付を記し、影響する項目を確認します。その項目に依存した文章は読み直しますが、見ていない段落まで確認済みにはしません。何を直し、どこをまだ調べていないかが分かれば、次の作業を限定できます。

単なる表記の修正と、入力や方式の変更も区別しましょう。結果の違いを調べる順序は設定の比較で扱っています。旧版を消すのでも、旧版だけを放置するのでもなく、現在の版との関係を示します。

共有用の控えを作る

自分用の資料には必要な背景が含まれていても、共有相手がそのすべてを知る必要はありません。公開するコピーでは、主張を理解するために必要な部分だけ残し、ファイル名や画像の端、注釈も確認します。他人の資料を根拠として使うことは、その人の私生活を公開する許可にはなりません。

最初は短い記録で十分です。識別名、取得日、原資料の場所、一つの主張、その根拠、保留理由、次の確認先を記します。読み返した人が同じ資料に戻れ、判断がどこで止まっているか分かるなら、保存は役割を果たしています。

1. 1

   変えた項目を固定

   以前のタイムゾーン設定と資料で裏づけた新値を記し、原画像は残します。

2. 2

   依存先をたどる

   再計算するUTC項目と、その項目を使った説明文を分けて列挙します。

3. 3

   作業の到達点を書く

   UTCだけを確認したなら、項目は確認済み、説明文は再読待ちとして残します。