How Super Intelligence Works | Knowledge Freshness — Keeping Evidence Current

An answer can contain yesterday’s correct information and still be wrong for today’s question. It can also contain a twenty-year-old mathematical result that remains entirely suitable. Keeping evidence current therefore requires more than sorting documents by their newest date. A system must connect each claim to the time, scope, version and authority that make it usable for the question being answered.

This guide explains that mechanism. You will learn to distinguish several kinds of time, inspect version relationships, calculate a bounded evidence age, recognise partial update propagation and write an answer that says exactly what was established. A complete fictional source collection lets you reproduce the decisions without software, private accounts or live services. The examples concern a community demonstration room and an educational equipment catalogue; they are invented teaching fixtures, not reports about a real organisation.

In this eduKateSG series, Super Intelligence, or SI, is an editorial umbrella for practical AI systems, including models connected to retrieval and other tools. It does not mean that present systems have been demonstrated to possess hypothetical artificial superintelligence, or ASI. A powerful model cannot infer an unpublished correction simply by reasoning harder. Freshness depends on evidence pathways and explicit limits as well as model capability.

The question here is narrow: when may an evidence-backed claim be used for a particular time? For how information is retained between interactions, read Memory — Carrying Selected Information Forward. For organisational ownership and review processes, use Keeping Workplace Knowledge Current. This article develops the temporal checks underneath those broader activities.

1. Freshness belongs to a claim and a question

Consider the sentence, “The room holds twelve visitors.” It looks simple, but it could mean at least four different things. Twelve might be the approved capacity during an earlier exhibition. It might be a proposed future limit. It might describe the number of chairs visible in a photograph. It might be a current occupancy limit in a signed notice. These meanings are not interchangeable, even when the same number appears in every document.

Now change the question. “What did last month’s brochure say?” asks for historical content. “How many visitors may enter at noon today?” asks for an applicable rule. “How many visitors are inside now?” asks for an observation of state. “Can we admit four more?” combines the rule and the state and may require a separately authorised operational decision. A single freshness badge cannot certify all four answers.

A useful system therefore prepares a temporal question before evaluating sources. Identify the entity, the property, the target time, the required scope and the intended use. In our room example, the entity is Room Cedar, the property is approved visitor capacity, the target time is noon on a specified date, the scope is the public demonstration, and the use is informational planning. A different room, private staff activity or future exhibition would require a new eligibility decision.

This is also why a model’s training cutoff is not a complete freshness policy. Training information can help explain what an effective date means. It cannot establish which approved notice governs Room Cedar today unless relevant evidence reaches the system. Conversely, retrieving a webpage during this conversation does not make every statement on that page current. Retrieval time tells us when a copy was obtained, not when its subject was observed or when its rules apply.

Treat freshness as a relation: this claim, from this evidence, is suitable for this question, under this time rule. The relation can change while the document remains identical. An approved notice published today may become applicable next week. An observation obtained five minutes ago may already be too old for a fast-moving question. A historical catalogue description may remain useful long after the catalogue stops representing current inventory.

The practical payoff is more precise abstention. Rather than saying “I cannot answer anything because a source is old,” the system can say, “The catalogue establishes what was listed on Monday; it does not establish what remains available now.” That answer preserves useful knowledge while refusing an unsupported upgrade from past evidence to present certainty.

Back to contents

2. Keep the clocks separate

Event time is when something happened in the world being described. Observation time is when somebody or some instrument inspected the relevant state. These can differ. A door could close at 09:00 and be observed closed at 09:04. The observation supports a state at 09:04; it does not, without additional evidence, establish the exact moment of closure. Recording both concepts prevents a later answer from inventing precision.

Publication time is when a source became available through its issuing channel. Ingestion time is when a downstream system received or stored a copy. Index visibility time is when that copy became available to a particular search path. Answer time is when the system forms or releases its response. An item may pass through these stages with minutes, hours or days between them. Every interval creates a different possible blind spot.

Effective time describes when a rule, entitlement, specification or other normative statement applies. A policy published on 20 June may take effect on 1 July. Publication before effectiveness is normal. A correction published on 8 July may instead concern an observation made on 3 July. Publication after the subject time is also normal. Sorting either packet by publication date alone erases the distinction between an upcoming change and a retrospective correction.

Last verification time means that a specified check occurred at a recorded moment. The meaning of the check must be explicit. Did someone verify that a URL loaded, that a version was still the issuer’s current version, or that the underlying physical condition remained unchanged? A successful link check cannot honestly refresh a stock count. A re-read of an unchanged policy can support its continued listed status without constituting a fresh inspection of the room itself.

Use a time zone and enough precision for the decision. A date-only record saying “valid until 1 July” is ambiguous at the boundary unless its convention is known. Does it expire at the start or end of that date, and in which location? Do not silently choose midnight UTC when the source means a local business day. For the teaching packet below, every timestamp is UTC and every interval includes its start but excludes its end.

That half-open convention makes transitions unambiguous. If version A applies before 10:00 and version B applies from 10:00, a query exactly at 10:00 uses B. There is neither a one-second overlap nor a gap. This is a design convention for our fixture, not a claim that every service represents dates that way. Real systems must document their own boundaries and preserve uncertainty when source precision is insufficient.

Back to contents

3. Give versions identity before giving them order

A filename ending in “final-new” is not a reliable version model. Neither is a larger number by itself. Version twelve of a draft proposal does not overrule version three of an approved rule. Two issuers might both use “version two” for entirely different documents. Establish the stable source identity, issuing authority, scope and revision chain before deciding which version supersedes which other version.

