Terms and Definitions

The following terms are defined for use throughout ARCS. Defined terms appear in ordinary text; no special formatting is required once defined here.

3.1 Core Record Concepts

Term	Definition
Interaction Record	Any artifact created, retained, transmitted, or derived by an automated system during or as a result of human-directed use, including artifacts held by the operator or by any vendor within the custody surface.
Record Surface	The complete set of locations where interaction records may exist. Includes provider systems, tenant systems, local storage, integrations, backups, archives, review datasets, and derived records.
Derived Record	Any artifact created outside the original system as a result of an interaction. Includes copied text, downloaded files, generated documents, stored notes, tickets, filings, emails, and database entries.
Intermediate Record	An artifact created during system processing that is not directly visible to the user. Includes agent traces, tool call logs, retrieval queries, system prompts, and runtime state.
Material Record	Any interaction record reasonably likely to be relevant in discovery, audit, or governance review.
Deliberative Content	Content that consists of, reflects, or is derived from an operator's, user's, or agent's reasoning process. Includes questions asked, options considered, arguments explored, conclusions reached or abandoned, and provisional assessments subsequently revised. Deliberative content is the governance-sensitive axis distinguishing records that require heightened lifecycle controls from operational telemetry.
Deliberative Record	An interaction record whose content is predominantly deliberative as defined in this section. Deliberative records include records where the operator's, user's, or agent's reasoning process constitutes the substantive content, as distinguished from operational telemetry, transactional metadata, or exported outputs. Deliberative records carry the highest governance sensitivity under ARCS-TAX and are the primary subject of content-telemetry separation.
Record Class	A category of interaction record distinguished by its creation trigger, content type, retention behavior, or governance treatment. Record classes include, without limitation: prompt/input text, model output, system prompt, feedback submission, review copy, training derivative, safety flag, telemetry event, agent trace, tool call artifact, and operational log. Record classes are the unit of analysis for retention configuration, non-creation claims, and taxonomy controls under ARCS-TAX. A non-creation claim under ARCS-NCR is made per record class, not per system.
Residual Artifact	Any record created by a system notwithstanding a non-creation claim for a different record class. Residual artifacts for a non-creation deployment may include session identifiers, timestamps, connection metadata, operational logs, receipt hashes, billing records, network routing metadata, and any other records generated by the interaction that are not within the non-created class. Each residual artifact class is documented and governed per its applicable retention and deletion controls.

3.2 Surface Concepts

Term	Definition
Custody Surface	The complete set of systems, vendors, and storage locations where copies of interaction records may exist, including primary stores, backups, logs, caches, safety pipelines, analytics systems, training pipelines, and vendor-held copies.
Discovery Surface	The subset of the record surface reasonably susceptible to legal production. Includes records reachable through user possession, provider logs, vendor storage, backups, review datasets, or derived documents.
Review Surface	The set of systems in which interaction records may be accessed by humans other than the user. Includes safety review, support, evaluation, moderation, and feedback review.
Unknown Surface	Any portion of the record or custody surface that cannot be conclusively documented due to architectural uncertainty, third-party opacity, or system complexity.
Record Acquisition Modality	A pathway through which interaction records may become reachable by a party other than the originating user, including civil subpoena, regulatory examination, internal review, provider safety or moderation review, government purchase through commercial intermediaries, or national security process.
Automated Record Custody Gap	The condition arising when automated processing creates interaction records that travel farther, persist longer, or become more reachable than the responsible actor understands at the time of record creation.
Surface Map	A versioned document identifying every known location where interaction records may exist (record surface map) or every entity that possesses, controls, or can access interaction records (custody surface map). Surface maps are the primary governance deliverable for ARCS-CUS and ARCS-LIF and SHALL conform to the minimum schemas defined in Standard Annexes C and D.
Backup	A copy of interaction records created for disaster recovery, business continuity, or operational resilience purposes. Backups extend the custody surface and may persist beyond the retention period applied to primary copies. Backup exposure is a governance-relevant condition because records deleted from primary storage may remain accessible in backup media.
Cache	A temporary copy of interaction records or record components maintained for performance, availability, or operational efficiency. Caches extend the custody surface and may retain record content beyond the intended retention window. Cache behavior is governance-relevant where cached copies are not subject to the same deletion controls as primary copies.
Archive	A copy of interaction records placed in long-term storage for compliance, business continuity, or institutional retention purposes. Archives extend the custody surface and may persist indefinitely beyond the retention period applied to operational copies. Archive governance is distinct from backup governance in that archives are typically affirmative retention decisions rather than byproducts of operational resilience.
Custody Chain	The sequence of entities through which an interaction record passes or in which copies exist, from creation through final deletion or archival. In multi-vendor and delegation contexts, the custody chain may fragment across multiple independent systems. The custody chain is distinct from the custody surface: the surface identifies who currently holds records; the chain identifies how records moved between holders over time. Documentation of custody chain fragmentation is required under ARCS-CUS and ARCS-DEL.

