Skip to content

Reference

Glossary

Plain-language definitions of the terms used across AnvayaOS: capabilities, CSpaces, AEC, the nucleus, attestations and more.

Mirrored from the source repository at each release

This glossary is the canonical vocabulary reference for AnvayaOS.

It is written to help both:

  • newcomers who need plain-English explanations first
  • contributors who need the technical meaning Anvaya intends

The first sentence of each entry is layman-friendly. The second sentence is more technical. When Anvaya uses a term in a project-specific way, that is called out explicitly.

Core Concepts

If you only read a few entries, start here:

A

A2A

A2A is the agent-to-agent protocol family for discovering agent capabilities, exchanging task messages, and coordinating work through Agent Card-like descriptors. In Anvaya, A2A is never ambient network authority: every peer is an exact endpoint capability and every message carries authenticated AEC identity.

The bounded 0.5 Gate D services/anvaya-a2a core implements capability-scoped cards/discovery, caller/process-bound trusted SVID messages with attenuated capability transfer, replay-safe ordered delivery, kernel-derived child CSpace grants, quota-reserved sub-agent delegation, SVID-signed goal claims and deterministic goal arbitration, identity mismatch rejection, and hash-chained audit. Cross-node transport and durable service deployment remain later work.

Ambient Authority

Ambient authority means code gets broad permissions simply because of where or how it was launched. In capability systems, this is considered dangerous because the program can do more than it explicitly asked for.

In Anvaya, “no ambient authority” means a task or agent should only be able to act through explicit capabilities, not inherited global power.

ANVAYA

ANVAYA is the name of the project. The word is used to emphasize logical connection, lineage, and traceability from cause to effect.

In project terms, it signals that actions, permissions, and decisions should be understandable and auditable, not opaque.

Agent Execution Context (AEC)

An Agent Execution Context is the accountable container for AI-agent work. In plain terms, it is where an agent's identity, goal, permissions, supervisor, budget, planning space, approvals, and audit trail are tied together.

In Anvaya, the AEC semantic model is accepted in RFC 0002: AECs sit above normal processes and tasks, use explicit capabilities and RFC 0010 syscall-backed execution through those lower substrates, and do not add a separate kernel syscall family. The bounded Gates B–C runtime implements Ed25519 identity, structured root/delegated goals, rooted supervision, attenuation-only capabilities, quotas, process/task bindings, lifecycle/cancellation, a side-effect-free world model, exact approval/effect separation, reconciliation, and per-AEC hash-chained audit. The Broker-created AEC bridge and capability-bound A2A coordination are also evidence-backed in Gates A and D.

B

Blueprint Label

A blueprint label says how mature a claim is. In simple terms, it tells readers whether a statement is proven, planned, provisional, rejected, or superseded.

In Anvaya, blueprint labels are tracked in the RFC traceability matrix so manifesto and architecture claims do not get confused with current implementation evidence.

C

Capability

A capability is a tamper-resistant permission token for using a resource. It is best thought of like a keycard that opens only specific doors, not a master key.

Technically, capabilities are unforgeable references to kernel-managed objects or resources. In Anvaya, the current prototype proves abstract authority semantics and bounded table behavior, and RFC 0007 now accepts the production software CSpace/handle representation while CHERI hardware encoding remains future work.

Capability Table

A capability table is the place where a task's usable permissions are recorded. In plain terms, it is the system's local ledger of which keycards exist and what each keycard can open.

In the current Anvaya proof, the internal table is bounded to six slots and records slot state, generation, lineage, rights, parent-slot links, and validated object metadata; RFC 0007 generalizes that into the accepted software CSpace and handle representation.

Capability Boundaries

Capability boundaries is a public-facing Anvaya phrase for tightly scoped permission limits. It means every important action should have a visible and narrow boundary around what it is allowed to touch.

This is a site/positioning phrase layered on top of the more technical concept of capabilities.

Capability Delegation

Capability delegation means handing some authority to another task or agent. The important rule is that you should only be able to pass the same power or less, not secretly create more.

In Anvaya’s current proof slice, delegation is executable for an endpoint capability and for a bounded local object capability: endpoint receive/reply authority is narrowed to receive-only, and object read/inspect authority is narrowed to inspect-only for a second task context.

CHERI

CHERI is a hardware capability model that makes pointers carry authority, bounds, and permissions. In plain terms, it is a way for hardware to help enforce safer, narrower access rules.

For Anvaya, CHERI is a future-facing hardware-backed direction, not something the current prototype depends on for correctness.

