TENRX.ENERGX: A Traceable Unified Oil Field Engineering Intelligence System

Subtitle: I am definitely building a pure Rust engineering core for production analysis, measurement validation, diagnostic and uncertainty, and also reproducible engineering results.

Project Summary

I am building and developing TENRX.ENERGX, which is an engineering intelligence system designed to help oil field engineers, contractors, and smaller operations investigate operation problems, validate measurement, understand production performance, and make engineering decisions based on traceable evidence that was brought out from the output of the system.

The problem I want to address in the oil and gas field industry is complex, which most developers don't really want to go there, because understankding oil and gas is not just coding—it is understanding oil and gas problems and complying them with Rust operation. An engineering calculation can produce a number without adequately explaining whether the input is reliable. Most numbers are certain, but most are uncertain. Current software gives numbers without explaining how, what happens, why it happens, what the problems were, or what the solutions are. That is what TENRX.ENERGX wants to achieve.

Engineers need to reconcile measurements from different sources, investigate production changes, examine equipment performance, and compare several possible explanations before reaching a sensible conclusion. It takes time to do that, and mostly it comes with error. Many smaller oil field contractors face difficulty accessing expensive specialist engineering software, data, or technical resources needed for advanced analysis. Some workflows rely on spreadsheet calculations, hand calculations, and paperwork. When it comes to workflow certainty, there is not adequate check for units, data quality, assumptions, physical consistency, and uncertainty. Validating manually takes okperation time, reduces efficiency, and costs millions of dollars in loss because data is not unified.

TENRX.ENERGX is designed to bring these steps together as part of the engineering process rather than leaving them scattered across spreadsheets and manual calculations that are not certain. Most small contractors don't have PVT lab data or correlations for each of their wells because digitalizing every well is too costly.

My goal is not to make a simple calculator, a faster calculator, or a smarter calculator. My goal is to make a unified, reasonable white box behind an engineering result that is advanced, accurate, trusted, and reasonable—so when the output is given to an engineer, they know the evidence. I have confidence in this because it works, it is tested, and an engineering result becomes more traceable, transparent, consistent, and reproducible.

I have completed a 96-page engineering core master specification defining advanced capabilities sections, 10 planned Version 1 products, 8 shared engineering upgrades, deep process architecture validation requirements, and release gates. The implementation is in progress. I am seeking this grant funding to help turn this defined architecture into working Rust software, test it against documented engineering cases, and prepare Version 1 ready to launch at the target launch date of March 30th, 2027.

Planned Version 1 Products & Shared Engineering Core

The 10 planned products cover:

Production Loss Engineering

Well Performance Diagnostics

Artificial Lift Engine

Meter and Measurement Checker Engine

Pump Performance Engine

Pressure and Gradient Analysis Engine

Tank and Volume Calculation Engine

Production Allocation Engine

Gas Utilization and Flaring Engine

Equipment Reliability Screener

This shared engineering core is what collects them. It is intended to validate input, normalize units, assess data quality, reconstruct operating conditions, select applicable models, check physical constraints, qualify certainty, test possible explanations, and preserve the evidence behind the result.

My central engineering principle is that the system must never turn uncertainty into certainty, because certainty is the most costly thing in the oil and gas industry. The main reason I chose Rust is because Rust has zero garbage collection overhead. In the oil and gas industry, if a software workflow crashes, it brings massive problems and causes oil and gas companies massive financial loss. That is why I chose Rust as my core implementation language. When evidence is insufficient, a model is unstable, or numerical calculation fails, the system must expose that limitation instead of presenting an unsupported conclusion as fact.

Project Goals & How They Will Be Achieved

Goal 1: Implement the Shared Engineering Foundation (CORE)

My first goal is to implement the shared engineering foundation on which all 10 products and 54 capabilities depend. This foundation includes engineering data structures, input validation, unit and dimension normalization, data quality assessment, time series processing, operating state reconstruction, numerical methods, physical checks, uncertainty assessment, evidence tracking, model versioning, result generation, and provenance.

Different engineering products should not silently integrate the same measurement in different ways. A pressure value, flow measurement, or temperature reading must retain accurate units, context, source, and quality information throughout analysis. Missing measurements, invalid units, duplicate readings, sensor drift, inconsistent time spans, and conflicting inputs must be handled explicitly. If input is wrong, incomplete, or unsuitable for the selected model, the result is unreliable. CORE is built to support small oil contractors to help them integrate low-level inputs to give them solid certainty.

