`nexyron.feature_get`

Generic Description

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

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

Output Columns

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

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

Real Limitations And Tradeoffs