Proposed Standard For ` Uai/Memory Maintenance Uai`

This report proposes a machine-verifiable standard for a mandatory file named .uai/memory-maintenance.uai that every deployable agent and every deployable system must carry without exception. The recommended design...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-651251be/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-10/memory-maintenance-standard/Improvement/Proposed Standard for .uai memory-maintenance.uai.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-10T12:45:25.3874081Z
Content hash	sha256:651251bed171bbbf0c7ea24b53b8237e94bcd4eed72b9930a171f231e97a9988
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-10-memory-651251bed171.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-10-memory-651251bed171.txt

Current File Content

Structure Preview

• Proposed Standard for .uai/memory-maintenance.uai
• Executive Summary
• Standards Basis and Scope
• Exact File Specification
• Normative file rules
• Required and optional top-level fields
• Required nested structures
• Semantic validation rules
• JSON Schema excerpt
• YAML schema excerpt
• Sample YAML file
• Sample JSON file
• Memory Lifecycle and Storage Rules
• Creation, retention, archival, deletion
• Access control, encryption, backups, replication, consistency, conflict resolution
• Logging and auditability
• Enforcement and Integration
• Recommended enforcement points
• Failure modes
• Example OPA policy
• OS-level hooks
• Migration and Compatibility
• Compatibility rules
• Migration strategy

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 50373
• Preview characters: 11996

# Proposed Standard for `.uai/memory-maintenance.uai`

## Executive Summary

This report proposes a machine-verifiable standard for a mandatory file named `.uai/memory-maintenance.uai` that every deployable agent and every deployable system must carry without exception. The recommended design uses YAML 1.2 or JSON as the authoring syntax, canonicalizes the document into JSON, and validates it with JSON Schema Draft 2020-12. Versioning should follow Semantic Versioning, timestamps should use RFC 3339 date-time strings in UTC, and newly created subject and entry identifiers should use UUIDv7 for time-ordered indexing and auditability. For policy enforcement, the strongest default is: **missing file = build failure and deployment denial**; **invalid file = startup denial for any system with persistent memory**; **runtime drift = alert plus memory write quarantine or degraded mode, depending on declared profile**. citeturn36view1turn32view3turn35view0turn37view2turn38view1turn6view4

That recommendation aligns with the uploaded UAIX materials, which emphasize project-local memory under `.uai/`, explicit active-versus-cold memory boundaries, and disciplined memory handling rather than ad hoc persistence. The specification below converts that architectural direction into a concrete, enforceable contract suitable for CI/CD, runtime policy checks, and organizational audit. fileciteturn0file0 fileciteturn0file1

The design also builds directly on established security and privacy guidance. JSON Schema Draft 2020-12 is current and explicitly supports modern schema composition and validation features. OPA is designed to separate policy decision-making from policy enforcement and is already documented for CI/CD and runtime use. NIST publications provide the basis for key management, access control families, ABAC, contingency planning, and media sanitization. Official California sources require purpose disclosure, retention disclosure, reasonable necessity and proportionality, and consumer rights such as deletion and limiting the use of sensitive personal information. Official privacy-regulator guidance also reinforces data minimization, storage limitation, periodic review, deletion or anonymization of unnecessary data, and the distinction between pseudonymization and anonymization. citeturn36view1turn6view3turn6view0turn7view1turn9view0turn10view0turn34view0turn29view0turn9view1turn13view1turn13view2turn18view0turn18view1turn19view3

The result is not an existing external standard; it is a proposed organizational standard. But it is intentionally designed so that teams can implement it immediately with off-the-shelf validators, policy engines, audit systems, and deployment gates.

## Standards Basis and Scope

The proposed file should be required for any **deployable unit** that either stores memory, brokers memory, retrieves memory, exports memory, or makes decisions based on retained state. In practice that includes LLM agents, orchestration services, memory APIs, edge devices with local caches or embeddings, worker processes with replayable state, and stateless agents that intentionally declare *no* persistent memory. Requiring the file even for stateless systems is useful because it forces an explicit declaration that persistence is disabled, which is auditable and prevents accidental state creep.

