KYLLO Documentation¶

KYLLO is a programming language for AI agents — designed to make software development by AI agents more reliable, predictable, and verifiable.

Why KYLLO?¶

KYLLO takes its name from kyllopodion, an ancient Greek epic epithet meaning "crook-footed" or "with crooked feet". Our name comes from Hephaestus, the club-footed metalworker who embraced his imperfections and made the legendary weapons of the Gods.

The soul of this project is a programming language created by AI for AI.

The specification is evolving. Every technical specification section is an Initial Draft (version 0.1), except Section 57, which is a Working Register of open decisions. Nothing on this site should be read as a finalized, implemented language. Unresolved decisions are listed openly in Unresolved Questions, and gaps and contradictions are recorded in the documentation audit (reports/documentation-audit.md).

What KYLLO is for¶

AI-generated code should be checked against what it is supposed to accomplish, not merely whether it is syntactically valid. KYLLO is built around seven goals, stated in the introduction:

Prevent errors — catch mistakes before they become runtime failures.
Enforce requirements — let developers define rules programs must obey.
Verify behavior — check whether functions and systems satisfy their declared requirements.
Make failures explicit — require programs to account for possible failure states.
Control side effects — make file access, database changes, and network requests explicit.
Give AI useful feedback — provide precise, structured compiler errors.
Prioritize correctness — favor predictable, maintainable software over shorter code.

A program should not be considered correct simply because it compiles or runs. Anything that cannot be verified should be identified as unverified rather than assumed correct.

Where to start¶

Learning the language: Introduction · Getting started · Language guide · First program: Bank Account
Looking up exact rules: Technical Specification — 56 sections, TECHSPEC-01 to TECHSPEC-57 (file TECHSPEC-22 does not exist; see the specification index).
Compiler implementation: Compiler — architecture, diagnostics, build and deployment, and the initial Python target.
Verification and correctness: Verification — the verification model, statuses, testing, and evidence reports.
Runtime and security: Runtime · Security
Standard library and ecosystem: Standard Library · Ecosystem
Examples: Examples
Reference for agents: Glossary · Cross-reference index

Guide vs. specification¶

The Language Guide explains the language in tutorial form. The Technical Specification is the normative reference: it preserves the source section numbers and identifiers (TECHSPEC-01 … TECHSPEC-57). Where a guide simplifies a rule, the specification governs. Where the specification is silent, ambiguous, or undecided, this site says so instead of filling the gap.

Verification statuses¶

Every declared requirement receives one of these statuses (see Verification and Validation):

Status	Meaning
`PROVEN`	Mechanically established through formal verification.
`TESTED`	Passed specified tests, but not mathematically proven.
`CHECKED`	Passed a static or runtime check.
`FAILED`	A violation was detected.
`UNKNOWN`	Available verification methods could not establish the result.

Status is always shown as text, never by colour alone. A program as a whole is VALID, INVALID, or UNVERIFIED.

About this site¶

This site is generated with Zensical from Markdown. The source material (LANG.zip, 81 files) is preserved in source-original/LANG/ and inventoried in reports/source-inventory.md. Build and contribution instructions are in README.md at the project root.