Goal 2: Implement the Common Process Pipeline

The pipeline begins with input and structure validation, followed by unit normalization, data quality assessment, timeline alignment, operation state reconstruction, baseline construction, model selection, numerical calculation, physical validation, uncertainty assessment, deviation analysis, hypothesis testing, interpretation, and provable traceable engineering results.

Temporal handling is particularly important. Measurements taken at different times, at different scales, or under different operation conditions cannot automatically be treated as describing the same rate. The software must distinguish direct observation from interpolated or derived values, identify data gaps, preserve event chronology, and qualify results when available time series information is insufficient.

Example: If a pressure panel reading falls after a change in equipment operation, it is essential to examine timing and relevant evidence rather than automatically claiming the equipment event caused the decline. A relationship between two observations is reasonable to investigate, but is not automatically proof of causation.

Goal 3: Implement the 10 Specialized Version 1 Products

Each product addresses different engineering problems using the shared foundation:

Production Loss Engineering: Compares expected production with observed production, identifies meaningful deviations, estimates potential loss, reconstructs loss event timelines, and investigates possible explanations while accounting for operational conditions, data quality, model applicability, and uncertainty.

Well Performance Diagnostic: Assesses whether a well performs consistently with applicable inflow, outflow, pressure rate, fluid properties, and operating conditions against an appropriate baseline while keeping underlying calculations visible.

Artificial Lift Engine: Checks artificial lift performance across electric submersible pumps, gas lift, sucker rod pumps, progressing cavity pumps, and plunger lifts, identifying abnormal operating signatures without automatically declaring that the lift system is the cause of every performance problem.

Meter and Measurement Checker Engine: Assesses meter readings and measurements for consistency, calibration, bias, sensor disagreement, data quality problems, and uncertainty. Warning status indicators explain why, how, and when measurements have been qualified.

Pump Performance Engine: Analyzes pump head, flow efficiency, operating points, system interaction, cavitation indicators, and degradation behaviors. A pump health grade summarizes assessment without replacing underlying calculations and evidence.

Pressure / Gradient Analysis Engine: Analyzes pressure measurements and relationships including hydrostatic behavior, pressure transients, pressure gradients, and compression against engineering models while preserving methods, observations, and uncertainty.

Tank and Volume Engine: Calculates and reconciles tank volume and inventory movement using relevant dimensions and properties.

Production Allocation Engine: Allocates and reconciles measured production across wells, assets, or streams based on evidence-driven allocation confidence rather than assigned values.

Gas Utilization and Flaring Engine: Analyzes produced gas quantities, utilization, disposition, flaring, venting, and accounting balances, keeping produced, flared, and vented gas as distinct qualities.

Equipment Reliability Screener: Screens equipment for degradation and failure indicators using condition history, failure history, event correlation, and synthesized core signals, identifying top recurring equipment problems without treating an anomaly score alone as proof of failure.

Goal 4: Implement the 8 Shared Engineering Upgrades

Root Cause Reasoning Engine: Moves investigations beyond identifying that something is wrong toward evaluating which explanation is most consistent with evidence, distinguishing supported root causes from contributing factors.

Counterfactual Engine: Examines alternative conditions (e.g., estimating what production might have been under alternative operating conditions) as model-based comparisons rather than automatic proof of cause.

Uncertainty Decomposition Engine: Explains not only how uncertain a result is, but why, considering measurement inputs, parameters, numerical interpolation, structure, and missing data.

Physics Check Engine: Checks conversion relationships, dimensional consistency, operating limits, pressure/flow regulations, equipment constraints, and model applicability, rejecting mathematically successful calculations that violate physical constraints.

Cross-Product Collaboration Engine: Correlates relevant findings from different products into a common engineering case file while accounting for overlapping evidence and shared assumptions.

Historical Forensic Engine: Compares current problems with previous engineering cases to identify event patterns, recognizing that historical similarity alone is not proof of identical causes.

Operating Envelope Engine: Assesses whether an asset is operating within a normal region, degradation region, abnormal region, boundary condition, or unsupported model region.

Simulation Engine: Evaluates defined engineering scenarios using capable models and documented inputs, keeping simulated, predicted, and observed results strictly distinguished.