The format choice should be conservative and automation-friendly. YAML 1.2 is a strict superset of JSON, and the YAML specification explicitly positions its JSON schema support as a lowest common denominator for modern language interoperability. JSON Schema Draft 2020-12 is the right validation target because it has a stable metaschema and modern validation features such as dynamic references, redesigned array keywords, and unevaluated-item semantics. Semantic Versioning provides a clear compatibility contract for the schema itself. RFC 3339 provides a well-specified Internet date-time profile, and RFC 9562 standardizes UUIDv7 as a time-ordered UUID format based on Unix epoch milliseconds. citeturn32view0turn32view4turn36view1turn35view0turn37view2turn38view1turn38view3

For policy enforcement and access decisions, ABAC is the most natural default for memory systems because authorization often depends on subject attributes, object attributes, requested operation, and environmental conditions. NIST SP 800-162 defines ABAC in exactly those terms, and OWASP’s authorization guidance recommends least privilege, deny-by-default, validation on every request, and logging around authorization decisions. OPA is an especially strong fit because its purpose is to centralize policy decisions while allowing different enforcement points across the stack. citeturn34view0turn25view0turn6view3turn6view4

For security operations, the memory-maintenance file should be treated as a configuration artifact that drives encryption, access control, backup, retention, sanitization, and logging behavior. NIST SP 800-53 identifies access control, audit and accountability, contingency planning, system and communications protection, and PII processing/privacy families as core security and privacy control areas. NIST SP 800-57 provides guidance and best practices for cryptographic key management. NIST’s media sanitization guidance defines sanitization as rendering access to target data infeasible for a given level of effort. OWASP guidance reinforces minimizing sensitive storage, using strong encryption and authenticated modes, separating keys from data, and logging “when, where, who, and what” for auditable events. citeturn9view0turn10view0turn10view1turn9view1turn23view1turn23view2turn23view3turn22view0

## Exact File Specification

### Normative file rules

The specification should define the following baseline rules:

| Aspect | Rule |
|---|---|
| Required path | The file **MUST** exist at `.uai/memory-maintenance.uai` relative to the deployable unit root. |
| Applicability | One file per deployable agent or system. In monorepos, each independently deployable unit gets its own file. |
| Encoding | UTF-8, without BOM. |
| Accepted syntaxes | YAML 1.2 or JSON object. |
| Parsing | If the first non-whitespace byte is `{`, parse as JSON; otherwise parse as YAML 1.2, then canonicalize to a JSON data model before validation. |
| Duplicate keys | Forbidden. Validation failure. |
| YAML anchors / aliases / merge keys | Forbidden for this file to avoid ambiguous effective configuration and parser differences. |
| Root type | Object only. Arrays are invalid. |
| Unknown root fields | Forbidden, except under `extensions`. |
| Timestamps | RFC 3339 date-time in UTC with trailing `Z`. |
| Version fields | Semantic Versioning `MAJOR.MINOR.PATCH` with optional prerelease/build metadata. |
| New identifiers | UUIDv7 recommended for sortable IDs. |
| Comments | Allowed only in YAML authoring form and ignored after parse. |

The top-level schema should be closed (`additionalProperties: false`) to force deterministic governance, with a single extensibility box (`extensions`) reserved for organization-specific additions. That pattern keeps the root strict while allowing controlled innovation.

### Required and optional top-level fields

| Field | Required | Type | Validation notes |
|---|---|---:|---|
| `spec` | Yes | string | Const: `uai.memory-maintenance` |
| `schema_version` | Yes | string | SemVer; governs reader/writer compatibility |
| `document_version` | Yes | string | SemVer; increments when this file changes |
| `subject` | Yes | object | Identifies the agent/system this file governs |
| `governance` | Yes | object | Ownership, approvals, review cadence |
| `memory_model` | Yes | object | Declares persistence, entry contract, classes |
| `lifecycle` | Yes | object | State model, retention, archival, deletion |
| `storage` | Yes | object | Stores, replication, consistency, conflict rules |
| `access_control` | Yes | object | AuthZ model, deny-by-default, tenant isolation |
| `security` | Yes | object | Encryption, key management, integrity, secrets |
| `resilience` | Yes | object | Backups, restore tests, replication objectives |
| `privacy` | Yes | object | Personal-data handling, lawful basis, DSR support |
| `observability` | Yes | object | Audit logs, metrics, alerts, review health |
| `enforcement` | Yes | object | Bootstrap, CI/CD, runtime, OS/file watch behavior |
| `compatibility` | No | object | Reader compatibility windows, migrated-from info |
| `extensions` | No | object | Reserved namespace for local additions |

