The Temporal Authority Envelope: When a Facility Fact Is Still Safe to Act On

Method and evidence boundary: This is an authored operating method. Every facility, system, record, threshold, time, action, and result in the examples is fictional. The method is not evidence of a product deployment, customer result, service level, legal conclusion, certification, or industry standard. Each operator must set decision-specific thresholds with the people responsible for operations, safety, privacy, security, contracts, and other applicable requirements.

A self-storage manager asks an AI assistant whether a gate can be placed into a temporary service mode. The assistant retrieves four facts:

• the gate controller was reachable six minutes ago;
• the access schedule was approved yesterday;
• a maintenance note was entered three hours ago;
• the facility identifier was mapped last month.

Are those facts fresh?

There is no honest single answer. Six minutes may be too old for controller state and unnecessarily strict for an approved schedule. The maintenance note may describe a condition that existed before a repair. The facility mapping may still be correct, or it may have been superseded by a move, rename, or system migration. A green “data updated” badge cannot resolve those differences.

The usual approach assigns each record a time to live. After fifteen minutes, refresh it. After one day, mark it stale. That is useful cache behavior. It is not an operating-control model.

A fact is safe to use only inside a temporal authority envelope: the bounded interval and decision context in which its identity, authority, effective time, observation age, recording history, clock quality, conflict state, and expected action duration make it admissible. The envelope belongs to a fact-and-decision pair, not to the fact alone.

This distinction matters whenever software—or a person using software—joins facts that change at different speeds. An AI system can retrieve the right rows and still assemble an operationally impossible present.

Open the full-size accessible diagram.

Governed companion package

Inspect the fact-admission register and readiness gates.

These exact files contain an authored method and fictional or blank-contract examples. They do not establish factual authority, a product deployment, customer result, service level, legal or cybersecurity conclusion, compliance, certification, performance, or independent validation.

Download the source and limitations register ↓Download the temporal fact-admission register ↓Download the temporal-authority readiness suite ↓Download the accessible temporal-envelope SVG ↓Download the temporal-envelope PNG ↓

Freshness is a predicate, not a color

Most dashboards reduce temporal state to a colored badge:

• green: current;
• yellow: aging;
• red: stale.

The color hides the question that matters: current enough for what decision?

An address used to label a monthly report and a controller-state observation used to change physical access should not share one freshness rule. Even the same fact may have different admissibility limits. A controller observation might be acceptable for opening a diagnostic screen but not for issuing a remote command.

For a fact f, decision d, and evaluation time t, the admission test can be expressed conceptually as:

admissible(f, d, t) =
  identity_matches(f, d)
  AND authority_is_allowed(f.source, d)
  AND effective_interval(f) contains t
  AND observed_age(f, t) <= d.maximum_observation_age
  AND source_lateness(f) <= d.maximum_source_lateness
  AND clock_quality(f) >= d.minimum_clock_quality
  AND invalidation_state(f) is clear
  AND conflict_state(f) is allowed
  AND expected_completion(d) <= envelope_end(f, d)

This is not a proposed universal formula or a probability score. It is a control pattern. A production implementation needs explicit field definitions, units, comparison rules, owners, and failure behavior.

The important shift is from “the record is fresh” to “the record passed the declared admission contract for this decision at this time.”

Keep six kinds of time separate

One timestamp cannot carry the full temporal meaning of an operational fact. A minimum useful contract separates six clocks.

1. Effective time

When is the assertion intended to be true in the operating world?

An access schedule approved Tuesday may take effect Friday. A vendor credential may be recorded today but apply only through a declared expiration date. A facility name may have a future effective date. Effective time is sometimes called valid time or business time.

IBM's current Db2 documentation distinguishes an application period, which records when data is valid or in effect, from a system period, which records when a row version was current in the database. Its bitemporal table model combines both. That product documentation does not define a self-storage architecture, but the distinction is essential: when the system knew is not the same as when the fact applied.

