# looprig Glossary

This glossary defines the shared language used across looprig's code,
documentation, and public interfaces. It focuses on terms that have a specific
meaning inside the project.

Capitalized terms such as **Loop**, **Rig**, and **Session** name public runtime
concepts. Lowercase terms such as **harness** or **flow** usually name a module
or a general idea. Where an item is not implemented yet, its definition is
marked **planned**.

## Core Mental Model

**Agent.** A model-driven program that can receive input, maintain context, use
tools, and produce actions or answers within defined boundaries.

**Agent harness.** The machinery that turns model capability into a usable
agent system. It coordinates context, tools, permissions, events, storage,
recovery, and interfaces around one or more agents.

**Agent loop.** The execution cycle in which a model receives context, produces
output or requests a tool, receives the tool result, and continues until the
Turn ends. A looprig **Loop** is the owned definition and runtime boundary around
that cycle.

**Agentic system.** The complete system built from agents and the machinery
around them. It may include Loops, deterministic tasks, workflows, people,
storage, external services, and user interfaces.

**looprig.** The overall open source project and ecosystem. It includes the
harness, workflow engine, inference stack, storage backends, the sandbox,
standard tools, interfaces, and complete Rigs built from those parts.

**harness.** The runtime module that provides Loops, Rigs, Sessions, tools,
gates, journals, workspaces, delegates, and lifecycle control. The harness
provides the parts. A user assembles a Rig.

**Loop.** The immutable definition of one agent. A Loop selects the agent's
identity, model, instructions, tools, permissions, modes, context policy, and
delegation behavior.

**Rig.** The agent system a user configures, owns, and runs. A Rig assembles one
or more Loops with storage, workspace, access, lifecycle, and delegation
policy. looprig is the project. A Rig is what someone builds with it.

**Session.** One running or restorable instance of a Rig. A Session owns the
live execution state, event history, active Loop, selected access profile,
workspace, and pending gates for a body of work.

**Turn.** One unit of interaction submitted to a Loop, including the model and
tool activity required to complete it.

**Step.** One model execution step within a Turn. A step may produce content,
request tools, or end the Turn.

**Tool.** A named capability a Loop can ask to use, such as reading a file,
running a command, searching, or calling an application API. Tools are selected
individually and remain under the runtime access gate and OS confinement.

**Workflow.** Durable coordination across tasks, agents, people, and external
systems. In looprig, workflows are built with the `flow` module and are separate
from the model-driven execution inside a Loop.

## Foundational AI Terms

**GPU.** Graphics processing unit. GPUs provide the highly parallel computation
used to train and run many neural networks.

**JEPA.** Joint Embedding Predictive Architecture. A family of neural network
architectures that learns by predicting representations rather than directly
reconstructing every detail of an input.

**Large language model or LLM.** A neural network trained across large amounts
of language and other data. LLMs are one form of neural network, not the name
for all machine intelligence.

**Machine intelligence.** The knowledge and reasoning capability produced by
machine learning models. looprig supplies machinery around this capability; it
does not create the underlying intelligence.

**Multimodal model.** A model that can process or produce more than one kind of
content, such as text, images, audio, or documents.

**Neural network.** A learned computational system made from connected layers
of parameters. Neural networks include LLMs, multimodal models, JEPA systems,
and other model families.

**RAG.** Retrieval-augmented generation. A pattern that retrieves relevant
external information and supplies it to a model as context for a response.

**TPU.** Tensor processing unit. A specialized processor built to accelerate
the tensor computations used by machine learning models.

## Agents and Runtime

**Actor.** A runtime component that owns its mutable state and processes
commands serially. Native Loops use this model to keep concurrent activity from
creating conflicting state transitions.

**Active Loop.** The Loop currently selected to receive top-level user input in
a Session.

**Agency.** The identity of the actor responsible for an action, such as a
person, Loop, delegate, policy, or system component.

**Cause.** Correlation information that records what caused an event or action.
It lets later work be traced back to its originating Turn, tool call, delegate,
or control request.

**Context.** The messages, instructions, tool results, summaries, and other
content available to a model for an inference request.

**Context compaction.** Replacing older context with a smaller durable summary
so a Session can continue within the model's context limit.

**Context counter.** A component that estimates or exactly counts how many
tokens a complete inference request will consume.

**Context observation.** A measurement of current context use, including token
count, capacity, and occupancy.

