---
name: Notes operating guide
version: 0.3.0
status: active
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---


# Notes operating guide


## Purpose


Notes is Arco's private personal working-memory module. It preserves unfinished observations, thoughts and follow-ups that need to persist and evolve without becoming organisational truth merely because they were captured.


Notes follows [arco-module-manual.md](https://drive.google.com/file/d/1X3uzbh2_7cu_ZJGCwpcLSVyWihXHQxgZ/view) for the universal module contract and [arco-system-manual.md](https://drive.google.com/file/d/1doS7QXRtShzT45wHC13Vx0zxputK50l-/view) for maintained-file rules.


## Module contract


- **Boundary** — private personal working memory. Notes does not own raw transcript processing, authoritative organisational facts, durable decisions, repeatable Skills, formal task management or Arco Development.
- **Outputs** — bounded Note records plus unresolved/resolved Note index state.
- **Dependencies** — Context for entity relationships; destination owners for promoted material; Governance where promotion crosses into shared or authoritative state; Daily Scan may process configured intake but does not own Notes.
- **Access scope** — personal/private by default.
- **Lifecycle state** — **Early**, as recorded in [arco-modules.md](https://drive.google.com/file/d/1GcMnF4pLmxIhPRUlrPalmdAjjTkWUOX1/view).


## Governance and local requirements

The permissionable resources are the personal Notes records, indexes and views; actions include read/use, capture/update, lifecycle changes and promotion. Local configuration must resolve private storage, the owner and any required permission mappings before shared or cross-owner actions occur. Missing authority is not permission to share. Universal module controls and maintenance behaviour are inherited from the Module Manual and System Manual; local configuration owns selected values. Promotion consumes the destination owner’s permissions, approval or verification rules.

## Privacy


Privacy is intrinsic to Notes. In an organisational deployment, Notes content belongs in the individual user's provider-native private workspace rather than a shared organisational Notes repository.


A Note does not become public, shared or authoritative merely because it exists. Deliberate promotion is the boundary at which material may enter Context, Decisions, Development, Tasks or another owner. The destination owner's Governance and lifecycle then apply.


## Identity and lifecycle


Each durable Note receives a stable sequential identifier within its Notes runtime:


`NOT-###`


Refine the same Note while its central thought remains materially the same. When that thought materially changes, create a new Note and resolve the earlier one as `superseded`, linking the replacement.


Working states are:


- `active` — useful current working memory;
- `parked` — deliberately retained but not currently being progressed;
- `promoted` — handed to a more authoritative owner;
- `superseded` — replaced by a materially newer Note;
- `dropped` — no longer being pursued.


Active and parked Notes remain on the normal working path. Promoted, superseded and dropped Notes move to resolved history.


## Runtime structure


A Notes runtime maintains:


```text
notes-unresolved-register
notes-resolved-register
records/
    unresolved/
    resolved/
```


Registers follow the System Manual: UTF-8 CSV unless a documented approved exception exists. The deployed environment chooses provider-native Note/intake file formats and exact private locations through `readme-notes-local.md`. Core does not hard-code those paths.


The unresolved Register is the normal read path. Resolved history is consulted only when provenance, supersession or older reasoning materially matters.


Each Note record should preserve only the thought, state, materially relevant Context relationships, provenance and lightweight follow-up needed to keep the working memory useful. Notes records are working artifacts rather than versioned operating instructions.


## Capture and intake


Capture should be low friction. The deployment/user may use its normal provider-native word processor or another deliberately configured intake surface. Rough intake is chronological source material awaiting processing; it is not itself the durable Notes Register.


Provider-specific intake and processing configuration belongs locally. Daily Scan may process configured Notes intake, but raw transcript/source preparation does not become part of Notes merely because it feeds Notes.


### Preserve uncertainty when cleaning


Notes are intentionally non-definitive working material. Cleaning may remove verbal clutter, repetition and transcription noise, and may improve readability, but it must preserve the original level of certainty.


Do not turn exploratory language into settled language. In particular, do not silently convert thoughts such as `perhaps`, `I think`, `could`, `maybe`, questions, hypotheses or discussion points into `should`, `must`, requirements, decisions or established facts.


A cleaned Note should remain recognisably the same thought with its uncertainty, caveats, conjecture and open questions intact. If a Note later becomes sufficiently settled to belong in Context, Decisions, Development or another authoritative owner, use the normal promotion boundary rather than making the Note itself more definitive.


## Retrieval


Retrieve the **smallest useful context set, not the smallest possible context set**.


A normal recall should start from the unresolved Register, open only likely relevant current Notes, follow materially relevant Context or owner relationships, consult resolved Notes when history matters, and widen only as required.


Do not scan all Notes by default, but do not omit materially relevant linked information merely to preserve an artificial retrieval bound.


## Promotion


Promotion is a handoff, not duplication. When Note material becomes durable shared state, the destination owner determines what it becomes and who can access it. Notes retains only the minimum traceability needed to show what happened and must not maintain a competing authoritative copy.


## Local views


A deployment may create live views by client, project, person or topic when useful. These are projections/interfaces over Note IDs and relationships, not competing historical stores. Core does not require them.



## Canonical references

[arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view).

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 0.3.0 | Restored CSV Register inheritance and made existing local/Governance requirements explicit. | Stoirm Arnold — Defrag invocation | Codex Work |
| 26-Sep-2026 | 0.2.0 | Required Notes cleaning to preserve uncertainty, caveats, conjecture and open-ended framing rather than converting working thoughts into decisions or requirements. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 25-Sep-2026 | 0.1.0 | Promoted the proven Notes boundary into Early Core: private personal working memory, stable NOT identity, active/resolved lifecycle, bounded retrieval and deliberate promotion into authoritative owners. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
