ONEDGE ENERGY
UVS-2 / S-0.0.4 / I-1.1.0-rc3 / P-1.0.0 / G-1.4.0

Verifiable BESS evidence across specification, implementation, proof, and governance.

ONEDGE ENERGY now presents the active UVS-2 stack: Golden Record reconciliation, byte-level canonical commitments, provenance-tier attestation, the rc3 Module Extension Standard, registered proof primitives, and governance-bound claim discipline.

From whitepaper to active specification stack.

Renewable-heavy power systems are entering a battery-intensive phase where the bottleneck is no longer only generation, but evidence-governed coordination of flexibility assets under physical, financial, regulatory, operational, and warranty constraints.

ONEDGE ENERGY remains a proposed open standard and candidate specification. The public surface now reflects the active four-axis version vector rather than only the original whitepaper: the Standard axis defines the Golden Record, the Implementation axis defines SDK/runtime behavior, the Proof axis registers cryptographic primitives, and the Governance axis binds public claims and commercial regimes.

Open interface. Canonical evidence. Governance-bound claims.

UVS-2 separates four maturity tracks.

As of 2026-07-14, the manifest active vector is UVS-2 / S-0.0.4 / I-1.1.0-rc3 / P-1.0.0 / G-1.4.0. The axes are linked by compatibility rules, but they are not the same artifact.

S-0.0.4

Standard

Extends UVS to UVS-2, reconciles the Golden Record definition, formalizes the Fingerprint Baseline, and registers GRSCHEMA, TEEATTEST, and THREATMTX.

I-1.1.0-rc3

Implementation

Promotes the SDK bundle to rc3 and adds the Module Extension Standard for deterministic pluggable Runtime modules.

P-1.0.0

Proof

Registers Ristretto255/Pedersen commitments, Bulletproofs, R1CS, Keccak-256, and domain-separated transcript labels.

G-1.4.0

Governance

Adds a governed advancement state machine, compatibility matrix, hash-frozen release capsule, historical replay, containment, and public-legibility gates. This technical advancement does not alter or represent the execution status of any commercial instrument.

System dispatch and asset warranties require a shared evidence object.

The CEN coordinates Chile's SEN according to system-level objectives such as security, continuity, economic dispatch, and open access. That mandate is not designed to become the warranty arbiter, lender diligence agent, telemetry-provenance authority, or asset-degradation certifier for every BESS.

A dispatch instruction can be systemically correct and still create asset-level warranty, degradation, lender-legibility, or telemetry-provenance ambiguity.

The Golden Record has one canonical definition.

S-0.0.4 reconciles the prior whitepaper, oracle, SDK, bridge, and governance descriptions into one object: GR := (Commitment, Classification, Provenance, Binding). The Sovereign Operational Certificate is the contractual alias of the same object.

Commitment

State-bound

A cryptographic commitment to event state, dispatch, telemetry, envelope, transition, and proof artifact.

Classification

Three-state

The ternary outcome Compliant / Breach / Opacity, evaluated against a required provenance tier.

Provenance

Attested

The chain of signing roots, freshness anchors, and continuity proofs that justify the attained telemetry tier.

Binding

Cross-axis

The active (S, I, P, G) regimes under which the record was issued and audited.

Outcome 01

Compliant

Approved telemetry is available and the asset respected its declared physical, operational, warranty, and contractual envelope.

Outcome 02

Breach

Approved telemetry is available and the event operated outside the declared envelope, supporting attribution and warranty-defense logic.

Outcome 03

Opacity

Telemetry provenance fails or the evidentiary substrate is incomplete, corrupted, delayed, inconsistent, manipulated, or physically unavailable.

ONEDGE does not manufacture certainty. It classifies the evidentiary state.

Bit-identical commitments across runtimes.

GRSCHEMA-1.0.0 defines the byte-level canonical schema for event commitments, period aggregation, and verifier-side public inputs. Under P-1.0.0, the canonical commitment hash is Keccak-256 over the canonical byte sequence and transcript label.

GR_k := H_P( "ONEDGE-SDK/v1/GR/v1.0.0/Event" || u32_LE(label_length) || canonical_preimage_k ) Required conformance properties: - explicit little-endian integer widths; - u32-LE length-prefixed vectors; - ordered telemetry vectors; - domain-separated transcript labels; - exact reproduction of conformance vectors.

S-0.0.4 publishes deterministic GRSCHEMA vectors for Compliant, Breach, and Opacity cases. Module-operator fixtures for phi, psi, and delta remain open in Move 2.