3.3 Lifecycle Concepts

Term	Definition
Interaction Lifecycle	The complete sequence of record creation, transmission, storage, review, routing, export, backup, deletion, preservation, and downstream propagation.
Default Retention Posture	The record categories, retention durations, and deletion behaviors that apply in ordinary system operation, in the absence of any legal hold, preservation demand, or regulatory inquiry.
Preservation Posture	The operational state that applies when litigation is pending or anticipated, a preservation demand has been received, a regulatory inquiry has been initiated, or an internal investigation has been opened. Routine deletion may be suspended.
Feedback Routing	Any event that moves an interaction record into a different system, lifecycle, or retention regime. Includes thumbs-up/down, flagging, sampling for review, export, or forwarding to abuse monitoring.
Retention	The period during which an interaction record is preserved in accessible form, whether by default configuration, user control, or system policy.
Deletion	The removal of an interaction record from accessible storage. Does not guarantee physical erasure from all backup, cache, or archive media.
Preservation Override	A condition in which deletion or retention settings are suspended due to legal or regulatory requirements. Includes legal hold, litigation hold, and regulatory preservation notice.
Lifecycle Boundary	The point at which a runtime artifact transitions from an ephemeral operational state to a governed record subject to retention, preservation, and disposition controls. Lifecycle boundary events include: persistence to durable storage, transmission to another system or vendor, survival beyond session termination, capture by a monitoring, telemetry, or audit system, and incorporation into secondary datasets including training data, retrieval indices, vector databases, or derived analytics.
Session	A bounded period of interaction between a user or agent and an automated system. A session begins when the system is engaged and ends when the interaction terminates, times out, or is explicitly closed. Session scope determines which artifacts are grouped for governance purposes, including retention classification, receipt generation, and lifecycle boundary assessment. For multi-step agentic workflows, the session scope encompasses the entire workflow, not individual API calls within it.
Session Boundary	The defined point at which an interaction session terminates and session-scoped state is released. In non-creation configurations, the session boundary defines when in-memory processing state ceases to exist. The session boundary is a governance-relevant event because it determines the point after which records of the non-created class should not persist. Session boundary behavior is documented under ARCS-NCR and verified under ARCS-VER.
Ephemeral	A retention classification applied to records that SHALL not persist beyond the session in which they are created. Ephemeral records are deleted or discarded at session termination. Planning traces, intermediate results, and session state artifacts are classified as ephemeral by default under ARCS-AGT. Ephemeral classification does not override preservation obligations: if a preservation override is in effect, ephemeral records SHALL be preserved for the duration of the obligation.
Governed Persistence	A retention class applicable to agent memory stores that must survive across sessions to serve their operational purpose. A memory store classified as governed persistence is retained on operator-controlled infrastructure, subject to a defined maximum retention period with automatic purge, excluded from uncontrolled backup or synchronization, and subject to preservation override.
Legal Hold	A specific form of preservation override triggered by pending or reasonably anticipated litigation, regulatory inquiry, or internal investigation. A legal hold suspends routine deletion for records within scope. Legal hold procedures are governed by ARCS-PV and illustrated in Standard Annex AH.
Differential Retention	The application of different retention classes to different artifact types within a single interaction session. Differential retention recognizes that a single session may produce deliberative content, operational telemetry, and transactional metadata with different governance requirements.
Retention Class	A category of retention treatment applied to a record class or artifact class. The retention classes defined in this standard are: ephemeral (not persisted beyond session termination), session-bounded (retained for the duration of the session only), governed persistence (retained across sessions under defined controls), and durable (retained indefinitely or until explicit deletion). Each record class is assigned a retention class as part of taxonomy classification under ARCS-TAX.

3.4 Configuration and Deployment Concepts

