Documentation
Platform site
Docs/Product guides

Flagship product

Kernary Engineer

The autonomous embedded systems engineer coordinates specialist agents and deterministic tools across bring-up, diagnosis, repair and evidence review.

How it operates

EngineerorchestratorSYSTEMKERNELTESTDIAGNOSEBSP INTEGRATION
The orchestrator delegates subsystem work but retains one plan, policy boundary and evidence history.
  1. 01
    Plan

    Convert product intent into staged work with explicit acceptance criteria.

  2. 02
    Delegate

    Route tasks to boot, kernel, device-tree, build, test and diagnosis specialists.

  3. 03
    Execute

    Invoke typed Git, build, simulation, board and test tools.

  4. 04
    Prove

    Require durable artefacts and measurements before a stage can complete.

  5. 05
    Pause

    Stop at merge, signing, destructive hardware and production release gates.

Start a workflow

Terminal · proposed CLI
kernary engineer run \
  --project orbit-controller \
  --goal "enable CAN1 at 500 kbit/s and pass HIL" \
  --policy review-required \
  --attach build,board,evidence
Illustrative event stream
12:32:08  PLAN      8 stages / 14 acceptance checks
12:33:41  SOURCE    device-tree change proposed
12:37:12  BUILD     build://orbit-controller/2387 complete
12:40:55  BOARD     board://reservation/bay-07 attached
12:41:17  TEST      CAN loopback failed
12:41:22  DIAGNOSE  pinmux state conflicts with schematic net
12:42:04  REPAIR    minimal DTS patch proposed
12:43:04  TEST      18 passed / 0 failed
12:43:10  GATE      human release approval required

Specialist agents

AgentTypical scopeRequired evidence
System designRequirements, boot/security/update strategyAccepted plan and tests
BSP integrationBoard-specific sources, configuration, patches and provenancePinned sources and compatibility result
Boot chainBoot ROM, platform firmware (e.g., TF-A), bootloader (e.g., U-Boot) and boot mediaBoot logs and verified hand-offs
KernelKconfig, patches, modules and diagnosticsBuild plus runtime log
Device tree / driverBindings, pinmux, clocks and peripheralsValidation plus HIL result
Diagnosis / repairCorrelate logs, source, schematic and historyMinimal diff and rerun
ReleaseChecklist, SBOM and rollout proposalPolicy result and human approval

Permission model

  • Read project source and explicitly attached vendor material.
  • Propose source changes through version-controlled patches.
  • Request deterministic tool calls through typed policy proxies.
  • Request a board reservation and allowlisted recovery action.
  • Never access root signing keys or approve its own production release.

These docs are part of the product design. Interfaces remain proposals until an implementation is published.

View the platform →