Project

Kyllo is named for kyllopodion — “crook-footed” — the epithet of Hephaestus, the club-footed metalworker who embraced his imperfections and made the legendary weapons of the gods. The soul of the project, in the documentation's own words, is a programming language created by AI for AI.

Philosophy

“A program should not be considered correct simply because it compiles or runs. It should be checked against its intended behavior, and anything that cannot be verified should be identified as unverified rather than assumed correct.”

• Made by imperfect minds. Forged through verification.
• Trust Nothing. Verify Everything.
• Nobody gets a free pass. Not humans. Not AI. Not the compiler.
• Correctness claims must be supported by evidence.
• Mistakes should be harder to introduce and easier to detect.
• Requirements and behavioural expectations should be explicit.
• Verification must be honest about what it can and cannot establish.

Seven goals

1. Prevent errors
2. Enforce requirements
3. Verify behaviour
4. Make failures explicit
5. Control side effects
6. Give AI useful feedback
7. Prioritise correctness over shorter or faster code

Five design principles

1. Correctness over convenience
2. Explicit over implicit
3. Verifiable by design
4. No assumed success
5. Designed for AI agents

Project Status

• Specification: v0.1 Initial Draft.
• Documentation: v0.2.8 (2026-11-08), at kyllo-docs.pages.dev.
• OQ-001 is the only accepted design decision. 28 open questions remain (OQ-002–OQ-029).
• No compiler, release, download, or install is available yet.
• The MVP prototype scope is described on the Toolchain page: lexer, parser, AST, type checker, semantic analyser, contract checker, structured diagnostics, and Python code generation, with the Bank Account example as the first demo.

Roadmap

There is no dated release roadmap. The next step is the MVP prototype scope described on the Toolchain page: lexer, parser, AST, type checker, semantic analyser, contract checker, structured diagnostics, and Python code generation — with the Bank Account example as the first demo, and incorrect implementations rejected with useful diagnostics. The open design questions below must be resolved first.

Accepted decisions

One. OQ-001 — Statement Termination, accepted 2026-11-08 (documentation v0.2.7, reconciled in v0.2.8): explicit semicolons for simple statements and declarations, typed block endings, no automatic semicolon insertion, no redundant semicolon after a terminator. The record is at kyllo-docs.pages.dev/decisions/oq-001-statement-termination/.

Accepted decisions get a permanent record in the documentation's decision records, with updates to the affected specification sections, the Unresolved Questions register, the Language Guide, a dated changelog entry, and updated cross-references. Semantics are never silently changed.

Changelog

Documentation v0.2.8 (2026-11-08): reconciliation of OQ-001 — a terminator beyond the OQ-001 table is established only for an established grammar category with an attested form; END MATCH; established, IMPORT confirmed as a simple declaration, ENUM/TEST/PARALLEL terminators explicitly unresolved, 10 example corrections reverted.

Documentation v0.2.7 (2026-11-08): OQ-001 accepted. Earlier versions in the same day proposed and refined the statement-termination rules (v0.2.4–v0.2.6).

Open questions — 28

OQ-002–OQ-029 remain open. The ones named on this site:

• OQ-002 — numeric representation and decimal semantics
• OQ-003 — integer division and remainder
• OQ-004 — rounding context
• OQ-018 — proof language and proof engine
• OQ-019 — supported proof obligations
• OQ-020 — verification evidence schema
• OQ-023 — what “verified” means

Full register: kyllo-docs.pages.dev/unresolved-questions/.

Contributing

The first rule of contributing to Kyllo is the one the project sets for itself: never invent language semantics. Gaps and contradictions in the specification are documented, not filled in. Design questions go through the open-questions register and the decision-record process — proposed, refined, and only marked accepted when the specification, guide, register, and changelog have all been updated.

The source repository is private while the specification is being drafted. Follow the project through the documentation and its changelog instead.