JouleBridge: A Signed Edge Runtime for Energy Sites

Abstract

Energy sites are becoming software-controlled systems before they have learned how to produce trustworthy records. A depot can have EV chargers, smart meters, batteries, solar inverters, tariff rules, cloud dashboards, operator overrides, and a dispatch optimizer all touching the same physical site. The billing workflow later asks one boring question: what happened? The usual answer is a pile of logs that disagree.

JouleBridge puts a runtime at the site and moves the proof boundary closer to the device. It canonicalizes reads and commands, signs the exact representation, evaluates policy, stores the receipt in an append-only local ledger, and exports a proof pack. The cloud can still coordinate. The dashboard can still explain. But the evidence starts where the physical event starts.

Safety is a system property, not a component property.

Leveson's sentence is about safety, but it lands cleanly in energy infrastructure. A charger can be correct. A meter can be correct. A tariff table can be correct. The site can still be untrustworthy if the system cannot prove which reading, command, rule, and signer produced the final state.

The problem in one sentence

Energy sites are now controlled by software, but most site records are still ordinary logs.

Ordinary logs are fine when the only reader is the operator debugging a bad Tuesday. They are weak when money moves, regulators ask questions, tariffs change at the boundary of an hour, or an AI agent proposes a dispatch command that affects a depot bill. A log line can be missing. A timestamp can drift. A device identifier can be vendor-local. A dashboard can round a number. A cloud service can replay stale state. Everyone in the chain can be acting in good faith and still end up with three incompatible versions of the same event.

That is the specific gap JouleBridge targets. It does not try to replace every charger management system or every AMI head-end. It sits underneath the business workflow and asks for stronger input material. If a meter reports a reading, the runtime should know the source, the normalized unit, the timestamp, the canonical bytes, the hash, the previous chain head, the key that signed it, and the policy result attached to it. If a command is rejected, that rejection should also be a signed artifact. Failed control is still evidence.

The energy software market is not short of dashboards. It may be oversupplied with them. A dashboard is a weather report. JouleBridge is more like the calibrated instrument and signed lab notebook underneath it. The distinction sounds pedantic until the first disputed bill arrives.

A Pune depot dispute

Take a Pune EV depot with 12 chargers. The operator runs two shifts, charges three-wheelers and delivery vehicles overnight, and buys power on a commercial tariff. The chargers report 41,800 kWh for the month. The meter import says 47,600 kWh. The bill lands with a gap large enough to matter.

The current workflow is not a system. It is a negotiation. The charging platform has a session export. The discom has a meter reading. The depot manager has a spreadsheet. Someone will search for a missing session, a failed meter poll, a clock offset, a tariff misclassification, or a charger that kept drawing power after the session closed. If the gap is small, it gets absorbed. If the gap is large, it becomes a dispute. If the gap repeats, it becomes a customer relationship problem.

Now add AI dispatch to the same site. A battery is available. Tariffs change by time window. A cloud optimizer decides whether to draw from the grid, battery, or solar. The optimizer may be smart, but unless every read and command leaves a signed receipt, the operator is still asking finance to trust a dashboard. That is how dashboard-only energy startups become PowerPoint companies with nicer colors.

In the JouleBridge model, the depot exports a proof pack for the billing period. The pack contains ordered records for meter reads, charger states, accepted commands, rejected commands, policy bundle IDs, chain heads, and signatures. The discom, auditor, or counterparty can run a verifier. The question changes from "which dashboard do we believe" to "which chain verifies."

Why the runtime has to be local

The field is where the truth begins. Not the cloud. Not the BI warehouse. Not the investor demo running on a laptop with airport Wi-Fi and brave optimism.

An edge runtime is software that runs near the physical equipment. In JouleBridge, that means a gateway process at the site. It reads adapter events from devices and local systems, normalizes them, signs them, writes them, and syncs outward when connectivity allows. The cloud is downstream. It can coordinate policies, receive evidence packs, and show operator views. It should not be the first place where an event becomes trustworthy.

Local matters for four reasons.

First, latency. Some controls are too close to equipment to wait for a cloud round trip. Second, connectivity. Energy sites do not become legally simpler when the internet is down. Third, provenance. If the cloud signs data after ingestion, it proves the cloud saw the data. It does not prove the site produced it. Fourth, failure handling. A gateway that reboots, a meter that pauses, or a charger that reports stale state should create a reviewable record. Silence is not an operating mode.

{
  "event_id": "evt-ocpp-8042",
  "charger_id": "ocpp-gw-17",
  "connector_id": 1,
  "observed_at": "2026-05-16T09:12:00.000Z",
  "max_kw": 42.7,
  "meter_kwh": 18842.19,
  "tariff_window": "solar-midday"
}