2. Occurrence or measurement time

When did the underlying event happen, or when was the condition measured?

A controller heartbeat may be received at 10:05 for a device observation made at 10:03. A photograph may upload at noon but depict a condition recorded at 9:30. A work-order state change can occur before a delayed integration reports it.

The facility event spine uses occurred_at and observed_at to keep those facts apart. The temporal authority envelope builds on that separation and asks whether the delay is tolerable for a particular decision.

3. Recording time

When did the governing system store this version?

Recording time supports history, correction analysis, and replay. It helps answer, “What could the system have known at 10:04?” A later correction should not silently overwrite the decision-time view.

System-period history is not proof that a business assertion was correct. It is evidence of what a particular system recorded during a particular interval.

4. Evaluation time

When did the person or system test the fact for admission?

Age must be measured at the decision boundary, not when a dashboard page happened to render. A fact admitted at 10:00 may no longer be admissible when a queued action starts at 10:20.

5. Execution time

When did the operational action actually begin and end?

Approval at 10:00 does not grant indefinite temporal authority. If a remote action waits in a queue, the source facts may need to be revalidated immediately before execution. Long-running work may require an envelope that remains valid through completion, or an interrupt when a critical fact changes.

6. Readback time

When did an independent source confirm the resulting state?

A provider receipt, accepted command, or database write is not necessarily the operating result. The decision chain remains incomplete until the relevant state is observed and reconciled. Readback time also defines how long the operation remains uncertain after action.

Two histories prevent retrospective fiction

Suppose a regional team corrects a facility's approved access schedule at 2:00 p.m. and makes the correction effective from 8:00 a.m. A system that stores only the latest row may later show the corrected schedule as if it were the value available to a 10:00 a.m. decision.

That rewrites history.

The fact needs two independent histories:

• effective history: the interval in which the assertion applies to the operating world; and
• recording history: the interval in which a particular system held that assertion.

At 3:00 p.m., the team may correctly say, “The schedule should have been X since 8:00.” It must not automatically say, “The 10:00 decision system knew X.” The first is an effective-time claim. The second is a recording-time claim.

This separation is especially important for AI evaluation. If an analyst reconstructs an old prompt from today's corrected database rather than the versions available at the original decision time, the replay gains information that the original system never had. The result is leakage, not a fair reproduction.

A temporal store can help preserve these histories. It does not decide which source was authoritative, whether a correction was justified, or whether the original action was appropriate. Those remain governance questions.

A timestamp format is not a time contract

RFC 3339 provides an Internet timestamp profile with an explicit relationship to UTC. It is a strong interchange choice for representing instants. It does not tell an operator:

• what the timestamp means;
• which clock produced it;
• whether the device clock was synchronized;
• how accurate or precise it was;
• whether the source copied a timestamp from another system;
• whether a local civil-time rule affected a schedule;
• whether the record was delayed, backfilled, or corrected.

Every time field therefore needs semantics in addition to syntax. 2026-08-22T10:05:00Z is unambiguous as an encoded instant. It may still be the wrong instant, an ingestion instant mislabeled as occurrence time, or a value copied from an untrusted clock.

For local operating schedules, store the governing time-zone identifier and rule context as well as normalized instants where appropriate. A recurring “6:00 a.m.” rule is not fully represented by a fixed UTC offset because civil-time rules can change. RFC 9557 defines optional additional timestamp information, including time-zone names, for Internet use. It is an encoding tool, not a substitute for schedule authority or business logic.

Clock quality belongs in the decision packet

Distributed systems do not share a perfect clock. Devices drift. Mobile clients operate offline. integrations retry. Operators enter facts after the event. Some sources provide second-level precision; others provide only a date.