### Required nested structures

The most important nested fields should be mandated as follows:

| Path | Required fields |
|---|---|
| `subject` | `subject_id`, `name`, `kind`, `statefulness`, `tenancy`, `deployment_class` |
| `governance` | `owner`, `approvers`, `last_reviewed_at`, `review_interval_days`, `next_review_due_at` |
| `memory_model` | `persistence_enabled`, `entry_id_format`, `required_entry_fields`, `classes` |
| `memory_model.classes[]` | `class_id`, `purpose`, `default_classification`, `retention_rule`, `access_policy`, `encryption_profile`, `backup_policy` |
| `lifecycle` | `states`, `retention_rules`, `deletion`, `archival` |
| `storage` | `primary_store`, `consistency`, `replication`, `conflict_resolution` |
| `access_control` | `authorization_model`, `deny_by_default`, `access_policies` |
| `security` | `encryption_at_rest`, `encryption_in_transit`, `integrity`, `key_management` |
| `resilience` | `backups`, `restore_testing` |
| `privacy` | `personal_data_present`, `minimization_required`, `retention_limit_enforced`, `dsr` |
| `observability` | `audit_log`, `metrics`, `alerts` |
| `enforcement` | `bootstrap`, `ci`, `runtime` |

### Semantic validation rules

These rules should be enforced **in addition to** syntactic schema validation:

| Rule | Enforcement |
|---|---|
| If `subject.statefulness = "stateless"`, then `memory_model.persistence_enabled` must be `false`. | Hard fail |
| If `subject.tenancy = "multi-tenant"`, then `access_control.tenant_isolation` must not be `none`, and `tenant_id` must be in `memory_model.required_entry_fields`. | Hard fail |
| If `privacy.personal_data_present = true`, then `privacy.lawful_basis`, `privacy.dsr.erasure_supported`, and at least one minimization mechanism must be declared. | Hard fail |
| If `resilience.backups.enabled = true`, then backup frequency, retention, and restore-test interval must be present. | Hard fail |
| If `storage.consistency.model = "eventual"`, then `storage.conflict_resolution.strategy` must not be `none`. | Hard fail |
| If `lifecycle.deletion.legal_hold_overrides = true`, entries under legal hold may not transition to `purged`. | Runtime rule |
| If `enforcement.runtime.startup_block_on_invalid = false`, then `subject.statefulness` must be `stateless` **and** `memory_model.persistence_enabled = false`. | Hard fail |
| `governance.next_review_due_at` must equal `last_reviewed_at + review_interval_days` within validator tolerance. | Hard fail or warning |
| All duration fields must parse as ISO 8601 durations and be strictly positive. | Hard fail |
| All timestamps must be UTC and end in `Z`. | Hard fail |

### JSON Schema excerpt

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "urn:uai:memory-maintenance:1.0.0",
  "title": "UAI Memory Maintenance",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "spec",
    "schema_version",
    "document_version",
    "subject",
    "governance",
    "memory_model",
    "lifecycle",
    "storage",
    "access_control",
    "security",
    "resilience",
    "privacy",
    "observability",
    "enforcement"
  ],
  "properties": {
    "spec": { "const": "uai.memory-maintenance" },
    "schema_version": {
      "type": "string",
      "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-[0-9A-Za-z.-]+)?(?:\\+[0-9A-Za-z.-]+)?$"
    },
    "document_version": {

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Proposed Standard for .uai/memory-maintenance.uai; Executive Summary; Standards Basis and Scope; Exact File Specification; Normative file rules; Required and optional top-level fields; Required nested structures; Semantic validation rules. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-489 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Proposed Standard For ` Uai/Memory Maintenance Uai`",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-651251be/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-10/memory-maintenance-standard/Improvement/Proposed Standard for .uai memory-maintenance.uai.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:651251bed171bbbf0c7ea24b53b8237e94bcd4eed72b9930a171f231e97a9988",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-10T12:45:25.3874081Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-489",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}