Error Model

Z+ doesn't crash. Signal chains degrade. No try/catch. No exceptions. No stack traces. A node goes quiet and the chain responds according to its declared behavior. Graceful degradation is structural.

Silence as Signal

In every existing language, the absence of data is an error. In Z+, silence is information. Quiet is different from gone. Gone is different from dead. Each triggers different downstream behavior.

.zpgraded silence

// hold last known value
sensor -> on_silence: hold(t-1)

// emit safe default after timeout
sensor -> on_silence(> 500ms): emit(0)

// graded silence — different durations mean different things
sensor -> on_silence(> 100ms) -> "quiet"
sensor -> on_silence(> 1s) -> "gone"
sensor -> on_silence(> 10s) -> "dead"

Silence Patterns

Advanced silence detection for real-world failure modes.

.zpsilence patterns

// intermittent silence — the sensor flickers
sensor -> on_pattern(silence: intermittent, window: 10s) -> "degrading"

// correlated silence — two sensors go quiet together
sensor_a -> |
             | on_silence(correlated, > 500ms) -> "shared_failure"
sensor_b -> |

// spike then silence — it screamed, then went quiet (bad)
sensor -> on_pattern(spike then silence, within: 200ms) -> "catastrophic"

The spike-then-silence pattern is something every embedded engineer knows intuitively. A sensor that spikes and then goes quiet is fundamentally different from one that slowly fades. Z+ expresses this distinction in one line.

Downstream Response

.zpdownstream behavior

// different responses to different silence grades
sensor -> heartbeat -> {
    "quiet" -> wait,
    "gone"  -> failover -> backup_sensor,
    "dead"  -> alert -> decommission
}

Retry

When operations fail, retry policies are structural — declared in the wiring, not bolted on.

Simple Retry

.zpsimple retry

// retry 3 times, then dead-letter
operation -> on_fail(retries: 3) -> dead_letter

Escalating Retry

.zpescalating retry

// increasing delays between retries
operation -> on_fail(schedule: [1s, 10s, 1m]) -> dead_letter

Per-Attempt Behavior

.zpper-attempt

// different behavior per attempt
retry -> {
    attempt(1) -> notify("retrying"),
    attempt(2) -> notify("second attempt"),
    attempt(3) -> escalate
}

FAFO — Consequence Awareness

The compiler knows about consequences. Not a hard stop. Not a nanny. A question: "hey, you sure?"

.zpcompiler warnings

// wire a heater with no thermal protection:
// COMPILER WARNING: node 'heater' has no telemetry constraint
// "You sure about that?"

// wire a gate with no knee on a safety-critical path:
// COMPILER WARNING: gate has no knee — hard cutoff on safety path
// "Consider adding knee for smooth transition"

← Priority Channels→