Scope boundary: the current vectors establish canonical encoding and structural equality. Real proof-validity, witness-binding, and adversarial proof vectors remain open under CUR-0014; deterministic hashes alone do not establish those properties.

What ONEDGE does — and what it does not do.

ONEDGE does
  • ingest baselined telemetry;
  • evaluate declared operating envelopes;
  • classify events as Compliant, Breach, or Opacity;
  • produce Golden Record / SOC evidence artifacts;
  • reduce, but not eliminate, evidentiary ambiguity;
  • support lender, OEM, owner, operator, auditor, and regulatory diligence.
ONEDGE does not
  • replace CEN or any system operator's dispatch authority;
  • replace BMS, SCADA, meters, inverters, sensors, or OEM monitoring hardware;
  • create telemetry where hardware telemetry does not exist;
  • certify compliance where telemetry provenance fails;
  • auto-resolve legal disputes or replace lender diligence;
  • guarantee WACC, LTSA, warranty, regulatory, or degradation outcomes.

Evidence quality is tiered, not assumed.

The active manifest carries five provenance tiers, τ0 through τ4, aligning observed telemetry, soft signatures, hardware attestation, BMS-TEE silicon roots, and ZK-continuity into explicit minimum evidence thresholds.

Provenance Tier τ0

Unverified

No signing root, freshness, or continuity requirement.

Provenance Tier τ1

Soft-signed

Operator-key signing with freshness requirement.

Provenance Tier τ2

Hardware

TPM/HSM/TEE at node boundary with freshness.

Provenance Tier τ3

BMS-TEE

OEM silicon, StandardCo registry, device-key chain.

Provenance Tier τ4

ZK-continuity

Tier 3 plus ZK-verified thermodynamic continuity.

Conformance Levels 0 through 4 describe statement maturity, while provenance tiers describe evidence origin and assurance. A Level claim requires at least provenance tier τ ≥ ℓ; the two scales are aligned but not interchangeable.

TEEATTEST-1.0.0 is normative for telemetry claiming τ ≥ 3. It defines the StandardCo Root → OEM Root → Device Key chain, freshness anchors, revocation, and tier binding.

Withhold compliant classification when evidence is defective.

THREATMTX-1.0.0 maps the original seventeen threats plus two derived threats, opacity-as-compliance and commercial misrepresentation, to concrete mitigation surfaces across provenance tiers, Golden Record schema rules, TEE verification, operator controls, SDK invariants, and governance controls.

The three-state model reduces these threats by withholding Compliant classification where the evidentiary substrate is defective.

rc3 adds deterministic module extensions.

I-1.1.0-rc3 introduces the Module Extension Standard for OEM-specific thermodynamic models without a full Runtime upgrade for each asset variant. Modules remain deterministic RISC-V no_std state-transition units subject to universal Physics Firewall invariants.

phi / φ

Reaction Operator

Q32 SOC accumulator coupling net power with resistive dissipation.

psi / ψ

Synchrony Coefficient

Q0 normalized deviation between GR-committed SOC and BMS-attested SOC.

delta / δ

Divergence Proxy

Q16 bounded stress indicator combining thermal headroom and SOC rate.

Entry Points
module_version, module_step, module_validate, and module_invariants.
Arithmetic
Q16/Q32/Q0 fixed-point formats, round-half-to-even truncation, saturating arithmetic, and sticky saturation clearance.
Invariants
PF-M1 through PF-M6: SOC bounds, thermal ceiling, ramp rate, synchrony bound, divergence bound, and saturation clearance.
Reason Codes
Module-extension codes occupy 0x0200..0x02FF, including unregistered module, version mismatch, invariant hash mismatch, synchrony exceeded, and saturation sticky.

Open architecture around a protected proof core.

Open / Public Surface
Public interfaces, schemas, Runtime ABI, cryptographic domain labels, XAM message structure, conformance vectors, audit-facing terminology, and module registry requirements.
Protected Core
ECME Kernel Runtime, proprietary proof circuits, internal DATA Codec implementation, calibration methodology, and commercial proof services remain governed by IKKUNA / StandardCo boundaries.
Physical Asset Layer
BESS asset, BMS, SCADA, inverters, sensors, meters, dispatch orders, operator actions, and asset-originated telemetry sources.

Governance is now part of the version vector.

S-0.0.4 extends the versioning scheme to UVS-2 by adding the Governance axis. Golden Record events embed a governance binding so the technical record can be attributed to the frozen commercial regime under which it was issued, without changing the ternary classification outcome.