Architecture

Bridge Kernel is the Rust runtime inside JouleBridge. Its pipeline is deliberately boring:

The adapter layer turns protocol-shaped input into runtime events. The current internal notes show fixture-backed or lab-ready coverage for Modbus TCP/RTU, OCPP, HTTP webhooks, MQTT, DNP3, IEC 61850, SunSpec, IEEE 2030.5, and a DLMS/COSEM simulator path. The honest boundary matters: those are not all equal production clients. The production wedge needs the adapters that the first site actually uses, then field hardening.

The canonicalizer makes each event deterministic. It normalizes units, timestamp forms, protocol field names, and sorted payload bytes before the proof layer sees them. This is where many systems quietly fail. They sign a blob that looks like data instead of signing a stable representation of the physical reading.

The proof engine hashes the event, links it to the previous chain hash, constructs signing bytes, signs with Ed25519, and assembles a proof envelope. The ledger stores accepted proof envelopes in SQLite with chain fields, partition columns, and sync state. The policy gate evaluates signed rules and records why an event was allowed, flagged, or denied.

That is the architecture. It is not magical. It is mostly the discipline to refuse unsigned ambiguity at the exact point where ambiguity is cheapest to remove.

Canonicalization, or why JSON betrays you

JSON looks deterministic until you hash it. Then it becomes a tiny legal argument wearing braces.

Two systems can represent the same event with different key order, whitespace, timestamp precision, number formatting, unit naming, or optional fields. A meter read of 19.42 kWh can arrive as 19420 Wh. A timestamp can arrive as an RFC3339 string, seconds since epoch, milliseconds since epoch, or a vendor string that should be a crime but is somehow in a production fleet. If those differences reach the signer, the hash becomes a formatting artifact rather than a proof of the underlying event.

The W3C's RDFC-1.0 recommendation exists because this class of problem is real beyond one data format. It defines canonicalization for RDF datasets so comparison, signing, and hashing can work over stable representations. JouleBridge uses the same engineering posture for energy events: before signing, make the event representation stable.

This is not an academic nicety. If a charger platform, depot gateway, and verifier cannot compute the same event hash, the signature becomes useless for dispute resolution. Everyone can be holding a valid-looking record and still fail to agree on what was signed.

The JouleBridge canonicalizer is intentionally scoped. It handles known units, timestamp normalization, sorted payloads, and first protocol-specific field renames. It does not pretend to be a universal ontology for every energy protocol. The right sequence is: prove the current wedge, learn from real site adapters, then expand the mapping layer where field data demands it.

The proof envelope

The proof envelope is the durable artifact. It is what the ledger stores and what the verifier reads.

Each field has a job. The event hash proves the canonical event bytes. The previous chain hash proves ordering. The chain hash commits the current event into the local sequence. The timestamp attestation states the runtime's time claim. The policy result says what rules were in effect. The signer identifies which key produced the signature. The signature binds the proof bytes.

NIST FIPS 186-5 matters here because Ed25519 is not a vibe. It is a digital signature algorithm with a standard verifier story. Log-backed storage work such as WiscKey matters because the runtime needs boring persistence patterns that can survive real process behavior. Canonicalization standards matter because the signature is only as useful as the bytes it signs.

The future hardware boundary is clear. Production deployments need hardware-backed key storage: TPM, secure element, or HSM depending on site class. Software-managed keys are good enough for development and lab proof. They are not the final trust boundary for a serious energy site.

Policy gate

A signature answers "who signed this." It does not answer "should this have happened."

That second question belongs to the policy gate. A policy bundle can express site import limits, charger priority, consent rules, tariff windows, maintenance locks, timestamp windows, anomaly thresholds, and emergency states. The runtime evaluates the proposed event or command against the active signed bundle and records the decision.

The important design choice is that rejection is not hidden. A rejected action becomes evidence. If an optimizer tries to exceed a 100 kW site limit, the runtime should not merely return an error to the UI. It should write a signed rejection with the attempted command, the active rule, and the reason. Bad attempts are often the most useful records in a control system.

This is where a lot of AI energy software will embarrass itself. A model that says "charge now" is not an operator. It is a proposal source. If the runtime cannot show which rule allowed the proposal, the AI layer is just another dashboard wearing a lab coat.

Evidence pack

An evidence pack is the exportable answer to a dispute or audit. It should contain site metadata, device list, time window, ordered proof envelopes, chain heads, policy bundle references, anomaly counts, verifier instructions, and an export hash. A PDF can help humans. The machine-verifiable pack is the product.

The verifier should not need to call JouleBridge Cloud. It should read the pack, recompute canonical event hashes, verify signatures, walk the chain, and report whether the sequence is intact. That is the difference between a company saying "trust our platform" and a system handing over evidence that survives outside the platform.

