Roadmap Ideas

Extend required-field validation to support conditions: a field is required only when another field has a specific value. Example: ModelNumber required only when StickBuilt = True.

Currently, allowBlank=False in Access is unconditional. The VBA pmgOOProperty.canBeEmpty already carries conditional logic in some classes — the migration script should capture and preserve it.

The VBA system supports 7 rule types: direct_source, fixed_value, conditional, lookup, formula, aggregation, RegExReplace. Nexus currently handles formula and basic conditional.

A type extension framework would allow registering new rule type handlers as plugins without modifying the engine core. Each type handler = a Python class implementing RuleTypeHandler.evaluate(entity, rule, context) -> value.

CN3710246 _tbl_sys_precedence_rules contains 638 consolidation resolution rows (Lookup, Seek, formula, RegExReplace). These are not validation rules — they determine the authoritative value of a property when multiple sources disagree.

Currently out of scope for EXP-1 (which focuses on required-field validation only). A consolidation phase following validation would ingest these 638 rules and resolve multi-source conflicts per entity per property.

Extend DynamicRuleEngine to emit a structured execution trace per run: which rules fired, which were skipped (and why), execution time per rule, output delta vs. previous run, entity-level violation detail.

Store traces in _tbl_rule_executions. Expose via GET /executions/{id} and GET /executions/{id}/diff/{prev_id}. Enables regression detection and client-facing auditability reports.

Each profile declares the minimum rule execution engine version it requires. Attempting to run a profile against an incompatible engine version raises a hard error before execution begins. Prevents silent rule misinterpretation when engine semantics change between versions.

Field: _tbl_calcrule_profiles.min_ree_version (string, semver). Engine startup validates all active profiles against current version.

POST /execute?dry_run=true returns which rules would fire and against what inputs, without committing output or writing quality tiers. Returns the full execution plan as structured JSON.

Reduces UAT friction: domain experts can review the planned rule application before committing. Pairs with the execution telemetry endpoint for before/after comparison.

GET /profiles/{id}/diff/{v1}/{v2} returns changed rules between two profile versions: rules added, rules removed, rules modified (with old and new formula side by side). Required for client auditability and change management.

cuGraph v3.0 supports property graphs natively. The DeltaPrism adapter already translates EDR output into a property graph structure. Wiring cuGraph as the graph backend would enable GPU-accelerated connected component analysis, centrality scoring, and cross-class entity relationship queries at 10-100x pandas speed.

Most valuable for large datasets: >50,000 entities where pandas graph operations become the bottleneck.

Benchmark suite comparing pandas vs cuDF rule execution at 2,133, 10,000, 50,000, and 200,000 entity counts. Validates the GPU speedup claim and identifies the crossover point where GPU becomes faster than CPU (expected ~5,000 entities for simple rules, ~1,000 for complex multi-join lookups).

Required for go/no-go decision on GPU as production runtime vs. development-only feature.

GPUEntityLoader currently reads a single Access DB. Extend to read multiple source DBs in parallel (async pyodbc) and merge into a single cuDF DataFrame before rule execution. Enables multi-site projects where entities are split across multiple Access files.

CLI tool: given an Access .accdb path, outputs a full schema report: table names, column names + types, row counts, and detected Nexus-compatible patterns (consolidation properties table, precedence rules table, FACT table prefix).

Enables onboarding a new Access-based project without manual schema discovery. Output format: JSON + HTML report (same brand). Command: python -m nexus.connectors.access_inspector {db_path}.

Script scripts/migrate_edr_rules_from_access.py reads _tbl_sys_consolidation_properties (allowBlank=False, isActive=True rows) and generates Nexus rule JSON: formula = required-field check, applies_to_classes from className, priority from orderWeight.

Seeds 409 real rules into edr-entity-validation profile. Resolves ISSUE-006 (19 synthetic rules). This is an EXP-1 deliverable, not a future idea — recording here for traceability.

Expose Nexus EDR validation results as a Nexus data feed: quality tier per entity, violation count, completeness score. Nexus consumes via webhook or polling endpoint. Enables pipeline health monitoring from the Nexus operations dashboard without a separate EDR dashboard build.

SQLite is the current default for local development. PostgreSQL is the production database. Running dev on PostgreSQL (via Docker Compose) closes the dev/prod schema drift risk. Docker Compose config already exists (docker-compose.postgres.yml) but is not the default. Make it the default for dev.

Audit all public-facing API symbols. Identify what is stable (will not break between minor versions) vs internal (no compatibility guarantee). Write a deprecation policy. Tag v1.0.0-rc1. This is the prerequisite for the PyPI package split.

Separate nexus-core (engine, Excel/JSON connectors, TCO example, public API) from commercial extras (Access connector, SQL Server/Oracle, Databricks, Snowflake runtimes, Flask admin). Core goes to PyPI. Extras ship via licence key + private registry. Split in pyproject.toml optional-dependencies.

ConsolidationEngine.resolve(entities) using DeltaPrism property graph. Deduplicates instruments and equipment across Access, SQL Server, and Excel extracts. Conflict resolution uses _tbl_sys_precedence_rules (638 rows in CN3710246). Exposes POST /consolidate. Core Oil & Gas value proposition.

The Flask admin panel currently shows TCO and PFP pipelines. Wire the EDR domain: run pipeline button triggers Access → validate → write-back. Quality tier distribution shown as a bar chart. Violation drilldown per entity class. No new UI framework — extend existing Jinja2 templates.

The EDRv6 VBA documentation contains Rule_Language_Spec_Card.md which is only a content outline with no actual spec. A formal spec for the Nexus rule language is required for: (a) client documentation, (b) rule editor validation, (c) IDE plugin support showing available functions and syntax. Should be written after EXP-1 completes and all 7 rule types are implemented.