LightSOPLang Dependency Optimisation

Graph-First Execution Model

Every LightSOPLang variable is declared exactly once. The interpreter treats each declaration as a node in a directed acyclic graph (DAG) whose edges are derived from references such as $report. This graph makes optimisation straightforward: the engine can topologically order commands, parallelise safe segments, and detect cycles before execution. Alternative approaches—manual dependency bookkeeping or ad-hoc tool calls—tend to devolve into brittle imperative code. By giving the LLM a DSL that mirrors the graph explicitly, we get explainable plans while the interpreter handles dependency complexity.

Because the DSL is compact, large language models can regenerate plans reliably without learning the entire execution protocol. They specify intent in LightSOPLang, the interpreter builds the graph, and human reviewers see a deterministic representation instead of opaque tool logs.

Value States and Propagation

Each variable carries a value record with four possible states:

• undefined: The default state before any command runs.
• success: The command executed and produced a result.
• fail: Execution threw an error or returned a failure outcome.
• canceled: Execution was skipped deliberately (for example, a plan branch abandoned by heuristics or user intervention).

Whenever a variable ends up undefined, fail, or canceled, the interpreter automatically marks every dependent variable as undefined to signal that recomputation is required. If a value transitions from success to fail (or fail to success), or the declaration itself changes, the same invalidation applies so that the graph always reflects the latest data.

Status transitions cascade according to the root cause: dependants of a fail node drop back to undefined so they can re-run once the failure clears, dependants of a canceled node inherit canceled, and dependants of an undefined node remain undefined. This aggressive propagation keeps the execution consistent even when regeneration is triggered mid-flight.

Timestamps and Deterministic Rebuilds

The interpreter stamps every value with the millisecond timestamp of its latest update. During evaluation it compares timestamps to decide whether a dependant is stale. If an upstream value is newer than a dependant, the dependant flips back to undefined and re-executes. This timestamp check is lightweight yet crucial: it allows the engine to short-circuit recomputation when nothing changed, and to recover gracefully when regeneration produces a revised script.

Contrasting with Manual Graph Handling

Manual dependency management usually demands additional tooling: developers script graph traversals, maintain caches, or lean on workflow engines built for batch jobs rather than conversational agents. Those systems struggle with mid-conversation revisions because they assume static DAGs. LightSOPLang’s single-declaration DSL lets the LLM emit a plan that doubles as documentation. The interpreter then handles all invalidation logic so humans and agents never touch the graph directly.

Another benefit is reviewability: by reading the DSL, operators understand why each command exists. LLMs excel at altering this representation, whereas editing a JSON graph or imperative script is error-prone. The DSL becomes a safe middle ground between natural language prompts and low-level orchestration.

Risks and Mitigations

Despite its advantages, the model introduces risks. A faulty script can cause repeated recomputation if dependencies oscillate between success and fail. Timestamp-driven invalidations mitigate infinite loops but developers should still guard against non-deterministic commands. The canceled state is powerful yet dangerous: if the LLM cancels critical steps by mistake, dependants inherit the cancellation automatically. Ensure review flows or tests cover cancellation semantics.

Finally, because each variable has a single declaration, scripts must be regenerated when major control-flow changes are needed. This constraint keeps the graph simple, but authors should model optional behaviour via sub-commands or conditional LightSOPLang patterns rather than attempting to redeclare variables inline.