**Context occupancy.** The proportion of a model's available context window
currently in use. It can be used to decide when compaction should begin.

**Context window.** The maximum amount of input and generated content a model
can consider in one request.

**Controller.** A public control surface for changing live state, such as
interrupting work, changing a mode, or selecting the active Loop.

**Command.** A typed request to change runtime state, such as submitting user
input, interrupting a Turn, resolving a Gate, or starting compaction. Commands
express intent; Events record what happened.

**Coordinates.** Stable identifiers that locate an action or event within its
Rig, Session, Loop, Turn, Step, and related execution scope.

**Delegate.** A Loop invoked by another Loop to perform bounded work. The parent
retains responsibility for the overall task.

**Delegation style.** The way a parent may use a Delegate. Synchronous-only
delegation returns one bounded result, while managed delegation permits a
longer-lived child Loop under Session control.

**Delegation depth.** The maximum number of parent-to-child delegation levels
allowed in a Session.

**Delegation quota.** The maximum amount of delegate work allowed by Rig policy.

**Foreign agent.** An agent runtime built outside the native looprig harness,
such as Codex or Claude Code, that is adapted into looprig's session and event
model.

**Foreign Loop.** The looprig representation of a foreign agent. It normalizes
the foreign runtime's input, output, tool activity, permissions, and session
identity without pretending it is a native Loop.

**Foreign session ID.** The session identifier assigned by a foreign agent. It
is preserved alongside looprig's own Session identity so either side can resume
the same work.

**Handle.** The public data-plane surface used to interact with a running Loop
or Session without exposing its internal runtime implementation.

**Hustle.** Auxiliary, managed model work performed for a Session, such as
context compaction or a future classifier. A Hustle is not a user-facing Loop
and has its own purpose, limits, inference binding, run identity, and outcome.

**Human in the loop.** A design in which work can pause for a person's judgment
when authority, ambiguity, or consequences require it.

**Inference binding.** The resolved model and inference client assigned to a
Loop or Hustle at runtime.

**Loop definition.** The immutable recipe used to construct a Loop. Binding the
definition resolves its runtime dependencies without changing the recipe.

**Loop engine.** The execution mechanism behind a Loop. It may be the native
harness engine or a foreign engine such as Claude Code or Codex.

**Meta-harness.** A harness that can host and coordinate other agent harnesses.
looprig is being built to operate native Loops and foreign agents through the
same owned Session, policy, event, storage, workflow, and client model.

**Native Loop.** A Loop executed directly by the looprig harness from explicit
model, context, tool, permission, and lifecycle parts.

**Orchestration.** Coordinating several tasks or actors into one body of work.
Loops orchestrate model and tool activity; Rigs coordinate agents; `flow`
coordinates durable workflows.

**Loop mode.** A named behavioral setting exposed by a Loop. Modes let a user
change an approved part of its behavior without replacing the Loop definition.

**Memory.** Information an agent can reuse beyond the immediate input. In
looprig, this may come from Session history, compacted context, workspace files,
or an application-provided store. Memory is not one hidden global subsystem.

**Primer.** A Loop that is eligible to receive top-level user input. A Rig can
contain several Primers and selects one as the initial active Loop. The active
Loop may change during the Session.

**Provenance.** Information about where instructions, content, configuration,
or actions came from. Provenance supports auditing and policy decisions.

**Runtime context.** Session and environment information supplied to a Loop at
execution time, separate from its immutable definition.

**Quiescence.** The state in which a Session and its participating Loops have no
active work. The Event hub federates those activity signals so a caller can
reliably wait for the whole Session to become idle.

**Single-flight.** An execution rule that permits only one active Turn in a
given Loop at a time.

**Subagent.** General language for an agent working under another agent. In the
harness, managed subagent work is represented through delegation to another
Loop.

**Transcript.** The ordered human-readable projection of a Session's
conversation and tool activity. It is derived from typed runtime history rather
than serving as the source of truth for restoration.

**System prompt.** The highest-level model instructions selected by a Loop
definition. It guides model behavior but does not replace runtime permissions
or OS confinement.

## Models, Inference, and Content

**API format.** The wire-level request and response shape used to communicate
with a model endpoint. OpenAI, Anthropic, and Gemini formats are supported as
native formats. A provider and an API format are not the same thing.

