SENTINEL Energy · Candidate Invention 001 · Pre-Commercial P4

SENTINEL EAC-1 — Evidence-Gated Energy Assurance Controller

An emerging IYABOKO energy-assurance technology designed to transform BESS and distributed-energy telemetry into qualified evidence, independent risk assessment, uncertainty-aware runtime assurance and governed operator decision support.

Real Telemetry · Evidence Integrity · Deterministic + Predictive Analysis · Uncertainty · Concordance · EAC Action Authority · Traceability
Executable Alpha 13 frozen scenarios Read-only P4 architecture Human-governed
Alpha Executable prototype demonstrated
13 scenarios Frozen internal validation suite
P4 Read-only real-BESS pilot
Control Disabled in current commercial stage
Problem & Purpose

Energy systems can have extensive data without having enough trustworthy evidence to justify the next action.

A BMS, EMS or SCADA system may provide measurements, alarms and predictive indicators. EAC-1 investigates an additional assurance question: should operational authority depend not only on estimated physical risk, but also on the integrity, sufficiency and agreement of the evidence supporting that assessment?

Problem 01

Sensor evidence can degrade.

Measurements can become stale, implausible, inconsistent, unavailable or poorly contextualised. A risk estimate should not automatically be trusted when its supporting evidence has degraded.

Problem 02

Predictive systems can disagree.

An anomaly detector may indicate elevated risk while deterministic engineering rules remain normal, or the opposite. EAC-1 preserves that disagreement rather than hiding it.

Problem 03

Risk does not equal authority.

Knowing that something may be wrong is different from establishing which operational response is presently justified, especially in high-consequence energy systems.

Candidate Invention Focus

Separate the estimated physical state from the authority to respond.

The present research architecture treats physical-risk assessment and action authority as related but distinct system states.

Candidate technical hypothesis

The level of operational action authority justified by a system may change in response to evidence integrity, predictive uncertainty, context or analytical disagreement even when the estimated physical-risk state does not materially change.

Physical Risk State ≠ Action Authority State A warning or anomaly is evidence for a decision; it is not automatically permission to execute a physical action.
Candidate invention status: This architecture is being researched and prototyped. It does not mean patented, patent-pending, independently validated, certified, novel or inventive in the legal patent sense. Patentability and prior art require separate professional review.
Runtime Architecture

From telemetry to a governed assurance record.

The current Alpha/P4 architecture maintains independent evidence, engineering, predictive and authority stages before an operator-facing recommendation is recorded.

01 Telemetry BESS, BMS, SCADA, sensors, historian or approved gateway data.
02 Evidence Qualification Source health, timestamp, staleness, plausibility, uncertainty and consistency.
03 Deterministic Assessment Engineering rules and hard constraints evaluate present operating conditions.
04 Predictive Assessment Trend, anomaly and predictive analysis produce a separate risk estimate with uncertainty.
05 Concordance + Authority Agreement, disagreement and evidence quality inform the EAC runtime authority state.
06 Advisory + Ledger Operator recommendation and assurance state are recorded for reconstruction and review.
Dual-Domain Engineering Direction

Keep deterministic protection available even if intelligent analytics fail.

The longer-term hardware architecture separates deterministic safety logic from more computationally intensive predictive and evidence-processing functions.

Domain A

Deterministic Safety Controller

Intended functions include signal acquisition, watchdogs, deterministic constraints, sensor plausibility, communications supervision, authority enforcement and fail-safe state management.

  • Independent watchdog behaviour
  • Deterministic engineering constraints
  • Sensor plausibility and health
  • Communication supervision
  • Authority enforcement
  • Fail-safe handling
Domain B

Intelligent Edge Assurance

Intended functions include anomaly analysis, time-series processing, predictive risk, uncertainty, evidence management, dashboards and fleet integration.

  • Predictive / anomaly models
  • Digital-twin analysis
  • Evidence sufficiency
  • Uncertainty calculation
  • Operator console
  • Fleet / enterprise interface
Design principle: Loss or degradation of Domain B should not remove the deterministic protection and fail-safe capability assigned to Domain A. Actual hardware safety architecture remains subject to engineering, verification, regulatory and site-specific review.
EAC Runtime Authority Namespace

Use EAC-prefixed authority classes to avoid confusion with organisational governance authority.

IYABOKO governance authority uses G-A0…G-A4. EAC-1 physical/runtime authority uses a separate EAC namespace. The two should never be inferred from one another.

EAC-A0

Observation

Record state and evidence. No operational intervention is authorised.

EAC-A1

Advisory

Operator notification or monitoring advice without automatic physical intervention.

EAC-A2

Reversible Restriction

Future authority class for bounded, reversible operating restrictions where separately validated.

EAC-A3

Protective Control

Future higher-consequence protective-control authority requiring substantially stronger engineering evidence.

