Abstraction Registry Procedures

Generic Description

Nexyron now exposes a abstraction registry procedure family for several higher-level abstraction and runtime objects:

• abstractions
• features
• interventions
• scenarios
• snapshots
• split policies
• datasets
• models
• policies

The implemented procedures are:

• CALL nexyron.abstraction_register(...)
• CALL nexyron.abstraction_list()
• CALL nexyron.abstraction_read(...)
• CALL nexyron.feature_register(...)
• CALL nexyron.feature_list()
• CALL nexyron.feature_read(...)
• CALL nexyron.intervention_register(...)
• CALL nexyron.intervention_list()
• CALL nexyron.intervention_read(...)
• CALL nexyron.intervention_record(...)
• CALL nexyron.intervention_response_record(...)
• CALL nexyron.scenario_register(...)
• CALL nexyron.scenario_list()
• CALL nexyron.scenario_read(...)
• CALL nexyron.snapshot_register(...)
• CALL nexyron.snapshot_list()
• CALL nexyron.snapshot_read(...)
• CALL nexyron.split_policy_register(...)
• CALL nexyron.split_policy_list()
• CALL nexyron.split_policy_read(...)
• CALL nexyron.dataset_register(...)
• CALL nexyron.dataset_list()
• CALL nexyron.dataset_read(...)
• CALL nexyron.model_register(...)
• CALL nexyron.model_list()
• CALL nexyron.model_read(...)
• CALL nexyron.policy_register(...)
• CALL nexyron.policy_list()
• CALL nexyron.policy_read(...)
• CALL nexyron.snapshot_build(...)
• CALL nexyron.snapshot_materialize(...)
• CALL nexyron.snapshot_materialized_list()
• CALL nexyron.snapshot_materialized_read(...)
• CALL nexyron.snapshot_materialized_drop(...)
• CALL nexyron.snapshot_refresh(...)
• CALL nexyron.dataset_build(...)
• CALL nexyron.dataset_materialize(...)
• CALL nexyron.dataset_materialized_list()
• CALL nexyron.dataset_materialized_read(...)
• CALL nexyron.dataset_materialized_drop(...)
• CALL nexyron.dataset_refresh(...)
• CALL nexyron.abstraction_artifact_status()
• CALL nexyron.abstraction_refresh_stale()
• CALL nexyron.abstraction_task_enqueue_stale()
• CALL nexyron.abstraction_task_list()
• CALL nexyron.abstraction_task_run_once()
• CALL nexyron.abstraction_task_run_all()
• CALL nexyron.abstraction_contract_status()
• CALL nexyron.feature_serve(...)
• CALL nexyron.feature_serve_many(...)
• CALL nexyron.model_score(...)
• CALL nexyron.model_explain(...)
• CALL nexyron.model_evaluate(...)
• CALL nexyron.model_compare(...)
• CALL nexyron.model_calibration_report(...)
• CALL nexyron.model_uncertainty_report(...)
• CALL nexyron.model_threshold_curve(...)
• CALL nexyron.model_gain_table(...)
• CALL nexyron.model_pr_curve(...)
• CALL nexyron.model_roc_curve(...)
• CALL nexyron.model_score_many(...)
• CALL nexyron.model_materialize(...)
• CALL nexyron.model_materialized_list()
• CALL nexyron.model_materialized_read(...)
• CALL nexyron.model_materialized_drop(...)
• CALL nexyron.model_refresh(...)
• CALL nexyron.policy_decide(...)
• CALL nexyron.policy_bandit_decide(...)
• CALL nexyron.policy_evaluate(...)
• CALL nexyron.policy_bandit_evaluate(...)
• CALL nexyron.policy_bandit_offpolicy_report(...)
• CALL nexyron.policy_bandit_subgroup_report(...)
• CALL nexyron.policy_bandit_sensitivity_report(...)
• CALL nexyron.policy_compare(...)
• CALL nexyron.policy_apply(...)
• CALL nexyron.policy_bandit_apply(...)
• CALL nexyron.policy_explain(...)
• CALL nexyron.policy_materialize(...)
• CALL nexyron.policy_materialized_list()
• CALL nexyron.policy_materialized_read(...)
• CALL nexyron.policy_materialized_drop(...)
• CALL nexyron.policy_refresh(...)
• CALL nexyron.policy_dataset_evaluate(...)
• CALL nexyron.policy_uplift_report(...)
• CALL nexyron.policy_offpolicy_report(...)
• CALL nexyron.policy_offpolicy_compare(...)
• CALL nexyron.policy_propensity_report(...)
• CALL nexyron.policy_propensity_overlap_report(...)
• CALL nexyron.policy_propensity_balance_report(...)
• CALL nexyron.policy_doubly_robust_report(...)
• CALL nexyron.policy_causal_diagnostic_report(...)
• CALL nexyron.policy_causal_compare(...)
• CALL nexyron.policy_doubly_robust_compare(...)
• CALL nexyron.policy_causal_value_report(...)
• CALL nexyron.policy_causal_bootstrap_report(...)
• CALL nexyron.policy_causal_score(...)
• CALL nexyron.policy_causal_value_curve(...)
• CALL nexyron.policy_causal_bandit_decide(...)
• CALL nexyron.policy_causal_optimize(...)
• CALL nexyron.policy_causal_gain_table(...)
• CALL nexyron.policy_uplift_compare(...)
• CALL nexyron.policy_dataset_compare(...)
• CALL nexyron.policy_gain_table(...)
• CALL nexyron.scenario_evaluate(...)
• CALL nexyron.abstraction_dependency_graph()

