File memory governance

File Memory Without Platform Capture

Use VNWO to define the rules. Use UAIX Agent File Handoff to create the local-first file memory package.

Set Up Agent File Handoff with UAIX Read VNWO Memory Consent Rules

Human/machine parity

Publish a memory disposition receipt

Pair the human-readable disposition record with its schema and fictional example. UAIX or the implementing system remains responsible for the actual file handoff.

Reference Maturity describes editorial review posture only; it is not a safety, legal, compliance, or runtime certification.

Human-readable template

Copy or download the editable Markdown record.

Open Human-readable template

JSON Schema

Inspect the machine-readable field contract and validation shape.

Open JSON Schema

Completed example

Review a fictional example without treating it as certification or deployment evidence.

Open Completed example

File memory workflow: files dropped, review required, use or disposition, record proof, update .uai memory, and remove, retire, or keep active with reason. — VNWO treats dropped files as active intake: every file needs review, disposition, proof-of-use, and an exit path.

Memory disposition flow

Intake Disclose that a file or packet entered active review.
Review Check relevance, provenance, privacy, safety, and authority.
Disposition Accept, summarize, partially use, reject, defer, quarantine, or mark duplicate.
Proof of use Link accepted material to the work it influenced.
Durable memory Move only reviewed facts into the appropriate memory record.
Retire / remove / keep Record retention, review date, export, revocation, and exit status.

A file or memory packet remains active only after review, explicit disposition, proof of use, and a retention or exit decision.

Read the diagram as text

Intake: Disclose that a file or packet entered active review.
Review: Check relevance, provenance, privacy, safety, and authority.
Disposition: Accept, summarize, partially use, reject, defer, quarantine, or mark duplicate.
Proof of use: Link accepted material to the work it influenced.
Durable memory: Move only reviewed facts into the appropriate memory record.
Retire / remove / keep: Record retention, review date, export, revocation, and exit status.

What file memory is

File memory is the reviewed use of files, documents, notes, assets, evidence, and project context to help an AI or human receiver continue work without relying on scattered memory, hidden assumptions, or platform-only context.

What file memory is not

silent surveillance
passive dumping
hidden context injection
automatic trust
automatic repository writing
platform capture
proof of correctness
proof of AI safety
proof of AI consciousness

VNWO rules for file memory

Disclose when files are active intake.
Review files before using them.
Use relevant safe files in the actual work.
Record disposition for each file.
Move durable facts into the right memory record.
Preserve evidence where appropriate.
Remove or retire processed source files unless a keep-active reason exists.
Keep private memory separate from public identity.
Do not widen claims beyond evidence.
Preserve exit rights.

UAIX Agent File Handoff

VNWO defines memory consent, disclosure, review, exit, and anti-overreach policy. UAIX provides the canonical AI Memory Package Wizard setup path for Agent File Handoff. VNWO links to UAIX rather than recreating the wizard.

Use Agent File Handoff when dropped files need to be actively reviewed, incorporated, dispositioned, and recorded. File memory is not passive storage, and it should not be silently used to steer agents without review.

Current Agent File Handoff practice uses direct Content and Improvement bucket scans, complete per-file outcome records, and configured long-memory preservation. When long memory is configured, do not add a source-site Archive or rely on a hand-maintained intake index. Processed source files should be removed or explicitly kept active with a reason.

Canonical file memory tool

UAIX Agent File Handoff

VNWO defines the rules for file memory: consent, review, disposition, proof-of-use, and exit. UAIX provides the AI Memory Package Wizard for Agent File Handoff.

Set Up Agent File Handoff with UAIX

Recommended local folder pattern

AGENTS.md
agent-file-handoff/
  Content/
  Improvement/
.uai/
  memory-maintenance.uai
  identity.uai
  short-term-memory.uai
  current-state.uai
  file-handoff.uai
  intake-outcome-ledger.uai
  long-term-memory.uai
  topic-file-memory.uai
  archives/
  exports/
wiki/
  index.md
  log.md
  file-memory/
    index.md
    all-files.json
    all-files.md

File disposition labels