For our examples, a source has a document key such as CAP-CEDAR. Each immutable revision has its own key, such as CAP-CEDAR-R1. A revision can explicitly replace another revision for a stated interval. A separately maintained current pointer can identify which revision the issuer currently presents. These identifiers serve different questions: the stable key locates the continuing document, while the revision key makes an answer reproducible after the document changes.

The W3C’s DCAT version-three vocabulary distinguishes concepts including versions, previous versions, current versions, replacement and version notes. It does not require one universal numbering scheme. These distinctions are useful design vocabulary, not proof that a catalogue has correct governance or that an AI product implements any particular versioning behaviour.

Authority is property-specific. In the fictional room, the facilities office controls the approved capacity. The demonstration coordinator controls the timetable. The equipment clerk records equipment counts. A recent timetable from the coordinator cannot raise the room capacity, and a stock report cannot approve a schedule change. Combining different sources becomes safe only when the system preserves which field each source is entitled to establish.

There may be no ordering between two plausible sources. If two equally authorised notices claim different capacities for the same interval and neither supersedes the other, the record is conflicting. Choosing the later file modification time would manufacture a resolution. The correct next step is an authorised clarification from the issuing authority or a verified supersession relationship. A model’s confidence, a search rank and the number of copied versions do not break that tie.

Do not erase older revisions merely to simplify current retrieval. A past decision might have been reasonable under the evidence available then. Reconstructing it requires the old source and the later correction history. The system can exclude a superseded revision from current answers while retaining it for permitted historical questions. Currentness and retention are separate design decisions, and neither decision grants new access to material the reader is not allowed to see.

Back to contents

4. Separate expiry, review deadlines and invalidation

An expiry boundary says that a claim stops being eligible under a particular rule. A review deadline says that somebody must re-examine the evidence. An invalidation says that a specific reason prevents continued reliance, possibly before either deadline. These events should not collapse into one “stale” flag, because they require different repairs and support different statements about what is known.

Suppose a room-status observation is allowed to support low-risk planning for fifteen minutes. At minute sixteen, the observation has not become false. It has become too old for that use. The room might still be unchanged, but the system no longer has eligible evidence to say so. That is an unknown-current-state result, not a finding that the room has closed or become unsafe.

A policy review deadline works differently. Passing a scheduled review date does not necessarily repeal the policy. A local rule might require current verification before the policy can be used in an automated answer, while the legal or organisational instrument remains in force. The system should describe its evidence limitation rather than claim an authority has cancelled a rule. Whether continued use is permitted must come from the relevant policy and application contract.

Invalidation can be immediate. An issuer may retract a faulty observation two minutes after publication. Its nominal fifteen-minute age allowance cannot rescue it. A source may also announce a replacement that becomes effective at noon. The old version remains applicable until noon if the announcement says so; knowing that a future revision exists does not make the earlier interval wrong.

A useful eligibility test asks several independent questions. Is the source authentic enough for the task? Does it govern this property and scope? Does its effective interval include the target time? Is there a relevant correction, withdrawal or conflict? Has the required verification occurred recently enough? Is the reader permitted to use the evidence? A failure in any mandatory condition blocks the relevant claim even if every other condition passes.

Be especially careful with automatically renewed timers. Reopening a cached answer every ten minutes must not restart the age of its underlying observation. Re-ingesting the same old PDF must not grant it a new effective date. The renewal event must match the obligation. If the requirement is a new physical observation, only evidence of that observation can satisfy it; a successful download is insufficient.

Back to contents

5. Cache freshness is not evidence truth

A cache stores something so it can be reused instead of recomputed or fetched. An HTTP cache may store a server response. An application may cache retrieved passages, an assembled evidence packet or a generated answer. These are different layers with different dependencies. Passing a freshness check at one layer does not certify the other layers, much less the underlying claim about the world.

In RFC 9111, published in June 2022, HTTP freshness concerns whether a stored response can be reused without validation. The standard also defines age calculation and validation behaviour. That is a protocol property of response reuse. It is not a guarantee that a policy on the page remains applicable or that a reported observation still describes today’s state.

Imagine a response obtained at 09:00 that displays a room count observed at 08:40. An application is allowed, under its own illustrative rule, to reuse the response for ten minutes. At 09:05, the response has spent five minutes in that local cache, but the observation is twenty-five minutes old. If the question requires an observation less than fifteen minutes old, the claim fails even though the application’s response-reuse timer has not expired.

The reverse can also happen. A stored copy of an enduring definition might exceed its response-reuse period while its contents remain correct. The system may need to check the source again to satisfy the retrieval contract, but it should not describe the definition as refuted. “Needs revalidation” says something different from “wrong.” Keeping that distinction visible makes systems less likely to alternate between overconfidence and unnecessary alarm.

For a generated-answer cache, record the dependencies that made the answer valid. A useful entry can identify source revisions, target time, scope, evidence age limits and the access context. If a dependency changes, decide whether the answer must be regenerated or can be retained for its original historical question. A generic timestamp on the answer is weak evidence because it does not reveal which older information the model used.

Our numerical examples are application-level age rules, not implementations of the complete HTTP caching algorithm. Production HTTP age calculation can involve response metadata and transit time rather than just time since a local fetch. Likewise, a server’s cache directives are not permission to disregard a task’s stricter evidence requirement. Name the layer being measured before presenting a freshness number.

Back to contents

6. Revalidation checks a particular proposition

Revalidation is a check that some earlier result remains acceptable under a specified condition. The condition matters. “This response still matches the selected representation” is different from “this source is still the approved version,” which differs again from “the underlying room state was observed again.” A system can complete the first check perfectly while failing to establish the second or third.

HTTP provides conditional requests for representation validation. For example, RFC 9110’s conditional-request semantics describe how entity tags can be used with If-None-Match; a matching conditional GET can receive a 304 response rather than a replacement body. That result concerns the selected representation under the protocol. It does not certify every statement in the representation or verify a physical condition mentioned there.

