Glossary

The nine terms of Resolution and three the chapters after it needed, one paragraph each, with the chapter where you do the thing rather than read about it.

Resource. Anything with a name — a URI, in this system a urn:*. A resource is not an object and not a function: it is a name a kernel can resolve, and what you get back depends on which verb you asked with. urn:iki:tutorial:camel-case is one; so is urn:kernel:catalog. You define one in Hello, resource and give it a name in Binding, and a host of your own.

Verb. One of five: Source (read), Sink (write), Exists, Delete, Meta (describe yourself). The same five for every resource, so there is no method vocabulary to learn — and Meta is the one that makes the system legible to a machine. An endpoint answering more than one declares a contract per verb, in Multi-verb endpoints.

Representation. What a resolution returns: bytes plus a media type. Not a language-specific value, because the answer may have crossed a process, a machine or a language. Declaring the type is what lets a transreptor find a route from what you produced to what somebody asked for. You return one in Hello, resource and ask for a different one in What resolution buys you.

Transreptor. An endpoint that converts one representation into another, and — the part that matters — declares which conversions it performs, so the kernel can select it when a request asks for a type the resource does not produce itself. A resource does not have a format; it has whatever the kernel can reach. You write one in Transreption.

Golden thread. The dependency a cached answer hangs from — declared by the endpoint (.depends_on(..)), conventionally named after the resource whose state it tracks. A resolution derived from other resolutions inherits their threads; a write to a resource cuts the thread named after it, and every cached entry whose threads include that one — directly or transitively — stops being valid at that instant. Since core 0.1.73 every cacheable entry also hangs from the thread named after its own target, so even a pure function’s, which declares none, is cut by a cut of its own name. Precise invalidation, not timeouts. You cut one in What resolution buys you and again, on a file, in Configuration.

Capability. The authority a resolution runs under, carried with the invocation and narrowed — never widened — as it passes down a call chain. What an endpoint declares it requires is what the kernel enforces, per verb, before the endpoint runs: declared equals enforced, and either half without the other is a defect. You declare one on your own endpoint in Multi-verb endpoints, and watch one cross a socket in Part III’s Exercises.

Scope. (Not a capability scope, one urn:cap:… string in a capability, which is what most chapters mean by “a scope”.) The resolution chain a request is resolved in: corridors a host injected ahead of the kernel’s root, innermost first, and whether the root is on the end at all. Every sub-request inherits it. Injecting a corridor (Kernel::issue_in) is the host’s authority, since a corridor placed ahead of the root can stand in for any door; cutting the root off (Confine) is the one chain-changing move an endpoint gets, and inside a severed chain a name outside it is unresolvable, never denied. The chain is part of the cache key. Scope and alias.

Alias. A logical name that resolves to a different backing resource without the caller knowing — a table of exact and prefix rules, installed on the kernel. The rewrite is reported, so the two names are one resource: one cache entry, one golden thread, the floor checked against the backing name, the catalog listing the backing name once, cycles refused. Not the alias mount of Part III, which rewrites on the way out to another kernel and reports nothing. Scope and alias.

Principal. Who asked — a fact a door establishes (a certificate, a passkey, a socket’s peer credential) and stamps on a write as provenance. Not the capability, which is what may happen: an anonymous local caller has authority and no identity, a signed-in caller with a narrow grant has identity and little authority. Since core 0.1.93 the door mints it into the request’s capability as a scope, urn:cap:principal:<iri>, which an endpoint reads with principal() and which widens nothing. Who is asking.

Catalog. urn:kernel:catalog: every bound endpoint’s description, as one RDF graph, assembled from the descriptions rather than maintained beside them. Nobody writes it, so it cannot be out of date. You read your own host’s in What resolution buys you and query it in The graph face.

Manifold. urn:kernel:actions: the capability-scoped list of what the current caller may invoke — the catalog, filtered by authority, per action. It narrows as the capability narrows, and it is computed, not configured. The machine client is where a client reads it instead of being told.

Tool list. What an agent is handed as the things it may do. Here it is not written down for the agent: it is the manifold under the agent’s capability, projected — over MCP, into an editor’s generated commands, into a shell’s completions. The description an endpoint carries is the tool definition, which is why Why an endpoint describes itself calls it load-bearing.