---
title: `nexyron.snapshot_build`
url: https://nexyron.tech/docs/cypher/procedures/abstraction-platform/runtime/nexyron-snapshot-build
description: nexyron.snapshot build builds one logical feature snapshot from registered feature definitions.
---

# `nexyron.snapshot_build`

## Generic Description

`nexyron.snapshot_build` builds one logical feature snapshot from registered feature definitions.

```cypher
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_id`
-   `snapshot_ts`
-   `features`

## 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

```cypher
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_id` or a carried alias of that value. Returning an optional matched node property or other nullable expression as `subject_id` makes 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_build` is 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.