LOX · CONTROL PRIMITIVE

LOX Perm

Make a start permissive or running interlock inspectable.

A heap-free, single-header C99 evaluator combines named Boolean conditions with qualification, latching, bypass metadata and first-out diagnostics. The same chain can gate a start or be reevaluated while an action runs.

DevelopmentC99 · header-onlyMITCaller-owned state
Last verified
2026-09-18 · public header, scenarios, limitations and evidence matrix reviewed
Integration boundary
Application supplies Boolean observations, time and action response
01 / TWO CONTROL PATTERNS

Start permission and run protection are separate decisions

A permissive is evaluated when a start is requested. An interlock is reevaluated while the action is running; if it denies, the caller stops the action. The library provides the condition model and verdict, while the application decides when to evaluate and what physical response to take.

START REQUEST

Permissive chain

Evaluate conditions before starting. A denied start can expose a mask and first-out index for operator diagnostics.

request→evaluate→allow / deny start
ACTION ACTIVE

Interlock chain

Evaluate repeatedly during operation. Latching definitions can hold a trip until explicit reset instead of allowing automatic restart when an input clears.

running→evaluate→continue / stop
02 / CONDITION LIFECYCLE

Boolean observations become qualified chain state

The caller defines a fixed set of tagged conditions at initialization. Each may be latching, bypassable or require a qualification interval. The caller updates each condition with its Boolean value and monotonic millisecond time, then asks whether the chain is permitted.

INPUTSCaller booleansanalog thresholds evaluated upstream
→
QUALIFYHold true for durationoptional per-condition delay
→
CHAINAll conditions requiredlatch / bypass rules applied
→
VERDICTPermit or denycaller controls the action

Definitions are fixed at initialization; changing latch, bypass or qualification configuration requires reinitializing the chain. The configured chain size is bounded and cannot grow dynamically.

03 / WHY A DENIAL HAPPENED

First-out and denial masks support an operator view

When a chain enters a denied episode, first-out identifies the condition that transitioned to denied first; equal timestamps resolve to the lowest index. The denial mask identifies all currently failing conditions. First-out is per chain, not a global ordering across several chains.

Optional bypass is allowed only for conditions declared bypassable. The API records operator metadata and exposes the bypass mask. It does not enforce second-person approval, expiry windows or plant-specific bypass restrictions; those controls belong in the application policy.

DENIAL TRACE
qualified condition drops
↓
chain changes to denied
↓
first-out index is retained
↓
denial mask drives display / log
clear and re-entering denial begins a new episode
04 / TRANSFER AND PERSISTENCE

Portable snapshot bytes are validated, not self-protecting

The runtime snapshot object is an in-memory transfer type, not a stable disk format. Fixed wire helpers encode and decode a portable fixed-size representation with magic, byte order, schema/config identifiers and validation of reserved bytes and masks.

The wire format has no CRC or other integrity check. A flash or EEPROM integration must add atomicity and corruption detection at its storage layer. Restoring a snapshot also restores bypass state, so products that clear bypasses on reboot must explicitly reset the chain after restore.

Integrity boundary. Format validation rejects malformed or incompatible snapshots; it does not detect every torn write or provide authentication.
05 / TEST AND PACKAGE EVIDENCE

Configuration and behavior have explicit host checks

The evidence matrix maps tests for snapshot round trips and invalid inputs, first-out tie breaking, wide-mask bit 63, configuration boundary compile checks and C++ inclusion checks. The repository also describes an installed-package consumer smoke for C and C++.

These are source/documented test claims. They do not establish target hardware timing, safety integrity or suitability for a safety-instrumented system. The repository explicitly disclaims SIL and ISO 26262 claims.

06 / SCOPE BOUNDARIES

A control primitive, not a safety system

  • Inputs are Boolean; thresholds, voting and analog logic are external.
  • Chain size and per-condition configuration are fixed at initialization.
  • Bypass expiry, authorization policy and maintenance-window enforcement are caller responsibilities.
  • Same-chain concurrent access requires external synchronization; no mutex is included.
  • Portable wire snapshots do not provide CRC, atomic writes or tamper resistance.
  • The project is not safety-rated and provides no SIL or ASIL conformance claim.

LOX product family · All products