Skill architecture

The model is a dispatch system. A target has a type. A type implements one or more regulatory functions, each declaring the operations available on it. An action implements an operation for a type, and where behaviour is the same across every implementing type, a single action serves them all. Dispatch resolves a target's type, finds the regulatory functions that type implements, and offers the operations those regulatory functions declare. The session's scope decides which of those operations it is offered.

For programmers. A regulatory function behaves like a trait in Rust or Scala, and the analogy is close enough to be worth stating.

A target is an object. Its type is the class. A regulatory function is an interface the class implements, and a class may implement several: a recipe implements both loading and execution, which is why the classification cannot be a class hierarchy. An operation is a method the function declares, and an action is its implementation. Because an action is registered against a type rather than written inside it, this is closer to a generic function with multiple dispatch, or to a Rust trait, than to a method on a class; an operation that does not vary across types is written once as a default implementation.

Dispatch is then what you would expect: given an object, ask what it implements and offer the methods of those interfaces. The one departure is scope, which has no counterpart in an ordinary trait system. There an interface belongs to the class and every caller sees the same methods; here the caller's role decides which methods it is offered, so the same object presents a smaller surface to a session at S1 than to one at S3* (c.f. cybernetic levels).

The three sections below take those parts in turn: what a thing is and what it participates in, what may be done to it and what does the doing, and how the operation is found and who may be offered it.

A regulatory function classifies artefacts (c.f. Physical Space) by the relation an agent bears to them: the agent loads a source, cites a stance, sequences a method, executes an action, declares a specification, convenes a deliberation, and records against an artefact carrying a lifecycle.

A type may implement several regulatory functions, which is why the classification is by regulatory function rather than by class. A recipe implements both loading, since it is consulted for its command, and execution, since its script is run. The regulatory functions document treats the taxonomy, the criterion behind it, and which document type implements what.

An operation is declared by a regulatory function; an action implements it for a type. The distinction matters because it is what keeps the catalogue small.

Actions are registered against a target's type rather than written into it, which makes this closer to multiple dispatch than to methods on a class. An operation whose behaviour does not vary across implementing types is written once and inherited by all of them, in the way a regulatory function carries a default implementation, and only genuinely type-specific behaviour is specialised. A catalogue that instead paired every operation with every type by hand would grow as the product of the two, and every pairing left unwritten would be a capability that could not be found.

Dispatch resolves a target's type and offers the operations its regulatory functions declare, so the applicable operations are computed rather than remembered. An agent holding an artefact can therefore ask what may be done with it, rather than needing to know the name of the action it wants.

Scope narrows that offer. An actor declares a System, whose cybernetic level determines which operations are in scope for it. At most levels the narrowing is a default: an agent is offered less but may reach outside its scope on request. At the audit level it is a constraint, since an auditor that can be persuaded to modify what it observes is not an auditor.

Scope is also where this model departs from a trait system in a typed language. There a trait belongs to the type alone, and every caller sees the same operations. Here what a target offers depends on the type and on the actor engaging it, and the level is what carries that dependence.

The framework applies these concepts to carry a unit of work, most often a task, from an unverified beginning to a verified end. A method governs the flow, and its phases are determined dynamically as the work proceeds rather than fixed in advance. Each phase cites the principles that govern its judgement and calls the actions that operate on the relevant artefacts, preferring generated structure wherever generation is possible. The extent to which the work must climb the verification ladder follows from what it changed. An agent may be configured and left running against a checkable finish condition.