Developer Documentation

This is an overview of how Energy Quotient™ designs, builds, and maintains its platform. It is written for partners, integrators, prospective team members, and technical evaluators who want to understand how the system is engineered and how we work.

It is a narrative overview, not a specification. The authoritative engineering records — architecture decisions, enhancement proposals, design records, and code — live in the product repositories, and this overview links to them where they are relevant. Repository access is granted per engagement; contact [email protected] to request it.

The platform itself is documented for operators in the Platform Guide. This section covers the engineering behind it:

• How We Work — the engineering philosophy, and how a decision becomes shipped capability.
• System Design — how the platform fits together, from the physics interface to analytics.
• How It’s Built & Maintained — repositories, release flow, and how updates reach a deployed system.
• Standards & Quality — safety, EMC, testing, measurement integrity, and our responsible-use posture.

Our engineering practices serve the same commitments we make to customers: measurement before intervention, explainability by design, safety and uptime first, and respect for operational privacy. Those commitments are published in full at eq.systems/responsible-use.

How We Work

Engineering at Energy Quotient™ turns physics and field problems into shipped, maintainable capability. A few principles govern how that happens.

Design, then implement

Significant changes are designed before they are built. A design states the problem, the constraints, the chosen approach, and why the alternatives were not chosen. Implementation is then measured against that design rather than discovered as the code is written. Small, low-risk changes do not need a formal design; the effort is matched to what is at stake.

Design philosophy

One principle runs through the hardware, firmware, software, infrastructure, and documentation:

Design it well. Do what is necessary. Prove it works. Test. Revisit only if broken.

In practice that means:

• Design to meet the requirement. Start from the spec — a latency budget, a throughput or reliability target — and design to hit it directly. A latency-critical path, for example, is built event-driven (interrupts, device events, publish/subscribe, callbacks) rather than polled; polling and retry loops are usually a synchronization problem worked around rather than solved at the design level.
• One source of truth. Every fact, definition, configuration value, or specification lives in exactly one place; other locations reference it. Data redundancy is a maintenance burden and a source of contradictions, not a safety measure.
• Root cause over backup. When a failure mode is found, the first response is to eliminate it at the source. A redundant backup path is justified only when the root cause genuinely cannot be removed, the backup is tested, and it is worth its ongoing cost.
• Proportional effort. A status indicator warrants different rigor than a waveform data pipeline. Safety-critical paths get thorough failure analysis and tested protections; low-stakes paths get simplicity.
• Minimal and direct. Write the simplest code that correctly solves the problem, without configurability or defensive handling for cases that cannot occur or that duplicate guarantees the platform already provides.

Decisions are recorded

Decisions worth keeping are written down and kept with the work. Architecture decisions are recorded as ADRs; other decisions such as procurement, operations, and tooling are recorded as dated decision records. Decisions not worth a record get none, and working documents stay clean and action-oriented rather than carrying a history of what was once considered. The records live in the repositories, versioned alongside the code they explain.

Same values, throughout the stack

These practices are the engineering side of the commitments we make to customers. Correct-by-design measurement infrastructure is what makes measurement before intervention meaningful; a system simple enough to explain is what makes explainability by design achievable; and eliminating failure modes, rather than tolerating them, is what safety and uptime first requires in practice.

System Design

The platform is organized as four cornerstones, each an independently licensable capability, spanning the path from the physical measurement to analysis and action.

The four cornerstones

• EQ Wave™ — the sensor cornerstone and physics interface. EQ Wave is a Waveform Measurement Unit (WMU) that performs Continuous Point-on-Wave (CPOW) capture: uninterrupted, sample-by-sample recording of electrical waveforms at 32 ksps. A WMU is to waveforms what a PMU is to synchrophasors: a defined device class for high-resolution measurement.
• EQ Coherence™ — the data substrate. Coherence handles ingestion, filtering, query, analysis, and the APIs that other software and machines use to reach the data. EQ Sight™ is its user interface, the human connector to the substrate.
• EQ Syntropy™ — the cognition layer. Syntropy provides physics-grounded analytics and agentic AI, attaching to Coherence through its APIs as a consumer of substrate data.
• EQ Resolve™ — the control and corrective-action layer. Resolve produces bounded, authorized control commands in response to substrate state and Syntropy outputs. It acts as an authorized actuator responding to human operators or authorized control systems, not as an autonomous decision-maker.

EQ Forensics™ is a bespoke power-quality investigation service, not a productized component. It is delivered as an engagement that uses the cornerstones as the instrument.