EAC-A4

Isolation Authority

Future isolation-level authority. Not enabled in the current P4 product.

EAC-AH

Human Authorisation

Evidence is insufficient or consequences require an accountable human decision before further action.

EAC-AF

Fail-Safe

Defined conservative state where the architecture must prioritise safety under critical evidence or system failure.

G-A*

Governance Authority

Organisation / professional decision rights remain a separate Core OS governance concept.

Executable Alpha

The candidate architecture has been implemented as executable software.

The current Alpha includes simulation, evidence qualification, deterministic assessment, predictive assessment, concordance, runtime authority, command gating and a hash-linked evidence ledger.

Engine

Evidence Processor

Converts telemetry into qualified evidence with sufficiency and integrity information.

Engine

Dual Risk Analysis

Deterministic and predictive states remain separately observable.

Engine

Authority Gate

Requested actions are evaluated against the current runtime authority envelope.

Evidence

Hash-Linked Ledger

Assurance records connect evidence, risk states, authority and gate outcome.

Executable software Automated tests Frozen scenarios Command gating Stale-data handling Predictor failure handling External reproduction pending
Frozen Validation Scenarios

Thirteen controlled scenarios test the current Alpha behaviour.

These are internal software-verification scenarios. They do not constitute field validation or certification.

Scenario Condition Deterministic Predictive Evidence Authority Gate result
SIM-001 Normal operation NORMAL NORMAL 1.000 EAC-A0 PERMITTED
SIM-002 Thermal rise WATCH WATCH 1.000 EAC-A2 PERMITTED
SIM-003 Hard limit CRITICAL WARNING Qualified EAC-A3 Protective request permitted in simulation
SIM-004 Predictive false positive NORMAL WARNING Qualified EAC-A2 Protective shutdown blocked
SIM-005 Faulty temperature sensor WATCH WATCH 0.475 EAC-AH Automatic reduction blocked
SIM-006 Corroborated abnormal temperature WARNING WARNING 1.000 EAC-A2 Permitted
SIM-007 Cloud loss WATCH WATCH 1.000 EAC-A2 Local assurance remains available
SIM-008 Predictor unavailable WATCH UNKNOWN 1.000 EAC-A1 Automatic reduction blocked
SIM-009 Analytical disagreement WARNING NORMAL 1.000 EAC-A1 Protective shutdown blocked
SIM-010 Stale telemetry WATCH WATCH 0.450 EAC-AH Automatic request blocked
SIM-011 Command outside authority WATCH WATCH 1.000 EAC-A2 OPEN_MAIN_CONTACTOR blocked
SIM-012A Same risk · high evidence WATCH WATCH 1.000 EAC-A2 REDUCE_POWER permitted
SIM-012B Same risk · degraded evidence WATCH WATCH 0.475 EAC-AH REDUCE_POWER blocked
Candidate Invention Experiment

SIM-012 asks the central EAC-1 question.

Can the same simulated physical-risk state legitimately produce different action authority because the quality of the supporting evidence is different?

SIM-012A · High Evidence

Same physical risk — qualified evidence

Deterministic state WATCH
Predictive state WATCH
Evidence sufficiency 1.000
Runtime authority EAC-A2 · Reversible Restriction
Requested action REDUCE_POWER
Result: request permitted in the internal simulation.
SIM-012B · Degraded Evidence

Same physical risk — evidence integrity degraded

Deterministic state WATCH
Predictive state WATCH
Evidence sufficiency 0.475
Runtime authority EAC-AH · Human Authorisation
Requested action REDUCE_POWER
Result: automatic request blocked; human review required.
Interpretation: SIM-012 is an internal proof-of-behaviour for the candidate architecture, not proof of patent novelty, real-BESS safety performance or regulatory suitability. The next scientific and engineering step is independent reproduction and real-world read-only validation.
First Commercial Real-World Stage

P4 · SENTINEL EAC-1 Pilot Site 001

IYABOKO is seeking one Australian battery, microgrid, energy laboratory or renewable-energy integration partner for the first controlled real-world validation deployment.

Read-only BESS assurance overlay

The P4 architecture receives authorised live telemetry without creating a control path back into the battery system. The existing certified or site-approved BMS, protection systems and operating procedures remain primary.

Environment Real BESS, microgrid or representative battery laboratory
Typical duration Approximately 8–12 weeks after commissioning
Telemetry Historian, API, MQTT copy, OPC UA, approved read-only gateway, replicated CAN or agreed equivalent
Control path Disabled by P4 architecture
Indicative commercial pilot · A$25,000–A$75,000 + GST / site Final quotation depends on interface complexity, number of assets, cybersecurity requirements, site access, sensing, reporting, travel and independent-validation scope.
P4 Data Architecture

Real plant data in. No live control out.