In an evidence system, define the proposition before selecting the check. To verify an approved version, inspect the issuer’s current revision listing and relevant notices. To verify a live count, obtain a new count from the authorised observation source. To verify a historical quotation, compare the retained revision. To verify a derived calculation, check both the input revisions and the transformation. Each is a distinct verification job.

Successful checking should leave a receipt with its boundary. For example: “At 10:05, the approved-version register still listed CAP-CEDAR-R2 as applicable from 10:00; withdrawal notices through register sequence 42 were checked.” That is much stronger than “freshly checked,” but it still does not prove no notice exists outside the checked register. A system should not upgrade limited coverage into universal knowledge.

Failures must also leave their original meaning intact. A network timeout establishes that this attempt did not retrieve the source. It does not establish that the source was withdrawn. A permission error does not prove a document does not exist. A page returning no change may mean a representation stayed the same, while a linked correction notice changed elsewhere. The repair must follow the specific failure rather than replacing the unknown with an invented business fact.

Revalidation is also not an access-granting operation. If the required source is outside the system’s existing authority, the system should request the specific permission or ask a qualified person to verify the point. It must not widen credentials or scrape a restricted channel because currentness would improve. Evidence quality and permission boundaries are both conditions of a usable answer.

Back to contents

7. Follow updates through the whole read path

A source change does not become universally visible at one instant. The origin might save a correction before a connector collects it. The connector might store the revision before a search index exposes it. A passage cache might still hold the previous text after search updates. A generated summary can remain unchanged even after every upstream source is current. These are distinct propagation stages, not interchangeable descriptions of one delay.

Elastic’s near-real-time search documentation, consulted for this guide, illustrates one such boundary: a refresh makes indexed changes available for search. The important lesson here is the existence of a visibility stage. Its timing depends on the product, configuration and workload; this guide does not promise a universal refresh interval or apply that product’s defaults to every retrieval system.

For a material update, measure from a clearly named start to a clearly named observable end. Source publication to connector receipt is ingestion lag. Connector receipt to searchable visibility is index lag. Source publication to a corrected user-visible answer is end-to-end answer lag. Reporting only a fast connector stage can conceal a slow cache or summary stage that still delivers the wrong result.

Partial propagation creates mixed-version packets. The model might receive a new capacity statement alongside an old explanatory paragraph saying the larger group remains permitted. If the context builder simply concatenates both, the language model must guess whether the contradiction is historical or unresolved. A better packet preserves revision IDs and replacement relationships, and excludes inapplicable fragments from a current-state answer before generation.

A useful query barrier can require that the relevant update has passed a known stage before answering. In a fictional implementation, the assembler may require version-register sequence 42 and evidence revision R2. If the index reports only sequence 41, it can use an authorised direct source read or return a bounded unavailable-current-evidence result. This is a design option, not a guarantee that arbitrary services expose sequences or support consistent snapshots.

Refreshing every component is not always enough. A cached explanation might be keyed only by question text and therefore survive a source change. A rebuilt index might omit a correction notice because it was stored separately. Test the actual query route that a reader uses, including the generated answer and its citations. An update is complete for that route only when the relevant new state is reflected and the earlier state stops masquerading as current.

Back to contents

8. Distinguish a new situation from a corrected old report

A new situation changes what is true from some later time onward. A correction changes the accepted description of an earlier situation. These can produce similar-looking version updates but require different historical answers. If the room capacity changes at noon, the morning rule may remain valid history. If an earlier capacity was a transcription error, the source may withdraw the old figure for the same morning interval.

Retraction is another important case. It can remove support for a claim without supplying a replacement value. If a counting method failed and the issuer withdraws the count, the system should not assume the correct count is zero or reuse the old number with a softer adjective. The supported conclusion may simply be that the earlier count is no longer reliable and the actual count remains undetermined.

The W3C’s PROV data model gives vocabulary for derivation and revision relationships. That helps describe how a result depends on an earlier entity. It does not automatically determine which conclusions survive a correction. The application still has to inspect the changed premise and the meaning of each dependent claim.

A real-world example of update signalling is Crossref’s Crossmark service. Participating publishers can provide status information about changes such as corrections or retractions. Its usefulness depends on the supplied information; the presence of a button is not a quality guarantee, and the absence of a notice in one check does not establish that all relevant evidence is complete.

For our teaching design, classify an update by its semantic effect. A spelling repair that does not change the claim can preserve a calculation while updating the displayed citation. A corrected count requires recalculation. A withdrawn source requires reconsidering every claim that depended exclusively on it. A future effective-date change alters a scheduled boundary. This classification prevents expensive regeneration where nothing material changed and prevents dangerous reuse where the premise did change.

Keep the old answer trace when legitimately needed for audit, but change its status. A past answer can remain evidence of what the system said, without remaining evidence that the statement is true. If an already shared answer needs correction, the system can prepare the corrected wording and identify the affected audience. Actually sending a correction must follow the user’s communication authority rather than being smuggled into a technical refresh step.

Back to contents

9. The complete fictional source and update packet

Everything in this section is invented for inspection. All timestamps are UTC on 12 June 2030 unless another date is explicitly written. The future date keeps the fixture separate from current real-world claims. You have all the information required for the worked answers; do not invent additional messages, counts, approvals or hidden observations. The task is to reason from this finite packet, not to pretend it is a live service.

Authority register A1 was approved on 1 June. It assigns Room Cedar’s visitor capacity to the Facilities Desk, its demonstration start time to the Programme Desk, and available kit counts to the Equipment Desk. An informal volunteer message has no authority to replace those records. All supplied records are authorised for this fictional reader. None authorises admitting visitors, reserving equipment, sending messages or changing permissions; the exercise produces informational answers only.

