Operating Model

How KLMS runs day to day. Owner: Operations (Process Engineer). Foundational doc; complements hr/policies/operating-cadence.md (the cadence policy, owned by HR) — this describes the model, not the binding cadence rule.

Session lifecycle

flowchart LR
  O["Session open<br/>canon review · integrity · briefing"] --> W["Work<br/>units execute"]
  W --> C["Session close<br/>report · capture · archive"]
  C -.->|next day| O
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class O,W,C s

Text fallback: each session opens (review the canon, verify archive integrity, write the briefing), the units do the work, and the session closes (day’s report, capture decisions per GR-6, archive). Repeat the next day.

The operating layer

Automation / hooks: .claude/hooks/ (SessionStart, SessionEnd — the latter runs scripts/archive-manifest.sh verify).
Pipeline / CI: .github/workflows/ (e.g. daily reports; gated on secrets).
Integrity & records: the manifest script + the Archives keep the record true.
Integrations: Notion (reports/registry, read-only sync), GitHub (the Archivist is tooled — ADR-0007). New integrations follow the Access Request SOP (SOP-001).

Runbooks (SOPs)

SOP	Purpose
SOP-001	Access request & approval
SOP-002	Document change management
SOP-003	Deploy the intranet (Vercel)

New runbooks land under docs/sop/ using the SOP template; each may spawn a job aid.

Operating rhythm

When	What	Owner
Session open	canon review · integrity check · briefing	PA / Archivist
Continuous	unit work; Directors coordinate	all units
Session close	day’s report · decision capture · archive	PA / Golden Rule / Archivist
Per change	change management (SOP-002)	Operations + owners
Per session	batch pushes — promote to `main` once, not per commit (deploy budget, ADR-0009)	all