Documentation
Platform site
Docs/Core platform

System design

Platform architecture

KERNARY separates reasoning, deterministic execution, physical control and production authority while linking every output through a shared evidence graph.

System boundaries

Kernary Control PlaneBuild planecells · jobs · artefactsBoard planepower · debug · HILFleet planecohorts · health · rollbackEvidence + Embedded System Knowledge
The control plane coordinates three execution planes; evidence updates Embedded System Knowledge.
BoundaryOwnsMust not own
EngineerPlanning, diagnosis, tool selectionSigning keys or unrestricted hardware
Build planeSource execution, compilation, artefactsCross-tenant writable state
Board planeReservation, flash, power, serial, instrumentsRelease approval
Fleet planeDeployment cohorts, health and rollbackAgent-defined global policy
Control planeIdentity, policy, workflow and auditCustomer build execution

Workflow state machine

Proposed workflow states
SPECIFIED → PLANNED → BUILDING → SIMULATED
    ↓                         ↓
  BLOCKED                 BOARD_VALIDATING
                              ↓
                         EVIDENCE_READY
                              ↓
                       AWAITING_APPROVAL
                              ↓
                    SIGNED → DEPLOYING → LEARNING

Every transition records its actor, policy decision, inputs, outputs and evidence references. A retry produces a new build or test run instead of silently mutating history.

Detailed engineering loop

The product-level system view stays simple, while execution advances through explicit stages. Each stage has its own acceptance criteria and can stop without silently advancing the release.

  1. 01
    Specify

    Capture the board, BSP, product constraints and required outcomes.

  2. 02
    Design

    Resolve the boot, kernel, driver, security and update strategy.

  3. 03
    Build

    Produce a reproducible image and versioned build manifest.

  4. 04
    Simulate

    Run static validation and QEMU or equivalent software-level tests.

  5. 05
    Validate

    Exercise the release candidate on the version-matched physical target.

  6. 06
    Release

    Pause at the policy-controlled human approval and signing boundary.

  7. 07
    Learn

    Return measured outcomes and retained failures to the system history.

Suggested service boundaries

Controlkernary-control

Projects, identity, policy, workflows and approvals.

Reasoningkernary-agent

Orchestrator, model adapters and specialist-agent runtime.

Executionkernary-build

Cells, snapshots, jobs, caches and artefacts.

Physicalkernary-board

Inventory, reservations, gateway protocol and instruments.

Knowledgekernary-graph

System entities, provenance, compatibility and failure history.

Lifecyclekernary-fleet

Devices, cohorts, telemetry, update health and rollback.

Trust principles

  • Reasoning may be probabilistic; builds, tests, measurements and signatures remain deterministic.
  • Agent cells receive short-lived scoped credentials through policy-enforcing tool proxies.
  • Signing occurs outside the agent sandbox with separation of duties.
  • Customer source, vendor material and schematics remain inside explicit tenant and provenance boundaries.
  • A successful build is weaker evidence than a successful version-matched physical test.

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

View the platform →