Consumer-Level Explanation

These procedures are the catalog-backed metadata layer for graph-native ML and simulation work.

Where it is logical as schema, Nexyron now also exposes direct Cypher DDL and discovery clauses for the abstraction catalog families:

• CREATE FEATURE ... OPTIONS {...} / SHOW FEATURES
• CREATE INTERVENTION ... OPTIONS {...} / SHOW INTERVENTIONS
• CREATE SCENARIO ... OPTIONS {...} / SHOW SCENARIOS
• CREATE SNAPSHOT ... OPTIONS {...} / SHOW SNAPSHOTS
• CREATE SPLIT POLICY ... OPTIONS {...} / SHOW SPLIT POLICIES
• CREATE DATASET ... OPTIONS {...} / SHOW DATASETS
• CREATE MODEL ... OPTIONS {...} / SHOW MODELS
• CREATE POLICY ... OPTIONS {...} / SHOW POLICIES

The procedures remain the operational surface for build, materialize, serve, score, decide, apply, and evaluation work.

Use them when you want to define:

• which model-ready features exist
• which intervention types exist
• which hypothetical scenarios exist
• which point-in-time snapshot surfaces exist
• which train/validation/test split rules exist
• which named dataset contracts exist
• which native model contracts exist
• which intervention selection policies exist
• and now separate executable dataset label and dataset filter contracts from descriptive dataset metadata
• how scenario overlays should be described without mutating base graph data
• and now build logical snapshot, dataset, or scored model rows directly from registered contracts

They are not the final scoring or simulation runtime yet. They are the first-class registry that later runtime layers can consume.

Conceptual Explanation

This procedure family connects several Nexyron surfaces:

• graph labels and node identity stay in the normal LPG model
• time-varying state still lives in temporal properties
• richer registry payloads use document-style maps and lists in Cypher
• scenarios store sparse overlay operations instead of whole graph copies

That split is important.

The current implementation deliberately does not pretend that a scenario registry entry is already an executed projection or a causal effect model. It stores:

• abstraction definition
• typed metadata
• sparse overlay intent
• snapshot assembly intent
• split, dataset, model, and policy intent

On top of that registry layer, Nexyron now supports two executable procedures:

• snapshot_build: executes the registered feature queries for one snapshot definition and returns rows shaped as subject_id, optional snapshot_ts, and a features map
• dataset_build: builds the snapshot rows, applies an optional split policy, and returns subject_id, optional snapshot_ts, split, label_name, label_value, and features
• dataset_build can now also apply:
  • label_query: an explicit Cypher query returning subject_id and value
  • filter_query: an explicit Cypher query returning subject_id

The executable builders also now accept optional at and system_at timestamps in epoch milliseconds. Inside registered feature, label, and filter queries, the current implementation exposes exact textual placeholders:

• $snapshot_at_ms
• $snapshot_at_datetime
• $snapshot_system_at_ms
• $snapshot_system_at_datetime
• $snapshot_name
• $dataset_name
• $scenario_name

If at is provided and a feature query does not return snapshot_ts itself, the built row is still anchored to that requested time. system_at is currently a shared dual-time execution context and placeholder surface, not a full engine-enforced bitemporal join planner.

And four operational materialization families:

