Field Notes

meta

Note lifecycle

StatusStableUpdatedSupportsnotes

Every note in the wiki carries a status field and an optional review_after date. Together they track whether a note is presently usable and when its time-sensitive claims need rechecking.

The four statuses

Status Meaning
seed A useful capture or skeleton that still lacks enough definition, grounding, structure, or connections to stand on its own
working A usable note with a known material gap, unresolved contradiction, incomplete claim checking, or an active hypothesis that still needs evidence
stable A coherent note at its current explicit scope whose material claims have been checked, important limitations are represented, and no known gap prevents reliance
stale A note with time-sensitive claims now known to be unsafe to rely on until they are revalidated or corrected

What stable means

stable means reliable at the present scope, not complete for all possible purposes or frozen forever. A short source card can be stable when it accurately describes its immutable artifact; an ambitious business plan can remain working when its central assumptions have not yet been validated.

Do not leave a note working merely because it is young, non-exhaustive, or expected to evolve. Reserve working for a known material gap.

When stale applies

stale is for notes whose time-sensitive claims can no longer be trusted until they are revalidated or corrected. It carries a visible warning callout naming the affected claims and needed review.

Stale is not “old” or “needs updating.” It is “unsafe to rely on right now.”

The lifecycle flow

flowchart LR
  New[just new] --> Seed[seed]
  Seed -->|coherent but materially incomplete| Working[working]
  Seed -->|adequate at current scope| Stable[stable]
  Working -->|known material gaps resolved| Stable
  Stable -->|new material gap opens| Working
  Seed -->|known unreliable current claims| Stale[stale]
  Working -->|known unreliable current claims| Stale
  Stable -->|known unreliable current claims| Stale
  Stale -->|revalidated with gaps remaining| Working
  Stale -->|revalidated at adequate scope| Stable
  Due[review_after becomes due] -. creates a verification task .-> Working
  Due -. does not change status by itself .-> Stable

Status transitions are driven by evidence, not by time alone. A due review_after date creates a verification task but does not automatically change status. The note stays where it is until that verification runs.

The review_after field

review_after: YYYY-MM-DD is an optional freshness schedule. It applies to notes that depend on:

  • Current prices or product features
  • Provider policies
  • Market availability
  • Laws, regulations, and tax rates
  • Unfolding proceedings

Set a date proportionate to volatility. A product feature note might review quarterly; a regulation might review annually; a market analysis might review monthly.

When the date arrives, just review reports the note as due. The verification task is to recheck the time-sensitive claims and update updated, review_after, and status as appropriate.

How statuses interact with editing

Creating a note

just new deliberately creates a seed. Before finishing the session, reassess the status based on the actual note that now exists. Promote a seed to working once it is coherent and connected; promote it to stable when the current scope is adequately grounded.

Editing an existing note

When editing changes a note’s material claims, reassess its status. A stable note that gains a new material gap should return to working. A working note whose gaps are resolved should promote to stable.

New evidence

When new evidence opens a material unresolved problem in a stable note, return it to working until the problem is resolved or the scope is narrowed.

Checking lifecycle status

  • just status summarizes lifecycle states and lists every non-stable note.
  • just review lists explicitly stale notes, due reviews, and the next scheduled review.
  • just query "type=question" enumerates the research frontier of open questions, which are usually working or seed.

Design decisions

  • Status is about reliability, not age, length, or activity. A note does not become stale because it is old; it becomes stale because its claims are no longer safe.
  • stable does not mean “finished.” A stable note can be extended, revised, and improved; it means the current scope is adequately grounded.
  • The review_after schedule is separate from status. A note can be stable and due for review; the review checks whether it should stay stable.
  • stale carries a visible warning callout so readers know the note needs revalidation before relying on it.

This note cites no sources of its own.

Working out connections…