Why is Noumena's scheduling and retry design called "idempotent", and why does that make it resilient?

Idempotent means running the same operation many times has the same effect as running it once — so retries and duplicate triggers are safe, and race conditions cannot cause double effects.

The invocation logic is inherently idempotent: even if the same permission is triggered multiple times, only the first valid execution proceeds, and all others are rejected based on the current protocol state — gracefully returning an error that the protocol is no longer in the expected state, without side effects. This protects against two hazards at once:

• Race conditions — if a crash happens, or several schedulers try to invoke the same permission concurrently, only one succeeds; the rest fail cleanly.
• Unsafe retries — external systems can retry without fear of causing inconsistent outcomes.

Because of this, system designers only need to keep the monitoring healthy; the underlying scheduling, queuing, and atomic execution guarantees are managed by the Runtime's internal transactional task scheduler.

Go deeper:

• Optimistic concurrency control (Wikipedia) — the "let the first valid write win, reject the stale ones" strategy that lets concurrent, retried invocations stay consistent without locking.