latent-logic-substrate.md

Latent Logic Substrate

Status: PROPOSED

The Principle

LMPL works by aligning with latent logic and control structures that LLMs have learned from code, not by mimicking any one programming language syntax. It should use forms that activate deeply learned patterns of binding, branching, iteration, data flow, contracts, and tool use while avoiding target-language syntax traps.

Rationale

LLMs have been trained on large volumes of code across many languages. Across that training data, the same computational structures appear repeatedly with different surface syntax: assignments, conditions, loops, maps, filters, aggregations, assertions, function calls, error handling, and tool/API boundaries.

The thesis is that these repeated structures become more deeply embedded than any specific language syntax. A model does not need LMPL to be syntactically valid Python, SAS, SQL, or JavaScript. It needs LMPL to sit close to the shared latent representation beneath those languages.

This explains why structured pseudocode can outperform both unrestricted natural language and concrete target syntax:

• Compared with natural language, it provides regular procedural shape.
• Compared with target code, it avoids language-specific syntax and idiom traps.
• Compared with compiler IR, it stays near human and model semantic intent.

Examples

This LMPL fragment activates familiar cross-language concepts:

clean_customers <- raw_customers
    |> filter(where: age >= 18 and status != "DELETED")
    |> derive:
        risk_band <- match income:
            case income < 20000: "HIGH"
            case income < 50000: "MEDIUM"
            case _: "LOW"

The model has seen these ideas in many forms:

LMPL concept	Cross-language analogues
<- binding	assignment, let-binding, variable introduction
filter(where:)	SQL WHERE, pandas masks, R filter, LINQ Where
derive	pandas assign, SQL projection, mutate, map
match/case	switch, pattern matching, if/else ladders
pipeline `	>`

LMPL chooses the form that makes the shared operation visible without requiring exact target-language syntax.

Anti-Patterns

• Making LMPL syntax too novel for the model's learned code priors.
• Copying one source or target language so closely that LMPL inherits that language's traps.
• Replacing familiar control structures with clever symbolic notation.
• Treating formal grammar validity as more important than model interpretability.
• Adding abstractions that humans can define but models cannot reliably recognize from context.

Technical Reference

• ../../../core/language-reference.md §3 — The Latent Structure Argument
• runtime-self-description.md
• structured-pseudocode-as-semantic-compression.md
• ../a.related-domains/code-translation-ir.md
• Kumar et al., "Training with Pseudo-Code for Instruction Following", arXiv:2505.18011
• Thimmaiah et al., "PLSemanticsBench: Large Language Models As Programming Language Interpreters", arXiv:2510.03415
• EngineeringSoftware/PLSemanticsBench — benchmark repository for final-state, semantic-rule, and execution-trace prediction

Future Considerations

The latent-structure thesis should be tested by comparing LMPL forms against:

1. Concrete source-language code.
2. Concrete target-language code.
3. Natural-language explanations.
4. Opaque symbolic DSL forms.

If the thesis is correct, LMPL should be easiest for models when it uses familiar cross-language constructs and hardest when it invents compact but unfamiliar notation.

PLSemanticsBench provides a useful pattern for the perform.internal slice of this evaluation. Its tasks separate final-state prediction, semantic-rule prediction, and step-by-step execution-trace prediction. LMPL should borrow that separation rather than using one undifferentiated "did the model understand it?" score.