AGENTS.md is the entry
Every package, file tree or database profile starts with a root AGENTS.md. It names the Dimension, its authority, its policies and the Composer procedure.
Your world pulls
what it needs.
A Dimension does not begin with a shelf of meta-models chosen up front. It begins with one file. As the work proceeds, the agent reading that file notices what the world cannot yet describe, finds the specification that covers it, asks you, and installs it at a pinned version.
How it works
Need is detected, not scheduled
The agent watches for terms the installed models cannot hold and for references that point outside them. Both are demand signals.
You approve
The agent proposes a specific model at a specific version, explains what it answers and what it pulls in behind it. Nothing installs without your approval.
Install is pinned
The specification is fetched, its digest verified, written under meta-models/, appended to vercy.lock and recorded in the event registry.
What tells the agent it needs another model
An uncovered term
You mention an entity, decision, event or document that no installed model can hold. The Composer matches your words against the trigger vocabulary each model publishes.
A dangling reference
An installed specification declares what it deliberately does not contain and where that lives. Following the pointer is cheaper and safer than widening a model past its purpose.
A Finding with no home
Before writing, the agent checks that the information belongs in a model it actually has. If not, it resolves first rather than improvising a place for it.
A coverage gap
At the start of a session the agent diffs the object registry against the installed set, so a world that outgrew its models says so instead of drifting.
What gets installed
An install is four writes and no surprises: the specification directory with its own AGENTS.md, a separate binding file for storage and interface, a pinned entry in vercy.lock, and an entry in the event registry. Format and carrier never enter the logical specification, so the same model can later move from Git to a database without changing what it means.
The Composer proposes. The owner decides. An agent may read the catalogue freely, but it may not install, upgrade, replace or remove a specification without explicit approval, and it may never silently move a pinned version.
Machine endpoints
/models/composer-index.json
/models/catalog-index.json
/models/<id>/spec.yaml
/models/<id>/AGENTS.md
/llms.txt
The resolution index publishes, for each model: identity and canonical semantic name, version, specification URL, digest, conformance, the trigger vocabulary that suggests it, and the declared references to other models with the catalogue id each one resolves to. Unresolved references stay visible in the index rather than being dropped, so gaps in the corpus remain auditable.
Start here
The five-step wizard produces the Owner Package, including the Composer procedure your agent follows from then on.