• snapshot_materialize plus snapshot_materialized_list/read/drop: builds a snapshot contract once, stores feature values as per-feature temporal streams keyed by (timestamp, subject_id, value), reconstructs grouped snapshot rows for compatibility reads, persists them through database snapshot export/import and file-backed reopen, and lets later calls read or clean up those materialized stream points without recomputing features immediately
• dataset_materialize plus dataset_materialized_list/read/drop: does the same for dataset rows after split and label assignment
• model_materialize plus model_materialized_list/read/drop: scores every row from one registered model contract, stores the result as a abstraction artifact, and lets later calls reuse or inspect that scored output without rebuilding it immediately
• policy_materialize plus policy_materialized_list/read/drop: evaluates one registered policy contract, stores the selected intervention targets as a abstraction artifact, and lets later calls reuse or inspect that decision output without recomputing it immediately
• all list procedures now also expose requested_at_ms, requested_system_at_ms, and refresh_required
• all artifact families can now be recomputed in place with snapshot_refresh, dataset_refresh, model_refresh, and policy_refresh
• feature_history: reads the canonical feature stream directly when callers need all values for one feature over a time range

There is also now a direct serving procedure:

• feature_serve: resolve one snapshot contract for one subject_id, optionally reuse matching materialized feature streams, and return the served feature map plus whether the result was materialized or computed
• feature_serve_many: do the same for an explicit list of subject_id values in one call
• model_score: score one subject from a registered model contract, preferring a matching materialized model artifact first, then a matching materialized snapshot, then on-demand snapshot computation
• model_explain: explain one subject score from a registered model contract by returning the exact resolved feature values and weighted per-feature contribution map used to produce the score
• model_evaluate: evaluate one registered model against a labeled abstraction dataset and return aggregate classification metrics such as accuracy, precision, recall, F1, and ROC AUC
• model_compare: compare two registered models on the same labeled abstraction dataset and threshold, returning side-by-side aggregate quality metrics
• model_calibration_report: report probability-quality metrics for one registered model on a labeled abstraction dataset, including Brier score, log loss, expected calibration error, and maximum calibration error
• model_uncertainty_report: report aggregate uncertainty behavior for one registered model on a labeled abstraction dataset, including average uncertainty, maximum uncertainty, and high-uncertainty rate
• model_threshold_curve: evaluate one registered model across multiple operating thresholds on a labeled abstraction dataset and return one row per threshold
• model_gain_table: build a rank-based gain table for one registered model on a labeled abstraction dataset and return one row per ranked bucket
• model_pr_curve: evaluate one registered model across multiple thresholds and return one precision/recall point per threshold
• model_roc_curve: evaluate one registered model across multiple thresholds and return one ROC point per threshold
• model_score_many: do the same for an explicit list of subject_id values in one call
• policy_decide: evaluate one registered policy contract, optionally reusing a matching materialized policy artifact first, then deriving ranked intervention targets from the policy’s bound model contract
• policy_bandit_decide: evaluate one multi-arm policy contract by choosing a concrete arm per subject with epsilon-greedy, LinUCB, or Thompson-style contextual exploration on top of the current model score and logged reward history
• policy_evaluate: summarize what has actually been observed for one policy by reading the intervention events and linked responses already recorded in the graph
• policy_bandit_evaluate: summarize one bandit policy's applied arms and realized feedback from the existing intervention-event and response graph path
• policy_bandit_offpolicy_report: estimate one current bandit policy from logged intervention events with IPS, SNIPS, and doubly robust reward estimates
• policy_bandit_subgroup_report: summarize logged bandit outcomes by subgroup through a Cypher query that maps subject_id values to group labels
• policy_bandit_sensitivity_report: sweep propensity clipping bounds for one logged bandit policy and show how IPS, SNIPS, and doubly robust values move under different clipping assumptions
• policy_dataset_evaluate: evaluate one registered policy against a labeled abstraction dataset using the policy’s current selection contract
• policy_uplift_report: build an observational treated-versus-control summary for one registered policy on a labeled abstraction dataset
• policy_offpolicy_report: build an inverse-propensity-weighted off-policy summary for one registered policy on a labeled abstraction dataset using an explicit propensity query
• policy_offpolicy_compare: compare two registered policies on the same labeled abstraction dataset using the same inverse-propensity-weighted off-policy contract
• policy_propensity_report: learn treatment propensities automatically from the current policy selections on a labeled abstraction dataset and summarize the learned propensity model
• policy_propensity_overlap_report: diagnose common support, extreme propensities, and effective sample size from the native learned propensity model
• policy_propensity_balance_report: show pre-weighting and propensity-weighted covariate balance over numeric snapshot features for one policy
• policy_doubly_robust_report: learn propensities and treated/control outcome models automatically and return doubly robust treatment-effect estimates
• policy_causal_diagnostic_report: summarize overlap, balance, and effect-estimation quality for one causal policy contract in one row
• policy_causal_compare: compare two current policy contracts by the learned treatment effects of the subjects each one would currently select
• policy_doubly_robust_compare: compare two policies on the same labeled abstraction dataset using the native learned doubly robust path
• policy_causal_value_report: summarize the current causal value of one policy after ranking by learned treatment effect and applying the current action budget, optionally with t_learner or x_learner
• policy_causal_bootstrap_report: estimate bootstrap uncertainty over the selected set's cumulative learned uplift for one policy
• policy_causal_score: return subject-level learned treatment-effect estimates for one policy on a labeled abstraction dataset, optionally with t_learner or x_learner
• policy_causal_value_curve: build a budget-by-budget causal value frontier over the learned treatment-effect ranking, optionally with t_learner or x_learner
• policy_causal_bandit_decide: choose intervention targets from the learned causal ranking with a lightweight exploration component
• policy_causal_optimize: optimize one policy on a labeled abstraction dataset by ranking eligible subjects by learned treatment effect instead of the current direct score, optionally with t_learner or x_learner
• policy_causal_gain_table: build ranked causal buckets over learned treatment effects so the optimizer can be inspected as a treatment-effect capture curve instead of only a selected-subject list, optionally with t_learner or x_learner
• policy_uplift_compare: compare two registered policies on the same labeled abstraction dataset by their observational treated-versus-control uplift summaries
• policy_compare: compare two registered policies over both their current selected target sets and their observed response summaries
• policy_dataset_compare: compare two registered policies on the same labeled abstraction dataset using their current selection contracts
• policy_gain_table: build a rank-based gain table for one registered policy on a labeled abstraction dataset using the policy’s current decision contract
• policy_apply: turn the currently selected policy targets into observed intervention events in the graph using the policy’s bound intervention contract
• policy_bandit_apply: turn the selected multi-arm bandit targets into observed intervention events while logging chosen-arm and exploration metadata in the existing payload field
• policy_explain: explain why one subject was or was not selected by a policy right now, including subject-query matching, threshold pass/fail, rank position, and cutoff status

