`nexyron.snapshot_materialize`
Generic Description
nexyron.snapshot_materialize builds and caches one materialized feature snapshot in the shared abstraction runtime.
CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.snapshot_materialize'
RETURN name, description, parameters, output_columns
Abstraction-platform runtime procedures build, materialize, refresh, inspect, and execute artifacts derived from registered abstraction contracts.
Consumer-Level Explanation
This procedure is part of the abstraction artifact and refresh runtime. It evaluates a registered snapshot contract, computes the active feature values for the selected subject abstraction, and stores the resulting values into feature streams for later serving, model scoring, or audit.
When at is supplied, Nexyron applies the same point-in-time context used by query-level ASOF <point in time> Cypher. Feature queries receive contextual placeholders such as $snapshot_at_ms, and the runtime injects an ASOF prefix around rendered feature queries that do not already contain one. Abstraction source_query and feature registry contracts should remain normal current-shape contracts; the snapshot build supplies the temporal context.
Parameters
name: Snapshot definition name Required.at: Optional ASOF timestamp in epoch milliseconds for snapshot execution and contextual query placeholders Optional.system_at: Optional system-time cutoff in epoch milliseconds for dual-time contextual query placeholders Optional.
Output Columns
subject_idsnapshot_tsfeatures
Example Contract Prerequisite
The executable Cypher blocks on this page query nexyron.procedures() so they work in an empty database and stay synchronized with the live procedure registry. A direct CALL nexyron.snapshot_materialize(...) requires the named abstraction contracts, artifacts, features, snapshots, datasets, models, or policies referenced by that call to exist first; otherwise the runtime correctly fails with an unknown-contract error rather than inventing state.
Conceptual Explanation
The important thing about nexyron.snapshot_materialize is that it stays inside the same Cypher and abstraction-contract runtime as the rest of Nexyron. That means it can compose with named abstractions, time-aware snapshot contracts, document-style payloads, graph-native identity, and later model or policy layers without forcing you to move into a separate tool first.
Materialized feature snapshots are keyed by snapshot name, scenario, requested at, and requested system_at for contract metadata and freshness tracking. The computed values are also written into stream-backed feature histories keyed by feature name, subject identity, scenario, optional system_at, and timestamp. That allows callers to read one subject or all subjects for one feature over a time range without opening one snapshot artifact per timestamp.
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 abstraction procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.
Advanced Example
CALL nexyron.procedures()
YIELD name, parameters, output_columns
WHERE name = 'nexyron.snapshot_materialize'
RETURN name,
[p IN parameters | p.name] AS parameter_names,
output_columns
ORDER BY name
Real Use Cases
- Build or refresh quarter-specific training artifacts close to the graph so analysts can inspect the exact rows, labels, and split behavior before promoting a model.
- Audit artifact freshness, dependency shape, and rebuild backlog when a late membership backfill or facility schedule correction invalidates downstream abstraction assets.
- Maintain daily feature snapshots for an abstraction so serving, model training, and policy evaluation can replay the feature set that was available at each ASOF point.
- Populate
nexyron.feature_historyso one feature can be retrieved as(subject_id, ts, value)across a bounded time range.
Real Limitations And Tradeoffs
- This surface is contract-driven. If the registered feature, snapshot, dataset, model, or policy definition is weak, the procedure will faithfully execute that weak contract rather than silently repairing it.
- Materialized streams improve reuse, but they add freshness and invalidation concerns that on-demand execution avoids.
- If a snapshot definition includes active features implicitly, freshness checks compare against the current effective active feature set. Adding or changing an active feature can make prior materialized snapshots stale.