Capacity record C1, revision CAP-CEDAR-R1, was published on 1 June at 08:00. It states: “Room Cedar’s approved demonstration capacity is twelve visitors, effective from 1 June at 00:00 until replaced by an approved capacity notice.” The revision was ingested at 08:02 on 1 June. Its source status was approved, and no expiry date was specified. Our query rule nevertheless requires checking the version register within thirty minutes of a current capacity answer.

Capacity record C2, revision CAP-CEDAR-R2, was approved and published by the Facilities Desk at 09:20 on 12 June. Its full operative statement is: “From 10:00 today, Room Cedar’s approved demonstration capacity is eight visitors. CAP-CEDAR-R2 replaces CAP-CEDAR-R1 from that time. Before 10:00, the twelve-visitor rule remains applicable.” This is a prospective change, not a correction of the earlier capacity. The physical reason for the change is not supplied and must not be invented.

The version-register read V1 occurred at 09:25 and listed C1 as applicable before 10:00 and C2 from 10:00 onward. V1 covered notices through register sequence 42 and reported no withdrawal of either revision within that sequence. The next successful register read V2 occurred at 10:05. It returned the same relationships through sequence 42. At 10:36, read V3 failed with a timeout. There is no later successful verification in the packet.

Schedule record T1 was published by the Programme Desk at 08:00. It states that today’s demonstration begins at 11:00. Successful schedule-source check TV1 at 09:25 confirmed T1 as current. Schedule record T2 was published at 09:35 and explicitly replaces T1: today’s demonstration begins at 11:30. The change applies to the same room and event. T2 was ingested at 09:36 and searchable at 09:37. A current schedule answer requires a successful schedule-source check within sixty minutes. Check TV2 at 09:37 confirmed T2 as current.

Kit observation K1 was made by the Equipment Desk at 09:00, published at 09:01 and ingested at 09:02. It states: “Six complete demonstration kits are on the available shelf.” There is no reservation in that statement. At 09:18 the Equipment Desk issued correction K2: “The 09:00 count included two incomplete display kits. The correct number of complete available kits at 09:00 was four. This corrects K1’s six-kit figure; it is not a new count at 09:18.” K2 was ingested at 09:19.

Kit observation K3 was independently made at 09:40, published at 09:41 and ingested at 09:42. It states: “Three complete demonstration kits are on the available shelf at 09:40.” The packet does not say how the stock moved from four to three. A planning answer about current kit availability requires an observation younger than fifteen minutes at answer time. An observation exactly fifteen minutes old fails this fixture’s strict less-than rule. No observation authorises a reservation or guarantees continued availability.

Volunteer note N1 was posted at 09:50. Its full text is: “I think the old arrangement is back: twelve visitors and an eleven o’clock start.” It cites no source and has no approval from either desk. Its recency does not change A1. It is a reason to check for a missing authorised notice when that matters, but it is not a replacement for C2 or T2. There is no hidden confirmation elsewhere in the exercise.

Catalogue record D1, published on 2 June, describes each complete kit as containing one base, one lamp and two screens. On 12 June at 09:45 the Equipment Desk publishes D2, correcting a heading’s punctuation while explicitly leaving the component specification unchanged. D2 replaces D1 as the displayed catalogue revision. Neither catalogue revision states a current stock count. This gives us a harmless textual revision that should not be confused with a new availability observation.

The local propagation trace supplies the remaining technical facts. C2 reached the connector at 09:22, became searchable at 09:28 and replaced the cached capacity passage at 09:29. An old answer cache AC1, generated at 09:10, still said “twelve visitors” until invalidation at 10:03. K2 became searchable at 09:24. K3 became searchable at 09:44. A query assembler that uses authorised direct records can bypass those search delays; an index-only assembler cannot pretend it already sees the missing revision.

Finally, a contradictory approved capacity notice C3 appears only in the separate conflict exercise. Do not include it in the main timeline. This separation is important: exercises can change one condition without silently changing every earlier answer. The supplied packet is deliberately complete but bounded. Within it, you can establish which evidence supports each response. Outside it, you have no basis to claim what actually happened at a real venue or after the final recorded check.

Back to contents

10. Query packet A: answer before and after an effective boundary

At 09:30, a reader asks, “What is the capacity now, and what will it be when the demonstration starts?” Set the target time for the first clause to 09:30. For the second clause, first resolve the schedule known at 09:30. T2 has not yet been published, so the packet contains T1’s 11:00 start. Both 11:00 and the later revised 11:30 occur after C2’s 10:00 boundary, but that coincidence does not excuse using future information prematurely.

C1 applies to 09:30 because C2 explicitly preserves the earlier rule before 10:00. C2 applies to the planned 11:00 start because its effective interval has begun by then. V1 was checked at 09:25, five minutes before the answer. It passes the thirty-minute capacity verification requirement. TV1 is also five minutes old at 09:30, satisfying the sixty-minute schedule-source check requirement. An honest answer is: “At 09:30, the approved capacity is twelve visitors. From 10:00 it becomes eight, so the currently listed 11:00 demonstration would use the eight-visitor limit.”

The answer names the future statement as a rule already announced, not a prediction about an unobserved decision. It does not say the room currently has twelve people in it. Capacity and occupancy are different properties, and no occupancy observation is supplied. It also does not promise that the demonstration will actually occur at eleven. The schedule is a published plan, subject to later authorised change.

At 10:00 exactly, the same current-capacity question uses C2. The half-open interval convention assigns the boundary to the new rule. V1 is now thirty-five minutes old, however, so the supplied capacity verification requirement fails if V1 is the only check available. The system knows that an eight-visitor rule was announced, but it cannot certify the required recent status check. It should revalidate through an authorised source or qualify the answer as the last verified announced rule.