And two package-level operational procedures:

• abstraction_artifact_status: list every materialized snapshot, dataset, model, and policy artifact with freshness metadata
• abstraction_refresh_stale: refresh every stale materialized artifact in dependency order, snapshots first, datasets after, models after their upstream snapshot inputs are current, and policies after their upstream model inputs are current
• abstraction_task_enqueue_stale: queue stale artifacts for later execution instead of refreshing them immediately
• abstraction_task_list: inspect the pending abstraction refresh queue
• abstraction_task_run_once: execute one queued refresh task deterministically through the normal snapshot or dataset rebuild path
• abstraction_task_run_all: drain the whole queued refresh backlog in one call
• abstraction_contract_status: summarize snapshot, dataset, model, and policy contract readiness, materialization coverage, staleness, and queued work in one result set
• abstraction_dependency_graph: inspect the current dependency edges from features to snapshots, snapshots to datasets, snapshots to models, models to policies, and live materialized artifacts back to their source contracts

In the current engine runtime, queued abstraction refresh work is also drained automatically before ordinary top-level Cypher queries. Semantic maintenance and introspection procedures themselves remain explicit, so abstraction_task_*, abstraction_contract_status, abstraction_artifact_status, and similar inspection calls do not silently consume the queue.

It also now supports:

• intervention_record: writes one observed intervention event into the graph and links it to a target node when the target abstraction resolves to a backing label
• intervention_response_record: writes one observed response event attached to an earlier intervention event and links it back to the same target when the abstraction resolves cleanly
• scenario_evaluate: builds a baseline snapshot, rebuilds it with a named scenario overlay, and returns the changed fields for each subject
• optional cascade_refresh on feature_register, snapshot_register, dataset_register, model_register, and policy_register so contract changes can immediately rebuild already materialized dependent artifacts

