`nexyron.snapshot_build`
Generic Description
nexyron.snapshot_build builds one logical feature snapshot from registered feature definitions.
CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.snapshot_build'
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 belongs to the semantic runtime layer and operates on named contracts rather than raw graph patterns alone.
Parameters
name: Snapshot definition name Required.at: Optional as-of timestamp in epoch milliseconds for 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_build(...) 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_build is that it now treats a source-query-backed subject_abstraction as the authoritative virtual subject set for the snapshot. When a feature query uses $subject_id, Nexyron resolves the feature's abstraction and executes that feature once per resolved subject. Feature rows that return subjects outside the abstraction are rejected. Feature rows that return NULL as subject_id are treated as invalid feature-contract output; during snapshot materialization the offending feature is marked draft and skipped so the rest of the subject snapshot can still complete.
For stage and society snapshots, feature execution still has to remain subject-scoped, but it no longer injects containment-list placeholders. A stage feature should bind the stage from $subject_id and match contained actors through schema-grounded relationships. A society feature should bind the society from $subject_id, match contained stages, and then match actors through those stages. This keeps materialized stage and society values scoped to the selected subject rather than to the whole database.
Eligible subject-scoped feature queries are batched by passing chunks of
resolved subjects through $nexyron_subject_id. The default chunk size is
2048, controlled by NEXYRON_FEATURE_SNAPSHOT_SUBJECT_CHUNK_SIZE. The default
inter-chunk pause is 0 milliseconds, controlled by
NEXYRON_FEATURE_SNAPSHOT_CHUNK_PAUSE_MS.
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_build'
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.
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.
- Source-query-backed abstractions enforce stricter subject membership than legacy label-only abstractions. Label-only definitions remain supported, but they do not seed or validate snapshot subjects with the same strength.
- Placeholder-backed feature queries trade more executions for clearer semantics: each feature is calculated for one abstraction subject instead of scanning the full graph and filtering afterward.
- Feature queries should return the supplied runtime subject as
subject_id, usually$subject_id AS subject_idor a carried alias of that value. Returning an optional matched node property or other nullable expression assubject_idmakes the feature contract invalid. - Containment-scoped stage and society features require registered relation contracts. Missing or overly broad relations produce missing-scope dry-run failures or materialized values that reflect the relation contract exactly.
nexyron.snapshot_buildis still a generic Cypher feature-contract executor. The batching defaults reduce overhead for the current materialization path, but they do not make every feature query a GPU kernel. GPU acceleration applies only when a workflow reaches an implemented dense boundary such as vector scoring, feature-matrix scoring, grouped numeric reductions, or projection-based graph analytics.