Memory provides continuity. Evidence provides accountability. A runtime needs both, but they have different permissions, retention rules, and users. Memory helps future execution; evidence explains past execution.
Key takeaways
- Memory should be typed, scoped, inspectable, correctable, exportable, and deletable.
- Evidence should preserve decisions and effects, not merely raw debug logs.
- Neither memory nor evidence makes stochastic execution perfectly reproducible.
Memory taxonomy and lifecycle
| Type | Purpose | Typical control |
|---|---|---|
| Working or task memory | Active plan, observations, intermediate state | Short retention; scoped to run |
| Project memory | Architecture, constraints, decisions, current truth | Project membership and review |
| User preferences | Stable interaction or formatting preferences | Consent, correction, export, deletion |
| Episodic memory | Selected prior events useful for future tasks | Promotion criteria and expiration |
| Prohibited memory | Secrets, sensitive classes, or data not needed later | Block persistence; redact or tokenize |
The lifecycle should define retrieval, consolidation, conflict resolution, correction, expiration, export, deletion, and promotion from task state into durable memory.
Evidence schema
- Original request and interpreted objective.
- Identity, authority, risk class, and active policy version.
- Selected context, sources, provenance, and exclusions.
- Tool calls, validated arguments, outputs, and side effects.
- Policy decisions and human approvals.
- Artifacts, changed state, errors, retries, and recovery.
- Remaining uncertainty and reason for the terminal state.
OpenTelemetry can support operational traces, but a user-facing evidence package usually needs additional product semantics and privacy controls. Source: OpenTelemetry GenAI conventions
Inspect this run
context.selectedverified4 repository sources admitted; credentials and unrelated files excluded.
policy.decidedallowedDraft-only write permitted. Deployment denied without approval.
tool.completedcompletedDependency manifest updated in isolated branch; idempotency key recorded.
test.failedrecoveredInitial test failed; runtime restored checkpoint and selected compatible version.
approval.requestedpendingPublish action paused. Diff, tests, and rollback path attached.
artifact.producedverifiedReviewable patch and decision summary sealed into evidence package.
Replay and reproducibility limits
Evidence can make a run inspectable and partially replayable, but exact reproduction may fail because models, providers, retrieval indexes, external systems, random sampling, and time-sensitive data change. A trustworthy runtime records versions, seeds where available, source snapshots or hashes, tool contracts, and material environmental state. It should label a replay as exact, functionally equivalent, partial, or unavailable rather than claiming certainty.
Source record
References
- AI Runtime Infrastructure Primary source
Christopher Cruz. arXiv. Published 2026-03; last reviewed 2026-06-20 UTC. Research paper.
OpenTelemetry project. Cloud Native Computing Foundation. Published Current specification repository; last reviewed 2026-06-24 UTC. Official specification.
National Institute of Standards and Technology. NIST. Published 2024-07-26; last reviewed 2026-06-20 UTC. Government profile.