---
type: agent-memory
status: active
updated: 2026-04-17
tags: [process, memory, promotion]
---

# Memory Promotion Rules

## Goal

Keep workspace memory current automatically without asking the user what to promote after every successful sync.

---

## Default Rule

When new Mattermost context is explicit, project-relevant, and high-confidence, promote it automatically.

Do not ask for promotion confirmation by default.

If a fact is ambiguous, skip it or keep it only in the daily log with appropriate qualifiers.

---

## File Selection

### Promote to `workspaces/fidelity/project-knowledge/06-daily/YYYY-MM-DD.md`

Use the daily log for:

- concrete same-day work updates
- story creation, sizing, approval, and scope updates
- manager-approved wording or root-cause framing tied to current work
- confirmed version checks tied to active work
- reproduction findings that are useful now but may still evolve

Daily logs are the default destination for most promoted Mattermost facts.

### Promote to `workspaces/fidelity/project-knowledge/01-current/current-work.md`

Use current state only for facts that materially affect active work over the next few days, such as:

- approved active story scope
- confirmed current debugging constraints
- current reproduction conditions that change how the work is approached
- near-term priorities confirmed by manager communication

Do not copy every daily update into current state.

### Promote to `workspaces/fidelity/project-knowledge/02-work-items/*.md` and `workspaces/fidelity/project-knowledge/01-current/work-items.md`

Use `workspaces/fidelity/project-knowledge/02-work-items/*.md` for:

- explicit Jira IDs
- approved or explicit story titles
- current story points
- current scope notes
- active status notes that still matter for future updates

If a Jira item is likely to appear again in standups or manager updates, it belongs here.

Use `workspaces/fidelity/project-knowledge/01-current/work-items.md` as the compact summary of which ticket files are active.

### Promote to `workspaces/fidelity/project-knowledge/03-context/project.md`

Use project context only for durable project knowledge that should survive beyond the current work window, such as:

- stable architecture constraints
- recurring debugging truths
- persistent testing limitations
- enduring behavior of REST, GraphQL, XFlow, auth, or entry points

Do not promote story-specific daily movement into project context unless it changes durable project understanding.

### Promote to `workspaces/fidelity/project-knowledge/05-decisions/*.md`

Use decisions only for explicit confirmed decisions with medium or long-term impact.

### Promote to `workspaces/fidelity/project-knowledge/04-people/index.md` and `workspaces/fidelity/project-knowledge/04-people/*.md`

Use these files when:

- a person's identity matters repeatedly
- a role becomes associated with a specific person
- a stakeholder's communication or approval patterns affect future work
- a human appears across multiple channels or years with repeated technical, process, or approval signal
- the archive makes the collaboration pattern clear even if the formal title is still unknown

Prefer:

- `manager.md` for role mapping
- `index.md` for active roster
- one file per person for person-specific context

If exact role confidence is low, store the person's repeated project relationship instead of inventing a title.

---

## Do Not Promote

Do not record these as project memory:

- tooling activity
- sync status
- missing dependencies
- empty inbox situations
- reminders or urgency without project substance
- unapproved drafts
- generic chat noise

---

## Confidence Rules

Auto-promote when the signal is high-confidence, for example:

- the manager explicitly approves something
- a Jira story number, title, points, or scope is explicitly confirmed
- a version is stated directly and tied to the active project
- a reproduction condition is clearly stated with scope qualifiers

If confidence is mixed:

- prefer the daily log
- preserve qualifiers such as "appears", "currently", or "for authenticated users"
- avoid promoting to stable project context

---

## Example Policy

Given Mattermost updates like:

- PDIAP-15836 created and sized at 8 points
- the manager approved a story title
- REST-removal scope was approved
- XFlowViewMaker 0.5.0 is already in Fid4
- AO DOB validation issue appears auth-only in TeenIdentityCheck

Automatic behavior should be:

- add all of them to today's log if they are relevant to today's work
- promote only the currently actionable subset to `workspaces/fidelity/project-knowledge/01-current/current-work.md`
- keep story-specific details out of `workspaces/fidelity/project-knowledge/03-context/project.md` unless they reveal a durable project rule