Skip to main content

Aethr Research / Safety & Control

Safety, Reliability & Control

Capability matters. Control determines where it can be trusted.

AETHR is building toward AI systems that can operate alongside consequential workflows — including industrial environments where incorrect recommendations can affect equipment, resources, compliance, economics, and eventually physical processes. Our safety work therefore begins with a practical question: what must be true before model-generated intelligence is allowed to influence a real system? This page describes the engineering principles we are developing around that question. It does not claim they are all complete.

The control problem

A capable model is not the same as a safe system.

Language models are probabilistic. Industrial systems contain physical constraints, operating envelopes, incomplete sensors, delayed measurements, permissions, safety procedures, regulatory requirements, and human accountability. A model can reason about these systems. It should not automatically become the authority that controls them.

The model reasons.
The system verifies.
The human decides.

DATA / TELEMETRY / DOCUMENTSSPECIALIST MODEL · contextDETERMINISTIC TOOLS + VALIDATORS · calculation / rules / retrievalCONTROL / POLICY LAYER · verified candidate actionHUMAN OPERATOR / ENGINEER · recommendation + evidencePHYSICAL SYSTEM · approved actionsNO AUTOAUTHORITY
The model may interpret, reason and recommend. Verification and authority remain separate layers — authority never flows automatically from model to machine.

Engineering principles

Six principles for bounded intelligence.

01

A confident answer without evidence is still an unsupported answer.

For consequential decisions, a model response should be grounded where possible in current measurements, engineering documents, approved operating procedures, validated calculations, historical site context, and provenance-bearing sources. The system must distinguish observed fact, retrieved fact, calculated result, model inference, and assumption — five different epistemic kinds, never blurred into one fluent paragraph.

02

The world can reject a plausible sentence.

Industrial processes obey conservation laws, equipment limits, mass and energy balances, chemistry, hydraulic constraints, and operating ranges. Generative reasoning should therefore be checked against deterministic models and engineering constraints when correctness matters. A water-intelligence model may propose an operating change; a deterministic calculation verifies flow, pressure, quality, capacity, and chemical limits before a person considers it. Nothing here implies the system currently actuates such changes.

03

The system should know when evidence is insufficient.

A trustworthy system must be allowed to say: data missing, measurement stale, sources conflict, confidence insufficient, request outside authority, calculation cannot be verified. Failure to answer is sometimes the correct behavior — and future evaluations should measure appropriate abstention alongside answer accuracy, not instead of it.

04

Reasoning authority and action authority are different.

Level 0 observes. Level 1 explains. Level 2 recommends. Level 3 prepares an action for approval. Level 4 executes within bounds. Level 5 executes autonomously. AETHR's initial industrial philosophy remains read-oriented, recommendation-oriented, and human-supervised — levels 0–2, selectively 3. Higher authority requires substantially stronger qualification, and unrestricted autonomous actuation is not a current deployment objective.

05

Operational experience should not silently rewrite the model.

Live telemetry, lab measurements, equipment state, and temporary site conditions should normally enter as external context — never as automatic weight updates. Selected operational cases may eventually become training data only after review, permission, de-identification where required, quality checks, test creation, and validation. No uncontrolled online learning. This is directly relevant to Industrial Intelligence, where yesterday's anomaly must not become tomorrow's prior without consent.

06

A system should fail into a known state.

Reliability means checkpoint recovery, data-stream state, idempotent tool calls, action logs, retry boundaries, rollback where applicable, and human escalation. A system that cannot explain what happened before a failure cannot safely continue after one — which connects directly to OMN's own training-system emphasis on recovery and state correctness, without claiming more than the implementation demonstrates.

Authority levels

Reasoning authority and action authority are different.

0OBSERVE1EXPLAIN2RECOMMEND3PREPARE FOR APPROVAL4BOUNDED EXECUTION5AUTONOMOUS EXECUTIONEARLY: 0–2 (+3)
The acceptable authority of a system should depend on the evidence available for its reliability. Early deployments remain at levels 0–2, selectively 3.

Failure modes

Different failures require different controls.

FailureDescriptionControls
HallucinationModel produces unsupported content.Retrieval · citation · abstention · verification
Stale contextReasons from outdated operational information.Timestamps · freshness gates · live-data checks
Constraint violationRecommendation contradicts engineering limits.Deterministic validator · operating envelope
Tool errorIncorrect function/tool invocation.Typed schemas · permission checks · dry-run · validation
Authority violationAttempts action outside permitted scope.Policy engine · capability boundary · human approval
Data quality failureSensors missing, noisy, or inconsistent.Quality flags · redundancy · uncertainty propagation
Recovery failureCannot reconstruct prior state.Logging · checkpointing · transaction history
Model uncertaintyEvidence ambiguous or out of distribution.Abstention · escalation · alternate evidence

Deployment scope

Trust should be earned per capability.

Do not ask “is the AI system safe?” Ask: safe to do what, under what conditions, with what authority? A model may be qualified to summarize maintenance history before it is qualified to recommend a process adjustment — and long before it should be permitted to execute one. Deployment scope expands only where evidence supports it.

