Problem-ordered pages do the work a portfolio doesn't

Status: surviving, as of 06 May 2026

Problem: How should I document answers to the Work Question in a way that does the work a portfolio doesn't?

A documentation structure that organizes entries by problem—each problem its own page, growing as proposed → criticized → revised → resolved or abandoned, with dates on events inside the entry rather than on the entry itself—does the work a portfolio is supposed to do and doesn't. A chronological structure (weekly logs, monthly summaries) cannot do this work, because it organizes by time rather than by content and fragments single problems across multiple entries.

The reasoning: a portfolio is supposed to show how you handle problems. A weekly log shows what you did this week, which is a different question. Problems don't resolve on a weekly clock—especially "set in motion" problems, whose feedback is delayed by design. Time-ordered entries split a problem's evolution across many entries, burying the throughline. Problem-ordered pages keep the evolution of each problem visible as a single trajectory, which is the unit a reader (or future-you) actually wants to see.

A second piece of the conjecture: of the four facets of the Work Question, "what did you do to expose your proposed solutions to criticism" is the one most easily faked by a chronological log that narrates activity. Problem-ordered pages with criticism as load-bearing structure—visible linked criticism nodes, not silent absorption into revisions—make the criticism facet hard to fake. That is the specific work portfolios fail to do, and the specific work this structure is meant to do.

What would refute this:

• A chronological structure that demonstrably surfaces problem evolution and exposes criticism as well as a problem-ordered one (would show the time/content distinction doesn't matter as much as claimed)
• Problem-ordered pages that, in practice, also fail to expose criticism—revealing that the structure isn't what was doing the work; something else was
• The structure producing pages that nobody (including future-you) finds usable, which would suggest the chosen unit doesn't match how you actually navigate your own work.

Problem Index

A single page listing all problems by status—open, solved, dissolved, abandoned, absorbed, possibly split—is the entry point that makes the problem-ordered documentation actually answerable to the Work Question. Without it, the problem notes exist as a graph but aren't navigable as a body of work. With it, a reader (or future-you) lands somewhere that shows the shape of the work at a glance: what's live, what closed and how, what got reframed.

The reasoning: problem-ordered pages solve the unit-of-organization problem, but they don't solve the navigation problem. A graph of linked notes can be entered from any node, which is good for following a thread but bad for seeing the whole. The index is the view onto the graph that surfaces the patterns the individual notes can't: the proportion of problems that get solved versus dissolved versus abandoned, the reframings, the convergences. It's also where you'd notice unnoticed duplication—different framings of the same problem—which is a real piece of work the index does that nothing else does.

The index also serves the polemical function the Work Question carries. Someone landing on a "Problem Index" page sees immediately that this is documentation organized around problems, not output. That framing happens before they read any individual note. A site without the index leaves the reframe implicit; the index makes it the first thing visible.

Problem note

Title: A findable, unambiguous handle. Doesn't need to be short. Names the problem; doesn't carry a claim.

Role tag: r/problem

Body opens with the full problem statement. Phrased as a question, including the such-that—what would count as having solved it. Example: "How should I document answers to the Work Question in a way that does the work a portfolio doesn't?"

Status line near the top. One of: open, solved, dissolved, abandoned, absorbed. Dated. When closed, includes a forward link where relevant (absorbed → which problem it now lives under; superseded framing → which note replaced it).

Example:
Status: open, 2026-03
Status: solved, 2026-05, surviving conjecture: [link]

Links out to:

• Conjectures addressing the problem
• Related problems (meta, sub, sibling—labeled by relation, not hierarchy)
• The convergence note if this problem turned out to overlap with others

Workflow tags as needed: wf/revise, wf/link, wf/split, etc. These operate independently of the role and status.

Conjecture note

Title: Can carry the claim itself, since the claim is the content. Example: "Status lines should be prose, not tags."

Role tag: r/conjecture

Body states the conjecture and its reasoning. What the claim is, what it's responding to, why it might be right. Hard-to-vary where possible. Includes what would count as refuting it where you can articulate that.

Status line near the top. One of: surviving, refuted, revised, abandoned. Dated. Includes forward links: refuted → criticism note(s); revised → successor conjecture note.

Links out to:

• The problem(s) it addresses (required—a conjecture not attached to a problem shouldn't be a conjecture note)
• Criticisms applied to it (as they're written)
• Predecessor or successor conjectures if part of a revision lineage

Workflow tags as needed, including wf/uncriticized if no criticism node has been linked yet. Clears when criticism is applied or you mark the conjecture as untested in the body.

Criticism note

Title: Can carry the criticism itself, since the content is the critical claim. Example: "Status as a tag fails the next-action principle."

Role tag: r/criticism

Body states what's wrong with the targeted conjecture and why. What the criticism is, what assumption or move in the conjecture it attacks, and why that attack lands. Specific enough that a reader can see whether the criticism actually applies or misses. A criticism that could be deflected by the conjecture's defender adding a convenient exception is a weak criticism—worth being explicit about what the criticism would force the conjecture to give up.

Status line near the top, optional. Add only if you find yourself returning to criticisms and updating their standing. If you do, vocabulary is: standing, answered (link to revised conjecture or counter-criticism), withdrawn. Default is no status line—criticisms tend to be write-once, and adding the line preemptively is overhead that hasn't earned its place. Let the convention emerge from actual use.

Links out to:

• The conjecture it targets (required—a criticism not attached to a conjecture shouldn't be a criticism note)
• Related criticisms if this one is part of a cluster attacking the same conjecture from different angles
• The successor conjecture if the criticism produced a revision

Workflow tags as needed. Standard wf/ tags apply. No criticism-specific workflow tag is needed at the start; if you find one missing through use, add it then.

One thing worth flagging across all three role notes: the required links are what make the role real. A problem with no conjectures attached is just an unanswered question. A conjecture with no problem attached is a floating assertion. A criticism with no conjecture attached is a complaint. The roles only do their work when the structure connecting them is intact. If you find yourself wanting to write a note that won't attach, that's usually a signal the note isn't ready yet—either you haven't articulated the problem it addresses, or it isn't actually playing the role you thought.