FOUNDATION · EXPLANATORY

Design principles that keep SDL from becoming another proprietary integration layer.

These principles guide specifications, reference software and future project proposals.

Status: DraftVersion: 0.1Document: SDL-CONCEPT-002
01

Business intent over hardware instructions

Applications request operations such as start_cycle, not relay timing or register writes.

02

Stable asset identity

A machine keeps the same operational identity when its controller or wiring changes.

03

Capability-based interoperability

Applications discover what an asset supports instead of assuming behavior from its type.

04

Local-first execution

Real-time validation, safety and physical execution remain available at the site.

05

Commands are requests; events are facts

Sending a command is not evidence that the requested physical result occurred.

06

Acceptance, execution and confirmation differ

The architecture distinguishes validation, hardware action and observed machine state.

07

Idempotency before retry

Duplicate delivery must not cause duplicate paid cycles or repeated physical actions.

08

Expired commands do not become future actions

Delayed time-sensitive commands are rejected rather than executed after reconnection.

09

State reflects confidence

Unknown, offline and stale states are never silently treated as idle.

10

Safety decisions stay near the device

Pump timeouts, interlocks and output limits are enforced locally.

11

Configuration is versioned operational data

Mappings and safety values are validated, auditable and recoverable.

12

Specifications define meaning; bindings define transport

Core semantics remain independent of MQTT, HTTP or future transports.

Every future SDL proposal should answer these questions.

  • Does it expose business intent or hardware detail?
  • What happens when the cloud is unavailable?
  • How is physical success confirmed?
  • Can a duplicate command cause a repeated action?
  • What is the safe failure behavior?
  • Can the behavior be simulated and tested?
  • Does it preserve compatibility with the shared core?
  • Is the feature documented clearly enough for another implementation?