The ontoref ladder, the mechanism

The same ladder, with the real output of ontoref ladder show, ladder audit, governs coverage and describe state. Each rung declares what checks it and what no check answers; one rung’s figures are never set beside another’s, and the audit closes without taking any rung as holding.

When your system says “I don’t know”

A report carried an open finding with a severity that, by written decision, does not gate: `unverifiable` — I cannot look at this from here. An agent in session read it as a defect, built the plane where the check does reach, and the report went to zero findings without verifying a single one of the five citations. That is what the talk is about: what a system does with what it cannot check, why the third state survives in the compiler and evaporates in a script, and what happens when the only way out of amber is green.

Install ontoref

The command below is not an illustration: it is the exact command a gate executes from outside this machine, against the public URL, into a disposable home, before every release. It installs a CLI and its data layer — no daemon, no account, no token. Then «ontoref setup» creates your project's own instance and «ontoref describe» answers from it. What it does not do is promise you a result: ontoref holds what you declared and tells you when it stopped being true. Declaring it is still your work.

From prompt to loop

Prompt, context, harness, loop — the sequence is not a ladder of improvements, it is a series of admissions. Each discipline exists because the previous one was caught assuming something it had no right to assume. And the last one still assumes one thing: that somebody declared what «done» and «safe» mean, and that the declaration is still true. A walk through what ontoref has been putting under each station — declared vocabulary, governed context provision, checks that declare their own coverage, a loop that proposes its memory and never applies it — with the counter-evidence included: four mechanisms that already forbade a failure, in writing, and not one of them fired.

A written rule does not apply itself

No rules were missing. There were four — written, canonical, consultable — and not one of them ran. A real case, with a log and timestamps, about the distance between a rule that is written and a rule that applies. The answer is not 'be more careful': it is a trigger — a hook that serves the rule where the decision happens, a gate in a chain somebody calls, a contract that rejects the file. And the honest part: ontoref, declared, was already there, and it was not enough.

Does AI manage your infra?

Why I Needed Rust

Rustikon 2026, Warsaw. Nearly four decades of automating infrastructure, compressed into one complaint: the failure shows up at deploy time, never before. The deck walks the three stages that got us here — local, networks, containers and CI/CD — and then spends its middle on a restaurant, because the analogy holds all the way down: the guest declares, the waiter validates, the kitchen executes, and the truth mutates at every step of the chain. The waiter IS the orchestrator, and the one who should catch an impossible order before it reaches the kitchen. From there the argument turns concrete: «we don't have mushrooms» is configuration drift, and Rust's Option type is the language-level refusal to pretend an ingredient exists — a substitution must be explicit, traced and re-authorized, never silent. Three questions the usual toolchain does not answer — why we wait for things to break, whether the declaration is even consistent with what is possible, whether CI/CD without semantic validation is more than continuous hope — and then Rust and Nickel against each one: schemas validated when the config compiles, a typed source of truth, traits as providers, contracts, a dependency graph, typed remediation. The measured part: MTTR from over 30 minutes to under 5. The part that cannot be measured, and the reason for the title: fear. Not evangelism — the tools were not the problem, and neither were the languages. The paradigm was.

Ontoref: Ontology and Reflection

The slides from the Ontoref talk: why a project's ontology and reflection should live with the code — versioned and verifiable. Navigable carousel + downloadable PDF.