Cognitive Sandboxing

Cognitive sandboxing means an agent can think, simulate, or plan inside an isolated internal model before it touches the real world. The core idea is “reason first, act later, and only with approval.”

In Anvaya, RFC 0002 accepts the planning-without-side-effects boundary for AECs. The bounded 0.5 Gate C runtime implements it with a world model that has no executor, exact expiring approval bindings, pre-effect capability/quota checks and a fully authenticated, flush-ordered two-slot COW action-start journal, one explicit executor boundary, substitution denial, and reconciliation. A user-facing approval UI and full 0.6 constitutional policy engine remain later work.

Content-Addressed Storage

Content-addressed storage identifies data by what it is, not by where it sits in a folder tree. In simple terms, the name comes from the content’s hash.

This is a planned Anvaya storage model, not something implemented in the current prototype.

CSpace / Cap-Table

CSpace is where a task’s capabilities live. A cap-table is the simpler generic phrase for the table or structure that holds those capabilities.

In Anvaya, RFC 0007 accepts per-task CSpaces, slot/generation/lineage metadata, format 0x1 software u64 handles behind RFC 0010 opaque handles, IPC import/export, parent/lineage revocation, stale-handle failure, and software fallback. CHERI sealed-handle encoding and process-loader details remain future work.

D

Device Mesh

Device mesh is Anvaya’s idea of multiple devices forming one coordinated system. A task, capability, or workload could move across devices instead of living on only one machine.

This is a future project concept, not part of the current first-light milestone.

DTB / FDT

A DTB is a small binary hardware description handed to the kernel at boot. It tells the system what memory and devices exist.

DTB means Device Tree Blob. FDT means Flattened Device Tree, the format behind it. In the current Anvaya prototype, DTB handling now covers header validation, a bounded memory-range discovery pass, and reservation-map scanning, but it is still not a full general-purpose parser.

E

Endpoint

An endpoint is a communication port used for message passing. You can think of it as a mailbox or rendezvous point between two execution contexts.

In Anvaya’s current prototype and accepted local IPC baseline, the first contract is still centered on one endpoint, but it now has three blocking request/reply proof paths rather than only one.

Energy Broker

The Energy Broker is Anvaya’s planned subsystem for making power and carbon visible system resources. It is about budgeting, scheduling, and accounting for energy, not just using whatever power happens to be available.

This is a future-facing Anvaya service, not part of the current verified-first-light implementation.

F

First-Light

First-light means the earliest executable milestone where the system proves basic life signs. In plain words: it boots, does something small but real, and leaves evidence.

In Anvaya, this started as the first QEMU/OpenSBI/S-mode boot milestone before the project moved to “Verified First Light.”

H

HAL

HAL stands for Hardware Abstraction Layer. It is the layer that hides some board-specific details so the rest of the system can stay more portable.

In Anvaya, HAL work is planned, but it is not yet a major part of the current boot slice.

Hart

A hart is a RISC-V hardware execution thread. It is the thing actually running instructions.

It is often close to what people casually call a core or hardware thread, but “hart” is the RISC-V term Anvaya uses in boot/status output.

Hardware Escape

Hardware escape means humans can still interrupt or reclaim control even if software misbehaves badly. In plain terms, it is the “hard stop” or “physical override” idea.

This is a future Anvaya safety principle, not something proven by the current prototype.

I

Intelligence Broker

The Intelligence Broker is Anvaya’s OS service for model serving, inference scheduling, and eventually agent coordination. It is the project’s name for AI workloads managed as first-class system concerns.

The 0.5 Gate A slice is implemented as a bounded no-std versioned model registry and inference service: exact model and MCP tool resources require explicit capabilities, inference sessions carry fail-closed quotas, every inference rechecks authority, and accepted/denied operations are hash-chain audited. QEMU proves the broker over live registered U-mode dispatch. The same service now exposes an audited, MANAGE-authorized RFC 0002 AEC-creation bridge; Gates C–D provide the bounded approval and A2A coordination cores.

Interrupt

An interrupt is a signal that makes the CPU pause normal execution and jump to handler code because something needs attention. A timer event is a common example.

Technically, a trap is the broader category, and interrupts are one kind of trap. In the current Anvaya prototype, one timer-backed interrupt path is now part of the verified slice.

IPC

IPC stands for Inter-Process Communication. More broadly, it means one execution context exchanging messages with another.

