aontu.dev valid

aontu

aontu is a language for the ontology of a software system: the entities it contains, the types they must have, and the relations that must hold between them. The definition is machine-checkable, so a change proposed by a coding agent is admitted or refused with the offending line named.

Their llms.txt

The beginning of the file, from our validated copy saved 2026-10-27T09:48:12.298Z. Cached copy · Source on aontu.dev

# aontu

> aontu is a language for the ontology of a software system: the entities it contains, the types they must have, and the relations that must hold between them. The definition is machine-checkable, so a change proposed by a coding agent is admitted or refused with the offending line named.

Documented against `aontu` 0.73.0. Every page below is also
served as markdown: append `.md`, or send `Accept: text/markdown` to the
page's own URL.

## When to use aontu

aontu is a library and a CLI you run yourself, not a hosted service. It is
a language for the **ontology of a system**: the entities it contains, the
types they must satisfy, and the relations that must hold between them.
Reach for it when **a rule spans more than one file, service or team, and
being wrong silently is expensive**: the rules a type checker inside one
service cannot see, and prose in a README cannot enforce.

For an agent this is the referee: propose a change, run `vet`, and get a
verdict with an exit class and an error code rather than an opinion. Every
refusal names the file, line and column that caused it.

Good fits:

- A checkable definition of a system an agent is editing: which services
  exist, who owns them, which may call which, what a record must carry.
- Rules that live between entities rather than inside one: typed
  references, an acyclic dependency graph, an inverse edge that must be
  written back. `rel()`, `acyclic()` and `inverse()` state them; the
  engine refuses the document when they do not hold.
- Layered configuration (base, environment, region, instance), where a
  plain deep merge already gives order-dependent answers.
- Validating that a concrete document satisfies a schema *and* returning
  the filled-in result, rather than only a pass or fail.
- Checking that two specifications are mutually consistent before either
  is deployed, and naming the exact path that conflicts when they are not.
- Constraining what a model may emit: the grammar below is GBNF, so a
  sampler can be held to syntactically valid aontu.

Poor fits, where something simpler wins:

- One flat config file with no layering: parse the JSON and move on.
- Merges where last-write-wins is genuinely what you want.
- Program logic: there are no user-defined functions, no loops and no I/O,
  deliberately. Evaluation terminates and is deterministic, which is what
  makes the verdict trustworthy; it is not what makes it expressive.
- Hot paths: this is a build- and load-time tool, not a per-request one.

How to run it:

- CLI: `npm install -g aontu@0.73.0` then `aontu file.aontu`.
- MCP: `npx -p aontu@0.73.0 aontu mcp`, a local stdio server
  exposing the engine as tools, answering with the same reports the CLI
  prints. It runs on your machine; there is no hosted endpoint, because
  resolving a document does not need one.
- Library: `npm install aontu@0.73.0`, or the Go module.
- In the browser, with nothing installed: [the playground](https://aontu.dev/playground).

## Documentati
…

Related sites

Explore similar publishers →

Similar publisher descriptions and documentation. Similarity does not imply affiliation or equivalent capabilities.

Machine-readable: GET /v1/resolve?q=aontu.dev · GET /v1/domain/aontu.dev · this page as Accept: application/json or text/markdown · MCP lookup_domain

Automatically discovered from public files. Inclusion does not imply endorsement or publisher participation.

Claim my listing on Agent Web Map for aontu.dev:
1. POST https://agentwebmap.com/v1/sites/aontu.dev/claims and keep claim_id and claim_secret private.
2. Publish the verification line "AgentWebMap verification: <token>" (token from step 1) in https://aontu.dev/llms.txt, or use the DNS, meta-tag or well-known method the response describes. This only verifies the listing; your website and domain remain yours.
3. POST https://agentwebmap.com/v1/sites/aontu.dev/verify with {"claim_id": "...", "claim_secret": "..."}.
4. Save the api_key from the answer; it manages the listing (PATCH https://agentwebmap.com/v1/sites/aontu.dev).
MCP equivalent: tools begin_ownership_claim, then verify_domain, at https://agentwebmap.com/mcp. Docs: https://agentwebmap.com/docs#verify

Corrections or removal requests: contact the directory.