Memory Asset Audit: A 30-Minute Template

A memory asset is a durable piece of context that makes future work better.

It is not a note. A note is an artifact. A memory asset is operational. It changes how an agent or a human approaches the next task.

A memory asset can be:

• a decision log
• a preference rule
• a source judgment
• an editorial standard
• a project history
• a customer insight
• a failure that became a constraint
• a recurring lesson
• an operating principle

The problem is that most knowledge systems contain many notes and few memory assets. The notes sit in folders. They get searched occasionally. They do not actively improve future work.

This blueprint gives you a 30-minute audit that converts passive notes into operational memory assets.

When to run the audit

Run it when any of the following is true:

• your agents keep asking for the same context
• your projects have rich discussion but weak retrievable context
• your notes feel voluminous but operationally empty
• new agents or collaborators cannot get up to speed without your verbal explanation
• decisions are repeated because the previous one is not findable

The 30-minute structure

The audit has six steps. Each step has a fixed time budget.

00:00-05:00  Step 1. Inventory the notes
05:00-10:00  Step 2. Classify each note
10:00-15:00  Step 3. Promote notes to memory assets
15:00-20:00  Step 4. Extract reusable rules
20:00-25:00  Step 5. Define new file types
25:00-30:00  Step 6. Update the Cognitive OS

Step 1. Inventory the notes (5 minutes)

Pick a single source of notes. It can be:

• an Obsidian vault
• a Notion database
• a folder of Markdown files
• a notes app
• a chat history
• a shared wiki

Do not attempt to audit everything. Pick the one source that would help agents the most.

Then list the last 30 entries. You can do this by date, by project, or by topic. The goal is to see a manageable slice, not the entire archive.

If the source has fewer than 30 entries, audit the entire source.

Step 2. Classify each note (5 minutes)

For each note, mark it as one of four types.

The classification is the most important step. It separates operational context from passive archive.

Step 3. Promote notes to memory assets (5 minutes)

For each note marked asset-ready or hidden asset, do the following:

• extract the reusable part into a short, plain sentence
• assign a name that is searchable
• place it in the right file

The right file is whichever file the future agent would read first. Common target files:

• decisions.md
• preferences.md
• lessons.md
• standards.md
• sources.md
• project/<name>/decisions.md

A memory asset should be small enough to read in 10 seconds and specific enough to change behavior.

Step 4. Extract reusable rules (5 minutes)

Look across the promoted assets for patterns.

Examples of reusable rules:

• “Always include a primary source link in published summaries.”
• “Prefer internal evidence over external claims in product memos.”
• “Escalate to a human before changing pricing or wording of a refund policy.”
• “Do not publish claims about another person without explicit approval.”

A reusable rule has three parts:

1. a clear behavior
2. a reason it matters
3. the situation where it applies

If a rule has only behavior, it is brittle. If it has only reason, it is ungrounded. The situation is what makes the rule operational.

Step 5. Define new file types (5 minutes)

Often the audit reveals context that does not fit any existing file. Define a new file type if the context would otherwise be lost.

Examples of new file types the audit may force:

• editorial-voice.md
• refund-policy.md
• vendor-checks.md
• data-sources.md
• tool-permissions.md
• tone-rules.md

The new file should have a one-line purpose statement, a list of what belongs in it, and a list of what does not.

Step 6. Update the Cognitive OS (5 minutes)

End the audit by making the changes visible.

• update the Cognitive OS file structure if a new file was created
• update the Start Here reading path if the audit changes onboarding
• update the operating standards if a new rule was extracted
• add a brief note to the operating log so future audits can compare

The point of the audit is not to produce a list. The point is to leave the system in a better state than it was before the audit.

Copyable audit checklist

Use this during a real audit.

# Memory Asset Audit

Date:
Source audited:
Notes reviewed:

## Step 1. Inventory

- Total notes reviewed:
- Date range:
- Source URL or path:

## Step 2. Classification

- asset-ready:
- reference:
- ephemeral:
- hidden asset:

## Step 3. Promoted assets

- asset name -> file
- asset name -> file
- asset name -> file

## Step 4. New reusable rules

- Rule: [behavior] because [reason] in [situation]
- Rule: [behavior] because [reason] in [situation]
- Rule: [behavior] because [reason] in [situation]

## Step 5. New file types

- file name: purpose
- file name: purpose

## Step 6. System updates

- Start Here updated:
- Operating standards updated:
- File structure updated:
- Operating log note added:

Anti-patterns to avoid

These are the common ways a memory audit fails.

• Auditing everything at once. The audit should be sliced. Pick a single source, a single project, or a single date range.
• Producing a list of notes without classification. Classification is what turns notes into assets.
• Writing long memory assets. If an asset needs more than 10 seconds to read, it will not be reused.
• Skipping rule extraction. Reusable rules are how memory assets become operational across projects.
• Skipping the system update. If the audit does not change the file structure, the audit was a reading exercise.

Operating principle

The point of a memory asset is not to remember more. The point is to remember the right things in a way that improves future work.

A note remembers. A memory asset compounds.

Download the memory asset audit checklist (.md)