In Anvaya’s current milestone, IPC still means a narrow synchronous request/reply contract rather than a broad messaging framework, but it now includes timer-backed, task-context, delegated endpoint-capability, and bounded object/task proof paths.

M

Microkernel

A microkernel is a very small kernel that keeps only the most essential low-level jobs in privileged mode. Most higher-level services live outside it.

Anvaya’s project-specific name for its microkernel layer is the Nucleus.

MMIO

MMIO stands for Memory-Mapped I/O. It means hardware devices are controlled by reading and writing special memory addresses.

In the current prototype, the UART is accessed through MMIO.

N

Nucleus

The Nucleus is Anvaya’s name for its privileged kernel core. It is the part that boots first and provides the narrow trusted substrate beneath everything else.

Right now, the Nucleus is still an early Rust prototype, but it already proves boot, panic, DTB-backed resource inventory, explicit IPC failure outcomes, capability attenuation, table-backed parent/derivative invalidation, a child task handoff, one timer-backed event path, three synchronous request/reply proof paths, and one bounded object/task capability-table proof.

O

OpenSBI

OpenSBI is the firmware layer that helps an S-mode OS interact with lower-level machine features on RISC-V. In simple terms, it is the helper firmware sitting below the kernel in the current virtual boot path.

Anvaya’s verified-first-light milestone relies on QEMU’s default OpenSBI firmware.

Operator Sovereignty

Operator sovereignty is a public-facing Anvaya phrase meaning humans remain the final authority over policy, deployment, and shutdown.

This is a user-facing expression of the deeper project principle of human override.

P

Post-Quantum Cryptography

Post-quantum cryptography means cryptography designed to remain safe even if practical quantum attacks arrive. In plain language, it is crypto meant to survive a future where today’s common schemes may not.

This is a long-term Anvaya design commitment, not a part of the current nucleus implementation.

Proof Bundle

A proof bundle is the evidence package that shows a milestone really happened and can be checked again. Think of it as the receipts for a technical claim.

In current Anvaya usage, that includes commands, CI references, deterministic serial transcripts, and an explicit scope of what was actually proven.

Protected Execution Context

A protected execution context is a place where code runs with enforced isolation from other code. In plain terms, it is a bounded execution environment that should not have unlimited spillover into the rest of the system.

This phrase is somewhat overloaded in industry. In Anvaya, it should be used carefully and tied to a more precise term like task context, AEC, or a future formal isolation boundary.

Q

QEMU

QEMU is software that pretends to be a computer so we can boot and test Anvaya without physical RISC-V hardware. It is basically a virtual hardware lab.

For Anvaya’s current milestone, the relevant target is the RISC-V virt machine provided by QEMU.

QEMU virt

QEMU virt is the generic virtual RISC-V machine Anvaya uses for early bring-up. It is the concrete emulated platform for the current verified-first-light proof.

It is not a real hardware board and should not be confused with physical-device support.

R

Request/Reply

Request/reply means one side asks for something and the other side answers before the caller continues. It is the simplest useful two-way interaction pattern.

In Anvaya’s current IPC slice, request/reply means blocking round trips over one endpoint, with timer, task-context, and delegated endpoint-capability paths currently proven; the object/task table proof is a separate local authority handoff, not a broad messaging framework.

Revocation

Revocation means taking back previously granted permission. In simple terms, if a capability was handed out earlier, revocation is how the system can later invalidate it.

Anvaya’s current proof demonstrates table-backed revocation for one local object family: after revocation, the parent slot, an inspect-only derivative slot, and a second-hop derivative fail authorization, while an unrelated local-object lineage remains valid. RFC 0007 now accepts the production software CSpace and handle representation that preserves this parent/lineage behavior.

RFC

RFC stands for Request for Comments. It is a design document used to explain, review, and freeze important technical decisions.

In Anvaya, RFCs are the decision ledger for things like the boot contract and the accepted narrow local capability/IPC baseline.

RV64GC

RV64GC is a specific 64-bit RISC-V ISA profile. It is the concrete architecture target used by the current Anvaya prototype.

You can think of it as “the flavor of RISC-V the current build is compiled for.”

S

SBI

SBI stands for Supervisor Binary Interface. It is the standard call interface an S-mode kernel uses to request certain services from lower-level firmware.

OpenSBI is the implementation used in Anvaya’s current QEMU path, but SBI is the interface concept and OpenSBI is one implementation of it.

S-Mode

S-mode is the supervisor privilege level on RISC-V. It is the normal privilege level where an operating system kernel typically runs.

