Omega-Runner Programming Specification

This document specifies a complete programming model that unifies:

• The Ethics(5)/(6) constraint system
• The Python Programming Principles Linter
• A concrete Ω (Omega) runner architecture
• A deterministic, auditable execution model for effectful programs

Our goal is to make execution, sequencing, and responsibility boundaries explicit, eliminating hidden control flow and implicit continuation.

Principle: No entity may both decide and act on the same transition.

The system is divided into three disjoint layers:

These layers may not be collapsed.

Definition: Pure code computes values and descriptions. It does not interact with the external world.

Allowed:

• Branching
• Loops
• Computation
• Data transformation
• Enumeration of candidates

Forbidden:

• IO of any kind
• Time dependence
• Hidden state
• Side effects

Python requirement:

• Every pure function MUST be decorated with @pure
• Pure functions MUST NOT call IO primitives

Definition: An effect program realizes exactly one externally visible transition.

An effect program is a blind actuator.

Mandatory properties:

• Exactly one effect per invocation
• Unconditional execution
• Deterministic behavior given inputs
• Immediate termination after execution

Forbidden inside effect programs:

• Loops (for, while)
• Branching (if, match, ternary)
• Boolean logic
• Exception handling
• Retries
• Conditional execution
• Silent no-ops

Python requirement:

• Every effectful function MUST be decorated with @effect
• Effect functions MUST have at most one return
• Returns MUST be non-boolean tagged values
• Effect programs MUST NOT decide continuation

Ω is the governance layer.

Ω:

• Sequences effects
• Decides admissibility
• Maintains history
• Interprets failure
• Enforces idempotence

Ω is explicitly not Ethics-linted.

Ω MUST NOT:

• Perform the effects itself
• Embed effect logic internally

Ω MAY:

• Loop
• Branch
• Retry
• Abort
• Log
• Parallelize
• Apply heuristics or policy

An Effect Description is a pure value describing a possible transition.

Structure (conceptual):

• kind
• arguments
• expected output

Properties:

• Serializable
• Hashable
• Side-effect free
• Non-executing

EDs represent possibility, not action.

• Pure code generates a Candidate Set of EDs
• Ω evaluates each ED via an admissibility function
• Authorized EDs form the Authorized Set

Only authorized EDs may be executed.

Ω defines a pure function:

Ω_admit(History, ED) → {ADMIT, REJECT(reason)}

Properties:

• Deterministic
• Total
• Side-effect free
• Explicitly reasoned

Admissibility is a first-class concept.

For each authorized ED:

1. Ω invokes the corresponding effect program
2. Ω observes termination
3. Ω verifies expected artifacts
4. Ω records the result in history

Effect programs:

• Cannot observe Ω
• Cannot observe history
• Cannot observe each other

Effect programs do not handle failure.

Ω classifies outcomes as:

• SUCCESS
• FAILED_EXECUTION
• MISSING_OUTPUT
• CORRUPT_OUTPUT
• EXPECTATION_VIOLATION

Recovery and retries are Ω-only responsibilities.

Ω maintains an append-only history ledger.

Each entry includes:

• Effect ID (hash)
• Status
• Timestamp
• Optional checksum
• Optional note

History is immutable and replayable.

Each Effect Description has a canonical identity:

id = hash(kind, args, output)  

Ω MUST enforce:

• No re-execution of successful IDs
• Explicit handling of duplicates

This guarantees idempotence and replay safety.

The following rules are enforced by the linter and are part of this specification.

Function Declaration

• Every function MUST declare exactly one of @pure or @effect

IO Discipline

• IO is forbidden in pure functions
• IO is permitted only in effect functions or module-level effect context

Control Flow

• Effect functions MUST NOT branch or loop
• Pure functions MAY branch and loop

Returns

• Implicit None returns are forbidden
• Boolean returns are forbidden
• Tagged or structured values are required

Exceptions

• try / except / raise are forbidden
• Exceptions constitute hidden control flow

Hidden Control Flow

• Multiple returns in effect functions are forbidden
• Short-circuit logic in effect context is forbidden

Effect programs MUST execute their effect at module load time or via a single linear entrypoint.

Definition without execution is invalid.

Invariant: If nothing happened, the runner failed — not the program.

1. Pure phase:
   • CSV → Effect Descriptions
2. Ω phase:
   • Admissibility filtering
3. Effect phase:
   • One receipt per invocation
4. Ω phase:
   • Verification and attestation

Batching is externalized by design.

• “main loops” in effect code
• Silent guards
• Self-retrying programs
• Programs that decide their own continuation
• Mixing description, decision, and execution

No system component may both authorize and realize the same transition.

Violating this invariant collapses the system back into hidden control flow.

This specification makes Ethics(6) executable without weakening it.

• Theory is preserved
• Responsibility is explicit
• Failure is localized
• Auditability is guaranteed

Ω is no longer implicit.

Ω is now a named, specified, and enforceable component.