Term	Definition
Deployment Mode	A distinct configuration of the system that affects record behavior. Includes consumer interface, enterprise deployment, API deployment, reduced-retention mode, non-creation configuration, agent runtime, multi-vendor workflow, and plugin or toolchain integration.
Reduced-Retention Configuration	A deployment mode intended to limit retention, logging, or review. Includes temporary mode, history-off, zero-data-retention (ZDR), or enterprise-controlled retention. Reduced-retention configuration and non-creation configuration are architecturally distinct. A reduced-retention configuration creates records and then limits their persistence through policy, time-based deletion, or user control. A non-creation configuration prevents specified record classes from being created. The two approaches have different legal, evidentiary, and governance characteristics. An operator SHALL not describe a non-creation deployment as reduced-retention, or a reduced-retention deployment as non-creation, in any conformance statement, audit evidence, or legal submission.
Non-Creation Configuration	A deployment mode in which one or more material record classes are prevented from existing by architectural design rather than by retention policy or deletion procedure. The defining characteristic is that records of that class are not created during normal operation of the system. A non-creation configuration does not imply that no records of any kind exist. Residual artifacts, operational metadata, and records of other classes may still be created, retained, and governed. Non-creation is a per-class architectural claim, not a system-wide absence claim.
Publish Boundary	The point at which an interaction record leaves the governed environment and is transmitted to an external recipient or system. In a non-creation configuration, the publish boundary defines the scope of the non-creation claim: records below the boundary are the non-created class, while records that cross the boundary are subject to standard retention and governance controls.
Multi-Vendor Workflow	An interaction that creates records in more than one system operated by different entities. Includes API chaining, tool integration, plugin execution, and federated agent systems.
Governance Declaration	A document provided by a vendor describing its retention behavior, preservation capability, discovery exposure, deletion verifiability, and custody surface for interaction records processed on its infrastructure. Governance declarations are required by CUS-12 and SHALL meet the specificity thresholds defined in the standard. A governance declaration is distinct from a conformance statement: the vendor describes its behavior; the operator assesses conformance.
Configuration Exposure	The set of record-behavior differences that result from changes in deployment mode, user settings, or system configuration. A configuration change may create, suppress, extend, or shorten record retention without the operator's awareness. Configuration exposure is documented through the configuration exposure matrix required under ARCS-VER.

3.5 Agent and Runtime Concepts

Term	Definition
Agent Runtime	The execution environment in which autonomous or semi-autonomous AI agents operate. Includes multi-turn planning, tool execution, persistent memory, and delegation across models or systems.
Runtime Component	A distinct module within an agent runtime that generates, processes, or stores interaction records as part of its operation.
Autonomous Execution	AI system operation that proceeds without direct human initiation for each action. Includes scheduled tasks, continuous monitoring, multi-step workflows, and background processing.
Delegation Chain	A sequence of interactions where one AI system invokes another, either within the same provider or across vendors. Includes tool calls, API chaining, and agent-to-agent handoff.
Tool Call	An invocation by an AI system of an external function, API, database query, file operation, or integrated service during interaction processing.
Persistent Memory	Information retained by an AI system across interaction sessions and accessible in subsequent interactions. Subject to record surface mapping and discovery surface assessment. Persistent memory constitutes an interaction record regardless of whether the user can view or delete it. Governance requirements for persistent memory are specified under ARCS-DEL.
Conference Runtime	An execution environment in which multiple agents participate in a shared session, coordinated runtime, or joint processing context. Records created in conference runtime may have fragmented custody across participating agents and their respective providers.
Trace	A record of the sequential steps, decisions, state transitions, or reasoning paths taken by an automated system during processing. Traces are the primary artifact class through which agent runtime behavior becomes documentable. Trace records may be deliberative, operational, or mixed depending on their content. Specific trace types defined in this standard include planning traces and execution traces. The term "trace" without qualifier refers to any record in this category.
Planning Trace	An agent's representation of its intended execution path, including task decomposition, step ordering, alternative approaches considered, and reasoning about which path to pursue. Planning traces are deliberative records and are classified as ephemeral by default under AGT-04. Planning traces encode abandoned approaches, which are deliberatively sensitive independent of the final output.
Execution Trace	The sequence of steps, decisions, tool invocations, and state transitions executed by an agent during a session. Execution traces are mixed records: structural metadata (step sequence, timing, decision branch taken) is operational telemetry; the reasoning or content that drove each decision is deliberative. These components are governed separately under AGT-02.
Artifact Class	A category of agent runtime artifact defined by its function and governance characteristics. The artifact classes defined in this standard are: planning trace, tool call artifact, intermediate result, execution trace, error recovery artifact, session state artifact, and security-sensitive tool output. Operators classify all agent runtime artifacts into one or more of these classes and apply the governance requirements specified for each.
System Prompt	An instruction set provided to an automated system that configures its behavior for a given deployment, session, or interaction. System prompts may encode operator intent, task constraints, behavioral boundaries, and delegation scope. System prompts are identified as a record class subject to assessment and may constitute delegation artifacts.
Retained Deliverable	An output of an agentic workflow expressly designated by the operator for persistent retention. A retained deliverable is distinguished from ephemeral intermediate results by explicit designation. The designation is documented and the retained deliverable is identified in the session-level receipt or attestation record.
Delegation Artifact	Any record encoding the scope, duration, or conditions of authority delegated to an agent. Delegation artifacts include system prompts encoding authorized scope, configuration parameters defining tool access, credential grants, and instruction sets defining the agent's authority at the time of execution. Delegation artifacts are deliberative records.
Content-Telemetry Separation	The classification principle requiring that deliberative content (what the user asked, what the system reasoned, what alternatives were considered) and operational telemetry (timestamps, token counts, latency measurements, error rates, resource identifiers) be stored, transmitted, and governed through separate infrastructure paths. Content-telemetry separation prevents operational logging from inadvertently capturing deliberative content and enables distinct lifecycle treatment for each category. Telemetry that does not reveal deliberative content and is not classified as an interaction record under ARCS-TAX is outside the scope of interaction record governance.

