nexyron.latest_global_temporal_event
Generic Description
Return the latest contribution recorded in Nexyron's global temporal timeline.
Simple example:
CALL nexyron.latest_global_temporal_event()
YIELD ts
RETURN ts
ts is an i64 epoch-millisecond timestamp. It is the latest available temporal data point in the database timeline, using an event's end_ts when the event is an interval and start_ts otherwise.
Consumer-Level Explanation
Use nexyron.latest_global_temporal_event() when "now" should mean the newest timestamp present in the data rather than the machine's wall-clock time.
That distinction matters for analytical and ML workloads. A customer, device, member, patient, or operational dataset may have been exported months or years ago. A feature named payments_last_30d should usually mean "30 days before the dataset's latest event", not "30 days before the server clock at query time".
Conceptual Explanation
The procedure reads the global temporal timeline high-water mark. The timeline receives contributions from temporal-property writes and other time-oriented stream/event surfaces that are recorded in Nexyron's temporal index.
Unlike nexyron.global_time_range, this procedure is not a timeline scan. The index maintains the latest event summary as data is recorded and rebuilds it only when the timeline is bulk-imported, pruned, or deleted. Normal reads are therefore constant-time relative to the number of timeline entries.
Use it as an anchor, then do the subject-specific work through temporal_history, temporal_rollup, or a scoped graph path:
CALL nexyron.latest_global_temporal_event()
YIELD ts AS anchor_ts
MATCH (m:MemberAccount)
WHERE element_id(m) = 'n:1'
WITH element_id(m) AS subject_id, m, anchor_ts
CALL {
WITH m, anchor_ts
CALL nexyron.temporal_history(
id(m),
'member_payment_transactions_stream',
anchor_ts - 2592000000,
anchor_ts
)
YIELD ts
RETURN count(*) AS payments_last_30d
}
RETURN subject_id, payments_last_30d AS value
More Detailed Explanation
In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with YIELD and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.
Advanced Example
This feature computes an inactivity flag against the latest available data timestamp, not against wall-clock time:
CALL nexyron.latest_global_temporal_event()
YIELD ts AS anchor_ts
MATCH (m:MemberAccount)
WHERE element_id(m) = 'n:1'
WITH element_id(m) AS subject_id, m, anchor_ts
CALL {
WITH m
CALL nexyron.temporal_history(
id(m),
'member_payment_transactions_stream',
null,
null
)
YIELD ts
RETURN max(ts) AS latest_payment_ts
}
RETURN subject_id,
latest_payment_ts IS NULL OR latest_payment_ts < anchor_ts - 2592000000 AS value
This shape avoids rescanning the full member population for every selected member. The only global operation is the cached high-water-mark lookup.
Real Use Cases
- Anchoring ML features such as "last 7 days", "last 30 days", inactivity, churn gap, freshness, recency, and rolling activity windows for historical exports.
- Building reproducible feature snapshots where the reference time should come from the data itself.
- Avoiding incorrect all-zero or stale recency features when the server clock is far beyond the dataset's last event.
- Replacing broad
max(ts)discovery scans that were only trying to find the dataset's latest temporal timestamp.
Real Limitations And Tradeoffs
- The procedure returns the latest event in the global temporal timeline, not the latest event for one specific label, subject, or property. For property-specific latest values, use it only as the global anchor and still compute the subject/property-specific value through the proper scoped temporal history or rollup.
- It returns no rows when the global temporal timeline is empty. Feature contracts should handle that case only when the dataset may genuinely have no temporal data.
- The high-water mark is maintained by timeline-aware writes. Plain scalar properties that were never registered as temporal properties do not contribute to this procedure.
- It should not replace
global_time_rangewhen the caller actually needs ranked subjects or timeline activity across a range.