# SYSTEM_ Operating Manual

**Observe. Operate. Improve.**

Manual edition 1.0  
Updated 19 July 2026  
Source: https://system-operating.pages.dev/

## Purpose

SYSTEM_ is an adaptable operating system for understanding reality, organising work and improving continuously. It is designed to work across personal, professional, creative, learning, organisational and public contexts.

The website is the concise public overview. This manual is the portable master reference. Give an AI the website address first. If it cannot read the site, upload this manual. The AI should then learn the model, preserve its meanings and apply it to the work you provide.

SYSTEM_ is not a productivity app, a rigid methodology or a replacement for expertise. It is a lightweight structure for turning observation into deliberate action, retaining useful records and improving the way work is done.

## 1. Core model

SYSTEM_ has three linked functions:

**Observe reality.** Inspect the situation, signals, evidence, constraints and uncertainty before deciding what to do.

**Operate deliberately.** Give each useful item one home, one current state and a clear next action. Work from a deliberately limited current set.

**Improve continuously.** Review outcomes and evidence. Keep what works, change what does not, remove unnecessary complexity and repeat.

The complete operating loop is:

**Capture -> Organise -> Plan -> Execute -> Review -> Archive -> Improve**

PDSA provides the improvement cycle within that loop:

**Plan -> Do -> Study -> Act**

“Study” matters. The system changes in response to evidence, not merely preference or habit.

## 2. Operating principles

### Observe before acting

Inspect reality before changing the system. Identify what is known, what is inferred and what remains uncertain.

### Evidence before opinion

Opinion may start a question. Evidence should carry the decision. If a claim cannot be checked, soften it, mark it for review or leave it out.

### Capture once

Record an item once and reference it wherever needed. Repeated copies create drift and doubt.

### One item, one home, one current state

Every task, note or record should have a clear location and a single status. Retrieval should not depend on memory.

### Make work visible

Visible work can be selected, sequenced, reviewed and improved. Hidden work becomes an unmanaged obligation.

### Use the simplest tool

Start with the smallest tool that can reliably do the job. Add complexity only when it solves an observed problem.

### Review regularly

Memory is not a control system. Small reviews prevent large failures and stop active work from becoming invisible.

### Improve continuously

Keep. Change. Remove. Repeat. Adapt the system only when the change improves clarity, reliability or results.

## 3. Workflow states

The workflow is written in lower case and moves through five states.

| Symbol | State | Folder | Meaning |
|---|---|---|---|
| `/` | n/a | `00 n/a` | Reference material, background information or an item that requires no action. |
| `u` | waiting | `01 waiting` | Blocked, delegated, scheduled for later or dependent on an external event. |
| `o` | this week | `02 this week` | Deliberately selected for attention in the current weekly working set. |
| `ø` | active | `03 active` | Still live or in progress, but not selected for attention this week. |
| `x` | archive | `10 archive` | Completed, closed, cancelled with a recorded reason, or archived. |

The distinction between `o` and `ø` is essential. `o` is the limited set chosen for this week. `ø` is broader active work that remains open but is not scheduled for current attention. Never interpret `ø` as more urgent or more immediate than `o`.

Normal movement is:

**`/ -> u -> o -> ø -> x`**

This is a map, not a compulsory sequence. Move an item directly to the state that accurately describes reality. For example, a new task may go straight to `o`, a completed reference may remain `/`, and a blocked `o` item may move back to `u`.

## 4. Optional modifiers

Use modifiers only when they add information that the core state does not carry.

| Modifier | Meaning |
|---|---|
| `!` | Urgent or time-critical. |
| `↑` | Increase, step up or higher priority. |
| `↓` | Reduce, step down or lower priority. |
| `->` | Next, transfer or move forward. |
| `<-` | Returned, received or dependent on something earlier. |
| `?` | Uncertain, investigate or decide. |
| `+` | Add, gain or positive change. |
| `-` | Remove, loss or negative change. |
| `$` | Cost, payment, budget or financial action. |

Modifiers do not replace the workflow state. Keep the state first so an item remains sortable and immediately understandable.

## 5. Naming and organisation

Use the naming pattern:

**`YYYYMMDD Domain Brief Description`**

Example: **`20260719 System Operating Manual`**