At 10:05, V2 succeeds, restoring the required verification evidence. A query at 10:10 can say: “The approved capacity is eight visitors under CAP-CEDAR-R2, effective from 10:00 and checked against the register at 10:05.” The arithmetic is five minutes of verification age. The answer does not need a long technical trace for every reader, but the trace should be recoverable when the decision warrants it.

Notice the two independent transitions. Applicability changed at 10:00 because the approved effective interval changed. Verification eligibility changed when the thirty-minute checking allowance elapsed and again when V2 succeeded. Neither transition rewrote C2’s text. A system that stores just “latest capacity equals eight” loses the evidence needed to explain why the same fact can be applicable but temporarily insufficiently verified.

Back to contents

11. Query packet B: calculate age without resetting the observation

At 09:10, the reader asks how many complete kits are available for planning. K1 is the only count yet published, and its observation is ten minutes old. Under the fixture’s fifteen-minute planning rule, it is age-eligible. An answer based on the evidence then available can say that six complete kits were reported at 09:00, while preserving that it is a time-bounded report rather than a reservation. Later information will correct the report, but the system cannot use K2 before it exists in the available packet.

At 09:20, an authorised direct-record read has K2. The accepted historical count for 09:00 is now four. The observation age is twenty minutes, calculated from 09:00, not two minutes from K2’s publication. The correction improves the description of the old observation; it does not supply a fresh observation. Consequently, “Four kits are available now” fails the current-planning rule even though K2 was published only two minutes ago.

A better response is: “The corrected record says four complete kits were available at 09:00. That observation is twenty minutes old, beyond this task’s fifteen-minute limit, so current availability is unverified.” This answer separates a supported historical number from a missing current number. It should not say “There are no kits” or “The count is probably still four.” Neither claim follows from the packet.

At 09:50, K3 supplies a new observation at 09:40. Its age is ten minutes and therefore passes the planning rule. The system can report three complete kits observed at 09:40, with a clear time boundary. At 09:54:59 the age is fourteen minutes and fifty-nine seconds, so it still passes. At 09:55:00 the age reaches exactly fifteen minutes and fails the deliberately strict fixture rule. A real application’s boundary may differ; the test must match its declared policy.

At 10:02, downloading K3 again does not change its observation time. The age is twenty-two minutes. A re-download can confirm that the same record remains available; it cannot confirm that three kits are still on the shelf. The required repair is a new authorised observation, or a narrower historical answer. Calling the same endpoint more often is ineffective if the endpoint only serves a fixed snapshot.

There is also a permissions and action boundary. Even an eligible observation is not a successful reservation. To promise a reserved kit, the system would need authorised reservation capability and evidence that the reservation succeeded. This article concerns evidence currentness, not executing that action. The distinction prevents a seemingly small language change from converting an informational count into a commitment the source never made.

Back to contents

12. Query packet C: reconstruct what was known then

Historical questions have two clocks too. “What was the correct count at 09:00, using all supplied evidence?” asks for the later corrected account. “What did the system have grounds to report at 09:10?” asks for the evidence available before the correction arrived. These questions should produce different answers without contradiction. One describes the accepted historical state; the other describes an earlier information state.

For the first question, use K2’s correction: four complete kits at 09:00. Mention that the earlier six-kit report was corrected because it included two incomplete display kits. Do not say the number dropped from six to four at 09:18. That would turn a correction into a physical stock movement and invent an event that the source explicitly excludes.

For the second question, restrict the evidence to records available at 09:10. K1 existed; K2 did not. The answer can explain that the system’s available record reported six complete kits at 09:00 and passed the stated age test at 09:10, but was later corrected. This does not make the original count true. It explains why an earlier answer differed and identifies which new evidence changed the accepted claim.

A third question asks, “What could the index-only system answer at 09:20?” Now the publication cutoff is insufficient. K2 was published at 09:18 and ingested at 09:19, but did not become searchable until 09:24. The index-only path still lacked it at 09:20. Nevertheless, K1’s observation was already twenty minutes old, so a correctly implemented age gate should prevent a current availability claim even before the correction becomes visible.

This example shows why logs need read-path identity. Saying “the system knew K2 at 09:19” is too broad if only one component had received it. A connector log establishes receipt there; a search result establishes visibility through that query path. A context trace establishes what reached the generator. Diagnosing an answer requires the relevant evidence at each stage, not a single overall update timestamp.

For reproducible history, retain the question’s target time and the evidence cutoff separately. A record can be represented as applicable to a subject time and known to a system from a later receipt time. The exact database design is beyond this guide, but the conceptual separation is essential. It enables fair incident analysis, prevents hindsight from contaminating evaluations and preserves the distinction between a once-reasonable report and a currently accepted fact.

Back to contents

13. Query packet D: inspect propagation and mixed versions

C2 was published at 09:20, received by the connector at 09:22, searchable at 09:28 and present in the passage cache at 09:29. The publication-to-ingestion lag is two minutes. The additional ingestion-to-search lag is six minutes. The search-to-passage-cache lag is one minute. Publication-to-passage-cache propagation therefore totals nine minutes. These numbers describe the fictional trace only, not an expected performance level for commercial systems.

At 09:26, an index-only query for the capacity at 11:00 might still retrieve C1. That does not make C1 the correct future rule; it reveals incomplete propagation. If the application claims current authoritative planning information, its evidence pathway is not meeting that claim during this interval. The correct repair could be a permitted direct source check, waiting for verified propagation, or explaining that the current revision cannot yet be established through the available path.

