work-state: The Pattern Turns Inward
April 30, 2026work-statepersonal-intelligencepatternscsiwyglongitudinal-intelligencememeticsbuilding-in-public
# work-state: The Pattern Turns Inward
The state pattern has now been recast three times. project-state runs a project. dot Emporium runs a storefront. The newest variant runs a person.
`work-state` is what happens when the substrate stops watching a project and starts watching the person doing the work.
## What changes when the unit becomes a person
project-state was designed for a known, bounded entity: a multi-stakeholder project with funders, milestones, deliverables, and a defined end. The state belongs to the project. Multiple humans contribute to it. The reporting goes outward — to Steering Committees, funders, partners.
dot Emporium reframed the same skeleton around a storefront. The state belongs to the inventory. Items move through phases. The reporting goes outward to buyers.
work-state changes the unit again. The state belongs to one person. The events being captured aren't milestones, they aren't items — they're the person's actual outputs across every surface the work happens on. Commits. Posts. Emails sent. Slack messages. Doc edits. Shares. Decisions. Things that were learned.
The reporting goes inward. There is no funder. There is no buyer. The audience for a work-state report is the person whose work it represents.
That single change — outputs flowing inward instead of outward — turns the same architecture into a different category of tool.
## The four-layer model
```
┌──────────────────────────────────────────────────────────────┐
│ Intelligence ← themes, planner, dashboard, longitudinal │
│ weekly/, longitudinal/ │
├──────────────────────────────────────────────────────────────┤
│ Reports ← daily-digest, weekly-report │
│ daily/, weekly/ │
├──────────────────────────────────────────────────────────────┤
│ Measurement ← metrics, project balance, velocity │
│ daily/*.json, longitudinal/*.json │
├──────────────────────────────────────────────────────────────┤
│ Evidence ← harvesters, one per surface │
│ events/YYYY-MM-DD/*.json + .jsonl │
└──────────────────────────────────────────────────────────────┘
```
Each layer reads from the layer below it. The Evidence layer is immutable. Everything above is regenerable. Delete `weekly/` and the weekly reports rebuild from `daily/` and `events/`. Delete `longitudinal/` and it reconstitutes from the same source.
This is the same substrate idea as project-state — flat files, append-only logs, atomic writes, deterministic ids — applied to a different unit. The schema differs. The skills differ. The lock discipline is identical.
## Surfaces and harvesters
Work doesn't happen in one place. It happens in seven, on a typical day:
| Surface | Captured |
| ------------- | ---------------------------------------------- |
| GitHub | commits, releases, branch creates, PRs |
| scsiwyg | published posts, drafts |
| Gmail | messages sent, filtered inbound, threads |
| Slack | messages, DMs, mentions, reactions |
| Google Docs | edit sessions, shares, link-share publications |
| X | posts (manual export — API is paid) |
| LinkedIn | posts (manual export — API is restricted) |
Each surface has a harvester. Harvesters are skills that know how to talk to one source, normalize what they pull into a canonical event envelope, deduplicate by deterministic id, and write through the foundation skill. They are isolated. They share no state with each other. The github harvester knows nothing about gmail. The gmail harvester knows nothing about slack.
What they share is the envelope:
```yaml
id: github-build-2026-04-29-a3f9c1
surface: github
type: build # build | publish | share | draft | receive | decide | learn
timestamp: 2026-04-29T14:23:51Z
project: scsiwyg # attributed to a portfolio project, or "unsorted"
themes: [] # memetic tags — enriched downstream
evidence: { ... } # surface-specific structured proof
metrics: { ... } # numeric measures
raw: { ... } # full untruncated source payload
ingested_at: 2026-04-30T06:00:14Z
harvester_version: 1.0.0
```
Seven event types cover everything the surfaces produce. `build`, `publish`, `share`, `draft` are the act-on-the-world types. `receive` captures inbound signal. `decide` and `learn` are the rare, high-value events that don't auto-detect well — they get logged explicitly, by hand or by another skill noticing.
## Why per-event, why granular
The first design decision was the unit of record. The choices were per-event (one file per atomic thing), per-day-per-surface (one rolled-up file per source per day), or per-day unified (one file with everything). Per-event won.
The reason: you can always roll up. You can never recover detail you didn't capture.
A per-event file is small, immutable, and self-describing. A daily JSONL index sits next to the per-event files for fast scanning. The system writes both: events as files, plus an append-only index. If the index is lost, it rebuilds from the files. If a file is corrupted, the index still tells you what should be there.
This is the same write discipline project-state uses for entity files plus an activity log — applied to a higher-volume problem. A typical day produces tens to hundreds of events. The per-event-file model handles that without introducing a database.
## Memetics and themes
The interesting work isn't capturing events. It's noticing what they're about.
Every event has a `themes` array. The harvesters leave it empty. A separate skill walks the corpus and attributes themes — recurring tags that mark what the work has been *about*, not just what it produced.
Themes are bootstrapped from a list in the manifest:
```
sovereignty
bare-metal
canadian-data-residency
agent-orchestration
skills-architecture
documentation-driven
methodology-as-infrastructure
observable-reasoning
simulate-before-deploy
structural-sovereignty
epistolary-narrative
longitudinal-intelligence
```
That's the seed list. New themes get discovered as the corpus grows. The themes file in `longitudinal/themes.json` tracks weight over time — which themes are gaining attention, which are fading, which are emerging.
This is where personal intelligence starts to become more than a tracker. The question stops being "what did I do this week" and becomes "what have I been thinking about for two months without realizing it." Memetic patterns are visible to the system before they are visible to the person.
## Longitudinal intelligence is the point
Daily digests are useful. Weekly reports are useful. But neither is the actual reason to build this.
The reason is the layer that sits on top: the longitudinal corpus. Once events have been flowing for a few months, real questions become askable.
Where is my output velocity going? When I shipped twenty commits a week and then dropped to five, did the depth go up? Did the projects shift? Did themes consolidate? When the build events shrink, do the publish events grow — am I synthesizing instead of producing?
What projects am I actually working on, in the empirical sense — not the aspirational one? The portfolio has a dozen entries. Where do the events actually accumulate? Where does the calendar say I'm focused versus where the evidence says I am?
What learning loops are working? When I capture a `learn` event, does the work that follows reflect it? When I make a decision, does the trajectory of subsequent events line up with what was decided? Or do the decisions and the work drift apart?
These are questions a human cannot answer well from memory. The corpus answers them mechanically — once it exists, and once the skills are in place to query it.
## What's different from project-state
The same surface differences that distinguished dot Emporium from project-state distinguish work-state from both.
**The unit of measurement is a person, not a project.** A project has a defined start, end, and stakeholder set. A person has none of those. The state must run continuously, indefinitely, across every domain the person works in. There is no closeout phase.
**The reporting flows inward.** project-state's reports go to a Steering Committee. dot Emporium's go to buyers. work-state's go to the person whose state it is. That changes the voice, the cadence, and the threshold for what's worth surfacing. A weekly report for yourself doesn't need executive summaries — it needs honest signal about where attention has actually gone.
**Cross-project attribution is the hard problem.** project-state knows what project it is. work-state has to figure out which of a dozen projects each event belongs to, from a commit message, an email subject, a doc folder path, a slack channel name. The attribution is heuristic, fallible, and correctable downstream. Most events resolve cleanly. The rest land in `unsorted` until something tells the system better.
**Privacy posture is per-surface.** A project's state is shared with the project team. A person's state is private by default. The system bakes that in: every harvester documents what it captures, what it stores in `raw`, and what knobs exist to redact, hash, or strip. Local-first means local-first.
**Themes matter more.** A project mostly knows what it's about. A person typically does not. The longitudinal layer's job is to surface what the person has actually been doing — including patterns the person didn't realize were patterns.
## What this enables that the others don't
Personal achievement becomes legible. A weekly report against a real corpus of evidence answers questions like *what did I ship this week, across all projects* without the person having to remember. The system already knows.
Surface intuition stops being mysterious. When you have a hunch that one project is consuming more attention than its stated priority, you can check. When you suspect a learning has been integrated into recent work, you can verify it across event streams. When a theme feels like it's been on your mind, the corpus will tell you whether the events agree.
Cross-project intelligence becomes possible. The portfolio has a dozen projects on paper. The events tell you which two are absorbing eighty percent of the work, which three haven't seen evidence in a month, and which one is producing publishes without builds — outputs without grounding.
Planning becomes evidence-based. The planner skill — once built — proposes where to focus next, given the longitudinal signal. Not by guessing. By reading.
## scsiwyg, again
The skills publish this post the same way every other workflow in this system publishes: through scsiwyg, via MCP. The blog you are reading is itself an output captured by `work-harvester-scsiwyg` once it ships, and the publishing event will land in `events/YYYY-MM-DD/scsiwyg-publish-...json` the next time the harvester runs. The system observes itself.
That recursion is not accidental. It is the test. A personal work intelligence system that cannot capture its own publishing event is not running.
## What's built, what isn't
Built: the foundation. Six skills — the source-of-truth manager, the orchestrator, and four surface harvesters (github, gmail, slack, gdocs). The substrate scaffolds in under a second from a bootstrap script. Events flow through. Idempotent re-runs verified.
Pending: the rest of the surfaces (scsiwyg, x, linkedin), the digest layer, the metrics layer, and the longitudinal intelligence skills that make the whole thing more than a tracker. Foundation first. The intelligence builds against real data, not a mental model of it.
The pattern keeps recasting because the substrate keeps holding. Project. Storefront. Person. The skills change. The schema changes. The substrate is the same flat files, append-only logs, deterministic ids, and atomic writes that ran the first version and will run the next one.
The next recast is already obvious in outline. A team's collective state, aggregated from each member's work-state, with privacy boundaries that keep individual evidence local but allow rolled-up signals to surface. That is not built. The pattern says it can be.