Network Working Group T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 7 September 2026 Expires: 7 March 2027 The Data Artifact Management (DAM) Protocol for Agentic AI Systems draft-sato-soos-dam-01 Abstract This document specifies the Data Artifact Management (DAM) protocol for agentic AI systems governed by the Sovereign Object OS (SOOS) framework. DAM defines a typed taxonomy of data artifacts produced and consumed by AI agents, a governance envelope for each artifact type specifying provenance, access policy, temporal validity, and retention requirements, and the normative interface between agent- generated artifacts and the Governance Audit Record (GAR). DAM addresses three classes of data in agentic systems: kernel- generated artifacts (IDP event logs, GAR records, AEP session state), agent-generated artifacts (outputs of agent actions), and externally ingested artifacts (data made available by resources). DAM specifies the Data Artifact type (DA-Type) taxonomy referenced in the Resource Governance Protocol (RGP) and the Agent Execution Protocol (AEP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Problem Statement 1.2. Scope of This Document 2. Conventions and Definitions 3. Architecture Overview 3.1. DAM Position in the SOOS Stack 3.2. DA-Type Taxonomy 3.3. Artifact Lifecycle States 3.4. GAR Provenance Integration 4. Artifact Classes 4.1. KGA -- Kernel-Generated Artifacts 4.2. AGA -- Agent-Generated Artifacts 4.3. EIA -- Externally Ingested Artifacts 5. Graph Write Authority Model 6. Governance Envelope 7. Data Location and Usage Model 7.1. KGA In-Flight Usage 7.2. Default Retention for AGA and EIA 7.3. AGA Consumption by Downstream Agents 7.4. External Disclosure 7.5. Data Residency and Analytics Eligibility 7.6. Content-Versus-Audit-Trail Separation 7.7. Semantic Retrieval Over Ingested Documents 8. Open Issues 9. Security Considerations 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Author's Address 1. Introduction 1.1. Problem Statement Agentic AI systems produce, consume, and transform data continuously across the lifecycle of a governed session. A booking agent reads availability data from a supplier API, produces an itinerary document, and records its reasoning chain. A disaster response agent ingests sensor readings, produces routing plans, and generates situation reports. An enterprise procurement agent queries inventory databases and produces purchase orders. In each case, the data is not homogeneous. Availability data from a supplier API has different provenance, access policy, and retention requirements than a GAR audit record. A routing plan produced by an agent has different write authority semantics than an IDP event log produced by the kernel. A sensor reading ingested from an external source has different validation requirements than an agent decision document. No existing protocol specifies a unified typed taxonomy for data artifacts in agentic AI systems, a governance envelope that travels with each artifact type, or the normative interface between artifact production and the GAR provenance chain. Without such a specification, agentic systems cannot make machine-readable claims about what data they produced, under what authority, with what retention obligation, or how that data connects to the governance audit record. DAM closes this gap. DAM does not specify data encoding formats or storage systems. DAM specifies the governance layer above those concerns: the artifact type taxonomy, the governance envelope fields, the write authority model, and the GAR provenance interface. 1.2. Scope of This Document This document (DAM-01) supersedes DAM-00, the placeholder submission that established the draft identifier, abstract, problem statement, and architecture overview. DAM-00's architecture overview (Section 3) is carried forward unchanged; Sections 4 through 6, previously marked "(Stub)," are specified normatively here. The DA-Type taxonomy (Section 3.2), graph write authority model (Section 5), and governance envelope fields (Section 6) implement the architecture locked per the SOOS UpgradeSprint Day 7 session record (DR-GRP-DAM-01, June 30, 2026). Sub-type registry content (OQ-DAM-01), the artifact lifecycle state machine, and the AGA-to- EOD linkage mechanism are the substantive design decisions made in producing this revision; see Section 8 for what remains open. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Data Artifact (DA): Any discrete unit of data produced, consumed, or transformed by an agentic AI system or its governing kernel during a governed session. A DA is typed (Section 3.2), carries a governance envelope (Section 6), and has a write authority class (Section 5). DA-Type: The type identifier for a Data Artifact. DA-Types are organized into three top-level classes: KGA (Kernel-Generated Artifact), AGA (Agent-Generated Artifact), and EIA (Externally Ingested Artifact). DA-Types are registered in the IANA DA-Type Registry (Section 10). Governance Envelope (GE): The structured metadata record that travels with each Data Artifact, specifying: provenance (who produced it, under what session and mandate), access policy (Cedar policy reference governing read/write), temporal validity (not-before, not-after), and retention requirement (KERNEL_PERMANENT, SESSION_SCOPED, OPERATOR_DEFINED, REGULATORY_MINIMUM). KGA (Kernel-Generated Artifact): A DA produced by the GEC kernel as a governance record. Includes IDP event records, GAR records, AEP session state, SACR objects, and EOD endorsement records. Subject to kernel-only write authority (Section 5). AGA (Agent-Generated Artifact): A DA produced by an AI agent as an output of its action execution. Includes documents, reports, code outputs, decisions, and recommendations. Subject to agent-write with kernel audit (Section 5). EIA (Externally Ingested Artifact): A DA made available to the agent by an external resource. Includes API responses, database query results, file contents, and sensor readings. Subject to kernel validation against the active RGP Resource Envelope before agent ingestion (Section 5). Provenance Chain: The ordered sequence of GAR records that establishes the production history of a Data Artifact: who produced it, in which session, under which mandate, and with which kernel governance events preceding production. Retention Requirement: The retention policy class attached to a DA in its Governance Envelope. Four classes are defined: KERNEL_PERMANENT (GAR records; never deleted except by legal order), SESSION_SCOPED (valid for session duration only), OPERATOR_DEFINED (operator configures retention period), REGULATORY_MINIMUM (minimum retention period specified by applicable regulatory obligation). 3. Architecture Overview 3.1. DAM Position in the SOOS Stack DAM sits above GAR in the SOOS governance stack and below the agent execution layer (AEP) and resource governance layer (RGP). DAM is the data governance layer: it specifies the types and governance envelopes of the data artifacts that flow between the layers above and the audit record layer below. The SOOS stack layers relevant to DAM: +----------------------------------------------------------+ | AEP / AOP / RGP (Agent Execution Layer) | | Agent produces AGA | Agent ingests EIA | Kernel logs KGA | +----------------------------------------------------------+ | +----------+ | DAM | | DA-Type | | Gov Env | | Write | | Authority| +----------+ | +----------------------------------------------------------+ | GAR (Audit Record Layer) | | Provenance chain | Merkle-signed session block | +----------------------------------------------------------+ DAM is not a messaging protocol. It does not specify how Data Artifacts are transmitted between agents or resources. It specifies the governance metadata (DA-Type, Governance Envelope, write authority class) that every Data Artifact in a SOOS-governed system MUST carry. 3.2. DA-Type Taxonomy The three top-level DA-Type classes: +---------+------------------------+----------------------------+ | Class | Description | Examples | +---------+------------------------+----------------------------+ | KGA | Kernel-Generated | IDP records, GAR | | | Artifact: produced by | records, AEP session | | | GEC kernel as | state, SACR objects, | | | governance record | EOD endorsements, | | | | KEE-1 WAL entries | +---------+------------------------+----------------------------+ | AGA | Agent-Generated | Documents, reports, | | | Artifact: produced by | code, decisions, | | | agent as action | recommendations, | | | output | itineraries, purchase | | | | orders | +---------+------------------------+----------------------------+ | EIA | Externally Ingested | API responses, | | | Artifact: made | database query | | | available by | results, file contents, | | | external resource | sensor readings, | | | | supplier data | +---------+------------------------+----------------------------+ Sub-type registries for the KGA class are registered by this document (Section 4.1, Section 10(a)); AGA and EIA sub-type lists remain open, deferred to a future revision (OQ-DAM-01). DA-Type strings use the format: {CLASS}/{subtype}, e.g., "KGA/GAR_SESSION_BLOCK", "AGA/ITINERARY", "EIA/SUPPLIER_API_RESP". 3.3. Artifact Lifecycle States A Data Artifact's lifecycle_state (Section 6) is one of: PENDING, DRAFT, COMMITTED, VALID, EXPIRED, SUPERSEDED, or REVOKED. EXPIRED, SUPERSEDED, and REVOKED are terminal; no artifact leaves any of these three states. PENDING -> DRAFT -> COMMITTED -> VALID is the normal production path. DRAFT is OPTIONAL: a class whose artifacts are produced atomically (most KGA) MAY transition PENDING directly to COMMITTED; a class whose artifacts accumulate content over time before being finalized (a long-running AGA, or an EIA ingested in a streamed response) uses DRAFT as an intermediate state. VALID is reached when governance_envelope_hash (Section 6) is first computed. From VALID, an artifact transitions to exactly one of the three terminal states: EXPIRED (temporal_validity.not_after reached, Section 6 -- KGA never reaches this state, per Section 4.1), SUPERSEDED (a revision was produced, Section 6's revision model), or REVOKED (kernel-initiated per Section 5's Tier-specific authority). Which principal may initiate which transition, for which artifact class, is specified in Section 5, not here; this section defines the state machine's shape, not its authority model. The GAR provenance chain records every lifecycle transition as its own causally-linked record (Section 6's revision model); Section 3.4 gives the mandatory fields common to all such records. 3.4. GAR Provenance Integration Every Data Artifact production or ingestion event in a SOOS-governed session MUST be recorded in the GAR provenance chain. The mandatory GAR record for artifact production carries: (a) da_type: the DA-Type string. (b) da_id: UUID v7 assigned at production time. (c) producing_session_id: the AEP session in which the artifact was produced or ingested. (d) producing_agent_xpid: XPID of the agent that produced/ingested the artifact. For KGA artifacts, producing_agent_xpid is the GEC's XPID. (e) mandate_ref: the MJWT jti that authorized the action producing this artifact. (f) governance_envelope_hash: SHA-256 over canonical JSON of the artifact's Governance Envelope. The mandatory provenance fields on Cedar evaluation records (cedar_policy_id, cap_rrs_control_id, authority_source_uri) defined in [I-D.sato-soos-gar] Section 8.6 apply to all DAM artifact production events that are gated by Cedar policy evaluation. 4. Artifact Classes 4.1. KGA -- Kernel-Generated Artifacts KGA artifacts are the authoritative governance record of the SOOS kernel: IDP event logs, GAR records, AEP session state, SACR objects [I-D.sato-soos-mad], EOD endorsement records [I-D.sato-soos-idp], and KEE-1 WAL entries [SOOS-KEE]. The initial KGA sub-type registry (Section 10(a)): KGA/GAR_SESSION_BLOCK, KGA/GAR_SAR, KGA/GAR_ALE, KGA/IDP_EVENT, KGA/SACR, KGA/EOD_ENDORSEMENT, KGA/AEP_SESSION_STATE, KGA/DRR, KGA/PRD. KGA/DRR (Decision Rationale Record) and KGA/PRD (Policy Rationale Declaration) [I-D.sato-soos-hem] Section 12.7 are stored in GAR's Rationale Store [I-D.sato-soos-gar] Section 6 and were already referenced elsewhere in this document (Section 7.1) without being formally registered until now. Every KGA da_id MUST equal the identifier of the underlying GAR record it represents (SAR's session_id, an ALE's own event id, or the equivalent per-record identifier of the other sub-types); DAM does not mint a second, parallel identifier for a record GAR already identifies. Key properties: Write authority: kernel-only (Tier 1, Section 5). No agent, operator, or external resource may write or delete a KGA. Retention: KERNEL_PERMANENT (Section 6), consistent with GAR's own retention model [I-D.sato-soos-gar] Section 6.4. A KGA MUST NOT be deleted except by legal order, recorded as a court-order attestation record in GAR at the time of deletion. Tamper evidence: every KGA is covered by its Session Block's Merkle root and KIA threshold signature per [I-D.sato-soos-gar] Section 14.4's two-layer model (span hash chain within a block; Merkle root and signature across the block). DAM does not define a separate tamper-evidence mechanism for KGA; it inherits GAR's directly. Lifecycle: a KGA transitions PENDING -> COMMITTED -> VALID at Session Block Close (Section 3.3) and never transitions further except SUPERSEDED or REVOKED under Section 6's revision model. A KGA MUST NOT be represented in EXPIRED state: KERNEL_PERMANENT retention has no expiry. 4.2. AGA -- Agent-Generated Artifacts AGA artifacts are the operational outputs of agent execution: documents, decisions, recommendations, itineraries, routing plans, purchase orders, and other substantive task results. Key properties: Write authority: agent-write with kernel audit (Tier 2, Section 5). The agent produces the artifact; the kernel logs the production event and provenance chain to GAR immediately, before the agent can suppress or modify that record. EOD linkage: this document resolves OQ-DAM-03. An AGA produced as a mission's primary output MUST carry an eod_ref field in its Governance Envelope (Section 6), populated with the eod_id (AEP-03 [I-D.sato-soos-aep] Section 6.2 schema; AOP-02 [I-D.sato-soos-aop] Section 6.1/6.2 for mission- or sub-goal- scoped EODs) whose primary_outcome.target_state names this AGA's da_type. This is a direct instance of the EOD-vs-actual gap record already described in [SSRN-PAPER2] Section 8: an AGA's eod_ref lets a GAR query join the artifact actually produced against the outcome that was declared before production began, without inventing a second correlation mechanism alongside the one AOP-02/AEP-03 already establish. An AGA produced outside any EOD-governed mission (for example, a single-turn AEP session with no Mission-Level EOD) MAY omit eod_ref. Sub-type registry: deferred to a future revision per OQ-DAM-01; the format {CLASS}/{subtype} (Section 3.2) applies uniformly. 4.3. EIA -- Externally Ingested Artifacts EIA artifacts are data made available to the agent by an external resource: API responses, database query results, file contents, sensor readings. This section corrects DAM-00's citation. EIA ingestion is not governed by the RGP Resource Envelope: per [I-D.sato-soos-rgp] Section 4, Resource Envelope is the budget and scope ceiling carried in the agent's Mandate JWT, checked at resource *assignment* time against the Resource Map SO [I-D.sato-soos-rgp] Section 10 -- a cost concern, not a data- trust concern. What governs whether a specific piece of ingested data can be trusted is the resource's Trust Level [I-D.sato-soos-rgp] Section 7.1 (TRUST-0 through TRUST-3) and its Governance Envelope (RGP's own Stage 1/Stage 2 declaration schema, [I-D.sato-soos-rgp] Section 7.2 -- a different object from DAM's Governance Envelope, Section 6, despite the shared name). DAM's EIA validation checks the latter, not the former. Key properties: Write authority: external-write with kernel validation (Tier 3, Section 5). Before permitting agent ingestion, the kernel validates the ingesting resource's current RGP Trust Level and Governance Envelope against the deployment's CAP profile rules for that trust level, and logs the ingestion event to GAR. Temporal validity: an EIA's not_after (Section 6) MUST equal the ingesting resource's valid_until from its RGP Stage 1 fingerprint [I-D.sato-soos-rgp] Section 7.3 (RGP's Staleness Bound) at ingestion time. DAM does not define a separate staleness rule; it reuses RGP's directly, the same way KGA (Section 4.1) reuses GAR's tamper-evidence model rather than defining a parallel one. EIA poisoning defense: malicious EIA content that causes a CAP prohibition violation is fully traceable in the GAR provenance chain only when something actually evaluates the content and produces a Cedar DENY. Per [I-D.sato-soos-cap] Section 16, the MANIPULATION prohibition's effect-based test is not mechanically verifiable by Cedar pattern-matching alone; behavioral inference requires an operator-configured external classifier. DAM does not claim traceability for content that never reaches a classifier: every EIA's Governance Envelope (Section 6) MUST carry a classifier_evaluated boolean field, set by the kernel at ingestion time to whether an external classifier per [I-D.sato-soos-cap] Section 16 was actually invoked against this artifact's content before the agent was permitted to use it. classifier_evaluated: false is not itself a fault -- many deployments will not configure a classifier for every capability class -- but it makes the absence of behavioral screening an auditable fact rather than a silent gap indistinguishable from "screened and passed." An auditor investigating a MANIPULATION- adjacent incident can now distinguish three cases from the GAR provenance chain alone: classifier evaluated and DENY fired (traceable, per DAM-00's original claim); classifier evaluated and PERMIT fired (a classifier miss, a different failure mode than "no classifier ran"); and classifier_evaluated: false (no screening occurred at all, and the resulting gap in traceability is itself visible in the record rather than assumed away). Output DA-Type cross-reference: [I-D.sato-soos-rgp] Section 7.2 item 9 and Section 7.4 already define an output_da_type field on a resource's Stage 2 declaration, typed as an SOV Sovereign Object type [I-D.sato-soos-sov]. Where a resource's declared output corresponds to an EIA this document defines, deployments SHOULD populate output_da_type with the matching EIA/{subtype} string (Section 3.2), giving RGP's own resource declarations a concrete DA-Type to point to rather than leaving the field's value space under-specified relative to DAM's taxonomy. 5. Graph Write Authority Model The three-tier write authority model governs who may create, modify, or delete each class of Data Artifact, and who may transition its lifecycle state (Section 3.3: PENDING -> DRAFT -> COMMITTED -> VALID -> EXPIRED | SUPERSEDED | REVOKED). Tier 1 -- Kernel-only write (KGA): Only the GEC kernel may write KGA artifacts. No agent, operator, or external resource is granted Cedar Action::WriteKGA. KGA write operations are enforced at the TEE boundary per [SOOS-KEE] KEE-1 property P1. Only the kernel may transition a KGA's lifecycle state; per Section 4.1, a KGA transitions PENDING -> COMMITTED -> VALID automatically at Session Block Close and MUST NOT be transitioned to any state by agent or operator action. Tier 2 -- Agent-write with kernel audit (AGA): The agent may produce AGA artifacts as outputs of Cedar Action::ProduceAGA-authorized actions. Each AGA production event is logged to GAR by the kernel immediately upon production. The agent cannot suppress or modify the GAR log entry for an AGA it produced. An agent MAY request an AGA lifecycle transition to SUPERSEDED (producing a revised output that replaces an earlier one) but MUST NOT request REVOKED; only the kernel, acting on an operator's or Mission Principal's authenticated instruction, may revoke an AGA. SUPERSEDED and REVOKED transitions MUST be recorded as new GAR records referencing the prior state (Section 6, revision model), never as in-place modification of the original production record -- the same discipline [I-D.sato-soos-gar]'s own tamper-evidence model requires of GAR records themselves. Tier 3 -- External-write with kernel validation (EIA): External resources produce EIA artifacts and make them available to the agent. Before permitting agent ingestion, the kernel validates the resource's current RGP Trust Level and Governance Envelope (Section 4.3) against the deployment's CAP profile rules for that trust level -- not against the Resource Envelope, which governs assignment budget rather than ingestion trust. The kernel logs the ingestion event to GAR, including the classifier_evaluated determination (Section 4.3). No party other than the kernel may write an EIA's Governance Envelope after ingestion; the external resource's role ends at the point its declared content is ingested and recorded. The graph write authority model prevents a core attack class: an agent that attempts to modify its own audit record (KGA) or suppress the provenance record of an artifact it produced (AGA). Both are DENIED by Cedar and enforced at the kernel boundary. 6. Governance Envelope Each Data Artifact carries a Governance Envelope: { "da_id": string, ; REQUIRED. UUID v7, or the ; underlying GAR record's own ; identifier for KGA (Section ; 4.1). "da_type": string, ; REQUIRED. {CLASS}/{subtype}. "provenance": { "session_id": string, ; REQUIRED. "agent_xpid": string, ; REQUIRED. GEC's XPID for ; KGA. "mandate_ref": string, ; REQUIRED. MJWT jti ; authorizing production. "produced_at": string ; REQUIRED. ISO 8601. }, "access_policy": string, ; REQUIRED. Cedar policy ; reference governing read ; access. "temporal_validity": { "not_before": string, ; REQUIRED. ISO 8601. "not_after": string | null ; REQUIRED for EIA ; (Section 4.3); null for KGA ; (KERNEL_PERMANENT, Section ; 4.1); OPTIONAL for AGA. }, "retention_requirement": string, ; REQUIRED. KERNEL_PERMANENT | ; SESSION_SCOPED | ; OPERATOR_DEFINED | ; REGULATORY_MINIMUM. "lifecycle_state": string, ; REQUIRED. PENDING | DRAFT | ; COMMITTED | VALID | EXPIRED | ; SUPERSEDED | REVOKED ; (Section 3.3). "supersedes": string | null, ; OPTIONAL. da_id of ; the artifact this one ; replaces, REQUIRED when ; lifecycle_state transitions ; a prior artifact to ; SUPERSEDED (Section 5). "eod_ref": string | null, ; OPTIONAL, AGA only ; (Section 4.2). "classifier_evaluated": boolean | null, ; REQUIRED, EIA only ; (Section 4.3); null for KGA ; and AGA. "derived_from": { ; REQUIRED for AGA (arrays ; MAY be empty); null for KGA ; (Section 3.4's causal chain ; covers KGA-to-KGA derivation ; instead) and EIA -- an EIA's ; own provenance is governed by ; RGP, not DAM lineage; a ; retrieved passage's relation ; to its source document uses ; retrieval_derivation, below, ; not this field. "direct_inputs": string[], ; REQUIRED. da_id values ; whose content was directly ; incorporated into producing ; this artifact. "context_inputs": string[] ; REQUIRED. da_id values ; read or consulted during ; production but not directly ; incorporated into this ; artifact's content. }, "retrieval_derivation": { ; REQUIRED for EIA/RETRIEVED_ ; PASSAGE (Section 7.7); null ; for every other artifact, ; including ordinary EIA. A ; single-parent relationship, ; not derived_from's multi- ; input array shape: a ; retrieved passage has ; exactly one source document, ; even when an agent's later ; synthesis draws on several ; passages -- that synthesis ; is an AGA with multiple ; direct_inputs, already ; covered above. "parent_da_id": string, ; REQUIRED. da_id of the ; source document EIA this ; passage was retrieved from. "retrieval_query": string, ; REQUIRED. The query that ; produced this retrieval, for ; audit: why was this passage ; selected. "relevance_score": number, ; REQUIRED. The retrieval ; mechanism's own similarity ; or relevance score, opaque ; to DAM -- recorded, not ; interpreted. "chunk_locator": string | null ; OPTIONAL. Where ; within the parent document ; this passage came from (page ; range, byte offset, section ; id) when the retrieval ; mechanism provides one. }, "external_disclosure": { ; REQUIRED for AGA (Section ; 7.4); null for KGA (never ; disclosed outside governance) ; and EIA (disclosure concern ; is upstream, at ingestion). "disclosed_to_class": string, ; REQUIRED. NONE | ; HUMAN_PRINCIPAL | ; EXTERNAL_THIRD_PARTY. ; Defaults to NONE. "disclosed_at": string | null ; REQUIRED. ISO 8601; ; null when disclosed_to_class ; is NONE. }, "data_residency": { ; REQUIRED for AGA and EIA ; (Section 7.5); for KGA, ; MUST mirror the underlying ; IDP record's own data_ ; residency field ; [I-D.sato-soos-idp] Section ; 4.1 where one exists, else ; null. "jurisdiction": string, ; REQUIRED. ISO 3166-1 ; alpha-2. "tier2_eligible": boolean, ; REQUIRED. "tier3_eligible": boolean, ; REQUIRED. "retention_days": integer | null, ; OPTIONAL. "anonymization_delay_days": integer | null ; OPTIONAL. } | null } derived_from records the production-time lineage between artifacts -- which inputs this AGA actually came from, not merely which session it was produced in. This is distinct from, and does not replace, GAR's own causal chain (prev_span_hash, Section 3.4) or eod_ref (Section 4.2): eod_ref names the outcome that was declared before production; derived_from names what was actually consumed during it. The direct/context split matters for two of this document's own claims: a poisoning trace (Section 9(d)) is far more precise when it can point at which specific EIA among several ingested during a session was a direct input to the AGA that triggered a CAP DENIED action, rather than only establishing that some EIA ingestion preceded it in time; and a privacy-restricted EIA's data_residency constraint (Section 7) propagates unambiguously to any AGA listing it as a direct_inputs entry, while a context_inputs entry records that the artifact was read without asserting the same propagation. An agent MAY decline to populate direct_inputs precisely (for example, when synthesis draws on many sources in a way the agent cannot cleanly attribute); an empty direct_inputs array with a non-empty context_inputs array is a valid, honestly- reported declaration that inputs were consulted but no clean attribution exists, and it is a materially different, weaker claim than omitting derived_from's substance and reporting nothing. Revision model: an artifact revision MUST NOT mutate an existing Governance Envelope in place. A revision is a new Data Artifact with its own da_id, carrying supersedes set to the prior artifact's da_id; the kernel then transitions the prior artifact's lifecycle_state to SUPERSEDED as a separate GAR record. This mirrors the fix already adopted for [I-D.sato-soos-gar]'s own CATALOG_VERSION_CONFLICT handling (causally-linked new record, not in-place field mutation) rather than reintroducing the same anti-pattern one layer up. governance_envelope_hash (referenced in Section 3.4's mandatory GAR provenance fields) is SHA-256 over the canonical JSON serialization of this object, computed at the point lifecycle_state first reaches VALID and recomputed on every subsequent lifecycle_state transition; a mismatch between a stored hash and a freshly computed one is the auditor's signal of post-production tampering (Section 9(e)). 7. Data Location and Usage Model Sections 4 through 6 specify how each class is written, what metadata it carries, and how long it is retained. This section specifies how each class is actually used after production or ingestion: who reads it, in what situation, under what restriction, and what remains once the work that produced or consumed it is finished. 7.1. KGA In-Flight Usage KGA is read in two structurally different ways, and this document's access_policy field (Section 6) governs only one of them. Direct read of a specific KGA record -- an auditor opening a named Session Block, a HEM Principal reviewing a specific DRR -- is governed by access_policy, per Cedar evaluation of the requesting principal against that artifact's own policy reference. Aggregate, in-flight query of KGA for planning intelligence -- an orchestrating agent's GOAL_COMPLETION_PROFILE query at Mission Framing, EOD_BREACH frequency lookups at Assignment Execution, HISTORICAL_PATTERN_MATCH evaluation during Mid-Flight Monitoring (all [I-D.sato-soos-aop] Section 12) -- is governed entirely by FAIP's Tier 1/2/3 analytics architecture [SOOS-FAIP], operating directly on the underlying GAR Event Log. DAM's Governance Envelope and access_policy field do not gate this path, and this document does not add a second access-control layer in front of it: FAIP's own tier eligibility rules (Section 7.5) are the sole gate. A reader of this document should not assume access_policy constrains aggregate analytics query the way it constrains direct record read; the two paths are independently governed by design, not by omission. 7.2. Default Retention for AGA and EIA KGA's retention default is unambiguous: KERNEL_PERMANENT (Section 4.1). AGA and EIA had no stated default prior to this revision. AGA retention_requirement defaults to SESSION_SCOPED when the operator has not configured a class- or subtype-specific policy. Deployments SHOULD configure OPERATOR_DEFINED retention for AGA subtypes that constitute the mission's actual deliverable (an itinerary, a purchase order) rather than relying on the default, since SESSION_SCOPED retention of a deliverable the Mission Principal still needs after session close is very likely wrong for that subtype. The default is deliberately conservative in the other direction: absent explicit operator configuration, DAM does not assume an AGA should be retained indefinitely merely because it might be useful later, given AGA content routinely includes personal data (Section 7.5). EIA retention_requirement defaults to SESSION_SCOPED for the same reason, overridden to REGULATORY_MINIMUM where the ingesting deployment's applicable law requires retaining ingested source data for a longer audit window than the session itself. This document does not enumerate which jurisdictions require this; deployments determine applicability per Section 7.5's jurisdiction field. 7.3. AGA Consumption by Downstream Agents An AGA consumed by another agent within the same SOOS-governed mission -- a sibling sub-goal's output read as input to the next sub-goal, or a Master AI's output read by a Local AI it spawned -- remains an AGA. It is not reclassified as EIA: EIA specifically denotes externally-sourced data validated against an RGP Trust Level (Section 4.3), and an AGA produced by another agent inside the same governed mission was never external to that governance boundary. The consuming agent's read is governed by the AGA's own access_policy (Section 6), evaluated per Cedar the same way any other Tier 2 read is. The consuming agent's own output, if it incorporates the consumed AGA's content, MUST list that AGA's da_id in its own derived_from.direct_inputs (Section 6); if it was read only for situational context, context_inputs. This is the mechanism that makes a mission's internal artifact graph -- previously entirely unrecorded -- reconstructable from GAR after the fact. An AGA consumed outside the mission that produced it -- a later, unrelated mission reusing a prior mission's output as a resource -- crosses a mandate boundary this document does not yet resolve normatively; see OQ-DAM-04. 7.4. External Disclosure external_disclosure (Section 6) distinguishes an AGA delivered back to the Mission Principal who commissioned it (disclosed_to_class: HUMAN_PRINCIPAL) from one sent to a party outside the mission's own governance chain entirely (EXTERNAL_THIRD_PARTY) -- a supplier, a customer, a vendor. Both are meaningfully different from internal consumption (Section 7.3), which does not set external_disclosure at all (disclosed_to_class: NONE). Once disclosed_to_class reaches EXTERNAL_THIRD_PARTY, the artifact's content is no longer within DAM's write-authority model (Section 5) regardless of what its Governance Envelope continues to say -- there is no mechanism by which SOOS can enforce anything about a copy that has left the deployment. What DAM does guarantee is that the disclosure event itself, and the artifact's data_residency and derived_from state at the moment of disclosure, are permanently recorded (Section 4.1's KGA provenance record for this event), so an auditor can later determine what was disclosed, to whom, and whether the disclosed artifact's own lineage included any data_residency-restricted input it should not have carried. 7.5. Data Residency and Analytics Eligibility data_residency (Section 6) generalizes the field [I-D.sato-soos-idp] Section 4.1 already defines for IDP records, to AGA and EIA. For KGA/IDP_EVENT specifically, DAM's data_residency field MUST mirror the underlying IDP record's own field value -- read-through, not an independently maintained second copy -- so this does not recreate the two-fields-one- value problem this suite has already found and fixed elsewhere (the XPID/ptxn_id collision in [SOOS-DIST] Section 2). Other KGA subtypes without an existing data_residency source are null; see OQ-DAM-01. Narrowing rule: an AGA's data_residency MUST be at least as restrictive as the most restrictive data_residency among the artifacts listed in its derived_from.direct_inputs (Section 6). Restrictiveness orders as: tier3_eligible: false is more restrictive than true; tier2_eligible: false is more restrictive than true; a shorter retention_days or a longer anonymization_delay_days is more restrictive than a longer or shorter one respectively; and a jurisdiction restriction, once present in any direct input, MUST carry forward. This is the mechanism that actually closes the privacy propagation gap identified during this document's design: a personal-data- bearing EIA's restriction now provably constrains every AGA built from it, not merely in principle but as a checkable MUST the kernel can enforce at production time. This is the same Narrowing Property shape already established elsewhere in this suite ([I-D.sato-soos-mad]'s recursive hub-only monotonicity; CAP-RRS-OP's Narrowing Property interaction at revision-adoption time) applied to a new dimension -- data residency -- rather than a new mechanism invented for this case alone. context_inputs entries do not trigger the narrowing rule: reading a restricted artifact for situational awareness, without incorporating its content, does not by itself restrict the reader's own output. This is a deliberate, narrower claim than direct_inputs' propagation, consistent with Section 6's distinction between the two. 7.6. Content-Versus-Audit-Trail Separation A right-to-erasure request against an EIA or AGA containing personal data creates a tension this document does not yet resolve: the artifact's content may need to be purgeable, while its provenance record (that ingestion or production occurred, under what mandate, with what governance_envelope_hash) must remain, since removing the provenance record itself would break the tamper-evidence chain Section 4.1 and Section 6 depend on. This suite already has an architectural answer to the same underlying problem: [I-D.sato-soos-sov]'s Zone A/B split (INV-ZA-1), which this document's author's own security review identified as the cleanest existing treatment of erasure-versus- audit-integrity in the suite. DAM does not adopt Zone A/B's mechanics normatively in this revision; doing so accurately requires a level of detail this document does not yet have grounds to assert. See OQ-DAM-05. 7.7. Semantic Retrieval Over Ingested Documents Sections 4.3 and 5 (Tier 3) govern EIA as discrete records: RGP-01's Resource Data Request [I-D.sato-soos-rgp] Section 11 ingests one record, one da_id. This section addresses a different case that record-shaped ingestion does not cover: an agent needing to search within a large, already-ingested EIA -- a contract, a manual, a policy document -- rather than consuming it whole. This is DAM's answer to retrieval-augmented generation [RAG-USE-CASE]: unlike a conventional RAG pipeline's vector store, which carries no provenance chain, every passage retrieved under this section is itself a governed, retention-managed, lineage- traceable EIA. EIA/RETRIEVED_PASSAGE is a new EIA sub-type (Section 10(a)). A retrieved passage's Governance Envelope (Section 6) carries retrieval_derivation, not derived_from: a single parent_da_id, not an array, since a passage has exactly one source document regardless of how many passages an agent's later synthesis draws on together (that synthesis is an AGA with multiple direct_inputs, Section 4.2 -- already covered, not duplicated here). This document does not specify how retrieval is computed -- chunking strategy, embedding model, similarity search -- for the same reason [SSRN-PAPER2]'s architectural principle already gives the rest of this suite: the LLM-adjacent computation is not the kernel's job. What the kernel governs is validation and commitment of the result, following the same two-phase discipline this suite's own security review found necessary elsewhere (Section 7.3's derived_from resolution check and [I-D.sato-soos-aep] Section 9.2 Step 4a use the identical shape): Validation pass (no artifact minted yet): (1) parent_da_id MUST resolve to an existing EIA in VALID lifecycle_state (Section 3.3). An unresolvable or non-VALID parent MUST fail validation with denial code DA_RETRIEVAL_ PARENT_UNRESOLVED, the same failure shape Section 7.3 already uses for derived_from. (2) The requesting principal MUST be authorized to read the parent document's content under the parent's own access_policy (Section 6), per Cedar evaluation of the requesting principal against that policy reference -- the same access_policy gate Section 7.1 already describes for direct KGA reads, applied here as a precondition to retrieval rather than assumed. Step (1) establishes only that the parent document exists and is current; it says nothing about whether this particular requester is entitled to read it. An unauthorized request MUST fail validation with denial code DA_RETRIEVAL_UNAUTHORIZED before any classifier evaluation or content minting occurs. (3) The passage content MUST be evaluated by an external classifier per [I-D.sato-soos-cap] Section 16 where one is configured for the parent document's capability class, and classifier_evaluated (Section 6) MUST reflect whether this specific passage was screened -- not whether the parent document was screened as a whole. A parent document's classifier_evaluated: true does not carry forward to its passages: the parent may have passed an overall screen while containing content -- an adversarially-planted clause designed to be retrieved and act on the agent as an indirect prompt injection -- that only a per-passage evaluation would catch. This is retrieval poisoning, a real and known attack class this suite's existing EIA poisoning defense (Section 4.3, Section 9(d)) does not address unless this per-passage requirement is enforced. Commit pass (only if validation passed): (4) Mint the EIA/RETRIEVED_PASSAGE artifact. Its data_residency (Section 7.5) is computed by the same narrowing rule already specified there, generalized: "the most restrictive data_ residency among direct_inputs" (AGA's case) and "the parent document's data_residency" (this section's case) are the same computation applied to a one-element input set, not two different rules. A source document's residency restriction therefore provably constrains every passage retrieved from it, the same way it constrains every AGA built from an EIA under Section 7.5. (5) temporal_validity.not_after (Section 6) MUST NOT exceed the parent document's own not_after: a passage cannot outlive the source it was retrieved from. Rejection: failure of (1), (2), or (3) leaves no artifact minted, per the same no-write-until-validated discipline as [I-D.sato-soos-rgp] Section 11.3 -- there is nothing to undo, since nothing was written until the commit pass. 8. Open Issues OQ-DAM-01: DA-Type sub-type registry content. The three top-level DA-Type classes (KGA, AGA, EIA) are locked, and the {CLASS}/{subtype} string format is normative (Section 3.2). Section 4.1 registers an initial KGA sub-type list; AGA and EIA sub-type lists remain open, deferred to a future revision alongside the registration procedure (first-come- first-served with expert review, Section 10(a)). OQ-DAM-02: EIA poisoning defense normative treatment. RESOLVED (Section 4.3, Section 9(d)). classifier_evaluated makes the absence of behavioral screening an auditable fact; DAM no longer claims traceability it cannot support for content that never reached a classifier. OQ-DAM-03: AGA linkage to EOD target state. RESOLVED (Section 4.2). The eod_ref field, populated from AEP-03's or AOP-02's EOD schema, closes this against the now-authored AOP-02 Section 6. OQ-DAM-04: Cross-mission AGA reuse. Section 7.3 resolves same-mission AGA consumption but leaves open the case where an AGA is reused as input outside the mission that produced it, under a different mandate. Whether this requires re-validation analogous to EIA ingestion, a distinct write-authority tier, or is simply out of scope for DAM and belongs to whichever protocol governs cross-mission resource reuse, is unresolved. OQ-DAM-05: Content-versus-audit-trail separation mechanics. Section 7.6 identifies [I-D.sato-soos-sov]'s Zone A/B split as the architecturally appropriate pattern for separating purgeable EIA/AGA content from permanent provenance, but does not adopt its mechanics normatively pending a review of Zone A/B against DAM's specific artifact classes. 9. Security Considerations (a) KGA integrity: Kernel-only write authority (Tier 1, Section 5) prevents agents from modifying or suppressing governance records. Enforced at the TEE boundary per [SOOS-KEE] KEE-1 P1. (b) AGA provenance completeness: Every AGA production event is logged to GAR immediately upon production. An agent cannot produce an AGA without a corresponding GAR record, and MUST NOT self-transition an AGA to REVOKED (Section 5, Tier 2). (c) EIA validation: EIA artifacts are validated against the ingesting resource's current RGP Trust Level and Governance Envelope (Section 4.3), not the RGP Resource Envelope, which governs assignment budget rather than ingestion trust. An EIA from a resource failing this validation is rejected and logged to GAR. (d) EIA poisoning: malicious EIA content that causes a CAP prohibition violation is traceable in the GAR provenance chain only when a classifier actually evaluates it. Per [I-D.sato-soos-cap] Section 16, Cedar's pattern-matching alone cannot perform the behavioral inference the MANIPULATION prohibition requires. DAM does not claim traceability beyond what classifier_evaluated (Section 4.3, Section 6) records: an auditor can distinguish classifier- evaluated-and-DENIED, classifier-evaluated-and-PERMITTED (a classifier miss), and not-evaluated-at-all (no screening occurred, itself an auditable fact) from the GAR provenance chain alone, rather than the single silent case DAM-00 originally claimed. (e) Governance Envelope integrity: governance_envelope_hash (Section 6) lets auditors detect post-VALID modification of a Data Artifact's Governance Envelope. Because Section 6's revision model forbids in-place mutation, any detected change to a previously-hashed envelope is itself evidence of a specification violation, not a legitimate revision that happened to skip the SUPERSEDED transition. (f) Write authority tier confusion: an implementation that conflates Tier 2 (AGA, agent-write) with Tier 3 (EIA, external-write) -- for example, trusting agent-asserted da_type on an artifact that should have been classified EIA -- would let an agent claim its own fabricated content is externally-sourced, bypassing Tier 3's kernel validation entirely. The kernel MUST determine da_type class from the production pathway (which Cedar action authorized the write, Section 5), never from an agent-supplied claim. (g) Retrieval poisoning: a source document EIA whose content as a whole passed classifier evaluation MAY still contain a specific passage crafted to act as an indirect prompt injection once retrieved and placed in an agent's context. Section 7.7 requires classifier_evaluated to be computed per retrieved passage, not inherited from the parent document's own evaluation, specifically to prevent this: a screen that only ever ran once, against the whole document, would not catch content designed to be uninteresting in aggregate and dangerous in isolation. (h) Retrieval authorization: Section 7.7's validation pass requires Cedar evaluation of the requesting principal against the parent document's own access_policy (Section 6), denial code DA_RETRIEVAL_UNAUTHORIZED, before any passage content is minted. Without this check, an agent lacking read access to a parent EIA under its access_policy could obtain verbatim excerpts of that document's content via a retrieval request that verified only the document's lifecycle_state (step (1)) and the content's classifier screening (step (3)) -- neither of which establishes the requester's own entitlement to see it. This is a stricter case than [SOOS-FAIP] Section 3.5's existence-oracle finding: retrieval mints and returns the passage content itself, not merely a relevance score against an access-policy-filtered candidate set. 10. IANA Considerations (a) DA-Type Registry. A new registry "SOOS Data Artifact Types" with the following top-level entries: +-------+----------------------------+---------------------+ | Class | Description | Reference | +-------+----------------------------+---------------------+ | KGA | Kernel-Generated Artifact | [This document] | | AGA | Agent-Generated Artifact | [This document] | | EIA | Externally Ingested | [This document] | | | Artifact | | +-------+----------------------------+---------------------+ Sub-type registrations follow first-come-first-served policy with expert review. The initial KGA sub-type list (Section 4.1) is registered by this document: KGA/GAR_SESSION_BLOCK, KGA/GAR_SAR, KGA/GAR_ALE, KGA/IDP_EVENT, KGA/SACR, KGA/EOD_ENDORSEMENT, KGA/AEP_SESSION_STATE, KGA/DRR, KGA/PRD. EIA/RETRIEVED_PASSAGE (Section 7.7) is also registered by this document. Remaining AGA and EIA sub-types stay unregistered pending OQ-DAM-01. (b) Governance Envelope Field Names Registry. A new registry "SOOS Governance Envelope Fields" registering the canonical field names specified in Section 6: da_id, da_type, provenance, access_policy, temporal_validity, retention_requirement, lifecycle_state, supersedes, eod_ref, classifier_evaluated, retrieval_derivation. (c) Retention Requirement Vocabulary Registry. A new registry "SOOS Retention Requirements" with initial entries: KERNEL_PERMANENT, SESSION_SCOPED, OPERATOR_DEFINED, REGULATORY_MINIMUM. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.sato-soos-gar] Sato, T., "The Governance Audit Record (GAR) for Agentic AI Systems", Internet-Draft draft-sato-soos-gar-07, August 2026. [I-D.sato-soos-hem] Sato, T., "The Human Escalation Mechanism (HEM) for Agentic AI Systems", Internet-Draft draft-sato-soos-hem-07, September 2026. [I-D.sato-soos-aep] Sato, T., "The Agent Execution Protocol (AEP) for Agentic AI Systems", Internet-Draft draft-sato-soos-aep-03, August 2026. [SOOS-KEE] Sato, T., "The Kernel Execution Environment (KEE-1) for the Sovereign Object OS", July 2026, . [I-D.sato-soos-rgp] Sato, T., "The Resource Governance Protocol (RGP) for Agentic AI Systems", Internet-Draft draft-sato-soos-rgp-01, August 2026. [I-D.sato-soos-cap] Sato, T., "The Constitutional AI Protocol (CAP) for Agentic AI Systems", Internet-Draft draft-sato-soos-cap-06, September 2026. [I-D.sato-soos-aop] Sato, T., "The Agent Orchestration Protocol (AOP) for Agentic AI Systems", Internet-Draft draft-sato-soos-aop-02, August 2026. [I-D.sato-soos-mad] Sato, T., "Multi-Agent Declaration (MAD) for the Sovereign Object OS", Internet-Draft draft-sato-soos-mad-04, August 2026. [SOOS-FAIP] Sato, T., "The Federated Agent Intelligence Protocol (FAIP) for Agentic AI Systems", September 2026, . [I-D.sato-soos-idp] Sato, T., "The Intent Declaration Primitive (IDP) for Agentic AI Systems", Internet-Draft draft-sato-soos-idp-05, July 2026. 11.2. Informative References [SOOS-DIST] Sato, T., "The Distributed Governance Runtime (KEE-2/SOOS-DIST) for the Sovereign Object OS", August 2026, . [I-D.sato-soos-sov] Sato, T., "Sovereign Object (SOV) for the Sovereign Object OS", Internet-Draft draft-sato-soos-sov-03, August 2026. [SSRN-PAPER2] Sato, T., "From Compliance to Intelligence: How AI Agent Audit Logs Become the World's Best Training Data", SSRN, July 2026, . [RAG-USE-CASE] Google Cloud, "What is Retrieval-Augmented Generation (RAG)?", . Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: tomsato@myauberge.jp URI: https://soosproject.ai