NIST SP 800-53 Rev. 5 includes AU-8 controls concerning timestamp generation and comparison to Coordinated Universal Time. NIST's current publication page also identifies Release 5.2.0, issued August 27, 2025, as a minor catalog update; the listed changes do not include AU-8. The publication is a security-and-privacy control catalog, not a facility AI design or a certification. It supports the narrower lesson that timestamp granularity and authoritative-time comparison are explicit controls, not invisible assumptions.

A practical clock-quality record can include:

• clock_source;
• clock_sync_state;
• estimated_error_bound;
• timestamp_precision;
• device_time_zone_context;
• last_sync_at;
• timestamp_semantics;
• time_quality_state such as verified, bounded, unknown, or untrusted.

Do not invent precision. A date-only certificate expiration should not be converted into a fabricated millisecond. A manual note entered at 2:00 p.m. about a condition seen “this morning” has uncertain occurrence time even though its entry time is exact.

An uncertain clock can still support some decisions. The admission rule should account for the uncertainty. If an observation may be off by five minutes, a decision with a two-minute maximum age cannot treat that observation as safely current.

The slowest input controls the join

Operational decisions rarely depend on one fact. They join identity, policy, current state, permissions, site capability, open work, and human availability.

The joined packet is not as fresh as its average input. Its temporal confidence is constrained by the input that fails first.

Consider a fictional decision packet:

Input	Observed or effective state	Decision-specific limit	Admission
Gate controller reachability	70 seconds old	120 seconds	pass
Approved service window	effective now	must cover action plus rollback	pass
Facility identity mapping	21 days old	revalidate on source change, not fixed age	pass
Open safety hold	source delayed 14 minutes	maximum delay 5 minutes	fail

Three green rows do not outvote the failed safety-hold input. The decision packet is inadmissible.

This produces three implementation rules:

1. Evaluate each required fact independently.
2. Do not average ages, confidence scores, or source delays.
3. Fail according to consequence: block, degrade to read-only, request human review, refresh synchronously, or use a specifically approved fallback.

The fallback must be designed before the failure. “Ask the AI to make its best guess” is not a temporal control.

Late and out-of-order facts need a correction path

In streaming systems, event order and arrival order often differ. Apache Flink's versioned 2.3 time concepts distinguish event time from processing time, describe watermarks as the mechanism that signals event-time progress, and explain that finite waiting for out-of-order data limits how deterministic an event-time application can be. Its versioned watermark guidance also covers bounded out-of-orderness, idle sources, alignment, and multi-input progress.

The facility lesson is not that every operator should deploy Flink. It is that completion is a declared assumption about lateness, not proof that all earlier facts have arrived.

For each event class, define:

• expected arrival delay;
• tolerated lateness;
• idle-source behavior;
• correction window;
• whether late facts revise a projection;
• whether an already executed decision needs review;
• whether notification or remediation is required;
• when the system may consider a window operationally complete.

A late fact should not disappear because a dashboard already rendered. It should enter a correction path with a link to the projection, decision, or action it may affect.

The correction path also needs an end. Unlimited retroactive recomputation can destabilize reports and operating state. A bounded process can distinguish:

• open window: late facts update the active projection;
• closed but correctable: changes require governed revision and notice;
• frozen record: original evidence remains immutable, with a linked correction rather than overwrite;
• expired operational consequence: the old decision cannot be undone, but the exception can inform review and future controls.

The nineteen-field temporal fact contract

The accompanying template uses nineteen fields. The exact storage format can vary, but the meanings should remain explicit.

Identity and assertion

1. fact_id
2. facility_id
3. fact_type
4. assertion_value_or_reference

Authority and provenance

5. governing_source_id
6. source_record_id
7. source_version_or_hash
8. authority_scope

Effective history

9. effective_from
10. effective_to

Observation and recording history

11. occurred_or_measured_at
12. observed_at
13. recorded_at
14. record_version_valid_to

Time quality and state

15. clock_quality_and_error_bound
16. invalidation_or_supersession_state
17. conflict_state

Decision admission

18. decision_contract_id
19. admission_result_reason_and_expiry