Goal 5: Embed Modular Process Development & Testing

I will use the complete master specification to guide modular Rust development, automated numerical regression, and integration. Local computing setups will support compilation, test execution, benchmarking, and handling engineering assets in stages: shared foundation demonstration, specialized product expansion, and release gate validation.

Success Criteria & Release Gates

I will judge success by whether the software produces correct, reasonable, reproducible, and operationally qualified engineering results.

The master specification defines 15 gates covering structural validation, unit/numerical/physical accuracy, engineering behavior, uncertainty, diagnostics, cross-product operation, historical/predictive validation, failure handling, reproducibility, provenance, engineering review, and release readiness.

I will test components against analytical solutions, dimensional checks, synthetic cases, and historical cases covering normal operations and failure conditions (missing measurements, invalid data, inconsistent timestamps, sensor drift, outliers, numerical errors, model failures). The system must identify these conditions, produce qualified calculations with clear warnings or diagnostics, and never silently invent missing data or present uncertain results as certainty.

Performance will be measured using documented workflows and repeated benchmarks, recording input sizes, execution times, and numerical agreement. Reproducibility ensures deterministic behavior where repeating a calculation with the same inputs, model version, and parameters produces consistent results with full provenance tracking back to equations and assumptions.

Funding Request & Budget Allocation

I am requesting a minimum of $15,000 and a maximum of $20,000 to support local computing capacity, power continuity, storage, connectivity, and implementation-related validation.

Full Budget Allocation ($20,000):

$7,500 — High-Throughput Multi-Core Workstation: Development workstation supporting parallel Rust compilation, numerical workloads, automated tests, integration, and performance benchmarking.

$5,000 — Power Connectivity Equipment: Appropriate UPS, inverter, and battery arrangement to reduce interruptions during extended development and testing sessions.

$3,500 — Dedicated Data Connectivity: Connectivity and data transfer capacity for staging and testing engineering datasets and time series arrays.

$2,500 — High-Speed NVMe Storage: Fast local storage for source builds, engineering datasets, test fixtures, regression results, benchmark outputs, and validation records.

$1,500 — Benchmarking & Validation Expenses: Directly related regression testing, reference case preparation, and validation activities.

Minimum Plan Allocation ($15,000):

If only $15,000 is available: $7,500 for workstation, $2,000 for power equipment, $2,000 for storage, $2,000 for connectivity, and $1,500 for benchmarking and validation.

Key Dates: November 5th, 2026 is the date by which a funding decision is needed, with March 30th, 2027 as the target launch date for Version 1.

Team & Track Record

I am leading TENRX.ENERGX as CEO, solo developer, and engineering architect.

My primary completed planning artifact is my comprehensive architecture of engineering core files, master specification defining all 54 capability sections, 10 planned Version 1 products, 8 shared engineering upgrades, process pipelines, failure handling rules, validation frameworks, and release gates.

My immediate responsibility is translating this architecture into working Rust components, running validation tests, and presenting achieved capabilities through actual deliverables and test results.

Risk Analysis & Mitigation

Scope Breadth: Managing 10 products and 54 capabilities is a substantial task. I manage this risk by building the shared foundation first with modular Rust components. If the complete scope cannot be validated by the target date, I will narrow or delay the release rather than present unfinished capabilities as production-ready.

Numerical Instability: Mitigated by planned safeguards including model applicability checks, numerical tolerance monitoring, physical validation, uncertainty assessments, and explicit failure statements so failed calculations never silently present valid-looking numbers.

Reference Data Availability: Where historical measurements or calibration data are unavailable, I will use analytical references and controlled synthetic cases, incorporating backtesting as reliable data becomes available.

Hardware / Power Interruptions: Mitigated by requested power continuity equipment, NVMe storage, version control, and reproducible test procedures to ensure work can resume smoothly after interruptions.

Conflicting Product Conclusions: The shared architecture addresses this through common versioned models, consistent result structures, provenance, and cross-product correlation to expose conflicting evidence for investigation.

If the full project does not reach its intended release schedule independently, completed components (unit normalization utilities, data quality checks, numerical calculation routines, physical validation routines, and provenance tools) will still serve as reusable engineering components once they reach necessary quality levels.

External Funding History

$0. I have raised no external funding for TENRX.ENERGX in the last 12 months. I am seeking grant support to advance the implementation, testing, and validation work described in this proposal.