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

Development status

Kyllo is a documentation project at this stage. The specification is v0.1 Initial Draft, and by its own criteria it is not ready for implementation planning (audit issue AUDIT-020). The documentation audit found 20 issues, 17 of which need design decisions before the language can be implemented with confidence.

There is no compiler, release, download, or install. The honest status is on every page of this site, because the status is part of the project — not a footnote to it.

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. Before that can be built with confidence, the open design questions below must be resolved.

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. Acceptance is documentation-level, not compiler implementation. The record is at kyllo-docs.pages.dev/decisions/oq-001-statement-termination/.

Accepted decisions get a permanent record under the documentation's decision records, updates to the affected specification sections, the Unresolved Questions register, the Language Guide, a dated changelog entry, and updated cross-references. Decisions stay proposed until all of those updates are complete. 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, so this site does not link to it — a public link would lead visitors to a page they cannot open. Follow the project through the documentation and its changelog instead.