3.6 Evidentiary Instruments

The following terms describe governance artifacts and assessment instruments that depend on the foundational concepts defined in subsections 3.1 through 3.5 and 3.7. These terms are downstream of the primitives; they identify artifacts produced by the governance process, not the governance primitives themselves.

Term	Definition
Conformance Level	The declared level of an implementation's governance posture under ARCS. ARCS defines three conformance profiles (Foundation, Minimum, Enterprise) that are operative, and six maturity levels (Level 0 through Level 5) that describe the completeness of an implementation's governance posture. Conformance profiles determine which control families must be satisfied. Maturity levels describe where an implementation falls on the governance completeness spectrum. An operator claiming a maturity level should also declare the corresponding conformance profile.
Assessor	An individual or entity responsible for evaluating conformance with this standard. May be internal (organization staff) or independent (external auditor).
Audit Evidence	Documentation, system outputs, logs, configurations, and other materials sufficient to verify conformance claims.
Conformance Statement	A written document produced by a conforming implementation containing the system name, operator, deployment mode, configuration identifier, assessment date, declared conformance level, exclusions, known non-conforming components, assessor identity, and all record-bearing components included in the assessment. Conformance statements SHALL conform to the template defined in Standard Annex H.
Attestation	A structured record confirming that a specific governance condition has been assessed and the result documented. Attestation records include session-level receipts, vendor compliance confirmations, and lifecycle audit attestations. An attestation documents what was assessed, when, by whom, and with what result. Attestation is the verification mechanism; the conformance statement is the governance deliverable. Attestation does not replace documentation.
Telemetry	Operational metadata generated by an automated system during processing, including timestamps, latency measurements, error codes, resource utilization, completion status, and system health indicators. Telemetry is distinguished from deliberative content for governance purposes: telemetry reflects system behavior; deliberative content reflects operator, user, or agent reasoning. The content-telemetry separation discipline requires that these categories be governed under their respective classifications even when generated as part of the same artifact.
Sovereignty Receipt	A governance artifact that records or attests to declared sovereignty-relevant conditions associated with the handling, processing, storage, or deployment context of governed records, including conditions related to operator boundary, custody surface, locality, or control over execution environment. Sovereignty receipts are interaction records subject to governance under this standard. Receipt schema and generation requirements are defined in companion instruments to this standard.

3.7 Entity Concepts

Term	Definition
Automated System	Any software, model, pipeline, agent, or service that processes human-directed input and generates outputs, logs, records, or derived artifacts as a condition of its operation.
Operator	The person, organization, or system that directs the use of an automated system. Distinct from the vendor that operates the underlying infrastructure.
Operator Boundary	The set of systems within the operator's control or governance responsibility for ARCS compliance.
Provider	The entity operating the AI system infrastructure. May be the same as or different from the deploying organization.
Tenant	An organization deploying an AI system for its own use or for its customers. In enterprise deployments, the tenant is typically the customer organization.
Vendor	A legal entity that operates infrastructure on which an automated system runs, stores data, or processes interaction records.
End User	The individual or automated system initiating interactions with the AI system.
Custodian	An entity that possesses, controls, or has the authority to access or delete interaction records.

3.8 Surface Class Taxonomy

The surface taxonomy in ARCS identifies six classes of automated-processing surface whose records present the custody gap condition described in this standard. The AI interaction surface is the primary domain addressed by ARCS controls. The remaining surface classes (transactional, identity, sensor, operational, and control-plane) are documented to establish that the governance gap condition is not unique to AI systems and to support future extension of the standard.

3.9 Conformance Keywords

The following conformance keywords are used throughout this standard:

shall indicates a mandatory requirement.

should indicates a recommendation.

may indicates a permitted option.

No alternative terminology SHALL be used in conformance documentation unless cross-mapped to the canonical term defined in this section.