**Capability.** A declared model feature such as tool use, images, audio,
thinking, or structured output. Capabilities let the runtime validate a request
before sending it.

**Chunk.** One incremental piece of a streaming model response.

**Codec.** The component that translates neutral inference requests and
responses to and from a specific API format.

**Content block.** One typed unit of content in a message. Current block types
include text, image, audio, document, thinking, tool use, and tool result.

**Conversation.** An ordered collection of messages supplied as model context.

**Delta.** A streaming update that adds to or changes the response accumulated
so far.

**Inference.** Running a model against a request to produce a response. The
`inference` module defines the provider-neutral contract for this operation.

**Inference client.** An implementation of the neutral invoke and stream
contract. It sends requests through a selected transport and API codec.

**Message.** A role and an ordered collection of content blocks exchanged in a
conversation.

**Model.** A secret-free description of the model to invoke, its provider
origin, API format, endpoint selection, and capabilities. Credentials are
resolved outside the model value.

**Model origin.** Provenance describing which provider or route supplied a
model, used for validation and policy decisions.

**Model SDK.** A library focused on calling one or more model APIs. It commonly
normalizes generation, streaming, tools, and structured output, but does not by
itself provide the complete durable agent harness.

**Multimodal.** Able to work with more than text, including images, audio, and
documents.

**Provider.** The service or runtime that makes a model available. The `llm`
module owns provider-specific authentication, validation, and routing policy.

**Router.** A component that directs neutral inference requests to the correct
API implementation and transport.

**Streaming.** Delivering model output incrementally as chunks instead of
waiting for the complete response.

**Structured output.** Model output constrained to a declared data shape,
usually a JSON schema, so an application can validate and consume it reliably.

**Thinking block.** Typed model reasoning content when a provider makes that
content available. Its handling depends on provider and Loop policy.

**Token usage.** Normalized input, output, cache, and reasoning token counts
reported for an inference request.

**Transport.** The connection-bound mechanism that carries an inference
request, usually HTTP, independently from the request's API format.

**Wire format.** The concrete bytes and framing exchanged with an external
model API, including JSON, Server-Sent Events, or newline-delimited JSON.

**Attestation.** Cryptographic evidence about the software and environment
running a confidential inference service.

**Confidential inference.** Model inference designed to protect requests and
responses from the surrounding service infrastructure through attestation,
trusted execution, or end-to-end encryption.

**SigV4.** AWS Signature Version 4. The request-signing authentication method
used for services such as Amazon Bedrock.

**TEE.** Trusted execution environment. Hardware-backed isolation used to run
code and handle data with evidence about the executing environment.

## Tools, Permissions, and Safety

**Approval scope.** The boundary within which a granted permission remains
valid, such as one action, one Turn, one Session, or another explicitly defined
scope.

**Auditable tool.** A tool that reports the security-relevant operation it is
about to perform so the runtime can record and evaluate it.

**Classifier.** A component that labels input for policy use. Planned
classifiers include detection of prompt injection and other untrusted content.

**Access profile.** The complete, immutable set of access states a Session's
commands run under: a `Deny`/`Gated`/`Allow` value for each capability
(workspace read/write, host read/write, network, command execution) plus HOME
and isolation choices. A profile is the sandbox's `AccessSource` for the gate and
the source of truth for OS enforcement, so a decision and its enforcement cannot
drift. It is selected before a Session opens and fixed for that Session.

**Access state.** One of the three per-capability decisions in an access profile:
`Deny` (reject without asking; no saved rule overrides it), `Gated` (use a
matching saved rule or ask once), or `Allow` (proceed).

**Confinement.** Whether a command runs inside an OS sandbox (`Sandboxed`) or
directly with the invoking user's authority (`Unconfined`). It is a property of
the executor, independent of the per-capability access states.

**Effect.** What resolving a Gate does to execution. A response may resume
parked work, initiate follow-up work, or apply a control-plane action.

**Fail closed.** Refusing an operation when the required permission or safety
guarantee cannot be established. The system does not silently fall back to a
less safe mode.

**Gate.** A durable pause that requires input from a person or policy before
work can continue. Gates are used for permissions, questions, and resumable
control decisions.

**Gate criticality.** Whether an unresolved Gate must survive restoration or may
be abandoned when a Session is restored.

**Gate control.** The live operation used to answer, reject, or otherwise
resolve a pending Gate.

**Gate resolver.** The Loop-level or Session-level owner responsible for
processing a Gate response.