P4 is intentionally non-invasive so the first real-world evidence can be collected without asking a pilot partner to hand operational control to an unvalidated system.

01 Real BESS Existing battery asset and site operating environment.
02 Existing BMS Primary battery-management and protection layer.
03 SCADA / Gateway Customer-approved telemetry copy or historian/API route.
04 EAC-1 P4 Evidence qualification, risk, uncertainty and concordance.
05 Operator Advisory Read-only assurance state and recommended investigation.
06 Evidence Ledger Timestamped records for reconstruction, validation and review.
Pilot Evidence Objectives

The P4 pilot should answer measurable questions.

The goal is not simply to run EAC-1 beside a battery. The pilot should determine where the architecture succeeds, where it fails and what evidence is required before any higher-authority stage.

Data

Telemetry Availability

Measure data availability, freshness, channel quality and mapping completeness.

Evidence

Traceability

Can every material advisory state be reconstructed from its supporting telemetry, rules, models and evidence status?

Safety

Gate Violations

Target zero execution of prohibited actions within the read-only P4 environment.

Detection

Event Performance

Measure relevant detection, false-positive, false-negative, uncertainty and disagreement behaviour.

Resilience

Failure Behaviour

Observe stale telemetry, model failure, communication loss and analytical disagreement.

Reproducibility

Event Reconstruction

Replay selected site events and compare the reproduced assurance state with the original record.

Current Validation Position

What is demonstrated — and what remains to be established.

IYABOKO deliberately separates internal verification, demonstration evidence, pilot evidence, external review and certification.

Internally verified

Alpha architecture

Executable software for evidence, dual analysis, authority and gating.

Internally verified

Frozen scenarios

13 controlled scenarios including SIM-012A/B.

Internally verified

P4 read-only gateway

Prototype telemetry-processing and control-disabled architecture.

Seeking partner

Real BESS field pilot

Not yet completed. Pilot Site 001 is the next commercial milestone.

Not yet obtained

Independent validation

University, research-laboratory or qualified engineering evaluation remains required.

Not yet obtained

Product certification

Relevant product, electrical, cybersecurity and functional-safety assessment remains future work.

Disabled

Autonomous high-energy control

Not enabled in P4 and not presented as a current commercial capability.

Future gate

Fleet / OEM deployment

Requires successful field evidence, engineering maturation and commercial integration.

Intellectual Property Boundary

Protect the candidate invention without overstating patent status.

The public EAC-1 page should explain the engineering proposition without publishing unnecessary claim detail, evidence-scoring weights or trade-secret implementation logic.

Patent

Candidate Claim Architecture

Evidence-dependent action authority, qualified evidence objects, separate risk and authority states, and physical enforcement are candidate areas for professional patent review.

Trade Secret

Scoring & Calibration

Detailed evidence weighting, calibration logic, model tuning and operational thresholds should not be unnecessarily published.

Software

Copyright & Versioning

Source code, documentation, simulation assets and evidence records should retain version and ownership controls.

Public disclosure rule: Share enough architecture for a credible technical discussion, but keep detailed patent-claim drafting, secret evidence scoring, production thresholds and unpublished implementation details inside controlled technical documentation.
Collaboration Sought

Three partner types can move EAC-1 forward.

Research validation, real-world pilot evidence and commercial integration are distinct relationships. They should not be bundled into one ambiguous partnership.

01 · Research

Independent Validation Partner

University, battery research centre, laboratory or qualified engineering group to challenge methodology, reproduce experiments, test failure behaviour and identify unsupported claims.

02 · Field Evidence

Pilot Site 001 Partner

BESS owner, microgrid, energy laboratory or integrator willing to provide a controlled read-only telemetry environment under agreed scope and responsibilities.

03 · Commercial

Integration / OEM Partner

Future engineering or technology partner for industrialisation, protocol integration, hardware maturation, deployment, manufacturing or licensing after validation.

Development Roadmap

Increase evidence before increasing control authority.

The commercial pathway deliberately places real-world read-only evidence ahead of live high-energy control.

P0 Pure Digital Simulation, software architecture and frozen scenarios.
P1 Controller-in-the-Loop Real controller hardware against simulated plant.
P2 Sensor / HIL Representative sensors and interfaces with controlled faults.
P3 Low-Energy Lab Controlled battery or subsystem test under appropriate engineering procedures.
P4 Read-Only BESS Pilot Real telemetry and independent assurance without live control.
P5+ Supervised / Certified Control Future stage requiring separate safety, engineering, validation and approval gates.

Become SENTINEL EAC-1 Pilot Site 001 or an independent validation partner.

IYABOKO is seeking one Australian BESS, microgrid, energy laboratory or renewable-energy integration partner for the first controlled real-world P4 deployment, along with an appropriate research or engineering partner for independent technical evaluation.