Feature lifecycle status updates are metadata-only. Use abstraction_task_enqueue_stale, abstraction_refresh_stale, or an explicit materialize/refresh procedure when the intended action is to recompute artifacts.

That keeps the abstraction clean for later effect recomputation and policy evaluation.

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, description
WHERE name STARTS WITH 'nexyron.feature_'
   OR name STARTS WITH 'nexyron.snapshot_'
   OR name STARTS WITH 'nexyron.dataset_'
   OR name STARTS WITH 'nexyron.model_'
   OR name STARTS WITH 'nexyron.policy_'
RETURN name, description
ORDER BY name

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Real Use Cases

• Registering reusable feature definitions without hardcoding feature metadata in notebooks or service code.
• Declaring intervention types separately from observed intervention events so policy design stays inspectable.
• Storing hypothetical scenario overlays as sparse operations instead of full graph projections.
• Defining named point-in-time snapshot contracts before building actual materialization workers.
• Defining split policies and datasets in the same catalog as features and scenarios so training surfaces are inspectable from Cypher.
• Keeping business-facing dataset descriptions in filter while putting executable subject selection into filter_query.
• Joining labels from an explicit label_query when the label is not already present as a feature in the snapshot.
• Building lightweight logical snapshots on demand from feature queries without exporting the whole graph into a separate ML system first.
• Binding one explicit as-of moment into feature, label, and filter queries so point-in-time dataset assembly does not rely on each query inventing its own time anchor.
• Binding both business-time at and system-time system_at into feature, label, and filter queries when you need one shared dual-time evaluation context without forking query definitions.
• Materializing one scenario-adjusted snapshot or dataset and re-reading it several times during validation, debugging, or human review without paying the query cost each time.
• Serving one actor’s current or as-of feature map directly from Cypher without building a whole training dataset first.
• Serving a bounded batch of actor feature maps from one shared snapshot contract without materializing a whole dataset.
• Registering a lightweight native scoring model directly in Nexyron when the runtime you need is a transparent weighted feature model rather than an external model service.
• Materializing scored outputs for one model contract when product, analytics, or intervention workflows need a stable predicted view to inspect repeatedly.
• Refreshing model artifacts after snapshot or model changes so decisioning and review surfaces stay aligned with the registered abstraction contract.
• Defining a native policy contract that ties a scored model surface to an intervention type so operational action selection stays queryable and versioned in the same abstraction catalog.
• Materializing a ranked intervention target list for one policy when operators or downstream systems need a stable decision artifact rather than recomputing selection every time.
• Applying one policy directly from Cypher when you want Nexyron to both choose the targets and record the resulting observed intervention events in one runtime path.
• Summarizing observed response rates and delays for one policy directly from Cypher when you want a contract-level operational view without writing a custom join over events and responses.
• Comparing two policy contracts directly from Cypher when you want to inspect target overlap and observed response-rate differences before changing strategy.
• Recording one observed response event directly against a prior intervention when you need the semantic runtime to retain the post-action reaction loop in graph form.
• Detecting stale materialized artifacts after a feature definition version changes and refreshing only the affected abstraction artifact instead of rediscovering the contract manually.
• Operating the whole semantic package as one managed surface by listing all materialized artifacts and bulk-refreshing the stale ones after contract changes.
• Separating stale-artifact detection from refresh execution when you want a deterministic queue to inspect or drain gradually instead of refreshing everything immediately.
• Draining a queued abstraction refresh backlog in one explicit operational step after reviewing what will be rebuilt.
• Letting ordinary Cypher workloads keep abstraction materializations fresh over time without forcing every caller to remember to run the queue manually.
• Checking whether a snapshot or dataset is merely defined, currently ready, or blocked on stale or queued artifact refresh without manually joining several procedure outputs.
• Propagating a contract change immediately into materialized dependents when you know the mutation should rebuild them now instead of waiting for a later maintenance step.
• Inspecting the current abstraction dependency chain directly from Cypher before deciding which contracts or artifacts to rebuild.
• Applying supported sparse scenario overrides such as override_feature and inject_intervention_exposure at snapshot-build time.
• Recording observed intervention events as graph data while keeping hypothetical interventions in the scenario layer.
• Comparing baseline and scenario-applied feature states directly from Cypher before deciding whether to operationalize a policy.
• Building a abstraction contract that future snapshot builders or simulators can read from one shared catalog.

Real Limitations And Tradeoffs