The pack also has to be useful to three different readers. The operator wants to know whether the month closes. The discom or counterparty wants to know whether the disputed reading is supported. The engineer wants to know where the chain failed if it failed. A single artifact can serve all three if it keeps the raw proof material and the human summary separate.

That separation is a product decision. If the human summary says "all good" but the raw proof section cannot be replayed, the summary is decoration. If the raw proof section verifies but no human can tell which charger or meter was involved, the pack is a cryptographic escape room. JouleBridge has to make both parts boring.

The first evidence pack can be JSON because the verifier is the important part. A later PDF summary can make the output easier for finance and operations teams. The PDF should never become the authority. It should be a rendered view of the same export hash, chain head, proof count, and anomaly set.

Most of the interesting energy markets are high-growth, developing world markets.

India is exactly that kind of market. EV charging, smart meters, AMISPs, solar rooftops, batteries, and AI-assisted dispatch are arriving in the same decade. If the proof layer is weak, every new control surface becomes one more place for disputes to hide.

Independent verification

The independent verifier is the moral center of the architecture. Without it, JouleBridge is just asking the market to trust a different server.

A verifier run should be plain. Load the evidence pack. Read the metadata. Check the exported file hash. Iterate the ordered proof envelopes. For each envelope, rebuild the canonical event bytes, recompute the event hash, recompute the chain hash from the previous chain head, reconstruct the signing bytes, verify the Ed25519 signature, and compare the policy result to the active bundle reference. At the end, report the final chain head and every gap, mismatch, missing field, bad signature, or ordering failure.

This sounds like plumbing because it is plumbing. Payments, securities, aircraft maintenance, and medical devices all depend on similarly boring review surfaces. Energy is late to this habit because the old grid did not expose the same volume of distributed, software-issued actions. Quarterly meter reads and manual dispute workflows can tolerate soft logs. AI-assisted dispatch across chargers, batteries, and tariff windows cannot.

The verifier also changes sales. A normal SaaS pitch says, "We have analytics." A proof-layer pitch says, "Take our export and break it." That is a different relationship with the buyer. It invites skepticism because skepticism is the buyer's real job. A utility, fleet operator, or AMISP does not need to admire the dashboard. It needs to know whether the evidence survives a hostile read.

There is a useful failure mode here. If the verifier fails, JouleBridge should not hide the failure behind customer-success poetry. It should say exactly where the chain broke. Bad signature at event 18,231. Missing previous hash at event 20,104. Policy bundle reference not found. Clock attestation outside allowed window. Those failures are painful, but they are also product data. A system that can point to the fracture is easier to improve than a system that only says "sync error."

Command receipts

Reads are only half the problem. Commands need receipts too.

An EV charger command might start from an operator console, a tariff-aware scheduler, a fleet route planner, or an AI optimizer. The command can be useful and still unsafe. It may ask too much site import during a peak window. It may violate a battery reserve rule. It may target the wrong charger because a vehicle assignment changed. It may arrive after the operator already placed the site into maintenance mode.

JouleBridge treats a command proposal as an event with consequences. The proposal is canonicalized. The policy gate evaluates it. The runtime signs either the accept path or the reject path. If accepted, the issued command and downstream device response get their own records. If rejected, the attempted command remains in the ledger with the rule that stopped it.

This is where the runtime earns its keep. A dashboard-only system can say a command was not sent. A signed runtime can show the exact command proposal, the active policy bundle, the rule evaluation, and the signed rejection. That matters when an AI agent is involved because "the model decided" is not an audit trail. It is a confession that nobody designed the control boundary.

Rejected commands are not embarrassments. They are proof that the boundary worked. A site that rejects an unsafe dispatch plan is behaving well. The useful product surface is not the absence of red marks. It is the ability to explain every red mark without a support engineer spelunking logs at midnight.

Security model

The security model is intentionally modest. JouleBridge does not claim that a small gateway makes a site magically tamper-proof. It claims that a signed local record makes tampering detectable and reviewable within the assumptions of the deployment.

The key assumptions are simple. The verifier must know the site public key or the trust chain that binds the key to the site. The runtime private key must be protected well enough for the site class. The canonicalizer and verifier must agree on bytes. The ledger must preserve ordering. The policy bundle must be signed or otherwise authenticated before it can govern events. The export path must preserve the evidence pack without silent mutation.

Each assumption has a failure mode. If a private key leaks, the site needs rotation and a signed transition record. If a gateway is physically compromised, the evidence after the compromise point needs suspicion. If the canonicalizer has a bug, signatures can be valid over bad representations. If policy bundles are not authenticated, an attacker can turn the guardrail into theater. If the cloud can rewrite exported packs, the verifier has to catch it through export hashes and chain heads.

