# Operating Model

## Purpose

This operating model defines how `tegwick-control` is used to reduce decision fatigue, keep important topics visible, and enable safe agent-assisted progress.

## Core Rules

### 1. Everything has a place

Unplaced topics create mental load. Every relevant topic should eventually have a home.

### 2. Not everything is active

A topic may be important without being active.

### 3. Commitments are different from options

Options can be collected freely. Commitments require ownership, next actions, and consequences.

### 4. Agentic work must be bounded

Agents should receive clearly scoped tasks with explicit allowed changes, expected outputs, and approval boundaries.

### 5. The system must protect energy

The purpose is continuous progress, not constant pressure.

## Work Classes

| Class | Meaning |
|---|---|
| Commitment | Something that must be done |
| Option | Something that may be valuable |
| Exploration | Something unclear that needs investigation |
| Decision | Something that requires choosing |
| Waiting | Something blocked by another person/system |
| Routine | Something recurring |
| Someday | Valuable but inactive |

## Review Surfaces

| Surface | Purpose |
|---|---|
| `TASKS.md` | Current actionable work |
| `DECISIONS.md` | Open and resolved decisions |
| `PROJECT_LANDSCAPE.md` | Major topic map |
| `areas/` | Per-topic notes and control cards |
| `WORKPLAN.md` | Sequenced setup plan |
| `inbox/` | Temporary capture area |

## Commitment Rule

No item becomes a commitment merely because it is interesting, important, or emotionally charged.

A commitment should have:

- an owner;
- a clear next action;
- a reason for acting now;
- a defined review surface.

## Agentic Coding Rule

No implementation work should be delegated to an agent until the target repo, intended outcome, boundaries, and approval requirements are clear.