**Gate route.** The Gate, Loop, and tool execution identifiers needed to deliver
a response to the correct resolver.

**Grant token.** An authenticated token issued by the sandbox authority to
permit a bounded escalation that untrusted code cannot forge.

**Guardrail.** A check or policy applied around model input, output, tool use,
or workflow execution. Broader integrated guardrails are planned.

**Permission.** Runtime authority for a proposed tool or system action. A model
requesting an action does not itself grant permission to perform it.

**Call preparer.** The preparation boundary a tool owns. It decodes and validates
untrusted arguments once, normalizes and canonicalizes the resources involved,
and emits one typed request listing the capability requirements the call needs.
Tools classify capabilities; the access gate decides `Deny`, `Gated`, or `Allow`.

**Prompt injection.** Untrusted content that attempts to redirect an agent,
override its instructions, obtain secrets, or cause unsafe actions.

**Read guard.** An in-process check that decides whether a native tool may read
a path. It complements OS confinement for subprocesses.

**Sandbox.** OS-level enforcement around spawned commands. The `sandbox` module
can restrict filesystem, process, network, environment, and resource access.

**Sandbox guarantee.** A report of what the current host actually enforced.
The sandbox reports achieved guarantees, not only the policy that was
requested.

**Restrict.** The operation that intersects a base access profile with a ceiling,
component-wise, without ever widening the base. It is how a role such as a
reviewer is held below the Session's selected profile.

**Grant.** A short-lived, single-spawn capability token the sandbox executor
mints only after the gate approves a `Gated` requirement. It binds the exact
command, working directory, profile fingerprint, and expiry, and is never a
durable permission record.

**Secret brokerage.** **Planned.** Resolving secret references only inside an
authorized tool or transport so raw secret values do not enter model context.

**Tool definition.** The reusable, unbound description of a tool, including its
name, input schema, and factory.

**Tool binding.** A tool definition connected to the runtime dependencies and
policy required for one Loop.

**Tool call.** One model request to invoke a named tool with structured input.

**Tool middleware.** A wrapper that can observe or constrain tool invocation
without changing the tool's business logic.

**Tool result.** The typed output of a tool call returned to the Loop. It may
contain content for the model and separate runtime metadata.

**Unconfined.** An explicitly acknowledged mode with no OS sandbox boundary. It
is never treated as a safe fallback.

**Untrusted content.** Content whose instructions must not automatically gain
authority, including web pages, files, tool output, and messages from external
systems.

**Workspace permit.** The runtime authority for a tool to perform a declared
operation against the Session workspace.

## Events, Durability, and Recovery

**Ambiguous append.** A storage write whose acknowledgement was lost, leaving
the caller unsure whether the record committed. `AppendDefinite` resolves this
by reading the Ledger state before deciding whether to retry.

**Append-only.** A persistence rule that allows new records to be added but
does not rewrite committed history.

**Blob.** An immutable byte object addressed by a key. Workspace snapshots use
Blobs for durable content.

**CAS.** Compare-and-swap. A write succeeds only if the stored revision or
sequence still matches the caller's expected value.

**Checkpoint.** A durable record of execution state from which work can resume.
Sessions checkpoint workspaces, while `flow` checkpoints graph state and the
execution frontier.

**Configuration fingerprint.** A stable digest of the Rig configuration that
affects restoration. It prevents a Session from silently resuming under an
incompatible definition.

**Content-addressed.** Stored under a key derived from the content itself,
usually a cryptographic digest. Identical content can be reused and corruption
can be detected.

**Enduring event.** An event persisted in the Session Journal because it
changes durable state or is required to reconstruct what happened.

**Ephemeral event.** A live-only event, such as a streaming token delta, that is
useful to clients but is not written to the Journal.

**Epoch.** A strictly increasing ownership generation assigned by a Lease. A
new owner receives a newer epoch than every prior owner.

**Event.** A typed fact emitted by the harness about Rig, Session, Loop, Turn,
Step, tool, gate, workspace, delegate, or lifecycle activity.

**Event hub.** The Session-level fan-in that publishes live events, tracks
subscribers, and supports quiescence without becoming the durable Journal.

**Fencing token.** The epoch used to prevent a stale process from continuing as
the accepted owner after another process has taken the Lease. The Session
Journal records its writer epoch as an opening fence.

