What actually changed?
Establish the observed change and its place in operational history.
TECHNOLOGY / THE FOUNDATIONS
Built below
the dashboard.
The intelligence is only as useful as the information underneath it. CarbonDex’s architecture addresses both how operational data is trusted and how it is interpreted.
OPERATIONAL SYSTEMS
- Assets & equipment
- Sensors & meters
- Controls & SCADA
- Networks
- Environmental data
01 / TELEMETRY INGESTION
Carbon Collect
SCADA, meters, controllers, OT equipment, databases, field devices
02 / SECURE TRANSPORT
Carbon Mesh
Encrypted, traceable movement between endpoints and services
03 / TRUSTED HISTORY
Carbon DB
Authenticated records and the time context behind a change
04 / SYSTEM INTELLIGENCE
Carbon Sentinel
System state, relationships, emerging conditions, forecasts
05 / OPERATOR INTERFACE
CarbonUI
Evidence, dependencies, risk and investigation in one view
TRUSTED DATA
SYSTEM CONTEXTCAUSAL INTELLIGENCEPREDICTIVE RISK
OPERATOR DECISION
FOUNDATION 01 / TRUSTED OPERATIONAL DATA
Know where the data
came from. And how
the system got here.
Trusted history is an operational capability.
The secure-data foundation addresses source-level records, distributed storage, polling and aggregation, consensus validation, and auditable historical information.
This creates a basis for investigating what changed over time and for evaluating the integrity of the information used in operational reasoning.
Source records→Aggregation→Validation→Trusted history
FOUNDATION 02 / CAUSALITY-FIRST INTELLIGENCE
Reason about the state.
Investigate the cause.
A statistical relationship can be a signal. Understanding its operational role is the next step.
CarbonDex is developing causality-first machine intelligence centered on system-state modeling, causal primitives, dynamic relationships, deterministic reasoning, and interpretable outputs.
The objective is to reason about changing conditions without depending exclusively on conventional model-training pipelines. The architecture remains under active development.
What depends on it?
Connect the condition to assets, resources, and operational requirements.
What could explain it?
Surface plausible relationships and identify what needs further validation.
INTELLECTUAL PROPERTY
Architecture-level
technology foundations.
CarbonDex's technology strategy extends into the foundations of trusted operational data and machine intelligence. The platform builds on an issued U.S. patent and a related published continuation, and on licensed causal machine-learning technology.
ISSUED U.S. PATENTView patent
US 12,238,231 B1
Method and system for a secure multilevel nested blockchain data storage.
Issued February 25, 2025
RELATED PUBLISHED CONTINUATIONView application
US 2025/0193033 A1
Related published continuation application in the secure multilevel data-storage family.
Published June 12, 2025 · Application publication
LICENSED TECHNOLOGYCausality-first design
Foundational causal machine learning
CarbonDex is licensed to use foundational causal machine-learning technology that underpins its causality-first architecture. The technology is the subject of a filed U.S. provisional patent application.
Provisional patent application filed · Not an issued patent
EVALUATING THE TECHNOLOGY
Start with evidence.
Define the operating conditions.
Discuss a demonstration using your asset relationships, available telemetry, and operational requirements. Scope the environment, define the question, and evaluate outputs against known conditions.
Availability and deployment design depend on the specific integration and operating environment.
Discuss a technical evaluationTECHNICAL EVALUATION
Questions an engineering
team should be able to answer.
Architecture-level context for evaluating fit. Interface availability and controls are scoped to the proposed deployment.
01Telemetry ingestion+
Define the source and preserve its context.
SCADA, OT equipment, meters, controllers, databases, networked systems, and environmental sensors can contribute different signal types. Integration scope starts with what each source exposes and how reliably it can be read.
Evaluate: source identity, timestamps, units, sampling cadence, missing data, and access boundaries.
02Operational history+
Understand what changed over time.
Carbon DB is designed to maintain authenticated records and historical context. Time-series interpretation connects current conditions with prior behavior rather than treating every observation as independent.
Evaluate: record provenance, clock alignment, historical comparisons, retention requirements, and audit access.
03Dependencies & correlation+
Relate observations to connected systems.
Asset relationships put observed changes in context. Temporal overlap and correlated behavior can guide investigation; they do not by themselves establish causation.
Evaluate: known dependencies, data gaps, alternative explanations, and the evidence behind each relationship.
04Detection & forecasting+
Separate observed change from possible consequence.
Carbon Sentinel is designed to identify changing conditions and potential failure states. Useful forecasts should expose assumptions, dependencies, and uncertainty so the operator can evaluate the proposed path.
Evaluate: baseline drift, expected operating changes, false positives, and conditions that weaken the hypothesis.
05Causal investigation+
Make the reasoning inspectable.
The causality-first architecture is being developed around system state and relationships. The objective is to give the operator a traceable path from evidence to an interpretation that can be confirmed or disproved.
Evaluate: observation versus inference, event ordering, competing hypotheses, and validation steps.
06Edge & interfaces+
Define the deployment boundary.
Edge placement, APIs, and integration interfaces should be scoped to the target environment. Data access, synchronization, compute limits, operator access, and network policy shape the integration design.
Evaluate: available interfaces, authentication, buffering, synchronization, failure handling, and compute budget.
07Security architecture+
Establish trust beneath the analysis.
Carbon Mesh addresses secure transport between endpoints and services; the data architecture addresses record integrity and auditable history. Security controls and cryptographic approaches must be confirmed for the proposed implementation.
Evaluate: identities, least-privilege access, transport protection, record integrity, and operational logging.
THE NEXT OPERATIONAL ADVANTAGE
Understand the system.
Before the next critical event.
Your infrastructure already produces the data.
The next step is understanding what it means.