LOW CONSEQUENCE / LOW AUTHORITYHIGH CONSEQUENCE / HIGH AUTHORITYSUMMARIZE · RETRIEVE · EXPLAINRECOMMENDCALCULATE + RECOMMENDPREPARE ACTIONBOUNDED EXECUTIONAUTONOMOUS CONTROLEVIDENCE REQUIREMENT INCREASES →
One of the defining diagrams of this page: consequence rises downward while the evidence requirement rises with it.

System philosophy

Not every answer should come from a language model.

AETHR's philosophy routes tasks by nature. The model interprets, synthesizes, hypothesizes, reasons in context, and interacts in language. Deterministic tools do arithmetic, mass balance, hydraulic calculation, constraint checking, database lookup, rules, and unit conversion. The policy layer holds permissions, allowed tools, action scope, and approval requirements. The human holds responsibility, judgment, exceptions, and high-consequence decisions.

QUESTIONROUTER / ORCHESTRATIONMODELREASONINGDETERMINISTICCALCULATIONRETRIEVALPOLICYCHECKHUMANESCALATIONTRACEABLE RESPONSEevery path leaves evidence — no unattributed answers
Each path leaves evidence. Nothing reaches the response unattributed.

Industrial boundary

Industrial Intelligence should sit above control systems before it ever sits inside them.

Aethr Industrial Intelligence is intended to integrate above SCADA, DCS, BMS, historians, CMMS, ERP, and lab systems — and never to initially replace PLC/DCS control logic or safety-instrumented systems. Early deployments read, interpret, correlate, explain, and recommend rather than autonomously actuate. The line is absolute: a language model should not become a substitute for deterministic plant protection.

EXISTING PLANT — UNCHANGEDSENSORS / EQUIPMENTPLC / SAFETY SYSTEMSSCADA / DCS / HISTORIANAETHR LAYER ABOVE — READ · INTERPRET · RECOMMENDDATA / CONTEXT CONNECTORSVERIFICATION + TOOLSSPECIALIST DARWIN MODELEVIDENCE-BACKED RECOMMENDATIONENGINEER / OPERATOR
No direct model-to-actuator arrow exists anywhere in this architecture. Every recommendation terminates at the engineer.

Accountability

Accountability should remain legible.

Every meaningful recommendation should eventually answer: what evidence was used, what assumptions were made, what tools were called, what constraints were checked, what uncertainty remains, who approved the action, and what happened afterward. That is an audit trail, not an opaque model answer.

Agent boundaries

Agents should receive capabilities, not unlimited access.

Least privilege. Explicit tool schemas. Allowlisted operations. Scoped credentials. Read/write separation. Approval for consequential writes. Immutable audit logs. No arbitrary command execution in production systems. Protected secrets. Connector isolation. No certifications are claimed here — no SOC 2, no ISO 27001, no IEC 62443 compliance — unless and until actually achieved.

Future evaluation

Reliability must be measured, not assumed.

A future reliability programme — not a completed certification — should cover factual grounding, evidence completeness, uncertainty calibration, abstention quality, tool-call correctness, constraint adherence, recovery behavior, prompt robustness, out-of-distribution behaviour, stale-data response, adversarial inputs, and long-context degradation.

Foundations

Safety also begins below the application layer.

OMN contributes a research culture around inspecting model internals, explicit optimizer routing, architectural ablation, training-state accounting, checkpoint identity, data exposure analysis, and evidence qualification. A model architecture does not solve safety by itself — OMN is not claimed to be inherently safer than other architectures. But a system whose assumptions are measurable and auditable gives researchers more surfaces on which to investigate reliability.

Scale

Safety should scale with the Darwin family.

As Darwin develops, Type-S (compact, edge) and Type-M (larger capability) present different risks: device constraints, quantization effects, offline behavior, and limited-context failures on one side; broader tool use, greater reasoning scope, higher-impact workflow participation, and more complex failure modes on the other. Type-M exists today only as a planned roadmap item, and the evaluation differential is a future direction, not a current programme.

Stricter standard

The standard becomes stricter when intelligence touches the physical world.

For water, energy, and operations, qualification should eventually cover physical consistency, process safety, data quality, uncertainty recognition, traceability, authority scope, recovery to safe state, and immediate human override. Each is a bar to clear before responsibility expands — never a property assumed from model capability.

Credibility

Where we are today

AETHR is still early in this programme. Current work focuses on building the architecture, evaluation methods, evidence standards, and deployment boundaries required before increasingly capable systems are trusted with greater authority. We do not present AETHR models as autonomous operators of critical infrastructure. Industrial deployments are intended to begin with bounded, human-supervised intelligence and expand only where reliability evidence justifies additional responsibility.

Long-term thesis

Safe AI should not require blind trust in the model.

The long-term goal is not a model simply declared trustworthy. It is systems in which trust decomposes into observable properties: what the model knows, what evidence it used, what it is allowed to do, what deterministic checks surround it, when it must abstain, who retains authority, and how the system recovers when something goes wrong. Capability can remain probabilistic. Authority does not have to be.