**Journal.** The ordered, durable history of enduring Session events.

**Journal sequence.** The monotonic position of an enduring event in the
Journal. Ephemeral events do not receive one.

**KV.** A revisioned key-value storage primitive whose writes use CAS.

**Lease.** Time-bounded, single-writer ownership of a named resource. Leases
and epochs prevent two runtimes from safely claiming the same Session writer.

**Ledger.** The neutral append-only record log defined by `storage`. A Session
Journal is persisted on a Ledger.

**Restore.** Reconstructing a Session and its workspace from durable events,
snapshots, and compatible Rig configuration.

**Snapshot.** An immutable capture of workspace contents. Snapshots can be
taken manually or by policy when a Step, Turn, or idle transition completes.

**Snapshot policy.** The rule that decides when workspace snapshots are taken
and whether a snapshot failure is best-effort or must fail the operation.

**Snapshot priority.** Whether a snapshot is best-effort or required. A
required snapshot failure fails the surrounding operation instead of being
reported only as an observation.

**Storage backend.** A concrete implementation of the neutral Ledger, Leaser,
KV, or Blobs contracts.

**Workspace.** The filesystem state assigned to a Session. It is where tools
read and change working files.

**Exclusive workspace.** A workspace whose root is leased so only one Session
runtime can own it at a time.

**Per-session workspace.** A separate workspace root created for each Session.
It isolates working files between Sessions.

**Shared workspace.** A workspace root intentionally used without exclusive
per-Session placement. Required snapshots are not permitted for this placement
because another actor may change the same files.

**Workspace coordinator.** The runtime boundary that validates and observes
tool operations against a workspace.

**Workspace observation.** Recorded information about files a tool read,
created, changed, or removed.

**Workspace store.** The harness component that captures and restores
content-addressed workspace snapshots through `storage.Blobs`.

## Durable Workflows

**Bulk Synchronous Parallel.** The execution model used by `flow`. All vertices
in a super-step read the same frozen state, run in parallel, then cross a
barrier before their reducers are applied in stable order.

**Conditional edge.** A graph connection whose destination is chosen from the
current state or task result.

**Control plane.** The component that coordinates workflow execution across
workers. The term also describes session operations that change live state,
such as gates and interrupts.

**Edge.** A directed connection that determines which graph vertex may run
after another vertex completes.

**Flow.** A durable workflow defined and run through the `flow` module. In
ordinary prose, we prefer **workflow** unless referring to the module or public
type.

**Frontier.** The set of graph vertices eligible to execute in the next
super-step.

**Graph.** A typed workflow definition containing vertices, edges, shared
state, and stable identifiers.

**Graph run.** One execution of a compiled Graph, identified independently so
it can be inspected, interrupted, checkpointed, and resumed.

**Graph state.** The shared typed state carried through a workflow. Tasks read
selected input from it and reducers fold task output back into it.

**Idempotency key.** A stable identifier for a side effect. External systems
can use it to avoid performing the same operation twice after a retry or
recovery.

**Ingress.** The boundary that accepts a request to start, resume, or otherwise
control a workflow run.

**Interruption.** An intentional durable pause that returns control to the
caller while preserving enough state to resume later.

**Manifest.** A description of a registered Graph and the task kinds it needs,
used to make workflow definitions discoverable to a control plane.

**Reducer.** A function that folds one task's output into Graph state after the
parallel execution barrier.

**Resume payload.** New information supplied when interrupted work continues,
such as a person's answer or an external system's result.

**Selector.** A function that derives one task's typed input from the frozen
Graph state.

**Super-step.** One parallel round of eligible workflow vertices, followed by a
barrier and deterministic state reduction.

**Task.** A reusable unit of workflow work with typed input and output. A Task
can be deterministic, call an agent, wait for a person, or interact with an
external system.

**Vertex.** A stable position in a Graph that binds a Task to selectors,
reducers, and routing.

**Workflow checkpoint.** The durable Graph state, completed work, frontier,
and execution metadata needed to recover a Graph run.

## Interfaces and Protocols

**ACP.** Agent Client Protocol. **Planned for the general integration.** ACP will
let looprig expose native Rigs to compatible clients and host compatible foreign
agents through a shared protocol. Existing Codex and Claude Code adapters prove
the foreign Loop boundary but are not the complete ACP implementation.