Term Parity

One vocabulary

Golden Record, SOC, ECME Kernel, StandardCo, MarketCo, and governance-bound terms resolve to canonical sources.

Antitrust-safe Surface

Access discipline

Third-party access surfaces are governed by the prevailing G-axis terms and cannot silently drift from them.

Manifest Binding

Compatibility gate

The manifest links compatible S, I, P, and G versions; unregistered governance bindings are rejected by spec rule.

ADVANCEMENT-1.0.0

Explicit activation

Recommendation, proposal, lock-in, activation, enforcement and retirement are distinct states. Unknown successor profiles fail closed, and public status must match the registered release tuple.

rc3 is active; root release remains ahead.

The next root release target is S-0.1.0 / I-1.1.0. The landing page reflects Move 1 completion while keeping Moves 2 through 4 open.

Move 1 / Complete

Modules rc3

Module Extension Standard, LaTeX canonical, SDK bundle rc3, and manifest registration.

Move 2 / Open

Vectors

XAM, crypto-domain, runtime ABI, and module operator conformance fixtures.

Move 3 / Open

Parameters

PARAMETERS.md and INVARIANTS.md registries for defaults, Q-formats, tolerances, and firewall values.

Move 4 / Open

Reference Runtime

Reference module pseudo-implementation and executable conformance fixtures.

Bounded claims for a pre-stable candidate stack.

Claims made
  • ONEDGE ENERGY has an active UVS-2 vector registered in the manifest.
  • S-0.0.4 defines the canonical Golden Record and related S-axis artifacts.
  • I-1.1.0-rc3 is a release-candidate SDK/spec bundle with module-extension rules.
  • P-1.0.0 registers the proof primitives and transcript labels used by the stack.
  • The system is designed to reduce evidentiary ambiguity by classifying records as Compliant, Breach, or Opacity.
Claims not made
  • It is not the S-0.1.0 / I-1.1.0 root release.
  • It is not already an adopted industry standard.
  • It has not completed TRL-7 validation.
  • It does not guarantee lower WACC or LTSA costs.
  • It does not guarantee warranty approval or prevent degradation.
  • It does not replace CEN dispatch, OEM monitoring systems, authorized market records, or regulatory determinations.
ONEDGE reduces the scope and ambiguity of disputes by producing verified operational evidence, breach evidence, or opacity evidence.

Document-first institutional interface.

This static page indexes the active public-facing specification surfaces. S-0.0.2 remains the base whitepaper and historical standalone anchor; the active S-axis must be read cumulatively through S-0.0.3 and S-0.0.4, with later amendments governing where applicable.

DocumentStatusVersionPurpose
ONEDGE ENERGY Base WhitepaperBase whitepaper / historical standaloneS-0.0.2Base public narrative; read cumulatively with S-0.0.3 and S-0.0.4. Later amendments govern where applicable.
Spec Hardening NoteActive S-axis hardeningS-0.0.4UVS-2, Golden Record reconciliation, Fingerprint Baseline, and defined-term parity. References to Addendum No.1 identify version provenance and do not establish execution or binding effect.
Golden Record Canonical SchemaActive S-axis schemaGRSCHEMA-1.0.0Byte-level event commitment, aggregate root, public-input vector, and cross-runtime conformance.
BMS-TEE AttestationActive S-axis attestationTEEATTEST-1.0.0Three-layer attestation chain, freshness anchors, revocation, and tier mapping for τ ≥ 3.
Threat Mitigation MatrixActive S-axis coverageTHREATMTX-1.0.0Threat-to-mitigation mapping across provenance, schema, TEE, operator, SDK, and governance surfaces.
Protocol Advancement StandardActive G-axis governanceADVANCEMENT-1.0.0Compatibility classes, qualification, release capsules, activation/enforcement states, historical replay, containment, documentation and public-legibility gates.
ONEDGE SDK Spec BundleActive I-axis RCI-1.1.0-rc3SDK specification, security model, Runtime ABI, crypto domains, XAM, and MODULES_SPEC.md.
Module Extension CanonicalActive I-axis RC canonical1.1.0-rc3LaTeX authoritative module contract, Q-format arithmetic, physical operators, PF-M invariants, and reason codes.
ECME on BESS BridgeActive S-axis bridgeBRIDGE-0.1.0Contractual and physical endowment bridge for BESS inventory-dissipation formalism.

Disclaimer: materials are provided for discussion and validation purposes only and do not constitute legal, financial, investment, regulatory, engineering, tax, or professional advice.