One Clear Card Is Not Yet a Continuous Record
At 18:20 on Thursday, Gu Ning gathered the papers organized that day. The event definition of R17, the acquisition of information, the historical table, the candidate calculations, and the open questions all had their places. Yet she noticed that if other requests were to be recorded afterward, there was still no single entrance from which all objects could be recovered.
Tang Ke said, isn't one card per request enough? Gu Ning answered that a card can state one object; a continuous record must also state which cards entered, which judgments were actually issued, which outcomes were adjudicated, and how a later adopted version connects to earlier versions.
This chapter continues the fictional Chengwan. The two organize the ledger structure at 18:20; no new client reply or complete confirmation is added. R17 still has no formally adopted final numerical probability, and the ledger will preserve that state; it will not fill in the candidate three-quarters just to make every row neat.
Part Four begins here. Reliability cannot be demonstrated by one good story alone; it requires continuous, recoverable objects of judgment. The ledger is not a tool that obtains correctness for judgment. It first gives later evaluation its objects, its scope, and also the positions that cannot yet be evaluated.
First Decide Which Tasks Are Recorded
If the ledger opens a card only when the recorder feels confident, the performance seen later applies only to this selected class of tasks. It may still have value, but it cannot silently stand for all inquiries or all problems.
Gu Ning separates the rule of entry from the content of the forecast. Entry into the record can follow an explicit task scope—for instance, every registered request requiring a judgment on confirmation within the original window. Whether a numerical judgment already exists is a status recorded after entry. Objects without an adopted probability can still retain their questions and reasons.
This does not require everything in the world to enter one ledger. A ledger may serve only one class of tasks; it simply has to state its scope, starting time, and grounds for exclusion. If the scope changes later, the relation between the old and new batches should also be preserved.
The original sixteen historical registrations in Chengwan are not sixteen saved ex ante probabilistic forecasts. We have obtained only part of the source material and certain outcome fields; historical forecast performance cannot be reconstructed from a table of historical outcomes. The registration ledger and the forecast ledger are related, but they do not share all their contents.
Object, Forecast, and Outcome in Three Positions
One request can correspond to one definite event; one event can have forecasts at several points in time; several forecasts may correspond to the same actual outcome. Only when these three layers of relation are kept apart will the ledger avoid manufacturing more confirmations as the number of updates grows.
The object page stores the request identifier, the condition version, and the event window; the forecast page stores the time of issue, the materials then available, and what was actually adopted; the outcome page stores the adjudication, its basis, and its verification status. The three pages need not literally be different sheets of paper, but the relations should be separately identifiable.
R17 established its object and information boundary at ten in the morning; candidate calculations appeared later, but a final probability has not been adopted. This can continue under the same entrance, without calling every exercise of organizing materials a numerical forecast.
Likewise, the original reply at 11:20 on Thursday was obtained once. Tang Ke handing it over, Ye Cheng re-reading it, and Gu Ning filing it are different handlings of the same original. The ledger can record the handling process; it cannot turn the number of handlings into a count of independent events.
Actual Adoption Requires a Position of Issue
A number may be tried out in a draft, used for a sensitivity comparison, or formally applied by the recorder to the current question. If there is only a column of values and no column of status, it will later be hard to know which of these is being evaluated.
Adoption needs no ceremony. The recorder can write "under these conditions, this probability is currently adopted," together with the time and the basis. What matters is that others can see this number has answered the specified question, not merely that it appeared somewhere in a calculation.
If the judgment is expressed as a range, the meaning of the range should also be stated. If only a directional judgment is adopted for now, keep the original sentence and its scope of application; do not fill in an arbitrary number for it later during scoring.
The ledger therefore allows different task statuses: object established, materials pending, candidate scenario, probability adopted, outcome pending. Status is not a ranking of value; it tells later users how this row may be used. Not adopted does not mean a probability of zero.
Keeping the Connection When the Same Event Updates
Set an independent comparison object: three-quarters was adopted earlier, and after new material arrived, three-fifths was adopted. Both judgments were formed before the outcome was obtained, and both answer the same version and the same window. The ledger can record them as two connected forecasts.
The later version does not erase the earlier one. If one later evaluates how updating performed, both can be returned at once; if one evaluates the judgment at a fixed point in time, the corresponding version is selected under a rule stated in advance. One may not, after knowing the outcome, choose the better-scoring attempt as the sole original forecast.
If the new material changed the condition version—for example, the first version became the second—the matter is different again. Here the object relation must be preserved, stating that the new judgment answers a new event; one cannot merely change the number in the same probability column and let the change of target disappear.
Forecast versions and task versions can thus coexist. The former preserves how understanding of the same object changed; the latter preserves how the object itself changed. The names are close, but mixing them will leave later evaluation unable to find either the original question or the original judgment.
The Outcome Column First Preserves the Basis of Adjudication
After a probability has been issued, the outcome still must be checked against the original event definition. Established, not established, and not yet adjudicated should be stored separately; one must not write established early because the affirmative tendency runs high, nor record a not-yet-obtained outcome as a failure because the window has not closed.
If complete confirmation has been received through the agreed channel, and the material suffices to verify all conditions of the first version, the event's establishment can be known. If nothing has been received while the deadline has not passed, the matter is not yet closed. Observation on the two sides is not symmetric, and the ledger must make this difference visible.
If the deadline has passed but the original material is missing, that still does not mean the event is known to be unestablished. It can be recorded as pending verification, with a statement of what is missing. This status differs from the window not yet having arrived, and the follow-up search actions differ too; a single empty outcome column would mix the two kinds of work together.
The outcome page stores the relevant times of arrival and of viewing so that adjudication can be returned to. Fields may be abbreviated according to the question, but a disputed boundary cannot be replaced by the last affirmative or negative label. The label is a product of verification, not the basis of verification itself.
A Small Independent Ledger
Leaving the original Chengwan registrations, set four independent example objects, numbered L01 through L04. "Independent example" here means they do not join the Chengwan main line; it does not assert that the four outcomes are mathematically independent of one another.
L01 adopted one-quarter while the outcome was unknown; after the window closed, sufficient material established it as not holding. L02 first adopted three-quarters while the outcome was unknown, then updated on the same event to three-fifths; after the window closed it was adjudicated as holding. Both have recoverable ex ante forecasts and corresponding outcomes.
L03 adopted one-half while the outcome was unknown, but the window has not yet closed and there is no sufficient material of establishment. L04, after the complete establishing material had already been seen, wrote an affirmative statement and recorded the certain affirmative status as one. It is a statement of a known outcome, not in the same forecast-task position as the first three.
This small ledger has four objects in total; one cannot therefore say there are four pieces of the same kind of ex ante forecast performance. L02 has two forecasts but only one event outcome; L03 is still pending; L04 is of a different task type. The use of organizing these four rows is to check relations and entrances of evaluation.
The Small Ledger First Answers Questions of Quantity
If we evaluate the first ex ante numerical judgments of L01 and L02, there are currently two adjudicable objects, two corresponding forecasts, one established and one not. The outcome frequency here describes only these two; it says nothing about whether one-quarter or three-quarters is individually calibrated.
If both forecasts of L02 are included in some update evaluation, there are three adjudicated forecast records but only two event outcomes. One can evaluate performance at multiple points in time, but cannot simultaneously claim one more independent final outcome.
L03 can enter the list of issued forecasts, but not the same denominator of currently adjudicated scoring. The ledger should state at once how many were issued in total, how many are currently evaluable, and how many remain pending, rather than giving only a single number that looks complete.
L04 can be kept on the page of knowledge statements to help check task transitions; it cannot be placed into the performance of unknown-outcome forecasts just because it is affirmative and the outcome held. Its exclusion should be based on task position, not on whether performance looks better or worse after exclusion.
The Rule of Evaluated Version Is Stated Before Outcomes
If a ledger allows multiple forecasts per event, it must state which layer it later intends to compare. One may compare first adoptions, or judgments at a roughly fixed distance from the deadline, or study the updating process specifically.
These purposes differ, and no single version rule suits all tasks. What matters is to state the rule, as far as possible, before the corresponding outcomes are seen; if it later changes because materials are incomplete, the reason and scope of the change must also be explained.
If, for each event, the forecast closest to the actual outcome is picked at the end, the evaluation has used the outcome to select its input. It answers what score post hoc selection can achieve, not how the judgments adopted by the recorder at times of uncertainty performed.
If there was no prior rule, one may still explore the performance of different versions; it should only be labeled exploration, and the most favorable set should not be presented as a capability the original plan had already proven. Exploration generates new questions; it cannot, in reverse, generate evaluation arrangements for the past.
Pending Items Do Not Disappear from the Ledger
While L03 awaits its outcome, the summary page may temporarily leave it unscored, but the complete object page still retains it. In this way the next round knows one item is pending and can continue the search, instead of seeing only objects already closed each time.
If an item remains unresolved for long, its search status and the gap should be preserved. Whether the search is still worth continuing can be decided separately; stopping the effort does not automatically negate the target, nor automatically permit deleting the item from the original entry list.
The number of pending items also affects the understanding of the current scope of evaluation. If most objects have not yet closed, the adjudicated subset may not directly represent the whole batch. The ledger first reports scope; further inference then states its additional conditions.
This continues the status distinctions of Chapter Fourteen, but the product is already different: there, an unobserved outcome was protected from being filled in arbitrarily; here, pending items remain findable across batches. Status must have a continuing entrance, or it will become invisible again at the next summary.
Correcting an Outcome Differs from Updating a Forecast
Suppose the original channel record for L01 is later recovered, revealing that the earlier basis of adjudication was mistaken. The outcome can be re-verified and corrected, noting the newly obtained material and the time of correction. The original forecast is still preserved as it stood on the materials then available; one must not, while correcting the outcome, conveniently change it to a number better fitting the new adjudication.
The correction of an outcome affects the related summaries, and this is a legitimate change. But the summary versions should also have a position, so that readers know on what adjudication the earlier performance depended and why it later changed. Reviewability does not require forever retaining a mistaken conclusion as the current one.
If what happened is merely another event—say, a confirmation after the window—then the original outcome need not be corrected. First ask whether the original event was truly mis-adjudicated, or whether an outcome at another time or of another version was obtained. Real-world continuation and recording error must not be conflated.
The correction page and the forecast-update page can therefore be kept apart. One repairs the basis of fact; the other preserves how the judgment at the time changed. Both permit change, but the objects of change differ; a blanket "updated" cannot be allowed to cover the concrete relations.
Batches Give Change a Position of Comparison
As the ledger gradually accumulates, the recorder may adjust event scope, material rules, or the model. If everything before and after the change is mixed into one group, it will later be hard to know which version a given performance came from.
Gu Ning imagines a batch page preserving the scope and rules a stretch of records used. Batches may be divided by model changes or by explicit periods; the key is to state why these objects enter together and where another set of rules begins.
Batches are not for dividing results into a good-looking group and a bad-looking one. If the record is segmented by outcome after seeing performance, that should be acknowledged as post hoc exploration, not presented as a validation batch that had been running independently from the start.
After a model is modified, a new batch can test how the modification continues. The old batch remains the material from which the modification was formed; it need not be deleted, but neither should it double as a fully independent new validation. The relation between what was used to change the rule and what is used to check the rule needs stating.
The Selection of Tasks May Also Change over Time
If at one stage only objects with already-explicit conditions were recorded, and the scope was later extended to objects whose first version was still under discussion, the ledger's difficulty of aim and material conditions may have changed. New performance differing from old does not by itself say the recorder became better or worse.
The batch page can preserve the scope of entry and the categories excluded, so that later comparisons first ask whether conditions were of the same kind. If one genuinely wants to compare overall performance after the extension, that can be done too—only not without stating that the task structure changed.
Conversely, keeping only the easily judged tasks after poor performance also changes the scope. Narrowing may be a reasonable work decision, but one cannot use post-narrowing performance to claim the old scope has been resolved.
The continuity of a ledger does not require every batch to be identical. It requires that change can be returned to: what was kept, what changed, and to which objects the current conclusion applies. Preserving relations of change matters more than forcing all numbers into a single column.
Multiple Judges Require Preserving Relations of Persons and Materials
If several recorders issue probabilities for the same event, these can be stored separately to compare different judgments. The event identifier remains the same and the outcome remains the same; one cannot say, because three people each have a forecast, that three mutually independent confirmations occurred.
A personnel page can state when shared material was obtained, whether anyone checked independently, and whether one person relied on another's judgment. It lets later users know the relations of input, without guessing how each person's mind was internally influenced.
If a jointly adopted probability is formed, store the joint version and the rule of its formation separately. Initial individual judgments may be retained, but the joint summary and the individual inputs should not both be counted as several unrelated pieces of new evidence.
That three people currently take part in organizing materials in Chengwan does not mean three formal numerical forecasts have been issued. The ledger first records the handling duties each completed. If actual judgments form later, they enter from that point in time; headcount does not fill the gap.
Material Versions Cannot Store Only the Last Copy
An original message may pass through organizing, screenshots, and summaries. If only the last summary is kept, then when the model changes later, it will be hard to see what the old summary deleted. For materials that influenced adoption, there should be a relation back to the original.
This does not require copying every file each time. One may keep stable provenance and acquisition notes, but it must be possible to identify which original and which version the current summary corresponds to. If the original is later recovered or corrected, that relation should also be preserved.
The precision a ledger needs is decided by the question. Simple, direct objects can be abbreviated; boundary disputes or complex retellings call for supplements. There is no need to manufacture precise times that were never obtained just to fill in fields.
Tool complexity cannot remedy relational confusion. A large table that records every retelling as a new message still double counts; a small sheet that preserves object, adoption, and basis is easier to verify. Structure serves the question; reliability is not conferred by the number of fields.
The Summary Page Lets Readers See Scope and Performance Together
A summary should at least state which class of tasks it evaluates, which forecast-version rule it adopts, the current scope of adjudication, and why pending and excluded items are absent from the corresponding calculations. Only then can later calibration or scoring numbers be placed in a definite position.
The complete ledger and a concise summary can be kept separate, so readers need not open all the originals each time. But the important conclusions of the concise page should be traceable to the corresponding set of objects; there cannot be only an average with no denominator.
If an outcome is corrected or a pending item closes, a new version of the summary can be generated. A new number differing from the old does not necessarily mean the model was rerun; it may only be that the scope of evaluation widened or an adjudication was corrected. The summary page must say which kind of change occurred.
In this way the same ledger supports current work and later inspection alike. When users see performance, they know where it came from; when they see a gap, they know how to continue. Number and scope appear together, so that the number does not decide the scope on its own.
Mistaken Records Also Need a Continuing Position
One forecast lacks its time of issue; another's outcome material is insufficient; an object mistakenly used the second version. Such records can be marked as temporarily unfit for a given evaluation, but the specific reasons should be preserved.
If every untidy row is deleted each time, the ledger may later appear never to have recorded an error. This affects not only the scope of evaluation but also deprives similar errors of material for improvement. Records that cannot be scored can still be used to examine process.
Conversely, one must not force a score onto a record just to keep it. A statement lacking an object definition may be impossible to adjudicate accurately; a draft lacking actual adoption may be impossible to score formally. To retain means to preserve the question, not to let every record enter the same formula.
A reliable ledger allows multiple uses. Probability performance, material acquisition, outcome verification, and handover quality can each be examined; the absence of a number for one of them does not declare the whole record without value.
Knowing What to Continue the Next Time It Opens
A continuous entrance also needs one concrete continuation note: what class of material to obtain next, which relation to verify, and who returns which outcome to which object. If it says only "look again later," the ledger has preserved the past but may not help the future continue.
For R17, if new communication arrives, Tang Ke still saves it through the original channel; Gu Ning then judges whether it supports the same event, whether a new forecast or a new version is needed. Ye Cheng continues organizing the historical gaps and will not, because the current message is newer, stop distinguishing history from the main line.
These duties do not make anyone an automatically correct adjudicator. If a new message is ambiguous, one still returns to the condition definitions; if duties are later handed over, the successor should be able to find the same pending item, not open a new, unrelated request.
The next opening may also bring no new material. One may note "checked, nothing added" and keep the original status; this neither amounts to renewed support nor requires the target probability to change with every viewing. The count of viewings is a handling record; a change in judgment requires its corresponding basis to be stated.
A Record Is Not a Sealing of All Reality
Within RC's position of limited judgment, what the ledger preserves are the relations organized for the task. It can connect the original adoption with subsequent feedback, but it does not seal all conditions, nor guarantee that every unrecorded cause is irrelevant.
This limitedness does not cancel outcomes already sufficient to adjudicate. If sufficient material shows the original window was not met, "not established" should be retained; one may not keep shielding the original affirmative judgment from inspection on the ground that reality still has remainder.
Nor is the ledger responsible for explaining every failure thoroughly at once. It can first accurately preserve forecast and outcome, then let competing explanations be constrained by material. Evaluation and explanation can be sequenced; there is no need to complete a tidy story immediately after every ending.
For feedback to promote calibration, the original judgment must remain returnable and contrary outcomes must remain able to enter. If the record is only rewritten again and again into versions fitting the ending, feedback loses its position of comparison and may make the old explanation more rigid rather than the judgment more reliable.
Saving the Continuous Entrance at 18:40
At 18:40 on Thursday, Gu Ning saves the ledger entrance. Under the R17 object are connected the event card, the material acquisitions, and the candidate calculations; formal numerical adoption remains marked as not formed, and the outcome remains marked as window not closed and no complete confirmation obtained. The original sixteen items of historical material are retained as comparison material, not reconstructed into sixteen records of ex ante forecast performance.
Tang Ke's communications, Ye Cheng's review of uses, and the day's handover note are connected by provenance. Open questions have a position for the next search; the candidate appended-clause procedure remains unimplemented; the ledger structure is formed, and no status has been added on the client's behalf.
What this chapter delivers is a record that continues across objects, versions, and batches. The next chapter will ask, when a group of genuinely issued probabilities and their corresponding outcomes enter a definite scope, what exactly calibration compares. Without such an entrance, calibration easily becomes picking a few numbers out of a story.