Principles Ledger and Question Arcs

A method for organising study around one guiding question per quarter and recording durable principles as atomic, teachable notes.

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 Reading Great Books.

The question arc

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

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

Treat the reading rows as roles, not fixed titles: any text that fits the row can fill it. A role-based eating plan works the same way: lentils can fill the legume role when chickpeas run out.

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 neighbours. The skills that this process builds, such as precise statement, case-making and honest limits, are the ones that last when tools change; see Capabilities Over Tools. For the person this practice aims at, see Philosopher-Engineer, and for the questions that come before an arc, Knowledge and Justified Belief.

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.