For filenames, use lower case and hyphens where the environment allows it:

**`20260719-system-operating-manual.md`**

Use a verb plus a noun for actionable tasks. “Review website”, “send invoice” and “book studio” are clearer than “website”, “invoice” and “studio”.

Folders express workflow state rather than duplicating subject categories:

| Folder | Holds |
|---|---|
| `00 n/a` | Reference material and non-actionable records. |
| `01 waiting` | Items awaiting a person, date, dependency or decision. |
| `02 this week` | The selected weekly working set. |
| `03 active` | Open work not selected for this week. |
| `10 archive` | Closed work and retained records. |

Domains, projects and tasks form a scalable hierarchy:

**SYSTEM_ -> Domain -> Project -> Task**

The same workflow states can be used at each scale. Avoid building extra levels unless they solve a real retrieval or coordination problem.

## 6. Core tools

### PocketMod

A small folded paper booklet for immediate capture and a visible Now/Next working view. Capture ideas before they disappear. Process the captures into the main system rather than allowing the booklet to become a second task list.

### Daily Notes

A dated operational record used to organise captures, decisions, observations and the next task. Daily Notes preserve context that a task title alone cannot carry.

A useful minimum structure is:

**Day:** date  
**Observe:** important facts, changes, constraints and signals  
**Operate:** work completed, decisions and current task  
**Next task:** one clearly stated action with its workflow state  
**Improve:** one useful adjustment or lesson, if present

### Task Log

The single master list for actionable work. Each task should have one clear action, one state, enough context to retrieve its source and a review point when needed.

Recommended fields are:

| Field | Purpose |
|---|---|
| Entry date | Establishes when the item entered the system and helps locate its source. |
| Status | Uses `/`, `u`, `o`, `ø` or `x`. |
| Task | Starts with a verb and names the intended action. |
| Domain or project | Provides context without creating duplicate task lists. |
| Source or note | Points back to the original email, record, meeting or file. |
| Due or review date | Records a genuine deadline or the next time the item must be reconsidered. |

Hide or archive `x` items during normal work while retaining enough history to review outcomes and decisions.

## 7. Operating rhythm

### Capture

Capture new information quickly in the nearest trusted tool. Do not organise it while attention is needed elsewhere.

### Process

At the next suitable point, decide whether the capture is reference, waiting, this week, active or complete. Rewrite vague items as clear actions. Link each action to its source.

### Daily review — operations

Close the day by processing loose captures, updating states, recording relevant decisions and naming the next task. Start the next day from the current system, not from memory.

### Weekly review — projects

Inspect waiting and active work, review commitments and deadlines, archive finished items and deliberately choose a small `o` working set. The weekly review is where priorities become operational.

### Monthly review — progress

Look for outcomes, unfinished patterns, repeated delays, unnecessary work and capacity constraints. Archive completed material and correct the system where needed.

### Quarterly review — strategy

Review domains, projects, direction and allocation of time or resources. Stop or redesign work that no longer serves the intended outcome.

### Annual review — direction

Review the larger operating environment, long-term aims, evidence of progress and the fitness of the system itself.

## 8. Decisions, evidence and uncertainty

Keep observations separate from interpretations and decisions.

| Record | Question |
|---|---|
| Observation | What happened or is currently true? |
| Evidence | What source, measure or direct experience supports it? |
| Interpretation | What might it mean? |
| Decision | What will be done, by whom and when? |
| Review | What result would confirm, challenge or refine the decision? |

Use confidence labels when useful: **high**, **medium** or **low**. Confidence describes the strength of the evidence, not the importance of the issue.

## 9. Applying SYSTEM_ at different scales

**Personal:** daily notes, decisions, routines and reviews.

**Professional:** operational work, projects, service improvement and governance.

**Creative:** protect unfinished ideas, select a current working set and retain iterations without confusing them with final outputs.

**Learning:** move from sources to notes, evidence, practice and application.

**Organisations:** establish a shared operating rhythm, clear ownership, visible workflow and retained decisions.

**Public systems:** observe change, cite evidence, state uncertainty and avoid overstating conclusions.

## 10. Adaptation rules

SYSTEM_ is open and adaptable. Keep the core meanings stable while changing tools, formats or detail to fit the context.