How data flows

A deployment is a set of distributed EQ Wave nodes measuring at the points of interest, feeding an edge gateway that runs Coherence and Sight. Analysis and AI run against the substrate at the edge, with selective cloud augmentation where a customer chooses it. Raw waveforms default to staying on-site; exports and uploads are explicit choices. This local-first default, and the human-in-the-loop and bounded-control postures above, are deliberate.

The measurement interface is deliberately isolating: EQ Wave connects to the gateway over optical fiber, giving complete electrical separation from the monitored system with no conductive path back to the digital side. The operator-facing detail of the sensor, the gateway, and data access is in the Platform Guide.

How It’s Built & Maintained

The platform is developed as a set of focused repositories, released independently, and kept running through automated builds and controlled updates.

Repositories

The work is split by domain rather than kept in a single tree:

• Firmware for the EQ Wave sensor.
• Edge software for data collection, the substrate, and analytics.
• Company, documentation, and web properties, including this site.

Each repository holds its own code, tests, and engineering records. Source access is granted per engagement.

Branch model

main is protected in every repository and advances only through reviewed pull requests. Day-to-day work lands on a shared integration branch, scoped so that concurrent work stays out of each other’s way, and reaches main through a reviewed merge. History on shared branches is not rewritten. The intent is a clean, reviewable path from a change to a release, with the review step never skipped.

Release and deployment

The pieces of the platform deploy on their own cadence:

• Gateway software is delivered as GPG-signed, versioned packages installed on the edge gateway.
• EQ Sight is deployed as its part of the substrate to the edge, and to the cloud where a deployment uses it.
• Documentation is built as a static site and published to this hub.

Updates reach a deployed system through a GPG-signed APT repository: the gateway verifies each release against a pinned key, so a package installs only if its signature checks out, with version tracking and downgrade rejection. Deployments can run isolated or offline, with documented offline update procedures, so a system on a segmented or air-gapped network stays maintainable.

Continuous integration

Builds, checks, and deployments are automated per property. Changes are built and validated before they merge, and documentation and site changes are validated (links, images, and content checks) before they publish. Automation enforces the same discipline the branch model describes, so that what reaches a customer has been built and checked the same way every time.

Standards & Quality

Measurement equipment for mission-critical power systems has to be safe, has to coexist with sensitive environments, and has to produce numbers that hold up. Our approach to each is below. Where a claim describes design intent or work in progress rather than a completed certification, it says so.

Safety and certification

The measurement hardware is designed to certification intent from the start: CAT III measuring inputs, Class I construction, and the IEC 61010 family for measurement, control, and laboratory equipment. Formal listing is pursued through a Nationally Recognized Testing Laboratory (NRTL) engagement. We design to support compliance expectations, and we do not claim a certification until it is formally granted.

Electromagnetic compatibility

EMC is verified in stages. FCC pre-compliance testing on the bench catches issues early and de-risks the formal runs; accredited-laboratory testing follows for the formal result. As with safety certification, pre-compliance is a development step, not a substitute for the accredited result.

Testing

The sensor is exercised with hardware-in-the-loop testing against known signals, so that its behavior is checked against ground truth rather than assumed. The edge and analytics software is covered by automated tests that run in continuous integration before changes merge.

Measurement integrity

Any measurement that feeds a compliance or quality record is backed by calibrated, traceable bench instruments. This is what lets a diagnostic result be defended: every conclusion traces back through the analysis to a specific waveform measurement, and every measurement traces back to a calibrated reference.

Responsible use, security, and data governance

How the platform is engineered for security and responsible use is a first-class part of quality, not an afterthought. The posture in brief:

• Physics-grounded and explainable. AI produces diagnostic hypotheses tied to waveform evidence, with confidence and the next test to run, not opaque verdicts. Humans decide when safety or uptime is at stake.
• Local-first and privacy-respecting. Raw waveforms default to staying on-site. The platform is not for employee surveillance, and customer data is not sold.
• Secure by default. Least-privilege access with audit logging, encrypted communication, minimal open ports, and support for isolated and offline deployment.
• Bounded, authorized control. When EQ Resolve executes control actions, it does so within explicit customer authorization and bounded limits, with manual override and safe-state defaults.

Report a suspected vulnerability to [email protected]; we work with researchers following responsible disclosure.

These are summarized here; the full, current commitments — including data ownership, retention, security roadmap, and responsible-AI practices — are published at eq.systems/responsible-use.