---
title: `nexyron.feature_get`
url: https://nexyron.tech/docs/cypher/procedures/abstraction-platform/registry/nexyron-feature-get
description: nexyron.feature get computes one registered feature for one abstraction subject.
---

# `nexyron.feature_get`

## Generic Description

`nexyron.feature_get` computes one registered feature for one abstraction subject.

```cypher
CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.feature_get'
RETURN name, description, parameters, output_columns
```

Abstraction-platform registry procedures create, list, read, and inspect named contracts such as abstractions, features, datasets, snapshots, models, policies, interventions, scenarios, and split policies.

## Consumer-Level Explanation

Use this when you want one raw feature value without building an entire snapshot contract. The procedure reads the feature definition, resolves the requested subject through the feature's abstraction, substitutes that subject into `$subject_id` and related feature placeholders, runs the feature query, and returns the matching `value`.

For whole feature maps, use `nexyron.feature_serve` with a snapshot. For a single definition-level value, use `nexyron.feature_get`.

## Parameters

-   `feature`: Feature definition name. Required.
-   `subject_id`: Requested subject identifier. Required.
-   `at`: Optional as-of timestamp in epoch milliseconds.
-   `system_at`: Optional system-time cutoff in epoch milliseconds.

## Output Columns

-   `subject_id`
-   `snapshot_ts`
-   `feature`
-   `value`
-   `source`

## 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.feature_get(...)` 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

Feature definitions remain Cypher contracts that return `subject_id` and `value`. The difference is that the owning abstraction now supplies the subject. A modern feature query calculates one value for one runtime subject by using `$subject_id` as its only runtime input.

This keeps the platform aligned around one subject identity: abstractions define who or what belongs to a semantic set, features compute values for those subjects, and snapshots record feature maps at a time grain.

The health and dry-run path follows the same model at small scale. For each abstraction, it samples up to ten abstraction subjects and calculates placeholder-backed features for those sampled subjects. The check validates that the feature can run with real subject parameters and that returned rows still belong to the sampled abstraction members.

## 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.feature_get'
RETURN name,
       [p IN parameters | p.name] AS parameter_names,
       output_columns
ORDER BY name
```

## Real Use Cases

-   Debug one member's feature value before materializing a larger snapshot.
-   Validate that a newly generated feature aligns with its abstraction source set.
-   Compute an on-demand feature value for a model explanation or policy decision path.
-   inspect or operate named abstraction contracts without reconstructing hidden prompt context in the frontend
-   keep feature, dataset, snapshot, model, policy, and artifact workflows on the backend contract path

## Real Limitations And Tradeoffs

-   `feature_get` first reads the stream-backed materialized value for the requested feature and subject when one exists at or before `at`; otherwise it executes the registered feature query for that one subject.
-   Membership validation only has teeth when the abstraction has a real `source_query`. Label-only abstractions still work, but they do not define the stricter virtual subject set.
-   Feature queries must still return `subject_id` and `value`. For already materialized values, parser-native selector reads such as `actor(Member:'member-102').subscription_package` use the feature stream directly and behave like latest-as-of temporal property access.
-   Legacy all-subject feature queries still work, but generated features should use runtime subject placeholders so `feature_get` does not have to scan the full dataset to answer one subject.
-   Dry-run sampling is a contract check, not a full snapshot. It validates a bounded set of sampled subjects before broader materialization.