The template expands several composite fields to make review easier, including separate maximum-age, lateness, execution-horizon, and readback requirements. It uses one row per fact-decision evaluation rather than turning a fact into a permanently green object.

A four-level operating ladder

Temporal governance can start without a streaming platform or an AI architecture team.

Beginner — name the timestamp

Take one report or queue. For every displayed time, write what it means: occurred, measured, observed, entered, effective, approved, executed, or read back. Mark unknown semantics as defects. Do not rename them by assumption.

Intermediate — define decision-specific age limits

Choose one low-consequence decision. List its required facts and assign:

• source owner;
• effective interval rule;
• maximum observation age;
• maximum source delay;
• refresh path;
• stale-state behavior.

Test the boundary values. If the maximum age is five minutes, decide whether exactly five minutes passes and document the comparison.

Advanced — preserve both histories and corrections

Retain the decision-time versions of facts. Separate effective time from recording time. Route late facts, corrections, invalidations, and conflicts to explicit processes. Make it possible to replay what the system knew without substituting today's corrected data.

Architect — enforce an envelope through action and readback

Treat temporal admission as a runtime policy. Re-evaluate facts immediately before consequential execution. Interrupt or degrade safely when an envelope closes. Link the admission packet, action receipt, independent readback, and any later correction through durable provenance.

A fictional Harbor Annex exercise

Harbor Annex is a fictional facility used only to test the method. A proposed assistant prepares a maintenance-priority recommendation at 10:00.

It uses five inputs:

1. a door-position observation measured at 9:57 and received at 9:58;
2. an active work-order record entered at 8:20;
3. a technician-availability roster effective from 8:00 to 12:00;
4. a local access window approved the prior week and effective today;
5. a facility identity mapping recorded thirty days ago.

At first glance, the work-order record is the oldest. It may not be the limiting fact. If work orders remain authoritative until changed and the source provides change notifications, its age may be acceptable. The door observation has a much shorter decision horizon. The roster becomes invalid at noon. The identity mapping uses a change-triggered revalidation rule rather than a universal TTL.

Now add one complication: a safety-hold event occurred at 9:54 but reached the central event processor at 10:03. The 10:00 packet did not include it.

The exercise should not ask whether the assistant made the “right” recommendation. It should ask:

• Was the safety source within its declared lateness budget at 10:00?
• Did the 10:00 decision contract permit action before completeness?
• Was the recommendation merely displayed, or did execution begin?
• Did the late hold invalidate the recommendation, interrupt execution, or create a review case?
• Can the system reconstruct the exact 10:00 evidence without erasing the later correction?
• Did an independent readback confirm any resulting operational state?

Those questions produce evidence. A retrospective opinion about what “probably would have happened” does not.

Test the envelope before trusting it

A temporal contract should ship with adversarial cases. The accompanying readiness suite includes forty tests across beginner, intermediate, advanced, and architect levels. The most important classes are:

• missing or ambiguous timestamp semantics;
• effective dates in the future or past;
• exact-boundary age comparisons;
• clock error larger than the allowed age;
• source delay within and beyond tolerance;
• late facts after a projection closes;
• conflicting authoritative sources;
• a fact corrected retroactively;
• a queued action whose envelope expires before execution;
• a long-running action crossing an effective-period boundary;
• daylight-saving transitions and local schedule ambiguity;
• provider receipt without independent readback;
• replay attempted with today's corrected rows;
• unknown invalidation state;
• required source idle or disconnected.

A test should include the input state, expected admission result, expected operating behavior, evidence required, and owner. “Handle stale data” is not a test case.

Measure the control, not a promised benefit

Early metrics should show whether the temporal control works. Useful candidates include:

