`nexyron.feature_serve`

Generic Description

nexyron.feature_serve serve one subject feature map from a snapshot contract, optionally reusing a matching materialized snapshot

CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.feature_serve'
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

This procedure belongs to the model and feature-serving runtime. Use it when you need feature resolution, scoring, explanation, evaluation, or model-quality analysis from already registered abstraction contracts.

Parameters

• snapshot: Snapshot definition name Required.
• subject_id: Requested subject identifier 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.
• prefer_materialized: When true, reuse a matching materialized snapshot before computing on demand Optional.

Output Columns

• subject_id
• snapshot_ts
• features
• 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_serve(...) 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.feature_serve is that it serves a snapshot-level feature map. Snapshot building now uses source-query-backed abstraction definitions to seed and validate subject rows when the snapshot declares subject_abstraction.

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

Real Use Cases

• Register reusable member-retention contracts once, then let snapshots, datasets, models, and policies reference those names instead of duplicating raw Cypher in every workflow.
• Keep admin and product teams aligned around one shared abstraction contract for members, households, facilities, interventions, and churn labels during quarterly retraining cycles.

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.
• Use nexyron.feature_get when you need one raw feature value. Use nexyron.feature_serve when you need the feature map defined by a snapshot.