Announcing LAILA 0.1.0

What's in LAILA 0.1.0

This release establishes LAILA as an end-to-end language workflow rather than just a syntax experiment. Source files can be parsed, checked, lowered into workflow plans, inspected through the CLI, and executed through the runtime engine.

A packaged language release

LAILA now ships as version 0.1.0 with a Python package definition, console entrypoint, and a focused language surface for AI workflow safety.

Core workflow primitives are present

The release includes schemas, fallbacks, workflows, typed inputs, infer, verify, trust, emit, and act.

Static safety checking is built in

The checker rejects invalid trust flows such as emitting values too early, trusting without required handling, using unknown schemas, or referencing missing fallbacks.

Lowering and runtime are part of the release

Valid programs lower into explicit workflow plans, and those plans are executed by the LAILA runtime with enforced infer / verify / trust / emit semantics.

Examples and tests ship with the project

The release includes runnable example workflows plus 135 passing tests covering checking, lowering, explanation, and runtime behavior.

LAILA 0.1.0 is intentionally small. The goal is not breadth — it is to make trust progression, fallback handling, and safe sinks explicit from day one.

Language features in this release

LAILA 0.1.0 is narrow on purpose. Instead of trying to be a general programming language, it focuses on the trust life cycle of AI-derived values.

Typed schemas and fallbacks

Outputs are described through schemas, and fallback values are declared explicitly so low-confidence paths are part of the program rather than afterthoughts.

Trust progression is first-class

infer produces model-derived values, verify promotes them through evidence or agreement, and trust handles the highest-confidence boundary before risky use.

Safe sinks are visible

emit and act are explicit sink points, making it possible for the checker to reason about where model outputs are allowed to flow.

schema Decision {
  action: string
}

fallback safe_decision = Decision {
  action: "escalate"
}

workflow decision_flow {
  input {
    question: string
  }

  infer draft: Decision from model "ops-model"
    using question

  verify reviewed from draft
    by vote 3
    require confidence >= 0.8
    else fallback safe_decision

  trust decision from reviewed
    require policy approval_policy_v1
    else escalate to human

  act apply_decision(decision)
}

schema fallback workflow infer verify trust emit act

CLI and tooling

The command-line interface is part of the release story. In 0.1.0, LAILA source can be checked, explained, lowered to a plan, and executed end-to-end through the LAILA runtime from a single entrypoint.

Commands available in 0.1.0

laila <file.laila>
laila check <file.laila>
laila ast <file.laila>
laila explain <file.laila>
laila explain --json <file.laila>
laila plan <file.laila>
laila run <file.laila>

Why that matters

This makes the language inspectable from multiple angles: syntax tree for authors, explanations for policy review, plans for runtime understanding, and execution for end-to-end demos.

Static checks and safety boundaries

A major part of 0.1.0 is not just what LAILA can express, but what it refuses to allow. The current checker and test suite focus on making trust mistakes visible early.

Programs rejected in this release

duplicate bindings
unknown schemas or fallback names
unknown names in using clauses
missing requirements on verify / trust edges
invalid emit and act flows
attempts to trust or act on the wrong trust level

What the checker is aiming for

LAILA makes workflow safety part of program validity. In practice, that means pushing trust progression, fallback handling, and sink discipline into the language contract rather than leaving them to convention.

Examples included with the release

LAILA 0.1.0 ships with example workflows that mirror the core teaching path for the language: first inference, then verification, then trust and fallback handling.

01 · Basic infer

A minimal workflow that defines a schema, accepts an input question, calls a model, and emits the inferred value.

02 · Verify with voting

A classification workflow that shows how voting, consensus, and confidence thresholds can be expressed as verification requirements.

03 · Trust + fallback

A reply workflow that demonstrates what happens when outputs are useful but inconsistent: verification fails, fallback takes over, and the result remains safe.

schema Reply {
  text: string
}

fallback human_review = Reply {
  text: "needs_human_review"
}

workflow trust_fallback {
  input {
    question: string
  }

  infer draft_reply: Reply from model "openchat/openchat-3.5-0106"
    using question

  verify verified_reply from draft_reply
    by vote 3
    require consensus majority
    require confidence >= 0.66
    else fallback human_review

  trust trusted_reply from verified_reply
    require confidence >= 0.60
    require verified
    else fallback human_review

  emit trusted_reply
}

What comes next

0.1.0 establishes the language skeleton. Future releases can deepen the policy model, broaden the requirement system, strengthen trust semantics, and tighten the relationship between compile-time guarantees and runtime enforcement within LAILA.

Richer trust policies

Trust today is present as a language stage and checker concept. Future releases can make policy requirements more expressive and operationally meaningful.

Better verification semantics

Voting and evidence-backed checks form the verification foundation today. Future releases will broaden the space of verification requirements — including a runtime-supported rerun strategy and real retrieval connectors for grounded against clauses — without losing clarity.

Sharper docs and user experience

Examples, a user manual, attendee cheat sheets, and CLI-driven demos will help the language feel easier to approach without weakening the core safety model.

LAILA 0.1.0 is the first public statement of the language: AI workflows should describe not only what to generate, but what must be true before those generations can be used.