Principles Ledger and Question Arcs

Most people choose what to study by canon ("the great books") or by topic ("networking", "philosophy"). There is a third way: pick a question you actually care about, then read whatever bears on it. This page describes a quarterly question arc, and a ledger of short principle notes that records what you learn in a form you can teach. It is also, in miniature, the method behind this library.

Choose texts by question, not by canon

A canon tells you what others found important. A question tells you what you need. Philosophers have always worked on problems, such as how we come to know things, what makes a design good, and what counts as a cause. When you hold a question, reading becomes selective and purposeful: you read the chapters that bear on it and put the rest down. This is a judgment about method, not a fact. Provisional It fits learners who already have some reading experience and who tend to collect books without finishing them. A first-time reader of a difficult author may still benefit from reading the whole work; see How to Read a Great Book: Levels, Modes and the Completion Standard.

The question arc

An arc runs for about a quarter and has seven parts.

Part	What it contains
Question	One sentence, open, and worth three months.
Engineering texts	Two or three selected chapters or papers from systems and engineering.
Philosophy text	One primary text that asks the same question in its own terms.
Math strand	The mathematics needed to state the question precisely (see A Map of Mathematics: Twenty-Five Areas and What Depends on What).
Hands-on lab	A small experiment, case study or model in your own field.
Make	About ten principle notes and one essay.
Exit evidence	You can teach the principle, show it in a case, and say where it fails.

An arc ends when its exit evidence exists, not when the calendar turns. A sensible rule is to avoid running more than a couple of weeks over.

Four worked arcs

How is a system's true state known? Engineering: Ashby on requisite variety (a controller needs at least as much variety as the disturbances it must absorb) and Meadows on stocks, flows and delays. Philosophy: Plato's Theaetetus, which tests the idea that knowledge is perception, and offers the wax tablet and the aviary as pictures of memory and of possessing without currently holding knowledge. The case: a monitoring dashboard is a claim about the world, and claims can be stale. See Stale Information and Dependable Reports.

Whom and what do we trust? Engineering: Saltzer and Schroeder's 1975 design principles for protection, including least privilege and fail-safe defaults. Philosophy: Hume's section X on miracles, which asks how testimony should be weighed against experience. The case: a sensor, certificate or report is testimony, and its weight depends on how often such sources are right.

What is good design? Engineering: the end-to-end argument (Saltzer, Reed and Clark, 1984), which says that some functions can be completely and correctly implemented only at the endpoints. Philosophy: Aristotle's Nicomachean Ethics VI, where technē (skill in making) differs from phronēsis (practical wisdom about what to do). The case: why rules alone do not make good designs.

What is a cause, and is there a root cause? Engineering: Richard Cook's "How Complex Systems Fail" and Charles Perrow's Normal Accidents. Philosophy: Aristotle's four causes (Physics II.3) and Hume's analysis of causation in the Enquiry, sections IV to VII. The case: failures usually have several contributing causes, each necessary and none sufficient alone. For a wider reading path, see Systems, Decisions and Robust Design.

The principle note

A principle note is a short, atomic note about one durable idea, written in your own words. It borrows the Zettelkasten tradition of one idea per note, linked to others. Use a fixed template:

Principle: one sentence.
Source: the text and section, with the strongest statement of it.
Mechanism: why it is true.
Holds when: the conditions where it works.
Fails when: the conditions where it does not.
Case: one real example, with the evidence.
Philosophical parallel: where an older thinker met the same idea.
Related: links to other notes.

Quality test. Could you teach it in five minutes, give a case, and name where it breaks? If not, it is a draft, not a principle.

Principles worth owning

These five are well established in their fields and make good first notes.

Requisite variety. A regulator can only control what it can match in variety. Established (Ashby's law, a theorem within cybernetics).
Stale data is not healthy data. A value without a timestamp and a collection status can look fine while the source has stopped reporting. Established as engineering practice.
Least privilege. Give each component only the access it needs (Saltzer and Schroeder, 1975). Established
The end-to-end argument. Reliability checks belong where the full meaning is known. Established as a widely used design argument; it is a guideline with exceptions, not a law.
Multiple contributing causes. Serious failures typically need several conditions together. Established in the safety literature, though how to apportion cause remains argued. Aporetic on whether "root cause" is a useful concept at all.

Each note should separate the claim from any analogy. Saying a monitoring dashboard is "like" Plato's wax tablet is an analogy; the engineering point stands without it.

Review rituals

A ledger is only worth keeping if you revisit it.

Quarterly exhibit. Lay out what you made: notes, essay, lab results. Update which principles are teachable. Decide whether to keep or swap the next question.
Yearly oral explanation. Explain one system end to end to a person, or record it, then take ten hard questions. You pass when you can answer "how do you know?" for each claim.
Annual essay. A longer essay, growing from the year's arcs. Keep every one; reading them years later is some of the best evidence of how your thinking changed.

Start small, then link

Do not build a system first. Write three principle notes, link each to at least one other, and add a one-page map of content (MOC) listing them under their guiding question. That is the whole method. A MOC is simply a hand-made index note that groups related notes and shows the order to read them in; this site's library is built the same way, with every page linking to its neighbors. The skills that this process builds, such as precise statement, case-making and honest limits, are the ones that last when tools change; see Building a Career on Capabilities, Not Tools. For the person this practice aims at, see The Philosopher-Engineer: Study and Workshop Together, and for the questions that come before an arc, What Does It Take to Know Something?.

Try this

Write one question you could spend three months on. Name one engineering text, one philosophy text and one hands-on lab that bear on it.
Write a principle note on "stale data is not healthy data" using the template above. Include one case where it fails to apply.
Teach one principle note aloud for five minutes. Mark where you hesitated; those are your gaps.