**BFF.** Backend for frontend. A service surface shaped for a particular user
interface while delegating runtime behavior to the harness.

**CLI.** Command-line interface. A text command surface intended for terminals,
scripts, and automation.

**Client.** A user-facing interface that observes and controls a Session, such
as a terminal, web, desktop, or mobile application. This is distinct from an
inference client, which calls a model API.

**Control plane operation.** A request that changes live execution, such as
submitting input, resolving a Gate, interrupting work, changing a mode, or
restoring a Session.

**HTTP API.** The harness service interface for Session history and control.
Its live event stream uses SSE.

**JSON-RPC.** A request and response protocol encoded in JSON. It is used by
several external agent and tool protocols.

**Live plane.** The stream of events produced while a Session is running. It
contains both enduring and ephemeral events.

**History-to-live join.** The handoff a client performs from durable Journal
history to the live event stream without losing or duplicating enduring events.

**MCP.** Model Context Protocol. **Planned.** MCP integration will connect
external tools and context servers to Loops while preserving looprig's
authentication, permission, gate, provenance, and audit boundaries.

**NDJSON or JSONL.** Newline-delimited JSON, where each line is one complete
JSON value. It is useful for streaming structured records between processes.

**Read plane.** The durable history surface used to inspect a Session from its
Journal, whether or not that Session is currently running.

**SSE.** Server-Sent Events. A one-way HTTP stream used to deliver live Session
events to clients.

**TUI.** Terminal user interface. looprig's interactive terminal presentation
layer is separate from the harness runtime.

## Evaluation and Observability

**Evaluation.** A repeatable test of an agent or workflow against defined cases
and metrics.

**Golden set.** A maintained collection of representative evaluation cases and
expected properties used to detect regressions.

**Hook.** A lifecycle callback that observes runtime or workflow activity
without owning the underlying state transition.

**LLM judge.** A model used as an evaluation metric to score output against a
rubric. Its score is evidence, not an infallible ground truth.

**Metric.** A rule that converts an evaluation result into a score or pass/fail
decision.

**OpenTelemetry.** A vendor-neutral standard for traces, metrics, and logs.
Complete correlated instrumentation across looprig is planned; existing events
and hooks provide part of the required foundation.

**Score.** A metric's structured evaluation of one result, including its value,
reasoning, and threshold outcome.

**Span.** One timed operation inside a distributed trace, such as an inference,
tool call, Gate, delegate run, or workflow task.

**Trace.** Correlated observability data that follows work across components and
services.

## Modules and Repositories

**`tui`.** The interactive terminal presentation module. It provides the TUI surface
without making the harness depend on terminal libraries.

**`client`.** **Planned.** The shared client module for web, desktop, mobile,
and framework-specific interfaces over the harness HTTP and SSE contract.

**`coderig`.** A complete coding Rig built from looprig modules. It demonstrates
how an application owns model policy, Loop definitions, tools, prompts,
delegation, storage, and its composition root.

**`core`.** The smallest shared vocabulary, including typed content, UUIDs,
stream accumulation, and structured logging helpers.

**`flow`.** The durable, replayable workflow engine for typed graphs, parallel
tasks, retries, checkpoints, interruptions, and resume.

**`foreignloop`.** The harness boundary and adapters that translate external
agent runtimes into looprig's Loop, Session, permission, and Event vocabulary.

**`fsstore`.** The local-filesystem implementation of all four `storage`
primitives.

**`inference`.** The provider-neutral model contract, content mapping, codecs,
streaming, routing, transport, usage, and context counting layer.

**`llm`.** The provider policy and integration layer built on `inference`. It
adds authentication, provider selection, model validation, and concrete model
services.

**`memstore`.** The in-memory reference backend for the four `storage`
primitives. It is useful for tests and short-lived local execution.

**`natsstore`.** The distributed implementation of all four `storage`
primitives over NATS JetStream. It can use an embedded or remote server.

**`rclonestore`.** A `storage.Blobs` implementation that uses the external
`rclone` program to reach local or cloud remotes without linking its dependency
tree into looprig.

**`sandbox`.** The standalone module that owns the access profile and its OS
enforcement for commands. It compiles a profile into the strongest available OS
boundary, mints post-approval grant tokens, and reports the guarantees achieved
by the current platform.

**`storage`.** The dependency-light persistence contract module. It defines
Ledger, Leaser, KV, and Blobs plus reference and conformance utilities.