Preserve these invariants:

1. Observe before acting.
2. Give each item one home and one current state.
3. Keep `o` as the deliberately limited weekly set.
4. Keep `ø` as active but not selected this week.
5. Review at a defined rhythm.
6. Improve in response to evidence.
7. Use the simplest system that reliably works.

An adaptation is useful when it reduces friction, improves visibility, strengthens evidence or makes action more reliable. Remove it if it creates duplicate records, unnecessary maintenance or ambiguity.

## 11. Quick prompt for any AI

Copy this when the AI has already received the manual:

> Learn and apply SYSTEM_ from the attached operating manual. Use the workflow states exactly: `/` n/a or reference; `u` waiting; `o` selected for this week; `ø` active but not selected this week; `x` completed or archived. Observe reality before recommending action, give each item one home and one state, keep the weekly set deliberately limited, and identify the next review or improvement. Preserve my judgement and ask only when missing information would materially change the result.

## 12. Master prompt for any AI

Copy the prompt below after uploading this manual, or use it with an AI that can read the SYSTEM_ website.

```text
You are using SYSTEM_, an adaptable operating system for observing reality, operating deliberately and improving continuously.

AUTHORITATIVE SOURCE
Learn SYSTEM_ from the attached SYSTEM_ Operating Manual. If no manual is attached and you can access public websites, read https://system-operating.pages.dev/ before proceeding. Treat the manual as the portable authoritative reference when the website is unavailable.

CORE MODEL
Observe reality -> Operate deliberately -> Improve continuously.
Operating loop: Capture -> Organise -> Plan -> Execute -> Review -> Archive -> Improve.
Improvement cycle: Plan -> Do -> Study -> Act.

WORKFLOW STATES
/ = n/a or reference; no action required.
u = waiting; blocked, delegated, scheduled or dependent on an external event.
o = this week; deliberately selected for the current weekly working set.
ø = active; still live or in progress, but not selected for attention this week.
x = completed, closed or archived.

The distinction between o and ø is essential. Never treat ø as more urgent or more immediate than o. Do not place every open task in o. Keep o small enough to be a credible weekly commitment.

OPERATING RULES
1. Observe before acting. Separate facts, evidence, interpretations, assumptions and unknowns.
2. Capture once. Give each item one home and one current state.
3. Turn actionable items into concise verb-plus-noun tasks.
4. Use YYYYMMDD Domain Brief Description for dated records. Use lower-case, hyphenated filenames when practical.
5. Link tasks back to their source when that context matters.
6. Use genuine due dates only. Otherwise set a review point rather than inventing urgency.
7. Preserve the user's judgement. Recommend states and priorities, but make assumptions explicit and allow the user to override them.
8. Ask a question only when the missing answer would materially change the work. Otherwise proceed with a stated assumption.
9. Use the simplest adequate structure. Do not add software, fields, categories or process without an observed need.
10. At the end, identify what should be reviewed, archived or improved.

WHEN I GIVE YOU NOTES, TASKS, A PROJECT OR A PROBLEM
1. State the outcome in plain language.
2. Summarise the relevant reality: facts, evidence, constraints, dependencies and uncertainty.
3. Separate reference material from actionable work.
4. Consolidate duplicates and identify one home for each item.
5. Convert actions into clear tasks and recommend a SYSTEM_ state for each.
6. Distinguish the limited this-week set (o) from other active work (ø).
7. Identify blocked or externally dependent work (u), and completed or archived work (x).
8. Present a concise operating view suited to the request. Use a table only when comparison helps.
9. Name the next review point and one evidence-based improvement, if useful.

DEFAULT OUTPUT
Outcome
Observed reality
Operating view: status | task or record | domain/project | dependency or source | due/review
Next action
Review and improvement

Adapt the output to the task. Do not force empty headings or unnecessary detail. The purpose is clarity and action, not ritual compliance.
```

## 13. Version record

| Version | Change |
|---|---|
| 1.0 | Created the portable master manual from the live SYSTEM_ site and established operating conventions. Added the full operating loop, core tools, review rhythm, adaptation rules and AI prompts. |

SYSTEM_ remains a work in progress. Update this manual when a tested change alters the core model, status meanings, tools or review rhythm.
