Glossary
Terms used across the Pico course. Course-specific vocabulary lives here so lessons can link to a single definition instead of redefining terms.
Composer
A component that takes parsed Rules and produces a Pico output artifact.
Constraint
A condition a valid Element must satisfy (for example, “the Pico responds to the hello event”). See Constructive realization.
Definition
What an artifact is supposed to be: purpose, intent, and expected outcome. In this course, a Pico’s Rules together with the surrounding lesson framing state a Definition. See Constructive realization.
Element
The concrete realized thing. In this course, a running hello-world-pico produced by the Rules → Parser → Composer pipeline is an Element. See Constructive realization.
Open Engineering
The overarching approach of treating engineering artifacts as declarative, composable, versioned, and machine-readable definitions.
Parser
A component that reads Rule definitions and turns them into an internal representation the Composer can operate on.
Pico
The small, declarative engineering artifact this course teaches you to build. A Pico is defined by Rules and produced by a Parser + Composer pipeline.
Realization
The constructive path from a Definition to an Element. In this course, the Rules → Parser → Composer → Pico pipeline is the Realization. See Constructive realization.
Rule
A single declarative statement that shapes the behavior or content of a Pico.
Validation
An executable or observable check that tests an Element against its Constraints (for example, a lab’s verify.sh or a course quiz). See Constructive realization.
Channel Policy
The authorization rules governing what a Pico relationship may do. Channel policy determines permitted actions; identity determines who the other party is. These remain separate concerns.
DIDComm
A protocol for encrypted peer-to-peer communication between Picos. DIDComm uses pairwise did:peer identities to protect cross-mesh and cross-engine messaging.
did:peer
A pairwise Decentralized Identifier used for private, relationship- specific identity. Each Pico-to-Pico relationship creates its own did:peer pair, providing isolation between relationships.
did:webvh
A web-resolvable Decentralized Identifier that serves as a Pico’s public cryptographic identity. The Pico Engine publishes the corresponding DID document at a stable URL. Conceptually the Pico’s “passport.”
ECI
An Event Channel Identifier. The legacy addressing mechanism for Pico communication. Parent and child Picos continue using ECIs for family channel communication.
Portability
The ability of a Pico to move between execution environments without losing its cryptographic identity, relationships, or trust state.
Subscription
A pairwise relationship between two Picos that are not in a parent/ child hierarchy. In Pico Engine 1.6, subscriptions are backed by cryptographic peer DIDs and encrypted with DIDComm.
Verifiable Credential
A signed claim about a Pico’s attributes or authority. A future layer on top of the identity architecture that will allow Picos to prove what they are and what authority they hold.
Capability
A provider-neutral action a Pico may perform, such as email.send or github.issue.create. Pico rules name capabilities rather than provider-specific tool names, keeping the Pico independent of any particular tool provider. See Part 3 · Hands.
Composio
A provider/platform that supplies tools to Picos. In this course it is named as one possible external Hands provider, but the Pico Hands abstraction must remain independent of Composio or any other provider.
Hands
The controlled mechanism through which a Pico acts on the world. A Composer equips a Pico with Hands; the Pico decides when to use them; the Hands perform the action. Hands are governed by identity, rules, policy, and authorization. Hands answer how an action is executed; Mind answers whether it should be. See Part 3 · Hands.
HandsProvider
An implementation of the Pico Hands capability that binds one or more Capabilities to a concrete execution mechanism — for example ComposioHands, KubernetesHands, LocalHands, MQTTHands, or PhysicalHands. A HandsProvider maps a Pico Capability onto its own implementation-specific operation. Providers are interchangeable; Pico rules remain unchanged when a provider is swapped.
ActionRequest
A structured request that a Pico’s Mind emits when it decides to act. An ActionRequest names the acting Pico and principal, the Capability being requested, and the authorization context. It is the input to a Hand’s execution and is evaluated against Policy before any provider is invoked. See Part 3 · Hands.
ActionResult
The normalized outcome of executing an ActionRequest through a HandsProvider. An ActionResult records success or failure, a provider-independent status, and any values the caller needs, without carrying credentials or sensitive provider payloads. It is the Pico-facing shape used by Rules and downstream Voice communication.
ExecutionContext
The bundle of identity, authorization, policy, and runtime information carried alongside an ActionRequest so a Hand can execute it safely. An ExecutionContext MUST include the acting Pico’s Identity and the authorized Capability; it MAY include environment, tenant, or approval-gate metadata. No Hand acts without an ExecutionContext.
Identity
The cryptographically verifiable answer to who is acting. In this course a Pico’s Identity is provided by did:webvh as its public identity and by did:peer for relationship-specific identities. Identity is required context for every governed Hand action; it does not by itself imply authorization.
Policy
A declarative rule that constrains what a Pico may do — which Capabilities are permitted, under which conditions, and with which required approvals. In the Pico course, Policy is stated in Rules and evaluated on the ActionRequest before a Hand executes. Policy is the Pico-course view of the Phase 7 Policy concept in templates/README.qmd (in-repo scaffold, not published as a learner page).
Evidence
A durable record of a Hand’s execution suitable for auditing — for example the acting Pico, the requested Capability, the chosen HandsProvider, the authorization decision, and the timestamped lifecycle of the request. Evidence describes execution without carrying credentials, access tokens, message bodies, or other sensitive values.
Action Event
A named runtime event emitted at each stage of a Hand’s execution lifecycle — for example pico.hand.requested, pico.hand.authorized, pico.hand.denied, pico.hand.succeeded, and pico.hand.failed. Action events let other Open Engineering components observe Pico behaviour without coupling themselves to a particular HandsProvider.
Nervous System
The provider-neutral communication fabric through which a Pico senses, communicates, coordinates, and interacts with other Picos, devices, and services. In this course the Nervous System sits after Hands in the Pico progression and is distinct from Brain/Mind (whether/why to act), Hands (how an action is executed), and Voice (what a Pico chooses to communicate). The Nervous System defines the semantic layer; MQTT and EMQX are candidate transport implementations, not the semantics themselves. See Constructive realization.
Pico Agent Transport
The abstraction that carries Nervous System messages between Picos and other participants. Pico Agent Transport names what is communicated (message envelopes carrying observations, events, commands, delegations, results, presence, and discovery) rather than how it is carried on the wire. MQTT is the first candidate implementation and EMQX is a candidate broker; the Pico must remain replaceable across transports without changing its Rules, Capabilities, or Hands.
Message Envelope
The structured wrapper around every Nervous System message. A message envelope carries the message type (observation, event, command, delegation, result), the sending Pico’s Identity, a stable message identifier, a correlation identifier for related exchanges, a timestamp, and the typed payload. Envelope fields are transport-neutral; transport bindings (for example MQTT topics or QoS) MUST NOT be required by the Pico to interpret the envelope.
Observation
A Nervous System message reporting that something was observed — for example a soil-moisture reading or a repository status snapshot. Observations are transient by default; the Pico’s Rules decide whether an Observation becomes Evidence, a Memory candidate, or is discarded. This course-scoped Observation is aligned with the Phase 7 Observation concept in templates/README.qmd (in-repo scaffold, not published as a learner page) and feeds the same Observation → Feedback → Definition loop.
Event
A Nervous System message reporting that something happened — a completed state transition worth telling other Picos about. Events differ from Observations in that they name a discrete occurrence (rollout_failed, door_opened) rather than an ongoing reading.
Command
A Nervous System message requesting that a named target perform an action. A Command is a request, not an authorization: the receiving Pico MUST evaluate the Command against its Rules and Policy before any Hand executes. Commands never bypass the Composer-equips, Pico-decides, Policy-authorizes, Hand-executes chain from Part 3 · Hands.
Delegation
A Nervous System message in which one Pico asks another Pico to carry out a mission. Delegation is a scoped request between identified Picos and MUST carry enough context (mission, authorization, correlation) for the delegate to accept, decline, or refine it under its own Rules and Policy.
Result
A Nervous System message reporting the outcome of a Command, a Delegation, or another correlated request. Results carry a provider-independent status and any values the caller needs, without carrying credentials or sensitive provider payloads — mirroring the shape of ActionResult for Hands.
Presence
A Nervous System signal describing a Pico’s availability on the transport — for example whether it is online, offline, degraded, or maintenance-mode. Presence is a transport-observable claim about availability; it is not a claim about capability, and it never substitutes for Discovery or Authorization.
Discovery
The Nervous System capability by which a Pico determines which Picos exist, which are currently available, what Capabilities they advertise, how they can be contacted, and what constraints apply. Discovery is the semantic query surface; the transport merely delivers Discovery messages. Discovery advertises Capabilities but does not by itself authorize their invocation.
MQTT
An event-driven publish/subscribe messaging protocol. In this course MQTT is named as the first candidate transport implementation of the Pico Agent Transport, not as the semantic owner of Pico messages. Nervous System vocabulary MUST remain intelligible without naming MQTT.
EMQX
A production-grade MQTT broker. In this course EMQX is named as a candidate broker implementation for the MQTT transport binding of the Pico Agent Transport. EMQX operational concerns (deployment, credentials, cluster topology) are out of scope for the course contract; they belong to separate adapter follow-up work.