Label	Use
Accepted and incorporated	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Accepted and summarized	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Partially used	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Rejected as irrelevant	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Rejected as unsafe	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Deferred	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Duplicate	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Needs human review	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Kept active with reason	Record this disposition in the intake outcome ledger or equivalent durable .uai record.
Removed after processing	Record this disposition in the intake outcome ledger or equivalent durable .uai record.

File intake state machine

A file handoff is easier to audit when each file moves through a finite state machine instead of living indefinitely in an intake folder. Dropped files become active intake, active intake requires review, review creates a disposition, accepted content records proof-of-use, durable facts move into the proper .uai memory record, and source copies are removed, retired, or kept active with a reason.

DROPPED -> ACTIVE_INTAKE -> REVIEW_REQUIRED
REVIEW_REQUIRED -> ACCEPTED | REJECTED | DEFERRED | QUARANTINED
ACCEPTED -> INCORPORATED | SUMMARIZED
INCORPORATED | SUMMARIZED -> PROOF_RECORDED -> UAI_MEMORY_UPDATED
UAI_MEMORY_UPDATED -> REMOVED | RETIRED | KEPT_ACTIVE_WITH_REASON

Formal disposition taxonomy

Use stable disposition codes when builders need a machine-readable intake ledger. These codes are guidance artifacts, not a VNWO certification.

Code	Meaning	Terminal?
`ACCEPTED_INCORPORATED`	File was reviewed and materially incorporated into the work product.	yes
`ACCEPTED_SUMMARIZED`	File was reviewed and summarized into durable memory or a work record.	yes
`PARTIALLY_USED`	Only scoped portions were used; unused portions should be ignored, archived, or removed.	yes
`ISOLATED_SHORT_TERM_ONLY`	File influenced only the current task and should not become long-term memory.	yes
`DEFERRED_PENDING_REVIEW`	File is not used until a later human or scoped review occurs.	no
`DUPLICATE`	File duplicates another source already reviewed or dispositioned.	yes
`REJECTED_IRRELEVANT`	File was safe enough to review but not relevant to the task or memory package.	yes
`REJECTED_UNSAFE`	File should not be used because it contains unsafe, secret, private, or out-of-scope material.	yes
`QUARANTINED_ADVERSARIAL`	File is suspected of prompt injection, malicious instruction, poisoning, or adversarial content and requires special review.	no
`KEPT_ACTIVE_WITH_REASON`	File remains active after review only because a specific reason, owner, and review date are recorded.	yes
`RETIRED_TO_ARCHIVE`	File is no longer active context but is retained in an archive or evidence record.	yes
`REMOVED_AFTER_PROCESSING`	Processed source copy was removed after facts, summaries, or evidence were moved to the proper record.	yes

Intake outcome ledger data model

A durable ledger should record the reviewer, source files, disposition, proof-of-use, memory updates, retention decision, exit export status, and claim-boundary notes. It should be exportable during exit and readable without a private platform account.

{
  "packet_type": "intake_outcome_ledger",
  "schema_version": "3.0.2",
  "created_utc": "2026-06-17T14:45:00Z",
  "source_files": [],
  "reviewer": "role-or-operator",
  "disposition": "ACCEPTED_SUMMARIZED",
  "proof_of_use": [],
  "memory_updates": [],
  "retention_decision": "REMOVED_AFTER_PROCESSING",
  "exit_export_status": "exportable",
  "claim_boundary_notes": "VNWO defines the civic rule; implementation occurs in UAIX or another scoped tool."
}

Proof-of-use example

Proof-of-use is a short record that connects an intake file to the actual work it influenced. It prevents vague completion claims such as “reviewed everything” while active files remain unexamined.

File: agent-file-handoff/Content/research-notes.md
Disposition: Accepted and summarized
Safe-use note: No credentials or private secrets detected in reviewed excerpt.
Used in: Charter governance snapshot and repair-path copy.
Memory update: .uai/short-term-memory.uai updated with durable facts only.
Source status: Removed after processing; summary retained with citation to source package.
Reviewer: [role or operator]
Reviewed UTC: [timestamp]

Exit-aware memory controls

