<!-- GENERATED FILE: edit records/term.*/*.md and run npm run build:glossary. -->

# Terms and Definitions

This document is generated from GraphMD term records.

## Benac Station

A Station participating in Benac semantics. It may run a full Benac kernel, a host implementation, a compatible storage/compute endpoint, or a package-mediated bridge represented inside Benac.

**Usage:** Use when the document needs to distinguish Benac-aware participation from a generic device or server.

**Source section:** 3. Station terminology

**Source:** `records/term.benac-station/benac-station.md`

## Owned Station

A Station believed by the user or organization to be under their administrative or physical control.

**Usage:** Owned does not automatically mean trusted for all data classes or capabilities; Local Policy still governs.

**Source section:** 3. Station terminology

**Source:** `records/term.owned-station/owned-station.md`

## Public Station

A Station advertised for public or semi-public use, such as public compute, public storage, or a public package mirror.

**Usage:** Public Stations should be treated as untrusted by default, especially for private data and plaintext compute.

**Source section:** 3. Station terminology

**Source:** `records/term.public-station/public-station.md`

## Station Sovereignty

The principle that each Local Station applies its own trust, capability, storage, compute, encryption, disclosure, and replication policy. Replicated documents and remote offers do not become authority automatically.

**Usage:** Use this phrase when explaining that Benac is decentralized without surrendering local control.

**Source section:** 3. Station terminology

**Source:** `records/term.station-sovereignty/station-sovereignty.md`

## Delivery Origin

The HTTPS origin that serves a browser PWA implementation of Benac.

**Usage:** The Delivery Origin is not automatically a Station, registry, or authority. It serves the app shell. If it also stores, computes, signs, or offers resources, those roles must be represented explicitly.

**Source section:** 3. Station terminology

**Source:** `records/term.delivery-origin/delivery-origin.md`

## Browser PWA Host

A Host Implementation delivered as an HTTPS-served installable Progressive Web App and running inside a mobile or desktop browser.

**Usage:** Use when describing the browser-hosted Benac implementation. Browser PWA Hosts are an important portability target because they run with ordinary browser capabilities.

**Source section:** 4. Host and platform terminology

**Source:** `records/term.browser-pwa-host/browser-pwa-host.md`

## Desktop Host

A Host Implementation running on Ubuntu, macOS, Windows, or a desktop browser.

**Usage:** Desktop Hosts may expose more capabilities than mobile browsers, but extra power must remain explicit and policy-gated.

**Source section:** 4. Host and platform terminology

**Source:** `records/term.desktop-host/desktop-host.md`

## Host Capability

A capability provided by a Host Implementation and made available to packages only through Benac’s capability grant model.

**Usage:** A Host may provide a capability; a package may request it; Local Policy may grant or deny it.

**Source section:** 4. Host and platform terminology

**Source:** `records/term.host-capability/host-capability.md`

## Platform Compatibility

The condition that a requested package operation appears compatible with known Station facts, such as available mediation paths, artifacts, resources, platform permissions, and capability grants.

**Usage:** Compatibility is not authority. Compatibility can be known, unknown, not yet determined, unavailable, denied, or observed after an allowed attempt.

**Source section:** 4. Host and platform terminology

**Source:** `records/term.platform-compatibility/platform-compatibility.md`

## Kernel

A short name for Benac Core plus the host-mediated mechanisms needed to execute packages and enforce policy on a particular Station.

**Usage:** Use “Benac Core” when precision is needed; use “kernel” informally when describing the governing runtime.

**Source section:** 4. Host and platform terminology

**Source:** `records/term.kernel/kernel.md`

## Package Bundle

A Package Bundle is an importable/exportable package distribution context containing a package document and selected related schemas, artifacts, fixtures, claims, documentation, reports, and blobs. A Package Bundle used as a package import artifact shall be represented as a Package Bundle ZIP file containing `bundle/package_bundle_manifest.json`. A Package Bundle is a distribution format. The package CID remains the authoritative content identity of the package document and is not changed by bundle-local packaging metadata.

**Usage:** Bundle-carried fixtures may be required for evaluating package validation, inspection, approval, fixture execution, or invocation in a Package Bundle context without changing the package CID.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.package-bundle/package-bundle.md`

## Package Artifact

A content-addressed artifact referenced by a package, such as a WASM module, schema document, media file, test fixture, model fragment, or operation resource.

**Usage:** Artifacts usually live in the Blob Store and are referenced by DASL CID.

**Usage:** Package artifacts may be raw blobs or structured documents depending on artifact role and CID codec.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.package-artifact/package-artifact.md`

## Package Interface

A declared surface through which a package can be used. A package interface identifies how the Station talks to the package and how the package talks back, including request schema, descriptor config schema where applicable, output schema where applicable, declared capabilities, artifact requirements, resource requirements, evidence behavior, and effect behavior.

**Usage:** Interfaces describe the package's schema-bound conversation contract. Interfaces do not grant authority. Interfaces do not classify the package or how package work is performed.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.package-interface/package-interface.md`

## Schema-defined package behavior

Package behavior represented as structured data interpreted by the Station according to defined schemas and semantics.

**Usage:** Schema-defined package behavior is a mechanism contract. It does not grant authority, classify packages, or classify how package work is performed.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.schema-defined-package-behavior/schema-defined-package-behavior.md`

## Invocation Contract Snapshot

A content-addressed snapshot of the schema-bound package contract relied upon for a package operation, including package CID, package interface, relevant schemas, descriptor scope where applicable, declared capabilities, artifact requirements, resource requirements, evidence behavior, and effect behavior.

**Usage:** Invocation contract snapshots identify the operation contract used for approval, invocation, audit, storage, compute, evidence, and effect records.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.invocation-contract-snapshot/invocation-contract-snapshot.md`

## Operation Status

A recorded status for a package-related operation, such as not currently mediated by this Station, not yet determined, grant missing, denied by policy, artifact unavailable, resource unavailable, attempt denied, attempt failed, or attempt completed.

**Usage:** Operation status records what is known about a specific operation without changing package content identity or granting authority.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.operation-status/operation-status.md`

## Station Status

A recorded fact or observation about what a Station currently knows, can mediate, has denied, has attempted, has failed, or has completed for a package-related operation.

**Usage:** Station status can change after inspection, Local Policy decisions, allowed probes, allowed attempts, platform permission decisions, resource checks, artifact checks, failures, or completed operations.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.station-status/station-status.md`

## Request

The input object supplied for a specific invocation of a package interface.

**Usage:** Requests are validated against package-declared request schemas before package execution. The package-visible request is the validated logical request from the invocation input envelope.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.request/request.md`

## Output

The package result returned by a package invocation after package-specific interpretation and validation against the package output schema where one is declared.

**Usage:** Output is not a substitute for raw evidence. Where output is content-addressed, its identity should include package CID, package interface, invocation contract snapshot, output schema, and output body through an output snapshot.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.output/output.md`

## Hello-World Package

A minimal package used to demonstrate and test that independent Benac implementations can import, verify, inspect, approve, invoke, and audit the same package.

**Usage:** The hello-world package should have minimal capabilities and no provider-specific behavior.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.hello-world-package/hello-world-package.md`

## Conformance Package

A package designed to test Benac compatibility across Host Implementations.

**Usage:** Conformance packages should cover package document validation, Package Bundle import, package inspection, fixture execution, generic request/config invocation, schema-defined package behavior, WASM package-host calling convention behavior, capability denial, evidence/effects, resource limits, no silent fallback, encryption, storage, and compute behavior as applicable.

**Source section:** 5. Package and execution terminology

**Source:** `records/term.conformance-package/conformance-package.md`

## User Principal

A principal associated with a human user or user-controlled identity.

**Usage:** A user may control multiple Stations and multiple keys.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.user-principal/user-principal.md`

## Agent Principal

A principal associated with an AI or human-operated agent using Benac APIs.

**Usage:** Agent identity and Agent Authority are separate.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.agent-principal/agent-principal.md`

## Package Author Principal

A principal claiming to have authored, assembled, or published a package.

**Usage:** Author claims are useful provenance but not automatic trust.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.package-author-principal/package-author-principal.md`

## Reviewer Principal

A principal that signs review, approval, test, security, conformance, or provenance claims.

**Usage:** Local Policy decides whether a reviewer’s claims matter.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.reviewer-principal/reviewer-principal.md`

## Compute Station Principal

The principal associated with a Compute Station or compute-capable endpoint.

**Usage:** Remote compute results should be attributable to this principal.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.compute-station-principal/compute-station-principal.md`

## Storage Station Principal

The principal associated with a Storage Station or storage-capable endpoint.

**Usage:** Storage offers, pin receipts, and retrieval receipts may be signed by this principal.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.storage-station-principal/storage-station-principal.md`

## Key Pair

A public/private cryptographic key pair used to identify a principal, sign claims, decrypt wrapped keys, or establish encrypted communication depending on the cryptographic profile.

**Usage:** Key usage should be explicit and profile-defined.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.key-pair/key-pair.md`

## Key Identifier

A stable identifier for a public key or principal key material under the Benac cryptographic profile.

**Usage:** Key identifiers should include algorithm/profile information.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.key-identifier/key-identifier.md`

## Private Key

Secret key material controlled by a principal.

**Usage:** Private keys shall not be package-readable and shall not replicate by default.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.private-key/private-key.md`

## Domain Separation

The practice of including object type, version, profile, or role context in payloads used for CIDs or signatures, references, or policy scopes to prevent cross-object confusion.

**Usage:** For structured objects, Benac object type and profile separation live in the logical payload encoded as DRISL. For raw blobs, the raw DASL CID identifies bytes while typed references bind Benac-specific roles.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.domain-separation/domain-separation.md`

## Identity Is Not Authority

A Benac principle: knowing who signed, offered, authored, stored, computed, or replicated something does not mean the Local Station should trust it.

**Usage:** Use this phrase to prevent signature and identity from becoming central-authority substitutes.

**Source section:** 6. Identity, signatures, and provenance terminology

**Source:** `records/term.identity-is-not-authority/identity-is-not-authority.md`

## Local Authority

The authority of the Local Station to decide which packages, principals, claims, capabilities, storage uses, compute uses, disclosures, and invocations are allowed locally.

**Usage:** Local Authority is not delegated to replication peers, package authors, storage providers, or compute stations unless Local Policy explicitly does so within scope.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.local-authority/local-authority.md`

## Trust Scope

The limits of a trust decision, such as allowed package CIDs, package interfaces, invocation contract snapshots, capabilities, descriptors, endpoints, data classes, time limits, or invocation counts.

**Usage:** Broad unscoped trust should be avoided. Trust scope does not grant capabilities outside the recorded scope.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.trust-scope/trust-scope.md`

## Capability Denial

A local policy result refusing a requested capability.

**Usage:** Denials should be recorded where relevant to inspection, approval, invocation, effect audit, retrieval, storage, compute, and operation-status records.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.capability-denial/capability-denial.md`

## Lease

A bounded local authorization to use a remote or sensitive resource, usually for storage, compute, disclosure, staging, or data egress.

**Usage:** Storage Lease and Compute Lease are specialized leases.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.lease/lease.md`

## Approval

A human, policy, or delegated local decision allowing a trust decision, capability grant, lease, or sensitive disclosure.

**Usage:** Approval should be attributable. Human approval may be required for high-risk data classes.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.approval/approval.md`

## Revocation

A local or signed claim that future use of a key, trust decision, capability grant, lease, or principal should stop or be treated as compromised.

**Usage:** Revocation cannot make a recipient forget plaintext already received.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.revocation/revocation.md`

## Fail Closed

The rule that Benac denies or stops operation when required identity, hash, blob, key, schema, trust, capability, lease, or verification information is missing, invalid, conflicted, or unsupported.

**Usage:** Fail closed is the opposite of silent fallback or hopeful execution.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.fail-closed/fail-closed.md`

## No Silent Fallback

The rule that Benac shall not quietly switch packages, package interfaces, descriptor scopes, invocation contracts, storage sources, compute stations, trust scopes, capability scopes, data classes, schemas, or security behavior without explicit policy and recorded trace.

**Usage:** Blocked alternatives, fallback authority, and fallback reasons should be recorded.

**Source section:** 7. Trust, authority, policy, and capability terminology

**Source:** `records/term.no-silent-fallback/no-silent-fallback.md`

## Couch/Pouch-Compatible Document Model

A document database model compatible with PouchDB locally and CouchDB-style replication semantics for structured records.

**Usage:** Benac uses this model for local-first replication-shaped records.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.couch-pouch-compatible-document-model/couch-pouch-compatible-document-model.md`

## Sync Peer

A replication partner for document exchange.

**Usage:** A Sync Peer may also be a Peer Station, Storage Station, or Relay Station, but those roles should be stated explicitly.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.sync-peer/sync-peer.md`

## Document Conflict

A replication conflict between different revisions or versions of a mutable document.

**Usage:** Safety-sensitive conflicts, especially trust/capability conflicts, should fail closed.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.document-conflict/document-conflict.md`

## Immutable Document

A document whose identity is content-addressed and whose contents should not mutate. Changes produce a new content identity.

**Usage:** Package documents, schema documents, descriptor snapshots, and signed claims are typically immutable.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.immutable-document/immutable-document.md`

## Append-Only Record

A record that is added but not edited as part of normal operation, such as an invocation record, evidence record, effect record, or audit record.

**Usage:** Append-only records are replication-friendly and audit-friendly.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.append-only-record/append-only-record.md`

## Mutable Local Control Document

A local policy or UI document that may change, such as aliases, local trust settings, sync settings, and local capability preferences.

**Usage:** Mutable local control documents require explicit conflict handling.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.mutable-local-control-document/mutable-local-control-document.md`

## Station Store

The combined local data store of a Station, including its Document Store, Blob Store, local policy documents, trust decisions, keys metadata, and invocation/evidence/effect records.

**Usage:** Station Store is a useful human-friendly phrase for “the Station’s local memory.”

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.station-store/station-store.md`

## Local Package Catalog

The Local Station’s view of imported, available, trusted, untrusted, revoked, or missing packages and package-related claims.

**Usage:** A catalog is local. It is not a central registry.

**Source section:** 8. Document, replication, and local store terminology

**Source:** `records/term.local-package-catalog/local-package-catalog.md`

## Registry

A central or semi-central catalog service.

**Usage:** Avoid using Registry as a core Benac noun. Use Local Package Catalog, Package Source, Storage Offer, or Distribution Source instead unless describing an external non-authoritative service.

**Usage:** Use Local Package Catalog, package source, distribution source, or Storage Station unless specifically describing a non-authoritative external registry.

**Avoid:** Do not imply Benac requires a central registry.

**Notes:** Additional source definition from "16. Terms to avoid, reserve, or use carefully": A central catalog or package service.

**Source section:** 8. Document, replication, and local store terminology; 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.registry/registry.md`

## Content-Addressed Blob

A byte object identified by a DASL CID v1 raw CID under the Benac cryptographic profile.

**Usage:** Retrieved blob bytes must verify against the expected DASL CID before use.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.content-addressed-blob/content-addressed-blob.md`

## Blob Chunk

A content-addressed part of a larger blob.

**Usage:** Chunks support large artifacts, mobile storage constraints, deduplication, and resumable transfer.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.blob-chunk/blob-chunk.md`

## Blob Reference

A document field or manifest entry that refers to a blob by DASL CID.

**Usage:** A blob reference does not prove the bytes are locally present.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.blob-reference/blob-reference.md`

## Pin

A storage commitment or local policy choice to retain a blob or chunk.

**Usage:** Pinning improves availability but does not by itself grant trust.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.pin/pin.md`

## Unpin

A request or action to stop retaining a blob or chunk.

**Usage:** Unpin is more honest than “delete” in decentralized storage, because other copies may exist.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.unpin/unpin.md`

## Missing Blob

A blob referenced by a document or manifest but not present in the Local Station’s Blob Store.

**Usage:** If a required executable or evidence blob is missing and no approved retrieval path exists, Benac should fail loudly.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.missing-blob/missing-blob.md`

## Blob Garbage Collection

The process of reclaiming unreferenced or unpinned blob storage.

**Usage:** Garbage collection must respect pins, leases, local retention policy, and encrypted/private records.

**Source section:** 9. Blob and content-addressed storage terminology

**Source:** `records/term.blob-garbage-collection/blob-garbage-collection.md`

## Storage Discovery

The process of discovering Storage Stations, storage offers, blob location claims, pin receipts, storage capabilities, and possible retrieval or upload paths.

**Usage:** Storage Discovery finds possibilities. It does not grant authority.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.storage-discovery/storage-discovery.md`

## Remote Storage

Storage capability provided by a Storage Station other than the Local Station.

**Usage:** Remote Storage may store public blobs, encrypted private blobs, packages, package bundles, evidence bodies, or compute-staging data under policy.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.remote-storage/remote-storage.md`

## Storage Effect

An effect record caused by storage activity.

**Usage:** Examples: blob uploaded, encrypted blob stored, blob fetched, package artifact published, pin requested, unpin requested, retrieval failed, CID mismatch detected.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.storage-effect/storage-effect.md`

## Content Availability

The practical availability of needed blobs, chunks, package artifacts, evidence bodies, or package bundles across local and remote storage.

**Usage:** Availability is tracked separately from content identity and trust.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.content-availability/content-availability.md`

## Benac CAS Exchange Profile

A possible standard profile for Benac-compatible content-addressed storage exchange between Stations.

**Usage:** It would define operations such as has_blob, get_blob, put_blob, pin_blob, unpin_blob, and storage_receipt without centralizing storage.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.benac-cas-exchange-profile/benac-cas-exchange-profile.md`

## Storage Bridge Package

A package that connects Benac to a storage system or object store not natively understood by the core.

**Usage:** Provider-specific storage behavior belongs in packages or compatible stations, not in Benac Core.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.storage-bridge-package/storage-bridge-package.md`

## Deletion Honesty

The principle that Benac should distinguish local deletion, remote unpin, access revocation, key destruction, and deletion requests, without claiming impossible global deletion guarantees.

**Usage:** Use this term when describing limitations of decentralized storage and plaintext disclosure.

**Source section:** 10. Storage discovery and remote storage terminology

**Source:** `records/term.deletion-honesty/deletion-honesty.md`

## Compute Discovery

The process of discovering Compute Stations, compute offers, costs, limits, evidence behavior, and mediated compute operation paths.

**Usage:** Compute Discovery finds possibilities. It does not grant authority.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.compute-discovery/compute-discovery.md`

## Remote Compute

Compute performed by a Compute Station other than the Local Station.

**Usage:** Remote Compute may be useful for expensive work but is dangerous for private data once plaintext is disclosed.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.remote-compute/remote-compute.md`

## Local Compute

Compute performed by the Local Station on its own Host Platform.

**Usage:** Local compute may still require capability grants and should still record evidence/effects.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.local-compute/local-compute.md`

## Compute Descriptor

A configured local descriptor for interacting with a Compute Station or compute service.

**Usage:** It may include endpoint, auth reference, allowed packages, data classes, and expected evidence requirements.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.compute-descriptor/compute-descriptor.md`

## Compute Result

A result returned from a mediated compute operation.

**Usage:** Compute results should be bound to request CID, nonce or challenge, package CID, invocation contract snapshot CID, output CID, evidence CID, and Compute Station Principal where possible.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.compute-result/compute-result.md`

## Compute Evidence

Evidence produced by or about compute execution, such as package interface, invocation contract snapshot, logs, input CID, output CID, timings, resource use, model descriptor, token stream, attestations, or failure details.

**Usage:** Compute Evidence does not automatically prove safe deletion or honest execution absent stronger mechanisms.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.compute-evidence/compute-evidence.md`

## Compute Staging

The process of making package artifacts, input blobs, or other required data available to a Compute Station or nearby Storage Station before execution.

**Usage:** Staging must be governed by Storage Leases, Compute Leases, encryption terms, and data-egress policy.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.compute-staging/compute-staging.md`

## Remote Compute Disclosure

The act of making private data or decryption capability available to a Compute Station.

**Usage:** This is a Plaintext Disclosure if the Compute Station can decrypt or receive plaintext.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.remote-compute-disclosure/remote-compute-disclosure.md`

## Compute Bridge Package

A package that connects Benac to a compute system not natively understood by the core.

**Usage:** Provider-specific compute behavior belongs in packages or compatible stations, not in Benac Core.

**Source section:** 11. Compute discovery and remote compute terminology

**Source:** `records/term.compute-bridge-package/compute-bridge-package.md`

## Encrypted Blob

A Private Blob stored as ciphertext under an encrypted envelope.

**Usage:** The ciphertext may be stored remotely without revealing plaintext, subject to metadata leakage.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.encrypted-blob/encrypted-blob.md`

## Encrypted Document

A replicated document whose sensitive contents are protected by an encrypted envelope.

**Usage:** The Document Store may replicate encrypted documents without being able to interpret their private contents.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.encrypted-document/encrypted-document.md`

## Envelope Encryption

A pattern in which content is encrypted with a fresh content-encryption key, and that content key is wrapped for one or more recipient principals.

**Usage:** Envelope encryption supports recipient-based sharing without re-encrypting large blobs for every recipient.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.envelope-encryption/envelope-encryption.md`

## Content-Encryption Key

A symmetric key used to encrypt a specific private blob, private document, or package bundle payload.

**Usage:** Content-encryption keys should not be package-readable by default.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.content-encryption-key/content-encryption-key.md`

## Wrapped Key

An encrypted form of a content-encryption key for a specific recipient principal.

**Usage:** Adding a wrapped key for a remote principal is a disclosure-relevant event.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.wrapped-key/wrapped-key.md`

## Recipient Principal

A principal for whom encrypted content has been made decryptable through key wrapping or other authorized sharing.

**Usage:** Recipient status should be explicit and auditable.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.recipient-principal/recipient-principal.md`

## Client-Side Encryption

Encryption performed by the Local Station before data is sent to remote storage, replication, export, or staging.

**Usage:** Client-side encryption protects against untrusted storage but not against compute that receives plaintext or keys.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.client-side-encryption/client-side-encryption.md`

## Plaintext

Unencrypted data or data made available in a form equivalent to unencrypted data for use by a host, package, station, or principal.

**Usage:** Plaintext exposure is the boundary where encryption stops protecting confidentiality from the recipient.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.plaintext/plaintext.md`

## Disclosure Effect

An effect record showing that private data, decrypted data, or decryption capability became available to another principal or host.

**Usage:** Examples: private blob wrapped for principal, private blob decrypted locally, private blob disclosed to remote compute, secret injected.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.disclosure-effect/disclosure-effect.md`

## Decryption Capability

A capability allowing a package, host, station, or invocation to access plaintext or request decryption under local policy.

**Usage:** Decryption should be scoped to specific blobs, descriptors, invocations, leases, data classes, and recipients.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.decryption-capability/decryption-capability.md`

## Output Encryption

A lease or policy requirement that outputs of compute or package invocation be encrypted to approved recipients before storage, replication, or return.

**Usage:** Output encryption protects result storage/transport but does not prove compute deleted intermediate plaintext.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.output-encryption/output-encryption.md`

## Deterministic Encryption

Encryption that produces the same ciphertext for the same plaintext and key or derivation conditions.

**Usage:** Benac should not use deterministic encryption for private blobs by default because it can leak equality and enable guessing attacks.

**Avoid:** Do not use deterministic private blob encryption unless explicitly approved for a low-sensitivity use case.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.deterministic-encryption/deterministic-encryption.md`

## Metadata Leakage

Information exposed by sizes, timestamps, access patterns, recipient lists, storage locations, plaintext hashes, or other metadata even when content is encrypted.

**Usage:** Benac should make sensitive metadata encryptable or minimizable where practical.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.metadata-leakage/metadata-leakage.md`

## Local Vault

Host-mediated protected storage for private keys, secret material, wrapped keys, and other sensitive local state.

**Usage:** Browser and desktop implementations may use different mechanisms, but packages should not read vault contents directly.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.local-vault/local-vault.md`

## Secret

Sensitive value such as API key, token, credential, passphrase, or private endpoint credential.

**Usage:** Secrets do not replicate by default and should be host-mediated.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.secret/secret.md`

## Secret Reference

A descriptor or request field that names a secret without containing the secret value.

**Usage:** Packages may reference secrets by reference but should not receive raw secret values by default.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.secret-reference/secret-reference.md`

## Secret Injection

Host-mediated use of a secret in an approved operation, such as adding an Authorization header to an HTTPS request.

**Usage:** Secret injection should be recorded as an effect and redacted from evidence.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.secret-injection/secret-injection.md`

## Private Replication

Replication of encrypted private documents, encrypted blobs, or encrypted package bundles without exposing plaintext to replication peers.

**Usage:** Private replication is useful but does not make remote compute safe after decryption.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.private-replication/private-replication.md`

## Deletion by Key Destruction

A privacy strategy in which access to encrypted content is removed by destroying or revoking decryption keys.

**Usage:** This prevents future decryption by those without keys, but cannot erase plaintext already disclosed or copied.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.deletion-by-key-destruction/deletion-by-key-destruction.md`

## Encryption Is Not Trust

A Benac principle: encryption protects data before disclosure, but once plaintext or decryption capability is given to a host or principal, Benac cannot prove deletion or prevent abuse.

**Usage:** This principle should appear in UX warnings and policy decisions involving remote compute.

**Source section:** 12. Encryption, decryption, and disclosure terminology

**Source:** `records/term.encryption-is-not-trust/encryption-is-not-trust.md`

## Invocation Ledger

The append-only record set of package invocations and their governing metadata.

**Usage:** The Invocation Ledger answers what ran, where, why, with which package, package interface, descriptor scope, invocation contract, actor, trust, capabilities, and outcome.

**Source section:** 13. Evidence, effects, ledgers, and receipts terminology

**Source:** `records/term.invocation-ledger/invocation-ledger.md`

## Evidence Ledger

The append-only record set of evidence produced or observed by invocations and related operations.

**Usage:** Raw evidence should be stored before or alongside normalized or validated output where practical.

**Source section:** 13. Evidence, effects, ledgers, and receipts terminology

**Source:** `records/term.evidence-ledger/evidence-ledger.md`

## Effect Ledger

The append-only record set of effects attempted or caused by packages, agents, storage, compute, disclosure, or host-mediated operations.

**Usage:** Effects are the receipts for what Benac touched or attempted to touch.

**Source section:** 13. Evidence, effects, ledgers, and receipts terminology

**Source:** `records/term.effect-ledger/effect-ledger.md`

## Audit Record

A structured record used to inspect, verify, or explain package, trust, storage, compute, encryption, disclosure, and invocation behavior.

**Usage:** Audit records may be content-addressed, signed, hash-linked, or included in package bundles.

**Source section:** 13. Evidence, effects, ledgers, and receipts terminology

**Source:** `records/term.audit-record/audit-record.md`

## Receipt

Evidence that a storage, compute, disclosure, package, or capability operation occurred or was attempted.

**Usage:** Receipts can be local records or signed claims from remote Stations.

**Source section:** 13. Evidence, effects, ledgers, and receipts terminology

**Source:** `records/term.receipt/receipt.md`

## Failure Record

A record of a failed validation, missing blob, denied capability, integrity mismatch, unsupported package operation, storage failure, compute failure, disclosure failure, or policy failure.

**Usage:** Failures are important evidence and should not be hidden.

**Source section:** 13. Evidence, effects, ledgers, and receipts terminology

**Source:** `records/term.failure-record/failure-record.md`

## Agent Action

An action taken by an Agent Principal or locally scoped agent session, such as authoring a package, importing a package bundle, validating a package, running fixtures, invoking a descriptor, requesting trust, requesting capabilities, requesting storage or compute leases, exporting or importing package bundles, or inspecting records.

**Usage:** Agent actions should be attributable and auditable.

**Source section:** 14. Agent terminology

**Source:** `records/term.agent-action/agent-action.md`

## Agent Authority

The scoped authority granted to an agent by Local Policy.

**Usage:** Agent identity and Agent Authority are separate. Agents cannot grant themselves trust or capabilities.

**Source section:** 14. Agent terminology

**Source:** `records/term.agent-authority/agent-authority.md`

## Package Draft

An agent-authored or human-authored package not yet trusted for normal execution.

**Usage:** Drafts may be validated, tested, inspected, and submitted for trust decisions.

**Source section:** 14. Agent terminology

**Source:** `records/term.package-draft/package-draft.md`

## Capability Request Document

A document asking for a capability grant under specified scope.

**Usage:** Agents may create such requests but cannot approve them for themselves.

**Source section:** 14. Agent terminology

**Source:** `records/term.capability-request-document/capability-request-document.md`

## Agent Workspace

A local or encrypted area, document set, package-authoring workspace, or client-managed context used for agent-authored drafts, notes, tests, requests, and intermediate artifacts.

**Usage:** Agent workspaces are not a required Benac Core object class. Where their contents enter Benac semantics, they do so as package drafts, documents, blobs, requests, reports, evidence, effects, or other typed Benac objects.

**Source section:** 14. Agent terminology

**Source:** `records/term.agent-workspace/agent-workspace.md`

## Review Agent

An agent authorized to inspect packages, tests, claims, storage lease requests, compute lease requests, leases, and supporting evidence and produce review claims.

**Usage:** A Review Agent’s claims are still evidence, not automatic authority.

**Usage:** This is an explanatory role, not a separate kernel authority class. Use ordinary Agent Principal, Local Policy, capability grants, claims, and attribution.

**Source section:** 14. Agent terminology

**Source:** `records/term.review-agent/review-agent.md`

## Builder Agent

An agent that authors or assembles packages, manifests, schemas, fixtures, or related authoring artifacts.

**Usage:** Builder Agents should not automatically gain execution authority over their own packages.

**Usage:** This is an explanatory role, not a separate kernel authority class. Use ordinary Agent Principal, Local Policy, capability grants, claims, and attribution.

**Source section:** 14. Agent terminology

**Source:** `records/term.builder-agent/builder-agent.md`

## Conformance Class

A named set of requirements an implementation may satisfy, such as Browser PWA Baseline, Desktop Host Baseline, Remote Storage Profile, Remote Compute Profile, WASM Execution Profile, or Encryption Profile.

**Usage:** Conformance classes help independent teams implement compatible subsets without ambiguity.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.conformance-class/conformance-class.md`

## Remote Storage Profile

A conformance class covering storage offers, storage descriptors, storage leases, remote blob get/put/pin behavior, storage receipts, and storage effects.

**Usage:** Implementations should claim this profile only if they support remote storage semantics.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.remote-storage-profile/remote-storage-profile.md`

## Remote Compute Profile

A conformance class covering compute offers, compute descriptors, compute leases, remote invocation, compute evidence, result binding, and compute effects.

**Usage:** Implementations should claim this profile only if they support remote compute semantics.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.remote-compute-profile/remote-compute-profile.md`

## Encryption Profile

A conformance class covering encrypted envelopes, private blob encryption, encrypted documents, key wrapping, recipient sharing, disclosure effects, and decryption verification.

**Usage:** The cryptographic profile supplies algorithms and test vectors.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.encryption-profile/encryption-profile.md`

## Interoperability

The ability of independent implementations to import, verify, trust, invoke, audit, replicate, store, retrieve, encrypt, decrypt, and export the same Benac objects under the same semantics.

**Usage:** Interoperability is the reason this terms document exists.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.interoperability/interoperability.md`

## Test Vector

A precise example input and expected output used to verify cross-implementation behavior.

**Usage:** Crypto, hashing, signing, encryption, DRISL encoding, package import, and hello-world invocation should all have test vectors.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.test-vector/test-vector.md`

## Conformance Trace

A recorded invocation/evidence/effect trace generated by a conformance test package.

**Usage:** Conformance traces help compare behavior across Host Platforms.

**Source section:** 15. Conformance and interoperability terminology

**Source:** `records/term.conformance-trace/conformance-trace.md`

## Node

Deprecated Benac term previously used for a local installation or participant.

**Usage:** Replace with Station, Host Station, Local Station, Peer Station, Storage Station, or Compute Station depending on context.

**Avoid:** Avoid in Benac-facing requirements.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.node/node.md`

## Adapter

An explanatory wrapper or translation layer used outside the Benac Core package model.

**Usage:** Use package interface, descriptor, storage bridge package, or compute bridge package when describing package-visible Benac objects. Do not make Adapter a core package category.

**Avoid:** Avoid as a core noun unless describing legacy systems.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.adapter/adapter.md`

## Provider

A broad external-service term that may obscure Benac roles.

**Usage:** Use Storage Station, Compute Station, Delivery Origin, API service, or external provider as appropriate.

**Avoid:** Avoid making “provider” an authority concept.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.provider/provider.md`

## Source

An application-level role for packages that produce information.

**Usage:** Use Source Package or package interface when needed. Do not make Source the core primitive.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.source/source.md`

## Tool

An application-level role for packages that can be invoked to perform a task.

**Usage:** Use Tool Package or package interface when needed. Do not make Tool the core primitive.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.tool/tool.md`

## Trustless Compute

A misleading phrase unless using specific cryptographic or hardware mechanisms with explicit threat models.

**Usage:** Use Remote Compute, Compute Station, Trusted Compute Station, or Untrusted Compute Station. Be honest about plaintext disclosure.

**Avoid:** Do not claim baseline Benac provides trustless private compute.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.trustless-compute/trustless-compute.md`

## Delete

A word that can overpromise in decentralized storage and remote compute.

**Usage:** Prefer local delete, unpin, request deletion, revoke access, rotate key, or destroy key depending on what is actually possible.

**Avoid:** Avoid implying guaranteed global deletion unless a specific protocol proves it.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.delete/delete.md`

## Canonical

A word to avoid as a Benac-specific noun or adjective. Benac records should describe the actual mechanism instead of using this word as a shortcut.

**Usage:** Use the specific mechanism instead, such as DRISL bytes produced by the required encoding rules, payload used to compute the CID, payload used to verify the signature, required CID string form, JSON projection, logical Benac object, Couch/Pouch operational document, normalized output, or validated output.

**Usage:** Use only when quoting an external specification, when an external standard name itself uses the word, or in this avoid-term record.

**Avoid:** Do not use canonical as a Benac-specific noun or adjective for package identity, structured payloads, package-visible input, output, claims, descriptors, invocations, or host metadata.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.canonical/canonical.md`

## Latest

A mutable version label that is not authoritative identity.

**Usage:** Use DASL CID for identity. “Latest” may be a local or signed name binding, not an execution identity.

**Avoid:** Do not execute by latest without resolving and recording an exact CID.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.latest/latest.md`

## Cloud

A vague infrastructure term.

**Usage:** Use Remote Station, Storage Station, Compute Station, Delivery Origin, or external service depending on role.

**Avoid:** Avoid treating cloud as a trust category.

**Source section:** 16. Terms to avoid, reserve, or use carefully

**Source:** `records/term.cloud/cloud.md`

## Station

A Benac-recognized participant, installation, or resource endpoint that can hold identity, policy, capabilities, documents, blobs, offers, invocations, evidence, or effects. Station is the preferred human-facing term for this concept.

**Source section:** 7. Definitions

**Source:** `records/term.station/station.md`

## Local Station

The Station from whose perspective a decision, policy evaluation, invocation, storage operation, compute operation, authentication event, or disclosure decision is made.

**Source section:** 7. Definitions

**Source:** `records/term.local-station/local-station.md`

## Host Station

The Station currently running Benac Core semantics for an operation and applying Local Policy.

**Source section:** 7. Definitions

**Source:** `records/term.host-station/host-station.md`

## Compute Station

A Station that offers compute capability. It may run package operations, transformations, model inference, WASM, native work, or other compute resources under policy.

**Source section:** 7. Definitions

**Source:** `records/term.compute-station/compute-station.md`

## Storage Station

A Station that offers storage capability for documents, blobs, chunks, package bundles, encrypted objects, package artifacts, evidence bodies, or compute-staging data.

**Source section:** 7. Definitions

**Source:** `records/term.storage-station/storage-station.md`

## Peer Station

Another Station with which the Local Station may exchange operational documents, blobs, claims, offers, receipts, package bundles, or authenticated messages.

**Source section:** 7. Definitions

**Source:** `records/term.peer-station/peer-station.md`

## Relay Station

A Station that helps move documents, blobs, claims, offers, receipts, or package bundles between other Stations without necessarily being trusted for execution, authority, or plaintext processing.

**Source section:** 7. Definitions

**Source:** `records/term.relay-station/relay-station.md`

## Station principal

The cryptographic principal associated with a Station, used to attribute claims, offers, receipts, invocations, exports, replication participation, remote-resource results, and Station-to-Station authentication.

**Source section:** 7. Definitions

**Source:** `records/term.station-principal/station-principal.md`

## Station profile

A machine-readable description of a Station’s Host Platform, Host Implementation, supported capabilities, storage features, execution features, authentication features, cryptographic profile support, DRISL encoding support, content-identity profile support, and relevant policy constraints.

**Source section:** 7. Definitions

**Source:** `records/term.station-profile/station-profile.md`

## Benac Core

The host-neutral semantic kernel governing packages, identity, authentication, trust, authorization, capabilities, invocations, evidence, effects, storage and compute leases, encryption and disclosure, content identity, DRISL structured encoding, and conformance.

**Source section:** 7. Definitions

**Source:** `records/term.benac-core/benac-core.md`

## Host Platform

The runtime platform on which a Benac implementation runs, such as iOS mobile browser, Android mobile browser, desktop browser, Ubuntu, macOS, or Windows.

**Source section:** 7. Definitions

**Source:** `records/term.host-platform/host-platform.md`

## Host Implementation

A platform-specific implementation that provides storage, execution, cryptography, authentication, networking, display, secret handling, replication, blob handling, CID handling, DRISL encoding, and optional capabilities.

**Source section:** 7. Definitions

**Source:** `records/term.host-implementation/host-implementation.md`

## Principal

A cryptographic identity representing a Station, user, agent, author, reviewer, Storage Station, Compute Station, Host Implementation, organization, or other actor.

**Source section:** 7. Definitions

**Source:** `records/term.principal/principal.md`

## Principal identifier

The profile-defined identifier for a cryptographic principal under the applicable identity or cryptographic profile. Principal identifiers are not DASL CIDs unless a specific profile explicitly defines them that way.

**Source section:** 7. Definitions

**Source:** `records/term.principal-identifier/principal-identifier.md`

## Authentication

A process or record by which an actor, Station, session, endpoint, or external service proves control of a relevant credential, key, channel, or account. Authentication is not authority.

**Source section:** 7. Definitions

**Source:** `records/term.authentication/authentication.md`

## Authorization

A scoped permission granted by Local Policy, explicit approval, trust decision, capability grant, storage lease, compute lease, or equivalent local authority.

**Source section:** 7. Definitions

**Source:** `records/term.authorization/authorization.md`

## Local Policy

The locally authoritative policy state used by a Local Station to decide whether claims, principals, packages, descriptors, capabilities, storage operations, compute operations, disclosures, or replicated records may be relied on or used.

**Source section:** 7. Definitions

**Source:** `records/term.local-policy/local-policy.md`

## Trust decision

A local decision, attributable to an issuer principal or local policy authority, that allows a package, package interface, invocation contract, descriptor, agent, Station, claim, Host Implementation, Storage Station, Compute Station, principal, or other target to be used under specific constraints.

**Source section:** 7. Definitions

**Source:** `records/term.trust-decision/trust-decision.md`

## Capability

A specific kind of power mediated by the Host Station, such as blob read, blob write, network fetch, storage use, compute use, decryption, secret use, data egress, display, file access, device access, or high-risk physical-world action.

**Source section:** 7. Definitions

**Source:** `records/term.capability/capability.md`

## Capability grant

A local authorization granting a specific capability scope to a package, package interface, descriptor scope, invocation contract snapshot, agent, storage lease, compute lease, authenticated session, or other locally accepted authority-bearing record.

**Source section:** 7. Definitions

**Source:** `records/term.capability-grant/capability-grant.md`

## Cryptographic profile

A versioned Benac profile defining cryptographic algorithms, content-identity profiles, DRISL structured-object encoding rules, signature algorithms, key identifier formats, signed claim envelopes, encryption envelopes, object-type/context binding rules, key wrapping, encrypted object metadata, and conformance vectors.

**Source section:** 7. Definitions

**Source:** `records/term.cryptographic-profile/cryptographic-profile.md`

## Content-identity profile

A profile defining how exact content identifiers are represented, parsed, generated, rejected, and verified. In baseline Benac, the content-identity profile uses DASL CID v1.

**Source section:** 7. Definitions

**Source:** `records/term.content-identity-profile/content-identity-profile.md`

## Authentication profile

A versioned profile defining local user authentication semantics, Station-to-Station authentication, agent authentication, external-service authentication mediation, authentication context records, session expiry, revocation, replay protection, and conformance vectors.

**Source section:** 7. Definitions

**Source:** `records/term.authentication-profile/authentication-profile.md`

## Content identity

Exact identity derived from content bytes under a defined content-identity profile. In baseline Benac, exact content identity is represented by DASL CIDs, not bare digest strings. Content identity is evidence of exact content, not authority.

**Source section:** 7. Definitions

**Source:** `records/term.content-identity/content-identity.md`

## Exact content identity

The identity of an exact raw byte sequence or exact structured byte sequence produced by the required encoding rules. Exact content identity does not mean trust, authorization, safety, provenance, authorship, or permission.

**Source section:** 7. Definitions

**Source:** `records/term.exact-content-identity/exact-content-identity.md`

## CID

In baseline Benac, “CID” means DASL CID v1 unless a future codec or hash extension explicitly permits otherwise. Portable Benac records use CIDs, not bare digest strings, for exact content identity.

**Source section:** 7. Definitions

**Source:** `records/term.cid/cid.md`

## DASL CID

The baseline Benac exact content identifier format. DASL CID v1 uses string prefix `b`, lowercase RFC 4648 base32 string encoding, CID byte version `0x01`, a content codec, SHA-256 hash type `0x12`, hash size `0x20`, and a 32-byte digest.

**Source section:** 7. Definitions

**Source:** `records/term.dasl-cid/dasl-cid.md`

## Raw blob CID

A DASL CID v1 identifying the exact raw byte sequence of a blob. Baseline raw blob CIDs use DASL raw codec `0x55` and SHA-256 over the exact bytes.

**Source section:** 7. Definitions

**Source:** `records/term.raw-blob-cid/raw-blob-cid.md`

## Structured document CID

A DASL CID v1 identifying the DRISL byte representation of a logical structured Benac object. Baseline structured document CIDs use DASL DRISL codec `0x71` and SHA-256 over the DRISL bytes produced by the required encoding rules.

**Source section:** 7. Definitions

**Source:** `records/term.structured-document-cid/structured-document-cid.md`

## CID codec

The content codec field inside a DASL CID. In baseline Benac, raw byte content uses codec `0x55`; structured DRISL content uses codec `0x71`.

**Source section:** 7. Definitions

**Source:** `records/term.cid-codec/cid-codec.md`

## CID string

The required string form of a DASL CID. In baseline Benac, CID strings use prefix `b` and lowercase RFC 4648 base32 encoding. Other forms are rejected unless a future codec or encoding addition explicitly permits them.

**Source section:** 7. Definitions

**Source:** `records/term.cid-string/cid-string.md`

## Binary DASL CID

The byte form of a DASL CID after decoding the string prefix and base32 payload. In baseline DASL CID v1, the binary CID contains version, codec, hash type, hash size, and digest.

**Source section:** 7. Definitions

**Source:** `records/term.binary-dasl-cid/binary-dasl-cid.md`

## Hash

The digest operation or digest component inside a content identifier. In portable Benac records, a bare hash or bare digest string is not the normal representation of exact content identity; a CID is used instead.

**Source section:** 7. Definitions

**Source:** `records/term.hash/hash.md`

## Digest

The byte output of a hash algorithm. In baseline DASL CIDs, the digest is a 32-byte SHA-256 digest.

**Source section:** 7. Definitions

**Source:** `records/term.digest/digest.md`

## SHA-256

The baseline digest algorithm used by DASL CID v1 in Benac for raw blob CIDs and structured DRISL document CIDs.

**Source section:** 7. Definitions

**Source:** `records/term.sha-256/sha-256.md`

## Bare digest string

A digest represented without the required content-identity profile, codec, algorithm, and length information. Bare digest strings are not used as portable exact content identifiers where Benac requires CIDs.

**Source section:** 7. Definitions

**Source:** `records/term.bare-digest-string/bare-digest-string.md`

## Content-addressed object

An object whose exact identity is determined by its CID. Mutating the object produces a different CID. Content-addressed identity is not the same as trust or authority.

**Source section:** 7. Definitions

**Source:** `records/term.content-addressed-object/content-addressed-object.md`

## Raw blob

An immutable byte artifact stored and verified by raw blob CID. Examples include WASM modules, package artifacts, media bytes, evidence bodies, encrypted payloads, chunks, fixtures, and staged compute inputs.

**Source section:** 7. Definitions

**Source:** `records/term.raw-blob/raw-blob.md`

## Structured object

A logical Benac object with schema-defined structured data, such as a package document, descriptor snapshot, signed claim payload, blob manifest, invocation record, evidence record, effect record, storage receipt, compute receipt, or Package Bundle Manifest.

**Source section:** 7. Definitions

**Source:** `records/term.structured-object/structured-object.md`

## Logical Benac object

The schema-defined semantic object that Benac validates, encodes as DRISL when required, hashes, signs, imports, exports, or verifies. A logical Benac object is distinct from the Couch/Pouch operational document that may store or replicate it.

**Source section:** 7. Definitions

**Source:** `records/term.logical-benac-object/logical-benac-object.md`

## DRISL

The baseline deterministic structured encoding profile used by Benac for structured objects that are content-addressed or signed. DRISL is a constrained CBOR profile that lets independent implementations produce the same bytes for the same logical Benac object.

**Source section:** 7. Definitions

**Source:** `records/term.drisl/drisl.md`

## CBOR

Concise Binary Object Representation, the binary data serialization format on which DRISL is based. Benac uses the DRISL profile rather than arbitrary CBOR for structured payloads used in CIDs or signatures.

**Source section:** 7. Definitions

**Source:** `records/term.cbor/cbor.md`

## CBOR Tag 42

The CBOR tag used by DRISL to encode CIDs compactly inside DRISL documents. In baseline Benac, CIDs inside DRISL are encoded as Tag 42 over a byte string containing `0x00` followed by the binary DASL CID bytes.

**Source section:** 7. Definitions

**Source:** `records/term.cbor-tag-42/cbor-tag-42.md`

## JSON projection

A JSON-shaped representation of a logical Benac object used for storage, APIs, inspection, import/export views, or Couch/Pouch-compatible documents. A JSON projection is not the byte representation used for CIDs or signatures unless a future schema or encoding addition explicitly says so.

**Source section:** 7. Definitions

**Source:** `records/term.json-projection/json-projection.md`

## CID link

A structured reference to a CID. In baseline JSON projections, CID links use the AT-style representation `{"$link": "b..."}`. In DRISL payloads, CIDs use CBOR Tag 42 according to the DRISL profile.

**Source section:** 7. Definitions

**Source:** `records/term.cid-link/cid-link.md`

## Couch/Pouch-compatible operational document

A JSON-shaped document suitable for CouchDB/PouchDB-compatible storage and replication. It may contain a JSON projection of a logical Benac object and operational metadata. It is not, by itself, the payload used to compute a structured document CID or verify a signature.

**Source section:** 7. Definitions

**Source:** `records/term.couch-pouch-compatible-operational-document/couch-pouch-compatible-operational-document.md`

## Couch/Pouch-managed metadata

Metadata controlled by the Couch/Pouch-compatible document system, including fields such as `_id`, `_rev`, revision history, conflict metadata, and replication state. Such metadata is excluded from the logical payload encoded as DRISL for CIDs or signatures.

**Source section:** 7. Definitions

**Source:** `records/term.couch-pouch-managed-metadata/couch-pouch-managed-metadata.md`

## Host-local operational metadata

Metadata maintained by a Host Implementation for local use, such as local availability, local verification status, UI state, cache state, local indexes, and sync status. Such metadata is excluded from the logical payload encoded as DRISL for CIDs or signatures and is not package-visible unless exposed through an explicit host-mediated API.

**Source section:** 7. Definitions

**Source:** `records/term.host-local-operational-metadata/host-local-operational-metadata.md`

## Document store

The Couch/Pouch-compatible operational document storage plane for structured metadata, package records, descriptor records, signed claim records, trust records, capability grants, storage offers, storage leases, compute offers, compute leases, invocations, evidence, effects, agent records, privacy records, and sync configuration.

**Source section:** 7. Definitions

**Source:** `records/term.document-store/document-store.md`

## Replication

The movement of eligible operational documents between Stations using Couch/Pouch-compatible replication or another compatible mechanism. Replication moves data but does not grant trust, authority, or content validity.

**Source section:** 7. Definitions

**Source:** `records/term.replication/replication.md`

## Couch/Pouch-compatible replication

Replication compatible with CouchDB/PouchDB-style document synchronization semantics. After replication, Benac still verifies CIDs, signatures, schemas, encryption metadata, conflict policy, and local authority before reliance.

**Source section:** 7. Definitions

**Source:** `records/term.couch-pouch-compatible-replication/couch-pouch-compatible-replication.md`

## Blob store

A content-addressed storage plane for immutable byte artifacts referenced by documents. Baseline blob identity uses DASL CID v1 raw CIDs.

**Source section:** 7. Definitions

**Source:** `records/term.blob-store/blob-store.md`

## Blob

An immutable byte artifact stored in the blob store and referenced by CID. A blob may be public or private, plaintext or ciphertext, complete or chunked.

**Source section:** 7. Definitions

**Source:** `records/term.blob/blob.md`

## Chunk

A byte range or piece of a larger blob that is independently referenced by CID in a blob manifest.

**Source section:** 7. Definitions

**Source:** `records/term.chunk/chunk.md`

## Blob manifest

A structured object describing a blob or chunked blob, including chunk CIDs, chunk sizes, total size, media type, compression metadata, encryption metadata where applicable, and top-level content identity.

**Source section:** 7. Definitions

**Source:** `records/term.blob-manifest/blob-manifest.md`

## Blob availability record

A record indicating whether a blob or chunk is present locally, missing locally, remotely available, pinned remotely, encrypted, staged for compute, partially available, or unavailable. Availability does not replace CID verification.

**Source section:** 7. Definitions

**Source:** `records/term.blob-availability-record/blob-availability-record.md`

## Blob location claim

A claim that a Storage Station or Peer Station may have a blob or chunk identified by CID. A blob location claim is a retrieval hint, not proof of content, trust, or availability.

**Source section:** 7. Definitions

**Source:** `records/term.blob-location-claim/blob-location-claim.md`

## Ciphertext CID

A CID identifying encrypted bytes exactly as stored or transferred. Ciphertext CIDs can be public without revealing plaintext identity, depending on the encryption profile and metadata.

**Source section:** 7. Definitions

**Source:** `records/term.ciphertext-cid/ciphertext-cid.md`

## Plaintext CID

A CID identifying plaintext bytes before encryption or after decryption. Plaintext CIDs can leak information about sensitive content and are not required to be publicly disclosed for private blobs.

**Source section:** 7. Definitions

**Source:** `records/term.plaintext-cid/plaintext-cid.md`

## Plaintext verification metadata

Local or policy-permitted metadata used to verify decrypted plaintext without necessarily disclosing a plaintext CID publicly.

**Source section:** 7. Definitions

**Source:** `records/term.plaintext-verification-metadata/plaintext-verification-metadata.md`

## Package

A content-addressed reusable behavior unit represented by a package document. A package document declares package metadata, schemas, schema ruleset identifiers, package interfaces, interface contract bindings, artifact references, declared capabilities, resource requirements, fixtures, documentation references, evidence behavior, and effect behavior. Claim references are external to the package document and do not change the package CID.

**Source section:** 7. Definitions

**Source:** `records/term.package/package.md`

## Package document

The structured package payload used to derive package content identity. A package document declares package metadata, schemas, schema ruleset identifiers, package interfaces, interface contract bindings, artifact references, declared capabilities, resource requirements, fixtures, documentation references, evidence behavior, and effect behavior. Claim references are external to the package document and do not change the package CID.

**Usage:** Use package document for the identity-bearing package object. Use Package Bundle Manifest only for the ZIP bundle distribution contract.

**Source section:** Final terminology sealing pass

**Source:** `records/term.package-document/package-document.md`

## Package CID

The DASL CID of the DRISL-encoded package document. The package CID is derived from the package document and is not a required field inside that document. Adding external claims or signatures does not change the package CID.

**Source section:** 7. Definitions

**Source:** `records/term.package-cid/package-cid.md`

## Artifact reference

A structured reference to a package, Host, or operation artifact blob, including DASL CID, size, media type, encryption metadata if applicable, and availability metadata.

**Source section:** 7. Definitions

**Source:** `records/term.artifact-reference/artifact-reference.md`

## Descriptor

A configured instance of a package, such as a particular endpoint, local model, device bridge, display surface, Storage Station, Compute Station, or other local configuration context.

**Source section:** 7. Definitions

**Source:** `records/term.descriptor/descriptor.md`

## Descriptor snapshot

An immutable structured snapshot of descriptor configuration used for invocation, audit, export, signing, or cross-implementation verification.

**Source section:** 7. Definitions

**Source:** `records/term.descriptor-snapshot/descriptor-snapshot.md`

## Descriptor snapshot CID

The DASL CID of the DRISL-encoded descriptor snapshot. Portable invocation records use descriptor snapshot CIDs.

**Source section:** 7. Definitions

**Source:** `records/term.descriptor-snapshot-cid/descriptor-snapshot-cid.md`

## Invocation

One package operation attempt under a particular request, trust decision, package interface, descriptor snapshot, invocation contract snapshot where relevant, Station Profile, actor principal, authentication context, and capability grant.

**Source section:** 7. Definitions

**Source:** `records/term.invocation/invocation.md`

## Invocation Record

The structured record of an invocation attempt, including invocation id, Station principal, initiating actor where applicable, package CID, package interface, descriptor snapshot CID, invocation contract snapshot CID where relevant, request reference, trust decision, capability grants, leases, status, output reference, evidence references, effect references, validation status, and failure details.

**Source section:** 7. Definitions

**Source:** `records/term.invocation-record/invocation-record.md`

## Request CID

The CID of a DRISL-encoded request snapshot where the request is content-addressed. A request snapshot binds request data to package CID, descriptor snapshot, interface identifier, and schema references.

**Usage:** Invocation records may carry request snapshot CIDs, inline request snapshots, or encrypted request references where permitted.

**Source section:** 7. Definitions

**Source:** `records/term.request-cid/request-cid.md`

## Output CID

The CID of a DRISL-encoded output snapshot or raw output blob where the output is content-addressed. An output snapshot binds output data to package CID, package interface, invocation contract snapshot where relevant, output schema reference, and validation status.

**Usage:** Invocation records may carry output snapshot CIDs, inline output snapshots, raw output blob references, or encrypted output references where permitted.

**Source section:** 7. Definitions

**Source:** `records/term.output-cid/output-cid.md`

## Evidence

Data observed or produced during an invocation or remote resource use, such as HTTP responses, token streams, logs, sensor readings, output JSON, raw bodies, signatures, attestations, authentication records, storage receipts, compute receipts, or validation results.

**Source section:** 7. Definitions

**Source:** `records/term.evidence/evidence.md`

## Invocation input envelope

A versioned logical object that supplies the package CID, descriptor snapshot CID or no-descriptor marker, interface identifier, schema references, request body, descriptor config body where applicable, data class, and initiating actor context for a package invocation.

**Usage:** The invocation input envelope is the source of package-visible request and descriptor config data after validation.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.invocation-input-envelope/invocation-input-envelope.md`

## Request snapshot

A content-addressed logical object that binds request data to package CID, descriptor snapshot CID or no-descriptor marker, interface identifier, request schema reference, descriptor config schema reference where applicable, request body, and descriptor config body where applicable.

**Usage:** Use request snapshots when invocation records need request CIDs that are not ambiguous across packages, interfaces, descriptors, or schemas.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.request-snapshot/request-snapshot.md`

## Output Snapshot

A content-addressed logical object that binds package output to package CID, package interface, invocation contract snapshot where relevant, output schema reference where applicable, output body, and validation status.

**Usage:** Use output snapshots when invocation records need output CIDs that are not ambiguous across packages, interfaces, invocation contracts, operations, or schemas.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.output-snapshot/output-snapshot.md`

## Package Validation Report

A machine-readable report describing the result of package validation, including package document schema status, schema reference resolution, package interface status, interface contract binding status, invocation contract snapshot status where derivable, artifact reference status, artifact availability by operation phase, declared capability status, fixture status, warnings, errors, diagnostic records, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.

**Usage:** Validation reports are evidence for authors, agents, reviewers, and Local Policy. Unsigned local reports are not authority outside Local Policy.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.package-validation-report/package-validation-report.md`

## Package Build Report

A machine-readable report describing the result of building a Package Bundle from an authoring workspace, including package CID, schema CIDs, artifact CIDs, invocation contract snapshot CIDs where derivable, included schemas, included fixtures, warnings, errors, diagnostic records, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.

**Usage:** Build reports help independent tools prove they produced the same package identity and schema-bound invocation contracts from the same logical package inputs.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.package-build-report/package-build-report.md`

## Fixture

A structured package test vector that defines package-under-test reference, package interface, descriptor config or descriptor snapshot where applicable, request data, expected validation result, expected output where deterministic, expected evidence behavior, expected effect behavior, expected denied effects where applicable, expected operation status, and expected diagnostic classification codes and diagnostic evidence behavior where failure is intended.

**Usage:** Fixtures test package behavior, schema validation, capability mediation, trace shape, evidence behavior, effect behavior, operation status, and expected failures.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.fixture/fixture.md`

## Fixture result

A structured record describing the result of fixture execution, including fixture identifier, package CID, package interface, descriptor snapshot CID where applicable, invocation contract snapshot CID where applicable, request snapshot CID, output snapshot CID where applicable, validation results, evidence/effect references, pass/fail status, diagnostic records, stable diagnostic classification codes, diagnostic evidence handling, Station Profile reference, operation status, and timestamps.

**Usage:** Fixture results are evidence for local approval, package review, agents, and conformance testing.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.fixture-result/fixture-result.md`

## Package Inspection Result

A machine-readable object describing an inspected package, including package CID, package document version, package metadata, package interfaces, request/config/output schema references, schema validation status, invocation contract snapshots where derivable, artifact references, artifact availability, declared capabilities, capability grant status where known, resource requirements, fixtures, claims, warnings, missing artifacts, operation status by phase, diagnostic records or diagnostic record references, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.

**Usage:** Inspection results support human review, agent review, package approval, and cross-implementation comparison. Inspection results distinguish package content validity from operation eligibility.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.package-inspection-result/package-inspection-result.md`

## Evidence record

A structured record describing evidence. Where evidence is content-addressed, it references evidence bodies or DRISL-encoded evidence records by CID.

**Source section:** 7. Definitions

**Source:** `records/term.evidence-record/evidence-record.md`

## Schema ruleset

A versioned set of schema validation rules defining the supported schema language, supported keywords, unsupported keywords, reference resolution behavior, validation result format, and diagnostic behavior.

**Usage:** Use schema ruleset instead of vague references to arbitrary schema behavior. Package documents, request schemas, descriptor config schemas, output schemas, and fixture schemas should declare or inherit a supported schema ruleset.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.schema-ruleset/schema-ruleset.md`

## WASM package-host calling convention

A versioned contract for how a Station mediates a package operation that uses a WASM artifact, including module format, allowed imports, forbidden imports, required exports, memory behavior, input encoding, output encoding, error behavior, resource behavior, evidence behavior, and effect behavior.

**Usage:** The WASM package-host calling convention is a mechanism contract. It does not grant authority, classify packages, or classify how package work is performed.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.wasm-package-host-calling-convention/wasm-package-host-calling-convention.md`

## Resource limit report

A structured record describing resource limits applied, exceeded, or relied upon during package validation, package build, fixture execution, or invocation.

**Usage:** Use resource limit reports to explain failures caused by package size, artifact size, request size, output size, WASM memory, execution time, fuel, logs, evidence records, or effect records.

**Usage:** A resource limit report should identify the limit kind, observed value, configured or granted limit, operation phase, relevant package/interface/invocation contract context where known, diagnostic references, and whether the breach denied the operation or denied/omitted only the offending record.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.resource-limit-report/resource-limit-report.md`

## Diagnostic record

A structured machine-readable record describing a validation, build, fixture, invocation, capability, resource, schema, artifact, package-host, storage, compute, encryption, execution, or policy problem. A diagnostic record contains a stable diagnostic classification code for the portable Benac failure class or contract boundary, required context bindings, origin information, optional origin-specific code/message/status/payload, normalized details where defined, and raw diagnostic evidence inline or by CID/encrypted reference where practical and safe.

**Usage:** Diagnostic records allow tools, agents, users, and conformance tests to understand failures without parsing prose, while preserving the raw or origin-specific evidence needed for debugging, audit, and future failure modes. A diagnostic classification code is not an exhaustive root-cause explanation and should not replace raw diagnostic evidence.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.diagnostic-record/diagnostic-record.md`

## Stable diagnostic classification code

A stable machine-readable identifier for a portable Benac failure class or contract boundary. A stable diagnostic classification code supports interoperability, routing, conformance, policy, recovery, and fixture expectations. It is not an exhaustive root-cause explanation and does not replace raw diagnostic evidence.

**Usage:** Use stable diagnostic classification codes for recognized supported failures. Use `diagnostic.unclassified` only when no more specific supported diagnostic classification code applies, and preserve origin-specific and raw evidence where practical and safe.

**Source section:** 16. Terms and definitions changes

**Source:** `records/term.stable-diagnostic-classification-code/stable-diagnostic-classification-code.md`

## Package validation context

The context supplied to package validation, such as package-document-only, package bundle, imported Station state, or another explicitly defined package distribution context.

**Usage:** Use this term when a validation result depends on whether schemas, artifacts, fixtures, blobs, claims, reports, or package bundle documents were available. Validation reports should identify the package validation context used.

**Source section:** Package authoring and validation terminology

**Source:** `records/term.package-validation-context/package-validation-context.md`

## Fixture discovery source

The source from which fixture records for a package were discovered, such as package document fixture references, package bundle manifest entries, package bundle documents, imported Station state, or another package distribution context.

**Usage:** Use this term to avoid implying that package_document.fixtures is the only way to discover package fixtures. Fixture discovery source is especially important for content-addressed packages whose fixtures bind to the final package CID.

**Source section:** Package authoring and validation terminology

**Source:** `records/term.fixture-discovery-source/fixture-discovery-source.md`

## Artifact availability

The machine-readable status of whether a package artifact referenced by CID is present, missing, included in a package bundle, available as a raw blob, available as a structured document, partially available, or available only through an approved retrieval path.

**Usage:** Artifact availability does not grant trust or authority. Availability resolution should consider artifact role and CID codec.

**Source section:** Package authoring and validation terminology

**Source:** `records/term.artifact-availability/artifact-availability.md`

## Evidence CID

The CID of the DRISL-encoded evidence record or raw evidence body where evidence is content-addressed.

**Source section:** 7. Definitions

**Source:** `records/term.evidence-cid/evidence-cid.md`

## Effect

An attempted or actual action caused by an invocation, such as sending a request, authenticating to a remote Station, injecting a secret, writing a blob, opening a display, disclosing a private blob, uploading to storage, invoking remote compute, decrypting content, or controlling a device.

**Source section:** 7. Definitions

**Source:** `records/term.effect/effect.md`

## Effect record

A structured record describing an attempted or actual effect. Where an effect record is content-addressed or included in a tamper-evident chain, it uses DRISL and CIDs according to the cryptographic profile.

**Source section:** 7. Definitions

**Source:** `records/term.effect-record/effect-record.md`

## Causal Reference

A structured reference from one Benac record to another record, object, actor, session, invocation, evidence item, effect, diagnostic, request, approval, package draft, package CID, invocation contract snapshot CID, descriptor snapshot CID, build report, validation report, fixture result, storage record, compute record, or disclosure record that helps reconstruct why an event occurred.

**Usage:** Causal references support audit, debugging, agent repair, and conformance reconstruction. They do not grant authority.

**Source section:** 7. Definitions

**Source:** `records/term.causal-reference/causal-reference.md`

## Effect CID

The CID of the DRISL-encoded effect record where the effect record is content-addressed.

**Source section:** 7. Definitions

**Source:** `records/term.effect-cid/effect-cid.md`

## Signed claim

A signed document in which a principal makes an attributable claim about a package, descriptor, principal, test result, authentication event, storage offer, storage receipt, compute offer, compute result, name binding, trust request, package bundle, disclosure record, or other target.

**Source section:** 7. Definitions

**Source:** `records/term.signed-claim/signed-claim.md`

## Signed claim envelope

The structured envelope around a signed claim, including signature metadata, issuer principal, cryptographic profile, signed-claim envelope profile, target reference, claim type, and the payload used for signature verification.

**Source section:** 7. Definitions

**Source:** `records/term.signed-claim-envelope/signed-claim-envelope.md`

## Claim payload

The structured content of a signed claim. Baseline claim payloads are signed over DRISL bytes or over another explicitly defined byte sequence derived from DRISL.

**Source section:** 7. Definitions

**Source:** `records/term.claim-payload/claim-payload.md`

## Typed target reference

The target reference inside a signed claim. For content-addressed targets, it includes target DASL CID, target CID codec, target object type or role, and schema/profile where applicable. For non-content-addressed targets, it includes target identifier class, profile-defined target identifier, target type or role, and applicable identifier/profile version.

**Source section:** 7. Definitions

**Source:** `records/term.typed-target-reference/typed-target-reference.md`

## Target CID

The CID of the content-addressed object targeted by a signed claim, trust decision, capability grant, lease, invocation, receipt, or other record where exact content identity is required.

**Source section:** 7. Definitions

**Source:** `records/term.target-cid/target-cid.md`

## Attestation

A signed or local claim about build provenance, review, test execution, Host state, compute execution, storage operation, authentication context, or other facts relevant to trust.

**Source section:** 7. Definitions

**Source:** `records/term.attestation/attestation.md`

## Name binding

A local or signed claim that associates a human-readable name with a CID or principal. Names are not authoritative by themselves and do not override content identity or principal identity.

**Source section:** 7. Definitions

**Source:** `records/term.name-binding/name-binding.md`

## Storage offer

A document or claim describing available storage, supported operations, endpoint descriptors, limits, retention claims, costs, evidence behavior, encryption requirements, required capabilities, and Storage Station principal.

**Source section:** 7. Definitions

**Source:** `records/term.storage-offer/storage-offer.md`

## Storage descriptor

A locally configured descriptor for interacting with a Storage Station or storage package.

**Source section:** 7. Definitions

**Source:** `records/term.storage-descriptor/storage-descriptor.md`

## Storage lease request

A structured request asking Local Policy or an authorized principal to create a Storage Lease under specified scope, including requested operations, target blobs or blob classes, data classes, encryption requirements, recipients, limits, retention expectations, evidence expectations, cost constraints where applicable, initiating actor, and supporting evidence where supplied.

**Usage:** A Storage Lease Request does not itself authorize storage effects.

**Source section:** 7. Definitions

**Source:** `records/term.storage-lease-request/storage-lease-request.md`

## Storage lease

A local authorization allowing use of a storage descriptor under specific operations, data classes, byte limits, allowed blob CIDs, recipients, encryption requirements, authentication requirements, remote Station principals, and expiry.

**Source section:** 7. Definitions

**Source:** `records/term.storage-lease/storage-lease.md`

## Storage receipt

Evidence or a signed claim that a storage operation occurred or was attempted, such as put, get, pin, unpin, retrieval failure, integrity failure, provider-side availability claim, retention claim, or authenticated storage acceptance. Storage receipts are bound to relevant operation, blob, chunk, request, or manifest CIDs where applicable.

**Source section:** 7. Definitions

**Source:** `records/term.storage-receipt/storage-receipt.md`

## CAS exchange profile

A provider-neutral content-addressed storage exchange profile for Benac-to-Benac or Benac-to-storage-peer blob/chunk presence, retrieval, upload, pin, unpin, and receipt operations.

**Source section:** 7. Definitions

**Source:** `records/term.cas-exchange-profile/cas-exchange-profile.md`

## Compute offer

A claim or document describing available compute that a Benac Station may evaluate, trust, authenticate, and invoke through a package or descriptor.

**Source section:** 7. Definitions

**Source:** `records/term.compute-offer/compute-offer.md`

## Compute lease request

A structured request asking Local Policy or an authorized principal to create a Compute Lease under specified scope, including target package/interface/descriptor where known, input references, data classes, resource limits, storage staging, data egress, disclosure implications, output encryption requirements, evidence expectations, cost constraints where applicable, initiating actor, and supporting evidence where supplied.

**Usage:** A Compute Lease Request does not itself authorize compute, data egress, storage staging, decryption, or plaintext disclosure.

**Source section:** 7. Definitions

**Source:** `records/term.compute-lease-request/compute-lease-request.md`

## Compute lease

A local authorization allowing use of a compute descriptor under specific limits, authentication requirements, package CIDs, invocation contract snapshot CIDs, descriptor snapshot CIDs, input blob CIDs, data classes, byte limits, cost limits, invocation counts, accepted Compute Station principals, output encryption requirements, and expiry.

**Source section:** 7. Definitions

**Source:** `records/term.compute-lease/compute-lease.md`

## Remote compute result

A compute result returned by a Compute Station.

**Usage:** Remote compute results should be bound where feasible to authenticated Compute Station principal, request CID, nonce or challenge, compute lease, package CID, invocation contract snapshot CID, output CID, evidence CID, and timing or sequence information.

**Source section:** 7. Definitions

**Source:** `records/term.remote-compute-result/remote-compute-result.md`

## Encrypted envelope

A document or blob wrapper that protects private content while preserving explicit metadata needed for storage, replication, sharing, authentication-bound use, or local policy. Encryption metadata is authenticated as associated data where required.

**Source section:** 7. Definitions

**Source:** `records/term.encrypted-envelope/encrypted-envelope.md`

## Associated data

Metadata authenticated by an encryption envelope but not necessarily encrypted. In Benac, associated data may include object type, cryptographic profile, content-identity profile, structured-object encoding profile, expected plaintext or ciphertext CID, data class, intended use, lease identifiers, creator principal, and recipient information.

**Source section:** 7. Definitions

**Source:** `records/term.associated-data/associated-data.md`

## Plaintext disclosure

An event in which private data, decrypted content, or a key capable of decrypting private data becomes available to a principal, host, package, authenticated session, Storage Station acting as processor, or Compute Station.

**Source section:** 7. Definitions

**Source:** `records/term.plaintext-disclosure/plaintext-disclosure.md`

## Disclosure record

A record that private data, plaintext, or decryption capability became available to a principal, authenticated session, package, Host Implementation, Storage Station acting as processor, or Compute Station.

**Source section:** 7. Definitions

**Source:** `records/term.disclosure-record/disclosure-record.md`

## Data class

A local or package-declared sensitivity class such as public, private, private media, private child data, private health, credential, biometric, secret material, or implementation-defined high-sensitivity class.

**Source section:** 7. Definitions

**Source:** `records/term.data-class/data-class.md`

## Secret metadata

Local secret and credential reference metadata that does not include raw secret material.

**Source section:** 7. Definitions

**Source:** `records/term.secret-metadata/secret-metadata.md`

## Credential binding

A local mapping from a descriptor or authentication reference to protected credential material or a host-mediated external authentication method.

**Source section:** 7. Definitions

**Source:** `records/term.credential-binding/credential-binding.md`

## Protected storage

Host-mediated storage for private keys, wrapped content keys, local vault metadata, and secret material. The mechanism may differ by Host Platform.

**Source section:** 7. Definitions

**Source:** `records/term.protected-storage/protected-storage.md`

## Agent

A human-operated or AI-operated client that can inspect Benac, author or import packages, validate and test packages, request trust, request capabilities, request storage or compute leases, discover storage, discover compute, invoke packages within granted authority, and inspect resulting records.

**Usage:** Agent behavior is outside Benac Core. Benac provides machine-readable APIs, attribution, authority boundaries, evidence, effects, diagnostics, and audit records that agents may use.

**Source section:** 7. Definitions

**Source:** `records/term.agent/agent.md`

## Agent authentication

Authentication of an agent principal or locally scoped agent session so Benac can attribute agent actions and enforce agent authority. Agent authentication does not allow an agent to self-authorize trust, capabilities, secrets, decryption, storage, compute, data egress, or policy mutation.

**Source section:** 7. Definitions

**Source:** `records/term.agent-authentication/agent-authentication.md`

## Trust request

A structured request, often authored by an agent or user, asking for scoped trust or authority with supporting justification, tests, fixture results, risk descriptions, data egress disclosures, storage implications, compute implications, encryption implications, and signed claim references.

**Source section:** 7. Definitions

**Source:** `records/term.trust-request/trust-request.md`

## Capability request

A structured request asking Local Policy or an authorized principal to grant a specific capability scope.

**Source section:** 7. Definitions

**Source:** `records/term.capability-request/capability-request.md`

## Tamper-evident record

A record whose integrity can be checked through CIDs, signatures, CID links, Merkle manifests, or equivalent mechanisms defined by the cryptographic profile and data model.

**Source section:** 7. Definitions

**Source:** `records/term.tamper-evident-record/tamper-evident-record.md`

## Merkle manifest

A structured manifest that links content-addressed children, chunks, or records into a verifiable tree or graph.

**Source section:** 7. Definitions

**Source:** `records/term.merkle-manifest/merkle-manifest.md`

## Conflict

A replication or local-state condition where multiple versions or records cannot be safely reconciled automatically. Conflicts affecting authority-bearing state fail closed until resolved locally.

**Source section:** 7. Definitions

**Source:** `records/term.conflict/conflict.md`

## Authority-bearing record

A record that can affect trust, authorization, capabilities, decryption, disclosure, storage, compute, execution, policy, or other power. Replicating such a record does not make it active authority unless Local Policy accepts it.

**Source section:** 7. Definitions

**Source:** `records/term.authority-bearing-record/authority-bearing-record.md`

## Host API

The stable semantic API exposed by a Host Implementation to Benac Core and packages, including storage, CID creation/parsing/verification, DRISL encoding and decoding, authentication, signing, encryption, schema validation, trust query, capability request, invocation lifecycle, evidence emission, effect emission, disclosure recording, blob access, remote storage, remote compute, clock, random bytes, Station Profile inspection, and mediated operation status.

**Source section:** 7. Definitions

**Source:** `records/term.host-api/host-api.md`

## Package host interface

The mediated interface through which WASM and other executable packages interact with host resources. Packages do not receive ambient access to the document store, blob store, secrets, keys, signing authority, decryption authority, network, storage, compute, device capabilities, host-local metadata, UI state, debug fields, or unvalidated local defaults.

**Source section:** 7. Definitions

**Source:** `records/term.package-host-interface/package-host-interface.md`

## Agent API

The machine-readable API through which authenticated or locally scoped agents and other clients inspect allowed state, author draft packages, validate manifests, run fixtures, create trust and capability requests, request storage and compute leases, invoke authorized descriptors, inspect traces, inspect claims, inspect principals, inspect blob availability, and export or import package bundles.

**Source section:** 7. Definitions

**Source:** `records/term.agent-api/agent-api.md`

## Storage interface

The semantic interface for Storage Station offer import and inspection, Storage Station authentication, storage descriptor creation, storage lease creation, blob/chunk presence checking, retrieval, upload, pin, unpin, encrypted backup, location claim handling, storage receipt handling, authentication-context handling, and integrity failure reporting.

**Source section:** 7. Definitions

**Source:** `records/term.storage-interface/storage-interface.md`

## Compute interface

The semantic interface for Compute Station offer import and inspection, Compute Station authentication, compute descriptor creation, compute lease request review, compute lease creation, data-staging coordination, remote invocation, remote evidence handling, replay protection, remote output validation, and plaintext disclosure recording.

**Source section:** 7. Definitions

**Source:** `records/term.compute-interface/compute-interface.md`

## Authentication interface

The semantic interface for local user authentication, re-authentication for sensitive actions, Station-to-Station authentication, signed challenge handling, agent session authentication, authentication expiry and revocation, authenticated approval records, host-mediated external service authentication, credential-use effect recording, and authentication-context inspection.

**Source section:** 7. Definitions

**Source:** `records/term.authentication-interface/authentication-interface.md`

## Conformance vector

A test input and expected output used to verify that independent implementations produce identical results for CID parsing, CID generation, DRISL encoding, JSON projection, signature verification, encryption envelope handling, replication verification, blob verification, or other standard behavior.

**Source section:** 7. Definitions

**Source:** `records/term.conformance-vector/conformance-vector.md`

## Conformance Suite

The collection of tests used to verify Benac interoperability across Host Platforms and independent implementations. The suite covers DASL CID parsing/generation/rejection/verification, DRISL encoding and JSON projection, content identity, principal identity, signed claims, encrypted envelopes, Couch/Pouch document replication, blob storage, storage discovery, compute discovery, package validation, package inspection, fixture execution, schema-defined package behavior, WASM package-host calling convention behavior, capability denial, trust grants, package approval, invocation ledgers, evidence/effects, resource limits, no silent fallback, and package execution behavior.

**Source section:** 7. Definitions

**Source:** `records/term.conformance-suite/conformance-suite.md`

## Public blob

A blob that local policy treats as suitable for public storage, retrieval, replication, or deduplication by CID.

**Source section:** 7. Definitions

**Source:** `records/term.public-blob/public-blob.md`

## Private blob

A blob that local policy treats as sensitive and normally requires encryption, disclosure control, and explicit policy before remote storage, replication, export, sharing, or compute staging.

**Source section:** 7. Definitions

**Source:** `records/term.private-blob/private-blob.md`

## Private document

A structured document whose contents are sensitive and should be encrypted before replication, export, remote storage, or sharing unless local policy explicitly permits plaintext disclosure.

**Source section:** 7. Definitions

**Source:** `records/term.private-document/private-document.md`

## Redaction

The process of removing, hashing, encrypting, or omitting sensitive fields from evidence, effects, logs, traces, documents, or exported records according to local policy.

**Source section:** 7. Definitions

**Source:** `records/term.redaction/redaction.md`

## Data egress

The movement of data from the Local Station to a network endpoint, remote Storage Station, remote Compute Station, replication peer, external device, package, host, or other recipient outside the current authorized local boundary. Data egress is recorded as an effect and requires applicable capability permission.

**Source section:** 7. Definitions

**Source:** `records/term.data-egress/data-egress.md`

## User override

A locally permitted explicit user decision to proceed despite a warning or risk. User overrides are attributable, scoped, revocable where possible, and recorded.

**Source section:** 7. Definitions

**Source:** `records/term.user-override/user-override.md`