• The current executable layer is still logical and query-driven, not a persisted offline feature store with freshness workers or online serving caches.
• Materialized snapshot and dataset rows now persist through Nexyron database snapshot export/import and normal file-backed reopen because they are stored in the engine snapshot schema, but they are still not independently managed offline feature tables with freshness workers.
• label_query and filter_query currently join by subject_id, with optional snapshot_ts support when the query returns it. They do not yet perform broader temporal interval joins or leakage checks on your behalf.
• The current point-in-time placeholder contract is explicit but still textual. It is good enough to bind one shared timestamp into registered queries, but it is not yet the same thing as a full engine-enforced PIT optimizer or bitemporal join planner.
• system_at currently gives you a shared dual-time execution context and artifact keying surface. It does not yet enforce valid-time versus system-time reconstruction inside arbitrary query logic unless the registered queries honor that contract.
• feature_serve currently resolves through snapshot contracts and optional materialized snapshots. It is not yet a separate low-latency online KV plane with freshness SLAs, skew checks, or distributed serving guarantees.
• model_explain is exact for the current weighted linear/logistic native model family because it reuses the same snapshot row and weight map as the scorer. It is not yet a generic explanation surface for arbitrary external models or nonlinear learned interactions.
• model_evaluate currently assumes a binary label interpretation for aggregate metrics. It is useful for contract-bound classification evaluation, but it is not yet a multiclass evaluator, ranking evaluator, or survival-analysis metric surface.
• model_compare compares aggregate dataset metrics under one threshold and one dataset contract. It is not yet a full model registry governance surface, statistical significance evaluator, drift monitor, or champion-challenger scheduler.
• model_calibration_report is a contract-bound binary probability quality report. It is useful for checking whether emitted probabilities behave like probabilities, but it is not yet a full calibration workflow with per-bin row outputs, recalibration fitting, conformal guarantees, or drift-aware monitoring.
• model_uncertainty_report only reports over the uncertainty values emitted by the current native scorer. It does not yet validate whether those values are statistically correct, calibrated as confidence estimates, or decision-theoretically optimal.
• model_threshold_curve is a threshold-sweep evaluation helper for one fixed dataset contract. It does not yet optimize thresholds under business constraints, costs, capacity limits, or treatment effects.
• model_gain_table is a rank-bucket analysis surface for one fixed scored dataset. It is useful for prioritization analysis, but it is not yet a treatment-yield model, uplift table, or constrained-action optimizer.
• model_pr_curve is a threshold-driven classification tradeoff surface. It is useful for understanding positive-class selection behavior, but it is not yet an average-precision summary, cost-sensitive optimizer, or capacity-aware action planner.
• model_roc_curve is a threshold-driven discrimination surface. It is useful for visualizing true-positive versus false-positive tradeoffs, but it is not yet a cost-weighted frontier, fairness-aware threshold planner, or operating-point optimizer.
• feature_serve_many is a bounded batch convenience surface over the same snapshot contract. It is not yet a dedicated vectorized serving runtime or a transport-level bulk API.
• The current native model runtime is intentionally narrow. It supports contract-bound weighted linear or logistic scoring, optional simple calibration, and simple uncertainty modes. It is not yet a native survival, sequence, graph-ML, or uplift serving stack.
• Materialized model artifacts are refreshed through the same abstraction artifact pipeline as snapshots and datasets. They are abstraction runtime artifacts, not a separate model deployment system or continuously managed serving tier.
• The current policy runtime is a ranking-and-threshold layer over the native model contract. It supports eligibility filtering, score thresholds, ordering, and action caps, but it is not yet a causal uplift optimizer, bandit runtime, or capacity-aware policy-learning engine.
• policy_bandit_decide and policy_bandit_apply extend that current policy layer into a lightweight contextual-bandit baseline by choosing among configured arms with epsilon-greedy, LinUCB, or Thompson-style exploration on top of one existing model score and the logged reward history already present in the graph. That is useful for multi-action experimentation without introducing a separate bandit store, but it is still a lightweight in-engine learner rather than a full online contextual-bandit training system.
• policy_bandit_evaluate reads realized feedback from the existing intervention/response graph path and the standard payload fields logged by policy_bandit_apply. It is useful for operational bandit summaries, but it assumes the logged payload contract is respected.
• policy_bandit_offpolicy_report lifts that same logged-event path into IPS, SNIPS, and doubly robust evaluation for the current bandit contract. It is useful for replay-style policy checking, but it still depends on the logged chosen-action propensity field and the current lightweight reward learner.
• policy_bandit_subgroup_report and policy_bandit_sensitivity_report make the current bandit layer more diagnosable without changing the architecture. They are useful for fairness, stability, and clipping diagnostics, but they are still contract-driven reports, not a full research framework.
• policy_apply records observed intervention events through the existing intervention-event shape. It does not yet handle downstream delivery guarantees, retries, external channel acknowledgements, or response tracking on its own.
• policy_explain is an operational explanation surface over the current policy contract and current scored rows. It explains the policy selection path, but it is not yet a causal or counterfactual explanation system.
• policy_evaluate is observational summary logic over recorded events and responses. It is useful for contract-level monitoring, but it is not yet causal attribution, counterfactual evaluation, or off-policy estimation.
• policy_dataset_evaluate and policy_dataset_compare evaluate current policy selections against labeled abstraction datasets. They are useful for checking how current targeting rules line up with known outcomes, but they are not yet uplift evaluation, treatment-effect estimation, or constrained action optimization.
• policy_uplift_report is an observational uplift-style surface over selected versus non-selected rows in one labeled abstraction dataset. It is useful for getting an immediate treated-versus-control proxy from the current policy contract, but it is not randomized evidence, not deconfounded causal estimation, and not a substitute for proper uplift modeling.
• policy_offpolicy_report is a stronger but still contract-driven surface. It applies inverse-propensity weighting to the selected versus non-selected outcome rates using an explicit user-provided propensity query. That makes it useful for basic off-policy estimation experiments, but it still depends entirely on the quality of the supplied propensities and is not yet doubly robust estimation, automated propensity learning, or full causal identification.
• policy_offpolicy_compare compares two inverse-propensity-weighted summaries side by side under the same user-supplied propensity contract. It is useful for comparing current policy contracts under one explicit off-policy assumption set, but it still depends on that supplied propensity model and is not yet doubly robust comparison, automated policy value learning, or constrained policy optimization.
• policy_propensity_report is the first native automated propensity-learning surface in Nexyron. It learns one simple binary treatment model directly from the current policy selections and the snapshot features inside the chosen dataset. That is useful as an engine-native baseline, but it is still a lightweight learned propensity model rather than a dedicated treatment-assignment modeling stack.
• policy_propensity_overlap_report extends that native propensity path into common-support diagnostics. It is useful when you need to see whether the learned treatment model is collapsing toward extreme assignment probabilities or leaving too little effective sample size for stable weighting, but it is still only as good as the same lightweight internal propensity learner.
• policy_propensity_balance_report adds a second causal-diagnostic layer on top of the learned propensity path. It shows how far treated and control groups differ on numeric snapshot features before weighting and after inverse-propensity weighting, which is useful for checking whether the learned weighting actually improves balance. It is still a lightweight internal balance report, not a full causal-diagnostic suite.
• policy_doubly_robust_report is the first native doubly robust surface in Nexyron. It automatically learns a simple propensity model and simple treated/control outcome models from the abstraction dataset, then combines them into a doubly robust estimate. That is meaningfully stronger than the purely observational and purely IPW-only reports, but it is still a lightweight engine-native estimator rather than a full causal-inference framework.
• policy_causal_diagnostic_report is the Phase A umbrella summary for the learned causal path. It combines overlap counts, worst-case unweighted and weighted balance, and the current doubly robust/plugin/IPW estimates in one row, which is useful for a fast contract-level check before you trust a causal ranking. It still depends on the same internal learners and should be treated as a compact operational diagnostic, not a research audit.
• policy_causal_compare moves the native causal layer from row-level scoring into current-policy comparison. It is useful when you want to compare the learned treatment-effect profile of the subjects each policy would select right now, but it still compares policies through the same internal treatment-effect estimates rather than through randomized or fully deconfounded evidence.
• policy_doubly_robust_compare extends that same learned DR path into direct policy-versus-policy comparison. It is useful when you want one native comparative effect estimate without supplying an external propensity query, but it is still constrained by the same lightweight internal learners and should be treated as comparative estimation, not a full benchmark suite.
• policy_causal_value_report summarizes one current causal policy under its chosen action budget. It is useful when you want a direct estimate of the selected set’s average and cumulative estimated uplift instead of only a row list. The current runtime supports both t_learner and x_learner, which is useful for checking whether the ranking is stable across simple heterogeneous-treatment learners, but the estimate is still model-based rather than experimentally validated.
• policy_causal_bootstrap_report adds a compact uncertainty layer on top of the same causal ranking. It repeatedly resamples the dataset rows inside the engine and reports mean, spread, and percentile bands for cumulative selected uplift. That is useful for seeing whether the estimated value is brittle, but it is still a deterministic internal bootstrap baseline rather than a full research resampling framework.
• policy_causal_score is the first subject-level heterogeneous treatment-effect serving surface in Nexyron. It makes the learned causal layer directly inspectable row by row, which is useful for debugging and triaging the optimizer. The current runtime supports both t_learner and x_learner, but the returned treatment effects are still lightweight internal estimates rather than production-grade individualized treatment models.
• policy_causal_value_curve adds a budget frontier on top of that same learned ranking. It is useful when you need to inspect how estimated causal value changes as action capacity grows. The current runtime supports both t_learner and x_learner, but it is still a model-based frontier rather than an experimentally validated budget curve.
• policy_causal_bandit_decide adds a lightweight exploration mechanism on top of the learned treatment-effect ranking. That makes it the first bandit-like action-selection surface in Nexyron, but it is still a simple internal exploration baseline rather than a full contextual-bandit learning system.
• policy_causal_optimize is the first native causal policy optimizer in Nexyron. It ranks eligible subjects by learned treatment effect instead of the current direct score contract, which makes it a real causal optimization path rather than only a score-threshold policy. It now also supports optional overlap trimming and the same t_learner / x_learner choice as the other Phase A causal surfaces, but it still uses lightweight learned models and a labeled abstraction dataset, so it should be treated as an internal causal optimization baseline rather than a final production policy-learning stack.
• policy_causal_gain_table gives the optimizer a ranked treatment-effect inspection surface similar to a gain table, but over estimated causal uplift instead of plain prediction score. It is useful for checking whether estimated uplift is concentrated in the top buckets, and it can now follow both the optional overlap band and the current t_learner / x_learner choice, but it is still derived from the same internal treatment-effect estimates and is not a substitute for randomized policy validation.
• policy_uplift_compare compares two observational uplift-style summaries side by side on the same labeled abstraction dataset. It is useful for checking which current policy contract produces the stronger treated-versus-control proxy under the same dataset assumptions, but it is still not causal identification, inverse-propensity estimation, doubly robust off-policy evaluation, or uplift model training.
• policy_gain_table is a rank-bucket prioritization surface for one current policy contract on one labeled dataset. It is useful for understanding how much observed positive yield the top-ranked policy buckets capture, but it is not yet uplift ranking, treatment-yield estimation, or action-capacity optimization.
• policy_compare is a structural and observational comparison surface. It compares selected-subject overlap and observed summary rates, but it is not yet a true policy simulator, uplift estimator, or causal A/B evaluator.
• intervention_response_record records the observed response structure, but it does not yet implement higher-level attribution, causal lift estimation, or automated state-transition learning from those responses.
• refresh_required currently tracks snapshot feature-version changes, and for datasets it also tracks key dataset contract fields such as label_query, filter_query, and split_policy. It is useful provenance, but it is not yet a full dependency graph or scheduler.
• abstraction_dependency_graph shows the current contract and artifact edges, but it is still an introspection surface, not a background refresh scheduler or a full cost-based dependency planner.
• The abstraction task queue is durable catalog state and now also has an engine-owned background worker that drains queued refresh tasks without requiring a foreground query. The procedures are still useful for deterministic inspection and forcing immediate execution, but this is not yet a cost-based scheduler or a distributed refresh service.
• abstraction_contract_status is a high-level operational summary, not a replacement for the lower-level artifact list, dependency graph, or row-level serving and build procedures.
• Point-in-time validation is now stricter for executable feature, label, and filter queries: rows with snapshot_ts or system_snapshot_ts beyond the requested at or system_at fail loudly. That is useful leakage protection, but it still depends on the query emitting those anchors when relevant.
• Observed intervention events are still something you should model in normal graph and temporal data. The registry does not replace event storage.
• Scenario overlays are stored as sparse patch intent, not as materialized projected graphs. The current executable support only applies safe row-level feature overrides during snapshot build and evaluation.
• Snapshot, dataset, model, and policy definitions are still contracts plus on-demand builders, not finished offline-training jobs, full model-training orchestration, advanced inference services, or causal intervention learning.