**`storetest`.** The shared conformance suite that checks whether a storage
backend obeys the neutral storage contracts.

**`serve`.** The harness package that projects Session history, live events,
input, Gates, interrupts, and restore over an HTTP and SSE API.

**`sessionstore`.** The harness persistence facade that stores and reconstructs
Session Journals over the neutral `storage` contracts.

**`tests`.** The cross-repository integration module that verifies looprig
modules work together through their public contracts.

**`tools`.** Optional standard tool implementations. Consumers can select each
tool independently, combine them with custom tools, or use none of them.

## Architecture and Engineering Language

**Composition root.** The application location where concrete models, stores,
Loops, tools, policies, interfaces, and other dependencies are selected and
wired together. The user's application remains the final composition root.

**Conformance suite.** Reusable tests that every implementation of a public
contract must pass.

**Contract hub.** A small, stable module that defines shared interfaces and
types without depending on their concrete implementations.

**Data plane.** The surface used for ordinary runtime work, such as submitting
input, receiving output, and invoking tools, rather than changing control
policy.

**Dependency inversion.** Defining a small contract at the layer that needs it,
then supplying concrete behavior from the outside. This keeps the harness from
depending directly on every backend or integration.

**Dependency direction.** The rule that lower, more stable contract modules do
not import higher-level products or concrete integrations. Dependencies point
toward shared contracts.

**Durability.** The ability to preserve and recover meaningful state after a
crash, restart, disconnection, pause, or move to another machine.

**Leaf module.** A narrowly scoped module with few dependencies and no reason
to import the wider looprig runtime.

**Module.** An independently versioned Go module and repository boundary, such
as `harness`, `flow`, or `storage`.

**Package.** A Go source boundary inside a module. Packages group closely
related types and behavior.

**Public seam.** An intentional interface between replaceable parts of the
system, such as inference, storage, the sandbox, or foreign agent execution.

**Reference backend.** A small implementation used to demonstrate and test the
expected behavior of a contract.

**Reference oracle.** A simple implementation whose behavior is used as the
expected result when testing more complex implementations.

**Replay.** Reconstructing state deterministically from durable history or
checkpoints without repeating already committed side effects.

**Structural coupling.** Satisfying a small Go interface by method shape rather
than importing the package that owns a concrete implementation.

**SDK.** Software development kit. A library surface intended to be embedded in
another application, as distinct from a finished agent product.

**stdlib-first.** A project preference for the Go standard library at stable
contract layers, adding third-party dependencies only where they provide clear
value and can be contained.

## Mission and Brand

**Federated knowledge.** Knowledge and reasoning made broadly available through
open, composable systems instead of remaining trapped in a few people,
institutions, models, or vendors. Here, federated describes access and ownership,
not one specific distributed-learning technique.

**Industrial Revolution.** The historical transformation in which engines,
machine tools, factories, and infrastructure converted new sources of physical
power into large-scale automation.

**Intellectual Revolution.** Our name for the shift from knowledge and
reasoning concentrated in a few people toward intelligence that can be made
widely available through neural networks and the machinery built around them.

**Lathe.** The mission metaphor for looprig. GPUs and TPUs provide computing
power, neural networks turn it into intelligence, and looprig gives that
intelligence the precision and control needed to produce useful systems. The
power source will keep changing. We intend looprig to remain the adaptable
machine that puts it to work.

**Steam engine.** The mission metaphor for a foundational source of power. In
the current era, GPUs and TPUs supply computation in the way steam engines once
supplied mechanical power. Neural networks turn that computation into
intellectual capability.

**Loop in the logo.** The open infinity form represents intelligence and its
continuing potential.

**Rig in the logo.** The triangle represents the structure that contains,
directs, and makes that potential reliable.

**Rig in the name.** A rig is assembled equipment that harnesses power for a
purpose. Sailing rigs harness wind, drilling rigs put mechanical power to work,
and test rigs make systems controlled and repeatable. A looprig applies that
same idea to an agent Loop.

**Electric Lime, `#D4F84D`.** The energy color. It represents the active power
of intelligence moving through the Rig.

**Light Sky Blue, `#A2D2FF`.** The stability color. It represents trust,
reliability, clarity, and calm control around that power.

**The rig that runs the loop.** A compact expression of the project name: the
Loop is the continuing intelligence, and the Rig is the owned machinery that
makes it useful.