LOX · FAILURE SUPERVISION
LOX Guard
Detect and recover everywhere. Contain where hardware allows.
A C99 guard-block runtime wraps application work, classifies failures into structured events, evaluates policy actions and retains a small local evidence record. Its current verified scope is host behavior with defined limits.
DevelopmentC99v1.0.2Host-tested core
01 / FAILURE TO EVIDENCEDETECTReturn, timeout or eventblock / panic / watchdog input →CLASSIFYStructured eventsource, type, severity, state →DECIDEPolicy evaluationhistory maps to action →RECORDBlackbox and reportlocal evidence for inspection
One failure boundary connects detection to inspection
The architecture is organized around a guard-block failure boundary. Core responsibilities include block execution, event creation, policy evaluation, action dispatch and mode state. Optional adapters connect existing monitoring and recovery libraries around that core.
Actions can include logging, dropping input, recovery, disabling a module, degraded or safe mode, quarantine or a deliberate reboot. Policy defines what is appropriate for the event and application; the library does not establish that a chosen action is safe.
02 / GUARDED EXECUTION
A wrapper reports outcomes; it is not a sandbox
The public contract includes Guard Block execution through `loxguard_run(...)`, source/block registration, structured results and event/action reporting. Checked span and arena helpers offer opt-in bounds checks when code uses those APIs.
Checked access paths can reject out-of-range operations. They cannot prevent unrelated raw pointer writes in ordinary C, make arbitrary code memory-safe, or recover from every form of undefined behavior. Soft guard blocks are useful for explicit errors, controlled failures, timeout/liveness results and recovery policy.
SUPERVISED BLOCK
block enters with context
↓callback returns / reports failure
↓event classified
↓policy action + blackbox record
hardware isolation requires MPU / MMU / equivalent03 / LOCAL DIAGNOSTIC STATE
Retain a bounded account of recent failure
The blackbox stores a last-failure snapshot and a bounded recent-event ring, with report/export paths for host inspection. Documented fields include boot count, reset reason, last failed source, event type, action, system mode and failure count. The core can operate in RAM without requiring LOX DB.
Optional persistence bridges and adapters may route evidence to other project components, but a checked-in interface is not evidence of a working production integration. Repository evidence specifically marks companion-enabled configurations outside default CI as not verified.
04 / CHECKED SPANS AND ARENAS
Bounds checks apply to accesses routed through the API
The optional checked APIs expose span/arena helpers and macros for validated reads and writes. These can reject invalid offsets, length overflow and arena exhaustion in the supported interface. The checks do not instrument all code or intercept DMA, trusted driver bugs, privileged runtime corruption or physical attacks.
Structured host export/import formats cover event and report lines, with unit-test evidence for those behaviors. Wire formatting, parsing and event retention are distinct from durable persistence: the blackbox core is in-memory, and a backend must define storage semantics.
ArchitectureFailure pipelineChecked span and arena APIExport formats
05 / REPOSITORY EVIDENCE
Host core is verified within its stated limits
The v1.0.2 evidence matrix marks Guard Block result/action behavior, checked spans and arenas, bounded blackbox rollover, host export/import and host demo fault paths as verified by source/tests. It documents Windows and WSL GCC/Clang host verification and package/consumer checks. An ARM compile-only gate is incomplete.
Hardware behavior, power-loss consistency, production RTOS/MPU containment and companion-enabled builds are explicitly not verified unless raw artifacts/gates are present. ESP32 evidence directories contain placeholders per the matrix. This page reports the repository’s documented evidence, not a fresh hardware test.
06 / CONTAINMENT AND STATUS
Recovery policy is distinct from memory isolation
- Soft guard blocks do not contain arbitrary pointer corruption or make C memory-safe.
- Memory-fault containment needs hardware or an equivalent isolated execution environment; production MPU/RTOS behavior is not verified here.
- DMA misuse, trusted driver bugs, physical attacks and corrupted privileged runtime are outside the stated scope.
- The project makes no safety/security certification or compliance claim.
- Host-tested core behavior must not be read as embedded hardware validation.