Anvaya’s current nucleus prototype runs in S-mode, not the higher-level machine mode.

Specification-Stage Project

Specification-stage project means most of the system still exists as design, docs, and staged contracts, with only a smaller amount of executable proof so far.

This is the right plain-English description of Anvaya today: real prototype work exists, but it is still much smaller than the full vision.

Synchronous IPC

Synchronous IPC is message passing where the sender and receiver meet in time, so one side blocks until the handoff completes. In plain terms, it is a live exchange, not a fire-and-forget dropbox.

Anvaya’s current IPC milestone deliberately freezes only the smallest blocking synchronous path; object/task capability-table work remains a separate local authority proof.

T

Task Context

A task context is the execution state and attached resources needed to run or resume a task. In plain terms, it is the bundle that makes a task a real runnable thing instead of just an idea.

In the current prototype, Anvaya uses a child task plus a bootstrap bundle, and it also records two deterministic local task contexts for the object-capability proof. RFC 0007 now accepts the production software CSpace and handle representation; the broader process-loader ABI remains future work.

Timer

A timer is the hardware time source used to trigger “do this later” events. In simple terms, it is how the system gets a wake-up event after a chosen delay.

In the current Anvaya milestone, one timer-backed interrupt path is part of the verified slice.

Trap

A trap is any event that diverts execution into handler code. Interrupts are one kind of trap; synchronous faults and exceptions are others.

In the current prototype, Anvaya installs a trap vector and uses it to handle the timer-backed path and panic-adjacent failures.

Trap Vector

A trap vector is the entry point the CPU jumps to when a trap happens. It is the kernel’s first landing zone for interrupts and exceptions.

The Anvaya prototype installs a low-level trap vector during boot and uses it for the timer-backed event path.

TSC

TSC stands for Technical Steering Committee. It is the proposed top-level technical decision body in Anvaya’s governance model.

At the moment, Anvaya is still in a bootstrap governance phase rather than full committee operation.

U

UART

UART is a simple serial hardware block used to send and receive bytes. It is often the earliest and most reliable debug console for a kernel prototype.

In Anvaya’s current proof path, the UART is the source of the deterministic serial transcript.

Userspace ABI

Userspace ABI is the stable binary contract between programs and the system runtime/kernel boundary. It covers calling conventions, binary compatibility, and low-level interface rules.

Anvaya now has an accepted syscall ABI contract in RFC 0010 and an accepted software CSpace/handle representation in RFC 0007. The broader userspace process-loader ABI, SDK ABI, application runtime ABI, and CHERI sealed-handle ABI are still not stable.

V

Verified First Light

Verified First Light is Anvaya’s name for the first evidence-backed boot milestone. It means the system has gone beyond “we think it works” and can now show reproducible proof for a narrow slice.

In the current repo, that milestone includes QEMU virt, OpenSBI, S-mode Rust nucleus boot, deterministic boot and panic transcripts, DTB-backed inventory, explicit IPC failure evidence, capability attenuation evidence, table-backed object/task capability evidence, a child task context, one timer-backed interrupt path, and three synchronous local request/reply IPC proof paths.

Vision Traceability Matrix

The vision traceability matrix is the project’s map from big promises to concrete RFC homes. In plain terms, it is how Anvaya keeps the manifesto, architecture, status page, roadmap, and implementation evidence from drifting apart.

The matrix lives in the RFC repository and labels each major claim as stable, evidence-backed prototype, provisional, planned, rejected, or superseded.

W

WASI

WASI stands for WebAssembly System Interface. It is the standard interface layer that lets WebAssembly programs talk to operating system services.

In Anvaya, WASI and “Anvaya WASI extensions” are planned future runtime concerns, not part of the current nucleus proof slice.

World Model

A world model is an internal model an agent uses to reason about the world before it takes action. In plain terms, it is the agent’s sandboxed mental workspace.

In Anvaya, RFC 0002 accepts world models as side-effect-free AEC planning state. The bounded 0.5 Gate C implementation stores plans and reconciled facts, owns no executor during planning, and requires an exact approval plus revalidated capability, quota reservation, and a fully authenticated durable action-start journal before the sole effect boundary. Durable world-model storage and production service deployment remain later work.

Notes On Style

  • Use AnvayaOS for the public project name.
  • Use first-light with a hyphen.
  • Use request/reply consistently for the current blocking IPC slice.
  • Use Nucleus for Anvaya’s privileged kernel core and microkernel when speaking generically.