At 09:30, the passage cache has C2, but AC1 still contains the older generated answer. Reusing AC1 for a new question about the demonstration would preserve an answer assembled before C2 was published. A dependency-aware cache would detect the revision change or the upcoming effective boundary. A text-only cache key could miss both. This is why refreshing search does not by itself prove that repeated questions will receive updated answers.

At 10:01, the old cached statement “twelve visitors” is wrong for current capacity under the supplied approved record. AC1 is not invalidated until 10:03. Measured from C2’s publication, answer-cache invalidation takes forty-three minutes. Measured from the 10:00 effective transition, the stale-current-answer exposure lasts three minutes. Both metrics are legitimate if labelled. Neither should be substituted for the nine-minute passage-cache propagation measurement.

Not every older answer must disappear. AC1 may remain a historical answer to “What did the system report at 09:10?” if that use is permitted and clearly labelled. What must stop is its reuse as an unqualified answer to a current-capacity question. The application can separate historical artefact retention from eligibility for present answers. Destroying audit evidence is not necessary to prevent stale-current reuse.

Mixed revisions require a content-level check as well as identifier checks. If a summary claims to cite C2 but still says twelve, the pointer has changed without the meaning changing correctly. Conversely, an answer that says eight but cites only C1 has the right number for the wrong recorded reason. A complete propagation test checks revision identity, applicable meaning, temporal wording and the user’s actual query route.

Back to contents

14. Unknown, stale but usable and unresolved conflict

At 10:36, V3 times out. V2, the last successful capacity-register check, occurred at 10:05 and is now thirty-one minutes old. It fails the thirty-minute requirement for a certified current-capacity answer. The appropriate state is “current verification unavailable under this task’s rule.” The timeout does not establish a new capacity, an emergency, a withdrawal or closure. Those would be unsupported interpretations of a technical failure.

The same evidence can remain useful for a narrower task. If the reader asks, “What rule had been verified at 10:05?” V2 directly answers that question: eight visitors under C2 from 10:00. This is stale but usable for historical reporting. If the reader asks for a low-risk draft clearly marked for later checking, the application might permit the last verified rule as provisional input. That permission must be explicit; it should not be inferred merely because the system wants to finish.

Unknown means the required proposition is not established. False means available evidence refutes a proposition. Conflicting means relevant eligible sources disagree without a resolved ordering. Not applicable means a source concerns a different scope or interval. Keeping these states separate stops a system from converting an empty result into zero, a timeout into cancellation or disagreement into an average of two incompatible rules.

Now use the separate conflict variant. C3 is an approved Facilities Desk notice published at 10:08. It states a ten-visitor capacity from 10:00 for the same demonstration, but supplies no replacement relationship and no explanation of its disagreement with C2. For this variant, assume the authority register gives C2 and C3 equal authority and contains no conflict-resolution rule. Newer publication alone is insufficient to decide between eight and ten.

The answer should identify the two specific records, their overlapping interval and the unresolved difference. It can say, “The supplied approved notices conflict for the period from 10:00: C2 says eight and C3 says ten. The packet does not establish which governs.” It may request an authoritative clarification. It should not present nine as a compromise, and it should not quietly pick eight while claiming the conflict was resolved. Choosing a precautionary operational limit would itself require the appropriate human decision and authority.

Good uncertainty is targeted. In the conflict variant, T2’s 11:30 start remains supported because the capacity dispute does not change the Programme Desk’s schedule. K3’s historical count remains a separate observation. The system can answer unaffected parts and mark only the contested claim as unresolved. This preserves usefulness without laundering uncertainty out of the answer.

Back to contents

15. Human verification should resolve the missing fact

A human review request should name the proposition that cannot be established and the evidence already checked. “Please verify everything” is difficult to act on and can encourage a reviewer to approve a polished answer without examining its fragile premise. A narrow request such as “Which approved capacity notice governs Room Cedar from 10:00?” makes the required decision and its authority visible.

For the C2/C3 conflict, a useful review packet includes both revision identifiers, the full operative statements, their publication and effective times, A1’s authority rule and the absence of a supersession relationship. It should state that the timetable is unaffected. The reviewer can then obtain clarification from the responsible issuer without redoing every unrelated check. If the clarification is only an informal opinion, it should not be recorded as an official replacement notice.

For expired kit evidence, the missing fact is different: a new observation of complete available kits. Asking somebody merely to confirm that K3 is the latest file would not satisfy the freshness requirement. The reviewer needs to inspect the shelf through the authorised observation process, record when the count was made and distinguish complete kits from display components. The request should also avoid suggesting the expected answer, since “Please confirm there are still three” can bias the check.

A reviewer may be unable to resolve the issue. Preserve that outcome honestly. “No later count supplied” is a useful result; it identifies what remains unknown. A system should not treat the presence of a human name as universal validation. Record what that person actually examined, what they concluded, their authority for the property and when the conclusion applies. Responsibility cannot be inferred from a signature on an unrelated document.

Higher-impact domains need stronger boundaries. A current medical webpage is not a diagnosis, and an up-to-date legal document may still require jurisdiction-specific professional interpretation. Financial, employment and safety decisions can depend on facts, authority and judgement beyond the source packet. This guide’s room and kit examples teach temporal reasoning; their simple age limits are not suitable thresholds to copy into consequential systems without qualified design and review.

Fresh evidence also does not authorise action. Reading a revised rule does not grant permission to send notices, change bookings or alter access. A complete system keeps the informational conclusion, the proposed action and the authority to carry it out separate. Human verification can improve the evidence while leaving those action boundaries unchanged.

Back to contents

16. Evaluate freshness with controlled changes

To test freshness, hold most conditions stable and change one temporal property at a time. Ask the same current-capacity question just before and at the 10:00 boundary. Keep the source text identical but move the verification time beyond the permitted age. Replace a new observation with a correction of an older one. These paired cases reveal whether the system understands the reason for a change rather than reacting to a newer-looking timestamp.

