SenCore · Device runtime

A capability runtime that understands the physical system.

SenCore connects declared hardware facts to reusable modules, drivers, structured commands, and generated configuration—without turning one vendor SDK into the platform model.

Runtime surfacesFrom structured commands to managed delivery.
Live01 · COMMAND
SenCmdStructured device commands
Live02 · CONFIG
SenConfigGenerated configuration
Live03 · BUILD
SenBuildManaged firmware build
Beta04 · DELIVERY
OTADelivery UX hardening

Runtime contract

Capabilities on top. Hardware truth underneath.

A light is requested as a capability. The selected board and attached hardware determine whether a compatible module and driver can satisfy it. Missing facts or incompatible resources fail explicitly.

APPLICATIONenvironment-monitor
capability requirements
MODULESLight · Presence · Connectivity
driver bindings
HARDWARE FACTSBoard · Buses · Pins · Memory

Designed as a system

The device is not a collection of special cases.

SenCore gives device code stable responsibilities and lets product behavior remain portable where the facts support it.

01 · CONTRACT

Structured interaction

SenCmd describes commands, parameters, validation, responses, and errors as a versioned interface shared by devices and tooling.

02 · CONFIG

Generated, verifiable intent

SenConfig turns selected hardware and application choices into a concrete device configuration with an identifiable artifact.

03 · BACKENDS

Replaceable build machinery

Build systems and vendor SDKs are backends. They translate a canonical plan; they do not redefine boards, drivers, or capabilities.

device · structured command

$ sen cmd invoke axis.enable id=1 \
  --sencore-version 0.1.13

✓ command alias resolved
✓ parameters validated and sent

{ "code": 0, "status": "ok" }

Evaluate SenCore against real hardware requirements.

Start with the constraints you have—not a board-name shortcut—and see how the capability model resolves them.