The operations an agent may drive are declared

Answers Topology · Derivation

Everything that may be done with the published parts is a value of one governed vocabulary: what it takes, what it gives, which published address it reads, and the files that serve it. The surface performs those operations and no others, an agent arriving with the published parts learns them from the parts and not from the surface's source, and a declared operation nothing serves is refused.

What goes wrong without it

The engine was published, in two runtimes proven identical, and the parts it binds against were published beside it. What could be done with them was still implied by the code that did it: a reader could compose from a term because a component happened to offer it, and an agent could bind because it had read the engine, but neither the offering nor the binding nor the drawing nor the carrying away was a thing the ground named. A capability the ground does not name is one the surface can quietly gain or lose, and one no second surface can be built to.

What proves it — 2

Each is a gate the build runs: a check inside a ring, a whole ring, or an eval beside them. A build stops at the first that refuses.

• ring:6the site ring
  The built site is the whole graph and nothing else: every page indexed, addressed by a label, self-contained and free of any private name; every structured-data identifier a subject the standards export wrote; every page unfurling to its own card, and every sitemap entry naming that card as its image; every journey with its SCXML twin; the sitemaps held to the graph; a graph under a megabyte. And the host held to the ground: the Worker serving the build as its assets and running first for every request; the allowlist and the redirect list it carries cut from the graph, every address the graph once answered to in the list with the status the law gives it and none of them a page; every endpoint served by the files it names; and the beacon sending to the collector's endpoint and nowhere else; every projection the law declares in the build, served by the files that say they serve it, and named in llms.txt; and the Worker reading the host's caching rules and owed headers from the law, writing none of its own; every answer a question carries a page where the walk is non-empty and nowhere else, its structured data naming exactly the rows the walk reached.
• eval:enginethe engine agrees with itself
  The binder that runs while the graph is built and the binder that runs in a reader's browser find the same bindings: every pattern bound against the whole model to the same instances and the same rows in every role, the published example among them, and every view bound again from every row it answers from, row for row, and the port of the pattern law beside the browser's engine refuses every way a declared pattern can be broken exactly as the law does, and every question bound again from every row of its root kind finds an answer exactly where the build published one and nothing where it did not.

Derived from — 2

• Grüninger and Fox, IJCAI-95 Workshop on Basic Ontological Issues in Knowledge Sharing, 1995Methodology for the Design and Evaluation of Ontologies
• Uschold and Gruninger, The Knowledge Engineering Review 11(2), 1996Ontologies: Principles, Methods and Applications

Where this model stands

law.json `operations` declares stand, bind, draw, compose and carry, each carrying its inputs and output in the reader's words, the address it reads, and the files that serve it.

The binding projection carries the operations and the view declarations beside the rows, the assertions, the patterns and the drawing rule, so one fetch gives an agent the parts and the verbs; the machine index describes each operation in prose.

The site ring holds every operation to a file under the site, the build or the standards export that names it back, and FND-025 holds every address an operation reads to one the law reserves. The composer performs the declared operations and labels each control with the declaration.

The engine eval proves the operation that binds agrees across its runtimes; the others are views of it or of the law's own vocabularies.

law.json `addresses.projections` declares every file the host serves for a machine to read: what it is, where it answers, the artifact fields it is cut from, and the files that serve it. An operation reads projections and nothing else, FND-025 holds that; llms.txt lists them from the law, so an agent learns what it may fetch without reading prose; and the site ring holds each to being in the build and to the files that name it.

What it does not claim

No operation is served at an address. The site is static, so an agent runs the published engine itself; an operation served by an endpoint would be the same declaration with an address in `served_by`.

An operation's inputs and output are in the reader's words, not a schema. A machine wanting to call one still reads the engine's signature.

RUL-041