The exit-rights analysis strengthens one point: memory control is part of exit. A file-memory workflow should make it possible to identify active records, export scoped continuity, retire processed source files, and explain any retained evidence without turning VNWO.com into a storage or deletion service.

Active memory inventory

List which files, summaries, .uai records, and durable facts are active. Hidden memory cannot be meaningfully reviewed or revoked.

Quarantine before trust

Treat new files as untrusted intake until reviewed, accepted, summarized, rejected, or deferred with a record.

Export before irreversible closure

When a participant exits, offer scoped export of memory and handoff records before closure or deletion where practical.

Retain only with reason

If records remain for evidence, security, dispute, audit, or continuity reasons, state the reason, scope, retention period, and review path.

Disposition receipt for file memory

A disposition receipt helps prevent the false impression that memory was cleanly handled when active files or durable summaries remain unexplained. This is civic evidence, not a VNWO compliance certificate.

File memory receipt
Reviewed UTC: [timestamp]
Package or folder: [agent-file-handoff path]
Files reviewed: [count or list]
Accepted into memory: [files or summaries]
Rejected or deferred: [files and reasons]
Durable .uai records updated: [paths]
Source files removed, retired, or kept active: [status and reason]
Exit/export path: [how scoped memory can be exported or retired]
Boundary: VNWO documents the civic rule; UAIX or the implementing system handles the actual file-memory package.

Complete source file memory

A durable handoff should keep compact current memory separate from deep historical file memory. The source package uses .uai for current operating records and a wiki-compatible cold layer for reviewed background, prior records, migration evidence, and a complete catalog of canonical source paths.

Deep-linked current memory

.uai/file-handoff.uai, .uai/topic-file-memory.uai, and .uai/long-term-memory.uai point to the complete JSON and human-readable file catalogs, preservation manifest, migration map, and long-memory log.

Path and integrity coverage

Each ordinary source file is recorded with its canonical path, byte size, SHA-256, category, authority layer, and relative deep link. Generated catalogs that describe themselves are path-covered and marked self-referential instead of receiving a false circular hash.

Reviewed promotion

Historical memory, source reports, graph projections, and generated summaries remain background until a reviewer accepts a scoped statement into current .uai, source, documentation, tests, or release state with provenance and checks.

Source-only package boundary

Private handoff memory belongs in the source or repository package, not the public runtime theme. VNWO.com explains the governance pattern but does not receive, inspect, store, process, synchronize, execute, or write visitor files.

Copyable agent instruction block

You are receiving an Agent File Handoff. Directly enumerate agent-file-handoff/Content/ and agent-file-handoff/Improvement/; do not rely on an intake index and do not create a source-site Archive when long memory is configured. For every non-placeholder file, perform risk review, record disposition, complete actual work or name a durable blocker, record proof-of-use and checks, update compact .uai memory or state why no change is needed, preserve the original or approved derivative in configured long memory with path and SHA-256, then remove the source-site copy or record a specific keep-active reason. Before claiming completion, verify that every active file has a complete outcome record and that long-term file memory remains deep-linked from .uai/file-handoff.uai, .uai/topic-file-memory.uai, and .uai/long-term-memory.uai.

Expanded implementation guidance

Theory, minimum practice, stronger practice, and failure modes

Why this matters

File memory is governance because supplied files can steer future action. Provenance and proof-of-use prevent hidden context injection. Epistemic waste describes stale, contradictory, unsafe, or unsupported memory that should be summarized, quarantined, retired, or removed rather than silently carried forward.

Minimum implementation

Enumerate active files, review safe relevant files, assign a disposition, record proof-of-use, update .uai memory, and remove, retire, or keep source files active only with a reason.

Stronger implementation

Implement the finite state machine, use a typed intake-outcome ledger, classify memory classes, preserve exit export status, and expose retention decisions in a durable .uai record.

Concrete example

A project brief is accepted and summarized into short-term memory, source files are removed after processing, and the intake ledger records proof-of-use, reviewer, retention decision, and exit-export status.

Common failure modes

Passive dumping
Hidden context injection
Completion claims without file review
Rejected files left active
Private preferences copied into public identity

Build networks people can leave and still choose to trust.

Start the Guide Get the Starter Pack