Kerniv / Autonomous hardware validation
The AI validation engineer for physical hardware.
Kerniv is building an intelligent engineering platform that understands electronic designs, operates real test equipment, investigates hardware and firmware failures, and turns measurements into reproducible engineering evidence.
Early stage · design partners welcome
The gap
Software engineering automated its verification years ago: every change runs against deterministic checks before anyone trusts it. Physical engineering still depends on manual laboratory work — configure, measure, export, interpret, repeat — and on the experience of the engineer holding the probe.
A validation engineer’s evidence lives across:
The bottleneck is not collecting more data. It is connecting engineering intent with physical behavior.
Slow to start, hard to repeat, and dependent on whoever remembers the conditions of the last run.
Every experiment leaves a record: configuration, limits, measurement references and the reasoning that selected it.
Kerniv extends engineering capacity and removes repetitive diagnostic effort. It does not remove engineers from the loop — judgment, safety and sign-off stay with people.
Platform
Kerniv closes the loop between what a design is meant to do and what the hardware actually does. Reasoning selects and configures experiments; instruments execute them; measurements are graded against written acceptance criteria; and every result returns to the reasoning layer as new context.
What the hardware is supposed to do, and how it was meant to do it.
Reasoning over design intent: what to test, what failed, what to try next.
Approved actions on the equipment your lab already runs.
The hardware whose behavior decides whether the design is right.
Results a review can stand on — and re-run.
Platform vision Kerniv is in early development. The diagram describes the intended system; specific capabilities are scoped and validated with design partners rather than assumed shipped.
How it works
See how Kerniv could transform electrical measurements into a structured diagnostic investigation — using a low-voltage DC/DC converter and a load-transient failure as the worked example.
The system receives the converter schematic, firmware information and the engineering requirements, and resolves the circuit into functional blocks.
The requirements resolve into an executable load-transient test: a written pass/fail definition exists before any instrument is touched.
Approved instrument actions execute the test. Output voltage, load current and the switching node are captured on one timebase.
Measurements are graded against the written acceptance criteria — deterministically, without a model in the decision path.
Transient response outside acceptance — investigation opened
The deviation is measured evidence. The root cause is not yet established; the next steps exist to rank candidate explanations.
Candidate failure mechanisms are ranked against the measured signatures. These are hypotheses with stated support — not conclusions.
Consistent with the observed ≈ 1.3 kHz ring and the slow return toward regulation. An under-damped loop explains both signatures without additional assumptions.
Discriminating test Ring frequency should be invariant to V_IN but shift with load capacitance.
A slow or heavily filtered feedback path reduces effective loop bandwidth and produces the same class of response. Cannot be separated from compensation with the current data.
Discriminating test Sweep the sense filter corner and watch the ring frequency.
V_IN was not recorded during this run. A sagging input under step load would deepen the undershoot, but there is no evidence either way yet.
Discriminating test Repeat the step while recording V_IN at the converter terminals.
A current-limit event produces a flat-topped, hysteretic response. The measured recovery is smooth and oscillatory, which argues against this mechanism.
Discriminating test Deprioritized — no servicing evidence.
The system selects one additional test that can separate the leading explanations — inside a pre-approved electrical envelope.
Separate the loop response from the supply and the sense path
If the ring frequency tracks V_IN, supply impedance moves up the ranking. If it is invariant to V_IN but shifts with the sense filter, the feedback path dominates. Only then is a compensation change justified.
Everything above becomes one reviewable record: configuration, evidence, candidates and the open question.
Applications
Kerniv’s initial focus is the electronics that convert, control and protect power. The verification loop — intent, experiment, measurement, evidence — is designed to extend to adjacent systems as the platform matures.
Automating characterization, control-system investigation, protection testing and validation of converters and power stages.
Electrical validation for the systems behind motion and actuation — from inverter switching to current-loop behavior.
Connecting firmware debugging with observed physical behavior, so timing and integration defects surface as measurements.
Longer-range applicability to demanding conversion and protection systems, including power delivery for AI computing infrastructure.
Initial commercial focus: power converters, motor controllers and embedded control systems. Infrastructure applications describe intended future scope, not current product support.
Principles
These are design commitments, not aspirations. They are what keep an ambitious system honest in front of a real board, a real instrument and a real reviewer.
A plausible AI answer is not a test result. Verification outcomes come from measurements and objective acceptance criteria — never from how certain a model sounds.
Agents cannot change voltage limits, disable protection systems, bypass interlocks, or declare unsafe operations acceptable. Safety-critical control lives in deterministic code, bounded by equipment capabilities and approved by qualified engineers.
Every engineering result connects to its inputs, instrument settings, test conditions, execution history and the reasoning that selected it — so any conclusion can be reconstructed, not merely believed.
Engineering professionals define objectives, approve high-risk actions, interpret uncertainty and hold final sign-off. The platform is designed around that division of responsibility, not in spite of it.
Kerniv is intended to integrate with established measurement equipment and commodity computing. Its value is engineering reasoning and orchestration — not a walled garden of instruments.
Architecture
The platform is layered so that reasoning and verification never blur together. Each stage has one job, and the boundary between them is enforced in code.
Evidence returns to the runtime as new context — every experiment informs the next one.
The runtime proposes typed tool calls. A deterministic execution layer validates every call against pre-approved envelopes — voltage, current, timing, sequence — before anything reaches an instrument. Independent verifiers grade results against written criteria.
Model output never commands hardware directly, and an agent cannot certify its own work.
Integration with existing laboratory equipment comes first. A dedicated Kerniv acquisition device is a possible future product — not a prerequisite for working with the platform.
Intelligence is intended to run on commodity compute where practical: standard workstations, professional GPUs, local or appropriately secured model inference, and the computers your lab already owns.
Precise measurement timing, triggering, high-speed acquisition and protection may require dedicated FPGA, microcontroller or instrument hardware. The split is deliberate: reasoning on general compute, determinism on dedicated silicon.
Design partners
Kerniv is seeking engineering teams willing to explore a new approach to physical hardware testing, debugging and validation. We are especially interested in organizations developing power converters, motor controllers, robotic systems and complex embedded electronics.
What an engagement involves
Understand one recurring validation challenge and the manual workflow it lives in today.
Define success criteria, safety constraints and the engineering effort the task currently costs.
Connect the relevant documents, software and test instruments — within agreed data controls.
Develop a bounded validation workflow and measure its performance against the baseline.
Review results, limitations and next steps together. We would rather say no early than oversell.
Prefer email? Write directly to hello@kerniv.com — replies come from an engineer, usually within two business days.
About Kerniv
Kerniv is founded by an engineer with a doctorate in electrical engineering focused on power electronics and electrical machines. That background spans automotive electronics, converter systems, embedded hardware, technical leadership and hardware validation — the unglamorous work of proving a design survives its operating conditions.
The company exists because the hardest part of hardware engineering is not generating designs. It is producing evidence that they work. Kerniv applies AI where its output can be verified, and keeps people where judgment, safety and liability matter.
Working on a validation problem worth solving? Start a conversation or write to hello@kerniv.com.
Questions
If yours is not here, ask directly — we would rather answer the hard question early than discover it in week four.
Ask us somethingKerniv is building an AI-based engineering platform focused on hardware testing, validation and diagnosis. It connects engineering reasoning with real measurement instruments, so design hypotheses can be tested against physical behavior rather than plausible-sounding text.
No. Kerniv aims to automate repeatable engineering tasks and support investigation. Engineers retain responsibility for objectives, safety, interpretation of uncertainty and final decisions. If anything, the platform raises the value of experienced judgment.
The intended architecture prioritizes integration with existing instruments wherever technically feasible. Actual compatibility depends on the specific device and the scope of integration, and is established case by case during design-partner work.
Understanding electrical designs, embedded software and engineering requirements is central to the platform vision. Which formats and toolchains are supported first will be determined during development and design-partner engagements — not promised in advance.
Kerniv is in an early development and design-partner stage. Specific available capabilities, integration scope and limitations are confirmed during the initial discussion, so nobody is working from marketing claims.
Confidentiality and data control are design requirements, not afterthoughts. Actual storage, retention, hosting and security arrangements are defined and agreed in writing before any customer integration begins.
Autonomous execution must be constrained by deterministic safety mechanisms, equipment capabilities and appropriate human approval. Kerniv does not let language models command instruments outside pre-approved electrical and operational envelopes.