• percentage of decision packets with complete time semantics;
• percentage of required facts admitted, rejected, refreshed, or unknown;
• observation-age distribution by fact type and decision contract;
• source-lateness distribution and late-event count;
• decisions blocked because a critical envelope closed;
• queued actions revalidated before execution;
• corrections linked to affected decisions;
• readback latency and unresolved readback count;
• records with unknown clock quality;
• replays using exact decision-time versions.

These are control-performance measures. They do not prove occupancy, revenue, savings, safety, customer satisfaction, or AI effectiveness. Any operational outcome claim needs its own denominator, comparison design, period, provenance, limitations, and permission.

Avoid one portfolio-wide “freshness percentage.” It can conceal the precise failures that matter. Report by decision type, fact class, source, facility context, and consequence band where appropriate.

The architecture in one sentence

The architecture is straightforward to describe and demanding to implement:

Bind each assertion to identity, authority, effective and recording histories, clock quality, and invalidation state; evaluate it against a decision-specific time contract; preserve the admission packet; revalidate before execution; and reconcile the result with independent readback and late corrections.

The accompanying diagram shows six layers:

1. authoritative fact sources;
2. temporal normalization without semantic collapse;
3. dual-history fact records;
4. decision-specific envelope evaluation;
5. action admission, refresh, degrade, or stop;
6. execution, readback, correction, and replay evidence.

No layer should silently manufacture missing time. Unknown stays unknown until an authorized source resolves it.

Twelve questions for an architecture review

1. What does every timestamp mean?
2. Which clock produced it, with what known error?
3. When was the assertion effective in the operating world?
4. When did each system record and supersede the row?
5. Which source governs this fact for this decision?
6. What observation age and source delay are allowed?
7. What happens at the exact time boundary?
8. Can a queued action outlive its evidence?
9. How are late facts and corrections linked to affected decisions?
10. Can replay recover only what was known at decision time?
11. Does a provider receipt have an independent readback path?
12. Who may change the temporal contract, and how is that change tested and rolled back?

If the system cannot answer those questions, it does not have a freshness model. It has timestamps.

Start with one consequential join

Do not begin by assigning arbitrary TTLs to every table. Choose one bounded decision where facts arrive from more than one source and a stale join has a clear operating consequence.

Then:

1. name the decision and responsible authority;
2. list the exact facts it requires;
3. define each time field's semantics;
4. preserve effective and recording histories;
5. set decision-specific admission and execution limits;
6. design refresh, degrade, stop, correction, and readback paths;
7. run the readiness suite at boundaries and under late data;
8. record what remains unknown.

The goal is not to make every fact real time. Real time is expensive, sometimes impossible, and often unnecessary. The goal is to make the time assumptions explicit enough that software cannot quietly act on a past that no longer governs the present.

That is the temporal authority envelope: not a fresher dashboard, but a defensible answer to a harder question—was this fact still authorized to support this action when the action actually happened?

Sources

• RFC 3339: Date and Time on the Internet: Timestamps, RFC Editor, July 2002.
• RFC 9557: Date and Time on the Internet: Timestamps with Additional Information, RFC Editor, April 2024.
• Time Ontology in OWL, W3C Recommendation, October 2017.
• PROV-O: The PROV Ontology, W3C Recommendation, April 2013.
• Application-period temporal tables, IBM Db2 12.1 documentation, checked August 22, 2026.
• System-period temporal tables, IBM Db2 12.1 documentation, checked August 22, 2026.
• Bitemporal tables, IBM Db2 12.1 documentation, checked August 22, 2026.
• Timely Stream Processing, Apache Flink 2.3 documentation; 2.3.0 was the latest stable release on the official downloads page when checked August 22, 2026.
• Generating Watermarks, Apache Flink 2.3 documentation, checked August 22, 2026.
• NIST SP 800-53 Rev. 5, National Institute of Standards and Technology, September 2020 with updates through December 10, 2020; current page notes Release 5.2.0 issued August 27, 2025.
• Artificial Intelligence Risk Management Framework 1.0, National Institute of Standards and Technology, January 2023.