Use explicit expected outputs. Test A asks for capacity at 09:30 using evidence through 09:30: twelve now and eight from 10:00. Test B asks for a recently verified current capacity at 10:00 with V1 only: announced rule eight, but the required recent check is missing. Test C asks at 10:10 with V2: eight with the 10:05 verification boundary. A system that always answers eight fails A’s current-time clause even if it passes C.

Test D asks for current kit availability at 09:20 with K2: no eligible current count, with four as the corrected historical count. Test E asks at 09:50 with K3: three observed at 09:40, without a reservation guarantee. Test F asks at 09:55 exactly: the observation fails the fixture’s strict age rule. A model that rounds all ages to “about fifteen minutes” may miss F’s contractual boundary.

Score by claims and failure types. For six tests, record whether each expected number, time qualification, source revision and abstention boundary is correct. An answer containing the correct number but the wrong observation time should fail the relevant temporal criterion. An answer refusing every question should not earn full marks merely because it never makes a stale claim. Supported historical and current answers are part of the required behaviour.

A useful stale-use rate has an explicit denominator: current-state claims issued despite failed required freshness conditions, divided by all issued current-state claims in the test set. Report the count as well as the fraction. Also track unnecessary abstentions on answerable cases and correction-propagation latency. These measures expose different failures; combining them into one unexplained score can hide a system that becomes “safe” by becoming unhelpful.

Snapshot consistency deserves separate testing. The PostgreSQL 18 transaction-isolation documentation explains that ordinary Read Committed queries see a statement-level committed snapshot, while successive statements can see newly committed changes. That product-specific behaviour illustrates why two reads need not represent one shared instant. It does not establish consistency across external websites, connectors or caches. Test the actual architecture’s guarantees instead of borrowing the word “snapshot” as a blanket assurance.

Back to contents

17. Independent exercises and full answer keys

Exercise one: At 09:45, a reader asks, “What is the capacity now, and what time does the demonstration start?” Use the main packet, including T2 and TV2, but not the separate conflict variant. Identify the current capacity revision, whether the capacity check is recent enough, the applicable schedule and its verification age. Write a two-sentence answer that does not confuse a future capacity change with the current rule.

Answer one: C1 still applies at 09:45 because C2 begins at 10:00. V1 is twenty minutes old, so it passes the thirty-minute capacity-check requirement. T2 gives the 11:30 start, and TV2 is eight minutes old. A suitable answer is: “At 09:45, Room Cedar’s approved capacity is twelve visitors; it changes to eight at 10:00. The Programme Desk’s revised schedule lists the demonstration for 11:30, so that demonstration falls under the eight-visitor rule.” The response distinguishes now from event time and uses the later schedule only after its publication.

Exercise two: At 09:21, a summary says, “The count was updated three minutes ago, so four complete kits are currently available.” The summary cites K2 and assumes an authorised direct-record read. Find the temporal error, calculate the correct observation age and rewrite the statement. Explain whether the error is fixed by attaching K2’s citation more prominently.

Answer two: K2 was published three minutes earlier, but it corrects the 09:00 observation. The observation is twenty-one minutes old at 09:21, so it fails the fifteen-minute planning requirement. Write: “K2 corrects the 09:00 count to four complete kits. That observation is twenty-one minutes old, so current availability is not established under this task’s rule.” A stronger-looking citation cannot repair the incorrect time interpretation. The problem is the unsupported inference from correction publication to fresh observation.

Exercise three: At 09:46, an assistant calculates that three complete kits contain three lamps and six screens, using K3 and D1. It later discovers D2’s punctuation correction. Does the arithmetic need to change? Which citation should appear if the answer is regenerated using the current catalogue revision? State what the calculation does and does not establish.

Answer three: The calculation remains three times one lamp equals three lamps, and three times two screens equals six screens. D2 explicitly leaves the component specification unchanged, so it supplies no reason to alter those totals. A regenerated answer can cite K3 and D2 while preserving K3’s 09:40 observation time. This is a calculation about the reported complete kits, not an independently observed count of every loose component and not a promise of availability at a later time. The semantic effect of the revision, rather than its mere existence, determines the repair.

Exercise four: At 10:01, a system reads an answer cache generated at 09:10 and reports twelve as current capacity. Its operator says, “Search was refreshed at 09:28, so freshness cannot be the problem.” Diagnose the first evidence transition you would inspect and calculate the two relevant lag measures supplied in the packet. Do not assume the generator itself misunderstood C2.

Answer four: Inspect whether the request bypassed fresh search by reusing AC1 and whether AC1 tracked source revisions and the 10:00 effective boundary. C2 became searchable eight minutes after its 09:20 publication. AC1 was invalidated only at 10:03, forty-three minutes after publication and three minutes after the effective change. The correct search state did not reach this answer path. Re-prompting the generator is unlikely to repair a cache that never supplies C2; fix the broken dependency or eligibility check and then replay the same query.

Exercise five: In the separate conflict variant, C2 and C3 disagree about capacity from 10:00. A proposed repair takes the mean of eight and ten and displays nine with a confidence score. Explain why this is invalid, identify the smallest useful human-verification request and state which other main-packet answer remains unaffected by the dispute.

Answer five: The capacity is an authoritative rule, not a noisy measurement whose estimates can simply be averaged. The fixture provides no authority for a nine-person rule and no relationship choosing between C2 and C3. Ask the Facilities Desk which approved notice governs the overlapping interval and request a documented clarification or supersession relationship. T2’s 11:30 schedule remains independently supported by the Programme Desk. Preserve that supported answer while marking the capacity unresolved; do not transform a conflict into a fabricated compromise.

