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.