This is why the roadmap includes hardware-backed key storage. TPMs, secure elements, or HSMs do not make the rest of the design automatic, but they move the private key out of the easiest failure path. They also make the sales conversation cleaner. A pilot can begin with software-managed keys. A serious deployment should not end there.

Why this is hard

The hard part is not adding SHA-256 to a codebase. The hard part is making proof survive the field.

Devices speak different protocols. DLMS/COSEM meter realities do not look like OCPP charger realities. Clocks drift. Gateways reboot. Operators override. Firmware versions change. A meter can report a stale value. A charger can miss a session boundary. The network can go down exactly when the tariff window changes, because infrastructure has a sense of humor and it is not friendly.

JouleBridge has to treat those cases as normal. That means explicit adapter boundaries, quarantine paths, policy explanations, replayable records, ledger integrity checks, archive and compaction rules, and evidence exports that admit uncertainty rather than hiding it under a green badge.

It also means the product cannot become a blockchain-for-energy cosplay project. Public consensus is not the missing thing at a depot. Local verifiability is. The site needs a chain it can export, not a token with a white paper and a Telegram group.

What is built, what is not

The public website should be precise here. Bridge Kernel exists as a Rust runtime design with implementation slices for canonicalization, proof envelopes, hash chaining, policy evaluation, local ledger persistence, adapter-shaped ingestion, sync paths, and evidence-ready package export. The local engineering notes show completed work on timestamp attestation, additive COSE-style packaging metadata, batch proof exports, policy explanations, tenant/site/device partition columns, and persisted ledger integrity verification.

The console and cloud exist as part of the broader JouleBridge product surface. The status block on the project page correctly frames the system as active company work, not a mature utility deployment. That distinction matters. Overclaiming production maturity would be the fastest way to make a serious reader stop trusting the paper.

The strongest current claim is this: the architecture and core proof path are real enough to evaluate. The deployment story still has to earn its scars.

Full hardware key storage is not finished. The production DLMS/COSEM path still needs field-grade transport, security-suite handling, external simulator validation, and live meter testing. OCPP and Modbus need real deployment hardening beyond fixture and lab coverage. PDF evidence-pack summaries are still future work. The company does not yet have a paid production pilot.

Those are not footnotes. They are the next risks. A signed runtime company lives or dies on whether the field version matches the paper version when a site behaves badly.

The sequence is legible: convert a pilot, harden the adapter path against actual site devices, move keys into hardware-backed storage, make the verifier boring enough for a counterparty, and turn evidence packs into the default artifact for billing and dispute workflows. This is also where startup storytelling has to stay modest. Name the trust boundary, name the weak parts, and improve them in public.

Standards posture and what comes next

JouleBridge should be standards-friendly without waiting for a standards body to bless the category into existence.

OCPP matters for charger workflows. DLMS/COSEM matters for Indian metering. Modbus matters because industrial equipment is not going to retire itself to make a startup's architecture diagram cleaner. Canonicalization standards matter for stable signing input. FIPS 186-5 matters for digital signatures. COSE may matter for future proof packaging. None of these standards, alone, creates the product. The product is the runtime boundary that composes them into a site record that can be checked.

That is the right relationship with standards: use them where they remove ambiguity, avoid cargo-cult compliance where they do not, and keep the product honest about what it implements today. A half-built DLMS adapter with a clear boundary is better than a brochure claiming universal meter support. A JSON proof envelope with COSE-style metadata is better than pretending the system already emits complete COSE-native transport if it does not.

The market will punish vagueness here. Energy buyers have seen enough vendor decks where every protocol logo appears in a heroic grid. The useful question is narrower: which protocol path is fielded, against which device class, with which failure logs, and with which verifier output? That is the level of specificity JouleBridge has to reach.

The next JouleBridge milestone is not a bigger homepage. It is a site that produces evidence under pressure. One depot, one gateway, one billing period, one verifier run that an operator can understand. Then more protocols. Then stronger key storage. Then standards alignment where it helps.

If JouleBridge works, the category it creates is not "AI energy optimization." That market will be noisy, crowded, and full of decks showing hockey-stick curves through 2030 with zero customers in 2026. The category is signed site evidence for energy operations.

The grid is going to get more software-controlled. That part is already happening. The useful question is whether the software can prove its own work.

Sources

• W3C RDF Dataset Canonicalization, RDFC-1.0
• NIST FIPS 186-5: Digital Signature Standard
• WiscKey: Separating Keys from Values in SSD-Conscious Storage
• Nancy Leveson, Engineering a Safer World, MIT Press
• Vinod Khosla interview on energy markets, Scientific American
• Open Charge Alliance OCPP 1.6 protocol page