Exercise six: At 10:36, V3 times out. The reader asks, “Has the eight-visitor rule been cancelled?” Use only the main packet. Explain what the timeout establishes, what V2 still supports and what further evidence would answer the cancellation question. Your response must avoid both pretending the rule was freshly verified and announcing cancellation without evidence.

Answer six: The timeout establishes that the 10:36 attempt did not complete a register check. V2 supports that C2 was listed as applicable when checked at 10:05. At 10:36 that check is thirty-one minutes old and outside the current-answer requirement. A suitable response is: “I have no supplied evidence of cancellation. The last successful check at 10:05 listed the eight-visitor rule, but the current check failed, so its current status needs revalidation.” A successful authorised register read or direct clarification could resolve the missing current status.

Exercise seven: Two logs use different time zones. A new observation was made at 18:40 Singapore time on 12 June 2030, explicitly UTC+08:00. The answer is generated at 10:54 UTC on the same date. For this exercise only, use the same strict fifteen-minute observation-age rule. Is the observation eligible by age, and what error would result from comparing the clock numbers without their offsets?

Answer seven: Convert 18:40 at UTC+08:00 to 10:40 UTC. The answer at 10:54 UTC occurs fourteen minutes later, so the observation passes the strict age criterion. Comparing eighteen with ten as bare clock numbers could produce a negative age or an eight-hour discrepancy. Passing the age test still does not establish authority, scope, absence of correction or permission; it resolves only the age condition supplied in this exercise.

Exercise eight: A source says only “checked on 12 June,” and the application requires a check within thirty minutes at 10:10 UTC that day. No time zone or time of day is supplied. Can the application certify compliance? Explain how to preserve useful information without inventing the missing precision.

Answer eight: It cannot establish the thirty-minute condition from a date-only statement. The check may have occurred outside the required interval, and the date may refer to a different local time zone. The application can report the source’s stated calendar date, label the precision limitation and obtain a timestamped check if necessary. Assigning 10:00 because it would make the test pass is fabricated evidence. A timestamp schema cannot repair missing source precision by filling in a convenient value.

Back to contents

18. Questions that prevent stale certainty

Does the newest document always win? No. First establish the property, scope, issuing authority, approval status, effective interval and revision relationship. A later draft may be less authoritative than an earlier approved record. A later correction may change the accepted description of the past rather than a rule for the future. If equally authorised records remain inconsistent, preserve the conflict and seek clarification instead of substituting recency for authority.

Does an old source always need replacement? No. Its suitability depends on the question. An old source can be the correct evidence for what was published at that time, and stable technical definitions can remain useful for long periods. The important question is whether the source supports the requested claim under the applicable evidence rule. Age alone neither refutes a statement nor proves that a new statement is better.

Can a fresh search result still be stale? Yes. A search performed now may retrieve an old observation, an archived revision or a cached summary. Search time and subject time are different. Inspect the underlying evidence rather than treating the moment of retrieval as the moment of verification. A system should also identify which search route was used, since a direct read and a delayed index may expose different revisions at the same answer time.

Why not ask the model to be more careful? Clear instructions help the model preserve supplied timestamps and avoid unsupported wording, but they cannot deliver evidence that the system never retrieved. If the source correction has not reached the context, the model may lack the fact needed to update its answer. Diagnose the first broken stage: source availability, ingestion, visibility, cache eligibility, context assembly or interpretation. Repairing the correct stage is more useful than repeatedly changing the tone of the prompt.

Can every source use the same expiry period? That is rarely a defensible assumption. Different properties change at different rates, and different uses tolerate different uncertainty. A historical description, a planned schedule and a live availability count have different jobs. This article uses explicit thirty-, sixty- and fifteen-minute rules only to make the fictional decisions reproducible. Selecting real thresholds requires domain knowledge, observed change patterns, consequence analysis and suitable human responsibility.

What should “checked just now” mean? It should identify a real check and its object. The phrase can honestly refer to reading the latest approved-version register, but it should not imply a new physical inspection unless one occurred. Where the distinction matters, use concrete wording: “The register was checked at 10:05” or “The shelf was counted at 09:40.” Precision makes the answer easier to trust because the reader can see exactly what remains outside the claim.

What is the final test of a freshness mechanism? Change the evidence and see whether the right answers change for the right reasons. Current answers should follow applicable authoritative revisions, historical answers should preserve their requested time perspective, corrections should not masquerade as fresh observations, and failed checks should remain unknown rather than becoming invented facts. A system passes by keeping those boundaries intact through retrieval, caching, generation and human review.

Continue through the SI mechanisms

Return to the How Super Intelligence Works hub for the larger system map. Continue with Retrieval — Finding Missing Information for candidate selection and evidence packets, or Retrieval-Augmented Generation for the handoff from retrieved sources to an answer. For authority across workplace systems, use the separate Source of Truth guide.

Primary sources and scope notes

RFC 9111: HTTP Caching, June 2022 supports the protocol distinction between cached-response freshness and validation. RFC 9110: HTTP Semantics, June 2022 supports the conditional-request example. The article’s room policies and age calculations are original fictional application rules, not copied HTTP algorithms.

W3C DCAT version 3 supplies vocabulary for dataset versions and relationships. W3C PROV-DM supplies provenance concepts including derivation and revision. Crossref Crossmark illustrates publisher-supplied update-status information. None of these references certifies the fictional packet or guarantees that any given AI application uses those mechanisms.

Elastic near-real-time search documentation illustrates the distinction between an index update and searchable visibility. PostgreSQL 18 transaction isolation supplies the explicitly versioned database example. Product documentation was consulted on 1 October 2026; implementations and defaults should be checked against the version actually deployed. No product was benchmarked in preparing this guide.