The newest news in raw, unedited form is in the Journal of the PROCESS, of BUILDING this little repository or agentic mdBook monorepo of skill *.md files ... check the Journal first, if you are revisiting -- otherwise, look at the repository or maybe fork/clone it.

Five Strategic Causal Engineering Visions

Causal Engineering has one objective: maximize the discovery of surprises — new actionable insights and useful knowledge. We focus on causal drivers because that's what makes the whole process efficient. Take business prospecting for a scalable company. Instead of spamming people, getting permanently blocked, and irritating uninterested prospects with robo-pitches, we design campaigns — freemium models, for instance — to maximize closable leads per $1,000 spent. The point of the campaign is to understand what actually causes someone to use our product, not to assume prospecting is just a numbers game.

1. The Orthogonal Opportunist: Exploiting Natural Experiments in Administrative Data

Treat every policy change, geographic boundary, and bureaucratic threshold as a free randomization you didn't have to pay for, then deliberately construct a portfolio of these natural experiments whose identifying assumptions fail in different ways—so that no single unobserved confounder can kill the whole portfolio. This is Taguchi thinking applied to causal identification itself: you are not just estimating effects, you are arraying designs orthogonally so that the weaknesses of one design (e.g., a regression discontinuity's local external validity) are covered by the strengths of another (e.g., a difference-in-differences' broader scope). The strategic bet is that the world is littered with quasi-random variation that no one has bothered to harvest because it's unglamorous, and that the marginal cost of adding the twelfth natural experiment to your array is nearly zero once the data pipeline exists. The risk is real: reviewers may see a "grab bag" of designs rather than a coherent identification strategy, and if your portfolio is correlated in its failure modes (e.g., all designs rely on the same parallel-trends assumption), you've built false confidence at scale. Mitigate by pre-registering the heterogeneity of assumptions across designs—making the fragility itself the object of study—and by publishing the "assumption coverage matrix" alongside the estimates.

2. The Negative-Space Cartographer: Mapping What Isn't There

Systematically catalog the absences in free data—the products never launched, the trials never run, the regions never treated, the queries never asked—and treat these null spaces as your most information-dense research frontier, because selection into non-existence is itself a causal process that reveals the decision rules of the actors you're studying. This is the prospector's inversion: instead of drilling where everyone else drills (published effects, successful launches, treated units), you drill where the absence of a drill-hole is informative, using the pattern of missingness as a signal about costs, beliefs, and constraints. The efficiency argument is that absence-data is almost always free (it's the complement of data someone else already collected), and the surprise-per-dollar is enormous because you are testing hypotheses no one has articulated—"why did this firm stop at formulation 47?" is a question with a cheap answer and a potentially huge payoff. The risk is that absence is unfalsifiable by default: you cannot distinguish "no one tried because it wouldn't work" from "no one tried because of a historical accident," and you may spend your budget building elegant theories of nothing. Defend against this by triangulating absences against revealed constraints (patent cliffs, regulatory calendars, procurement records) so that each null-space claim is anchored to at least one observable decision cost.

3. The Fractional-Factorial Field Lab: Running 2^(k-p) Designs on Cheap Interventions

Embrace the Taguchi insight that you can estimate main effects of many factors with a fraction of the runs, and apply it not to manufacturing but to behavioral or operational interventions in the field—running 8 or 16 armed mini-experiments where a naive team would run 64, accepting aliasing between high-order interactions in exchange for testing eight hypotheses per dollar instead of one. The vision is a "screening factory": cheap, fast, low-power experiments whose purpose is not to confirm but to rank which factors deserve the expensive follow-up, with the explicit understanding that Resolution III designs will confound main effects with two-way interactions and that this is an acceptable price for breadth. The strategic payoff is that most intervention effects are main-effects-dominated, so the aliasing cost is small relative to the discovery yield, and the free infrastructure (existing survey panels, app telemetry, call-center logs) absorbs most of the cost. The risk is the classic one: if the true structure is interaction-heavy (e.g., the intervention only works in combination), your fractional design will systematically mislead you into killing a factor that matters, and you'll never know it. Insure against this by reserving 20% of budget for foldover runs on the top-ranked factors, converting your screening array into a confirmatory one exactly where the stakes justify it.

4. The Adversarial Replication Exchange: Paying for Disconfirmation, Not Confirmation

Restructure your research budget so that a fixed fraction (say 30–40%) is spent only on attempts to falsify your own prior findings using free or cheap external data, and make the surprise—the failure to replicate—the primary deliverable rather than a embarrassment to be buried. The philosophical bet is Popperian and economic at once: the marginal dollar spent trying to kill a result buys more information than the marginal dollar spent extending it, because confirmation has diminishing returns while disconfirmation has option value—it tells you which of your beliefs are load-bearing before you build on them. This is efficient because replication attempts on already-collected public data (or on data you can obtain through FOIA, open science repositories, or scraping) cost a fraction of original data collection, and the "orthogonal array" here is over threats to validity: you deliberately array your replications so that each targets a different failure mode (measurement, selection, specification, publication). The risk is institutional and reputational: funders and collaborators may read a portfolio of failed replications as a portfolio of your failures, and the strategy can be gamed into nihilism where nothing is ever believed. Guard against this by pre-committing to a decision rule—"we will treat a finding as load-bearing only if it survives at least two of four adversarial probes"—so that disconfirmation buys calibrated confidence, not reflexive skepticism.

5. The Surprise-Weighted Portfolio: Budgeting for Maximum Entropy Reduction

Treat your research portfolio as an information portfolio and explicitly optimize for expected entropy reduction per dollar rather than for expected effect size or expected publication, which means deliberately over-weighting hypotheses that are (a) cheap to test, (b) currently near 50/50 in your prior, and (c) mutually orthogonal in what they would teach you if resolved. This is the deepest Taguchi analogy: just as orthogonal arrays maximize the information extracted per run by making columns independent, a surprise-weighted portfolio maximizes learning per dollar by making your hypotheses independent in information space—so that resolving one doesn't make the next redundant. The efficiency comes from the free-data augmentation: many of the highest-uncertainty, cheapest-to-test hypotheses live in data you already have but haven't interrogated (the unused columns of a survey, the untapped logs, the second-order interactions you never checked), so the marginal cost approaches the cost of attention rather than the cost of collection. The risk is that entropy-reduction is a process objective, not a substantive one—you can maximize surprise per dollar and end up with a portfolio of true-but-trivial findings, having optimized for the thrill of learning rather than for learning what matters. Defend against this by imposing a substantive constraint on the portfolio (e.g., "every hypothesis must connect to a decision someone will actually make") and by periodically re-weighting toward consequential uncertainty, so that the entropy you reduce is the entropy that stands between you and action.

Applied Curiosity Engineering

Projects, Areas, Resources, Archive Architecture

We will use the P.A.R.A. method (Projects, Areas, Resources, Archive) as a conceptual guide to organize the top-level chapters and sections within this mdBook's src directory as the foundational information architecture for your mdBook project. In contrast to a freeform approach OR generally adaptible mdBook approach that fits appropriately to the software being documented and implemented simultaneously, this mdBook is somewhat self-referential in terms of developing a PKE, thus following the PARA structured, hierarchical approach from the outset makes sense for developing a PARA-influence PKE.

In general, an issue-driven approach will be followed as we progress working through the daily modules in this mdBook's PKE development process, using the Zettelkasten concept of atomic notes. Each new issue that arises will be given it's own self-contained piece of research or issue#.md page. At first the issue#.md page will be in the 1.Projects folder until they are dispatched or dispositioned appropriately within the book's structure, all will be linked hierarchically by the SUMMARY.md file.

The 1.Projects folder will be the landing place for new issues and thereafter for short-term, less than one week efforts which are currently underway and should be regarded as under HEAVY construction. Issues that take on a larger life as much larger, ongoing effort will go to the 2.Areas folder. Issues that are developed and completed will go to he 3.Resources folder. Issues that are dismissed, after even a minor expenditure of dev effort, will go to the 4.Archive folder.

The 2.Areas folder will be for longer-term development and ongoing efforts that will stay open, perhaps indefinitely as perhaps usable, but under ongoing development. Areas that are developed for some time and eventually completed will go to he 3.Resources folder.

The 3.Resources folder will be for usable references and material that's that have been either curated or developed and although curation might continue to add things, these items should be regarded as stable enough to be considered usable, as good as complete. In some cases, a Project or Area might graduate to being in its own development repository, but page linking to that effort will be maintained in the Resources folder.

The 4.Archive folder will be for things that in the back Area 51 parking lot and might still be valuable for informational purposes, but are basically not something anyone should use.

Knowledge Management For PrePrints

The contemporary academic landscape is defined by an unprecedented acceleration in the dissemination of scientific knowledge, driven largely by the proliferation of scholarly pre-print archives such as arXiv, bioRxiv, and medRxiv.1 This paradigm shift presents a fundamental duality for the modern researcher: the "Velocity vs. Veracity" problem. On one hand, pre-prints offer immediate access to cutting-edge findings, dramatically shortening the cycle from discovery to communication and enabling researchers to build upon new work months or even years before formal publication.2 This velocity was instrumental during the COVID-19 pandemic, where rapid data sharing was paramount.2 On the other hand, this speed comes at the cost of the traditional gatekeeping function of peer review. Pre-prints are, by definition, preliminary reports that have not been certified by this critical process, introducing a significant risk of engaging with work that may be flawed, misinterpreted, or ultimately unpublishable.2

This deluge of unevaluated information threatens to transform from a professional opportunity into a state of chronic information exhaustion.8 The challenge for today's researcher is to develop a systematic methodology that transcends passive consumption and information triage. A strategic response is required to move beyond the mere management of information overload and toward the active, deliberate construction of a unique and valuable body of knowledge—an intellectual asset. This is the core promise of "Building a Second Brain," a methodology for creating an external, digital repository for one's ideas, insights, and learnings.9 Such a system allows the biological brain to be freed from the burden of perfect recall, enabling it to focus on its highest-value functions: imagination, synthesis, and creation.9

This report argues that by systematically integrating Tiago Forte's 'Building a Second Brain' (BASB) methodology with a modern, local-first technical stack and a deliberate strategy for public engagement, a researcher can construct not just a personal knowledge repository, but a powerful engine for accelerating research, generating novel insights, and building a distinguished professional brand. The user's query for such a system is not merely a request for productivity enhancement; it reflects a sophisticated understanding of the current academic environment. It recognizes that the rise of pre-prints shifts the burden of quality assessment onto the individual, while the digital landscape simultaneously opens new avenues for establishing professional reputation outside of traditional metrics. The proposed system is therefore an integrated strategy to thrive in this new paradigm: it internalizes the review process, accelerates personal learning cycles, and strategically leverages the resulting intellectual output for public credibility and collaborative advancement.

BASB and the Pre-print Ecosystem

Chapter 1: Architecting the Second Brain for Scholarly Inquiry

1.1 The CODE Framework in a Research Context

The Building a Second Brain methodology is built upon a four-step process known as CODE: Capture, Organize, Distill, and Express.9 While these principles are universally applicable, their implementation within a scholarly research context requires specific adaptation to address the unique challenges and workflows of academic inquiry.

Capture: Building a Systematic Intake Funnel

The first step, Capture, involves saving information that resonates with the researcher. In the context of pre-print investigation, this moves beyond haphazardly downloading PDFs. It necessitates the creation of systematic, semi-automated pipelines for monitoring the flow of new literature. This can be achieved by leveraging the programmatic access points provided by major archives. For instance, a researcher can set up RSS feeds for specific subject categories (e.g., "bioRxiv Biophysics") or for custom keyword and author searches.11 More advanced systems can directly query the APIs of services like arXiv to programmatically retrieve metadata for newly posted articles that match complex criteria.14

The guiding principle for capture, however, is not comprehensiveness but "resonance".9 The researcher should be selective, capturing only those pre-prints that are genuinely inspiring, surprising, useful, or directly personal to their ongoing work.10 This selective intake is crucial for preventing the Second Brain from becoming a "digital junkyard," ensuring that the time of one's future self is respected.10 Each captured item is a potential building block for future creative work, and its selection should be a conscious, intuitive act.10

Organize: The PARA Method for Action-Oriented Research

Once captured, information must be organized. The BASB system employs the PARA method, which stands for Projects, Areas, Resources, and Archive.9 The central innovation of PARA is its departure from traditional, topic-based filing systems (e.g., folders for "Genetics," "Immunology," "Statistics"). Instead, it organizes information based on its actionability, creating a dynamic system geared toward execution.15

This philosophical shift is particularly potent in an academic setting, where the tendency to collect information endlessly can stifle progress. A paper is not filed based on what it is about, but on how it will be used.

• Projects: These are the most actionable items. A project is a series of tasks aimed at a specific outcome with a deadline.10 For a researcher, this translates to concrete endeavors such as "Literature Review for Grant X," "Manuscript on Topic Y," "Conference Presentation Z," or "Preparing for comprehensive exams." A captured pre-print directly relevant to one of these efforts is filed in the corresponding project folder.
• Areas: These are long-term areas of responsibility that require constant upkeep but have no fixed end date.10 Examples include "My Research Field (e.g., Computational Neuroscience)," "Lab Management," "Teaching Duties (e.g., BIOL-101)," and "Professional Development." An interesting pre-print that broadens one's general expertise but isn't for a specific project would be filed under the relevant Area.
• Resources: This is a catch-all for topics of interest that are not related to an active Project or Area.10 This is where a researcher might store information on a new statistical method, a paper from a tangential field that sparked an idea, or notes on the history of science. It is a repository for potential future utility.
• Archive: This folder holds all inactive items from the other three categories.9 When a project is completed or an area of responsibility becomes dormant, its associated materials are moved to the Archive, keeping the active workspace clean and focused while preserving the information for future reference.

By prioritizing organization by actionability, the PARA method ensures that the most relevant information for current work is always the most accessible, reducing friction and promoting consistent forward momentum.

Distill: Progressive Summarization of Scholarly Work

The Distill step is where the true value of the Second Brain is created. It is the process of extracting the essential essence of captured information, making it more discoverable and useful for the future.10 The primary technique for this is "Progressive Summarization." When applied to a scholarly pre-print, this involves creating a multi-layered summary within an atomic note.

1. Layer 1: The initial note is created, containing the full abstract, key metadata (authors, title, DOI, link), and any passages highlighted during the first reading.
2. Layer 2: On a second pass, the researcher reviews the note and bolds the most important sentences and phrases within the highlighted passages.
3. Layer 3: On a subsequent review, the researcher reads only the bolded text and highlights the most critical points within that selection.
4. Layer 4: Finally, the researcher synthesizes the highlighted points into a one- or two-sentence executive summary in their own words at the top of the note.

Each time a note is revisited, it is enriched and made more concise, leaving behind a more valuable asset for the future.10 This layered approach allows the researcher to engage with the material at the appropriate level of depth—from a quick glance at the executive summary to a deep dive into the original highlighted text—on demand.

Express: The Recombination and Creation of New Knowledge

The final step, Express, is the output stage. It is where the captured, organized, and distilled building blocks are used to create new work.9 This is not a separate activity but the natural culmination of the preceding steps. With a growing collection of distilled, atomic notes, the process of writing a paper, preparing a presentation, or drafting a grant proposal shifts from a daunting task of starting from a blank page to a more manageable process of assembling and connecting pre-existing components.8 The Express stage is the ultimate purpose of the Second Brain: to consistently turn information consumed into creative output and concrete results.9 This report will further expand this concept to include public-facing expressions designed for professional brand management, such as blog posts, social media threads, and collaborative reviews.

1.2 The Atomic Note as the Quantum of Knowledge

The fundamental unit of this entire system is the Markdown-based atomic note. The principle of atomicity dictates that each note should contain a single, discrete idea, concept, finding, or critique derived from a source.10 For a pre-print, this means that instead of creating one monolithic note for the entire paper, the researcher creates multiple smaller notes. One note might capture the central hypothesis, another might detail a specific methodological innovation, a third could critique the statistical analysis, and a fourth might summarize a key result from Figure 3.

Each atomic note is a self-contained, reusable "building block" of knowledge.10 It must be enriched with metadata to ensure its context is preserved: the source (pre-print DOI, authors, title), relevant tags (e.g.,

#methodology, #topic-X, #critique), and, crucially, links to other related atomic notes within the system. This practice of interlinking transforms a simple collection of notes into a dense, navigable network of ideas, enabling the discovery of unexpected connections across different papers, disciplines, and time periods.10 This networked structure is the foundation for generating novel insights and hypotheses, which is a core function of advanced scholarly work.

Chapter 2: The Technical Substrate - Leveraging Rust, Markdown, and Git

The choice of technology for a Second Brain is not a trivial implementation detail; it is a philosophical commitment to a set of principles. While the BASB methodology is officially tool-agnostic, the user's specification of a stack comprising Markdown, a Rust-based static site generator (SSG), and Git reflects a deliberate choice for durability, performance, data sovereignty, and transparency.8 This toolchain, common in the world of professional open-source software development, treats the personal knowledge base as a serious, long-term project to be managed with professional-grade tools.

2.1 Why Markdown? The Principle of Plain Text

Markdown is a lightweight markup language for creating formatted text using a plain-text editor. Its selection as the format for atomic notes is foundational. The primary advantage of plain text is its longevity and portability. Unlike proprietary file formats (.docx, .pages, .one), Markdown files are not tied to any specific application or company. They are human-readable, can be opened and edited by countless applications on any operating system, and will remain accessible decades from now. This ensures that the intellectual asset being built is future-proof and free from vendor lock-in, giving the researcher complete ownership and control over their knowledge base in perpetuity.

2.2 Why a Rust-Based Static Site Generator? Performance, Sovereignty, and Durability

The user's preference for a Rust-based tool like mdBook points to a desire for a local-first, high-performance system. Static site generators like mdBook and Zola take a collection of plain text files (in this case, Markdown notes) and compile them into a set of simple, static HTML files.17 This approach stands in stark contrast to complex, database-driven, cloud-based platforms like Notion or the commercial version of GitBook.19

The advantages of this architecture are manifold:

• Performance: Rust-based SSGs are exceptionally fast. A typical site can be built in under a second, providing an instantaneous, frictionless experience for the user.17
• Data Sovereignty: The entire knowledge base consists of plain text files in a folder on the user's local machine. There is no reliance on a third-party server, no risk of a service shutting down, and no privacy concerns associated with storing sensitive intellectual work on a corporate cloud.19 The system is offline-first by design.
• Durability and Simplicity: The output is a set of static HTML files. This is the simplest, most robust form of web content, requiring no database or complex server-side processing to serve. It is highly secure, infinitely scalable, and can be hosted for free or at very low cost on numerous platforms.17
• Structure: mdBook, in particular, is designed to create book-like structures from Markdown files.18 This is an ideal paradigm for organizing complex research topics, allowing a researcher to structure their knowledge into coherent chapters and sections, complete with a table of contents and navigation.

2.3 Why Git? Versioning Knowledge and Enabling Collaboration

Integrating Git, a distributed version control system, elevates the PKM system from a simple collection of files to a robust, versioned project. Traditionally used for managing source code, Git is perfectly suited for tracking the evolution of intellectual work.22

By initializing a Git repository in the root directory of the Second Brain, the researcher gains several powerful capabilities:

• Complete History: Every change, addition, or deletion of a note is recorded as a "commit." This creates an indelible history of the knowledge base's evolution, allowing the researcher to see how their understanding of a topic has changed over time.
• Reversibility: Mistakes can be easily undone. If a set of notes is edited in a way that proves unhelpful, the researcher can revert the repository to any previous state, ensuring that no work is ever truly lost.22
• Atomic Changes: Git encourages the practice of making small, logical commits, which aligns perfectly with the principle of atomic notes. Each new idea or analysis can be committed with a descriptive message, creating a clear and understandable log of intellectual progress.24
• Branching: Git's branching capabilities are central to enabling collaborative workflows. A baseline workflow for a personal system would involve a main branch, representing the stable, "published" state of the knowledge base, and temporary feature branches for drafting new notes or synthesizing ideas.24 This isolates work-in-progress from the clean main branch, providing a structured environment for development that forms the basis for the advanced collaborative models discussed in Part II.

This technical substrate—Markdown for content, a Rust SSG for presentation, and Git for versioning—creates a powerful, sovereign, and durable foundation for a researcher's Second Brain. It is a system built not for ephemeral convenience, but for the long-term cultivation of a life's work.

Part II: Five Models for a Pre-print Investigation System

Introduction to Part II and Comparative Table

The foundational frameworks of Building a Second Brain and a robust technical stack provide the "what" and the "how" of a personal knowledge management system. This section addresses the "why"—the strategic purpose. The following five models represent distinct, actionable strategies for applying this system to the investigation of scholarly pre-prints. They are not mutually exclusive but represent a spectrum of approaches, each balancing the depth of private analysis with the breadth of public outreach and collaboration. A researcher might adopt one model for a specific project, or evolve from one to another over the course of their career.

To provide a strategic overview and guide the selection process, the models are first presented in a comparative table. This allows for a high-level assessment of each model's primary goal, methodological focus, collaborative intensity, technical complexity, and ideal user profile, enabling a researcher to identify the approach most aligned with their immediate needs and long-term professional objectives.

Table 1: Comparison of Pre-print Investigation Models

Chapter 3: The "Pre-print Digest" Model: Automated Curation and Public Dissemination

3.1 Concept

This model positions the researcher as a trusted curator and signal-booster for their specific field. The core activity is the systematic scanning of pre-print archives to identify the most significant, interesting, or impactful new papers. The primary output is a regular publication—such as a weekly or bi-weekly "digest"—that summarizes these findings and provides brief, insightful commentary. The goal is to build a reputation as a knowledgeable and reliable source, attracting a broad audience of peers and establishing a strong professional brand through consistent, high-value curation.

3.2 BASB Workflow

The workflow for the Pre-print Digest model is optimized for speed and consistency, emphasizing automation in the initial stages to allow the researcher to focus their limited time on the high-value tasks of selection and commentary.

• Capture: This stage is heavily automated to create a wide funnel of potentially relevant papers. The researcher would write simple scripts (e.g., in Python or Rust) to query the APIs of arXiv, bioRxiv, and other relevant servers on a daily basis for pre-prints matching a predefined set of keywords, authors, or subject categories.14 Concurrently, they would subscribe to RSS feeds from these archives and from journal alerts, using an RSS aggregator like Feedly to centralize the incoming stream.12 The metadata for each captured pre-print (title, authors, abstract, DOI) is automatically formatted into a new Markdown file and placed in a dedicated "Triage" folder within the
  Resources section of the Second Brain.
• Organize/Distill: The researcher dedicates a specific time block each week to process the "Triage" folder. This involves quickly scanning the titles and abstracts of the captured papers. Those deemed most interesting are moved from the generic Resources/Triage folder into a time-bound Project folder, such as Projects/Digest-Week-34-2025. For each of these selected papers, the researcher performs a rapid distillation, creating a single atomic note. This note does not require deep, multi-layered summarization; instead, it focuses on a concise, one-paragraph summary of the key finding and a crucial "Why it matters" sentence that provides the researcher's unique insight or context.
• Express: At the end of the weekly cycle, the distilled summaries from the project folder are compiled into a single, longer Markdown document. This document is structured with clear headings for each paper. The mdBook tool is then used to render this Markdown file, along with any previous digests, into a clean, professional, and easily navigable website. Each digest becomes a new "chapter" in the public-facing knowledge base.

3.3 Social Outreach and Collaboration

The social component of this model is primarily about public broadcast and brand building. Once the new digest is published to the mdBook site, the URL is shared widely across relevant professional networks.

• Dissemination: A link to the digest is posted on social media platforms like X, often accompanied by a thread that highlights the most exciting paper from that week's collection. The link can also be shared on platforms like Hacker News, relevant subreddits, or academic mailing lists to reach a broader audience.
• Ambient Collaboration: Collaboration in this model is ambient and indirect. It occurs through the public feedback received on these platforms—replies, quote tweets, comments, and discussions. This feedback serves as a valuable signal, indicating which papers are generating the most interest or controversy in the community. This public response is, in itself, a form of information that can be captured back into the Second Brain. For example, a particularly insightful critique from another researcher in a reply can be saved as a new atomic note and linked to the original pre-print summary, enriching the knowledge base. This creates a virtuous cycle where public expression leads to new private knowledge, which in turn improves future public expressions.

3.4 Technical Implementation

The technical setup for this model is straightforward, focusing on automation and simple deployment.

• Knowledge Base: mdBook serves as the core tool for managing the private notes and generating the public-facing digest website.18
• Automation Scripts: Python (with libraries like requests and feedparser) or Rust can be used to write the scripts that interact with pre-print APIs and parse RSS feeds. These scripts would be scheduled to run automatically (e.g., using a cron job).
• Deployment: A simple Continuous Integration/Continuous Deployment (CI/CD) pipeline, easily configured using GitHub Actions, can be set up. This pipeline automatically triggers whenever a new digest is committed and pushed to the main branch of the Git repository. The action will run the mdbook build command and deploy the resulting static HTML files to a hosting service like GitHub Pages, ensuring the public site is always up-to-date with minimal manual intervention.

Chapter 4: The "Deep Dive" Model: Focused Literature Review as a Living Project

4.1 Concept

This model is tailored for the intensive, focused effort of conducting a comprehensive literature review for a single, high-stakes academic project. This could be a thesis chapter, a grant proposal, a systematic review article, or preparation for a qualifying exam. In this model, the Second Brain is not a broad surveillance tool but a dedicated project space. The key innovation is transforming the traditionally private and static literature review process into a semi-public, dynamic, and "living" document that evolves over time and benefits from targeted collaborative feedback.

4.2 BASB Workflow

The workflow is characterized by manual curation and deep, iterative synthesis, reflecting the focused nature of the project.

• Capture: The capture process is manual, deliberate, and highly selective. Pre-prints are not captured automatically based on keywords but are actively sought out and chosen based on their direct and profound relevance to the specific research question at the heart of the project. The researcher is building a curated collection, not casting a wide net.
• Organize: All captured materials, notes, and drafts are consolidated within a single, dedicated Project folder, for example, Projects/NSF-Grant-2025-Background. This creates a self-contained intellectual workspace, ensuring all relevant information is co-located and easily accessible, minimizing context switching.
• Distill: This is the most critical activity in the Deep Dive model. Each selected pre-print is subjected to a rigorous and deep distillation process. The researcher creates a detailed set of atomic notes for each paper, covering its core hypothesis, experimental design, key results, statistical methods, stated limitations, and potential future directions. The technique of Progressive Summarization is applied meticulously to these notes over multiple sessions. Crucially, as the notes are distilled, they are heavily interlinked, creating a dense conceptual map of the literature within the project folder.
• Express: The distilled atomic notes are not left as isolated fragments. They are continuously synthesized into a coherent narrative within a single, long-form Markdown document, such as literature_review.md, which serves as the central "index" page for the project in the mdBook structure. This document is not a final product but a "living" synthesis that is updated in real-time as new pre-prints are analyzed and new connections between ideas are discovered. mdBook renders this document and all its supporting atomic notes into a navigable website, representing the current state of the researcher's understanding.

4.3 Social Outreach and Collaboration

The collaborative component of this model moves beyond public broadcast to a more intimate and structured form of feedback, leveraging modern web annotation technologies.

• Targeted Sharing: The URL for the "living" literature review, generated by mdBook, is shared not with the general public, but with a select group of trusted individuals—a thesis advisor, lab mates, a program officer, or a small circle of expert colleagues.
• Hypothesis Integration: The key collaborative tool is a web annotation service like Hypothesis.26 A small JavaScript snippet is added to the mdBook site's theme, enabling the Hypothesis sidebar on every page. This allows invited collaborators to engage with the text directly and asynchronously. They can highlight a specific sentence, paragraph, or figure and leave a comment, question, or critique anchored to that precise location.28
• Structured Dialogue: This process transforms the feedback loop. Instead of receiving a single email with high-level comments, the researcher receives a series of targeted, in-context annotations. A collaborator can question a specific interpretation of a result, suggest a missing citation directly where it should go, or debate a methodological critique right next to the text in question. This creates a rich, structured dialogue that is far more actionable and efficient than traditional feedback methods. It turns the solitary, often arduous process of a literature review into a dynamic, social, and iterative conversation, significantly improving the rigor and quality of the final scholarly product while strengthening the researcher's professional network.

4.4 Technical Implementation

The technical requirements for this model are relatively light, focusing on content structure and the integration of a third-party tool.

• Knowledge Base: mdBook is used to structure the project, with the main literature_review.md file serving as the core text and individual atomic notes for each paper organized as sub-pages.18
• Hosting: The static site generated by mdBook needs to be hosted on a simple web server to be accessible to collaborators. This can be easily accomplished using services like GitHub Pages, Netlify, or a personal server.
• Annotation Layer: The Hypothesis client is integrated by adding its universal embed script to the <head> section of the mdBook HTML template. This is a one-time modification to the theme that enables the annotation functionality across the entire site.27 The researcher can then create a private Hypothesis group and share the invitation link with their chosen collaborators, ensuring the conversation remains confidential.

Chapter 5: The "Heuristic Filter" Model: Quality Assessment and Collaborative Vetting

5.1 Concept

This model directly confronts the "veracity" problem inherent in the pre-print ecosystem.2 Its purpose is to move beyond passive consumption and establish a rigorous, transparent, and collaborative framework for assessing the quality and credibility of pre-print research. The researcher develops a personal or group-based set of heuristics for evaluation and then applies this framework in a structured process modeled directly on the peer review systems used in professional software development. The output is not just a summary of a paper, but a detailed, public, and citable assessment of its strengths and weaknesses. This model is ideal for researchers interested in meta-science, reproducibility, or for organizing a high-level journal club.

5.2 BASB Workflow

The workflow is methodical and structured, culminating in a formal assessment document that is itself subjected to peer review.

• Capture: A single pre-print is selected for a deep, critical vetting. The selection might be based on its potential impact, its controversial claims, or its relevance to an ongoing debate in the field.
• Organize: A new, dedicated Project is created for the assessment, for example, Projects/Vetting-Smith-et-al-2025.
• Distill: This stage involves a critical analysis of the pre-print through the lens of a predefined set of quality heuristics. These heuristics are themselves a key intellectual asset stored within the Resources section of the researcher's Second Brain. They are developed over time by synthesizing best practices from the literature on research assessment.7 Key heuristic categories include:
  • Author and Institutional Reputation: Examining the authors' track records and affiliations, while being mindful of potential biases against early-career researchers.4
  • Openness and Transparency Cues: Checking for the public availability of data, analysis code, and study pre-registration, which are strong signals of credibility.31
  • Methodological Soundness: Assessing whether the abstract formulates a clear hypothesis, if the experiments are well-designed to test it, and if appropriate controls are used.30
  • Independent Verification Cues: Evaluating the consistency of the findings with other independent sources in the literature.31
  • Citation Analysis: Looking at the cited references to ensure they are relevant and up-to-date.7
• Express: The researcher's analysis is not kept as a series of fragmented notes. It is synthesized and formally written up as a structured Markdown document, assessment.md, within the project folder. This document methodically steps through the heuristics, providing evidence-based commentary on how the pre-print performs on each dimension.

5.3 Social Outreach and Collaboration: The "Pull Request for Peer Review"

This model's core innovation is its collaborative component, which repurposes the robust and highly effective code review workflow from software engineering for academic peer review.32 This "Pull Request (PR) for Peer Review" process takes place on a platform like GitHub.

• Step 1: The "Issue": The process begins by opening a new Issue in a dedicated GitHub repository. This issue serves as a public proposal to vet a specific pre-print, allowing for initial high-level discussion and for others to signal their interest in participating.
• Step 2: The "Branch": The primary researcher creates a new Git branch locally, named something like review/smith-et-al-2025. On this branch, they add their drafted assessment.md file. This isolates the work-in-progress from the main, published body of assessments.24
• Step 3: The "Pull Request": The researcher pushes the branch to GitHub and opens a Pull Request. A PR is a formal request to merge the changes from their review branch into the main branch of the repository. In the PR description, they provide a summary of their assessment and explicitly request reviews from two or three trusted colleagues by @-mentioning their GitHub usernames.32
• Step 4: The "Review": The invited collaborators receive a notification and can now review the assessment within the GitHub web interface. This is a powerful, structured environment for feedback. They can view the "diff," which highlights every addition and change. They can leave comments directly on specific lines of the assessment.md file, asking for clarification, suggesting alternative phrasing, or challenging a particular interpretation. This creates an asynchronous, threaded conversation anchored precisely to the text being reviewed.32
• Step 5: The "Merge": The primary researcher incorporates the feedback, pushing new commits to the branch which automatically update the PR. Once all collaborators have approved the changes and a consensus is reached, the Pull Request is "merged." This action incorporates the finalized assessment.md into the main branch, where it becomes a permanent part of the public knowledge base.

This workflow transforms peer review from an opaque, private process into a transparent, collaborative, and educational one. The entire history of the discussion is preserved, and the final product is a community-vetted piece of scholarship.

5.4 Technical Implementation

This is the most technically intensive model, requiring the tight integration of several tools. The following table outlines the configuration.

Table 2: Toolchain Configuration for the Heuristic Filter Model

Chapter 6: The "Emergent Synthesis" Model: Zettelkasten for Novel Hypothesis Generation

6.1 Concept

This model is optimized for creativity, serendipity, and the generation of novel research hypotheses. It draws inspiration from the Zettelkasten (slip-box) method, treating the Second Brain not as an organized library of papers, but as a dynamic, interconnected network of individual ideas. The primary goal is to foster surprising connections between concepts, often from disparate fields, that can spark new lines of inquiry. This approach is less about systematically covering a field and more about cultivating a rich intellectual environment from which original thought can emerge organically.

6.2 BASB Workflow

The workflow prioritizes breadth of input and density of connections over hierarchical organization.

• Capture: The capture process is broad, opportunistic, and interdisciplinary. The researcher makes a conscious effort to capture pre-prints and other materials from well outside their core Area of expertise. An immunologist might capture a pre-print from computer science on network theory, or a historian might save an article from quantitative biology. These diverse inputs are typically placed in the Resources folder, seeding the system with varied conceptual raw material.
• Organize/Distill: This is where the Zettelkasten philosophy is most apparent. The focus is on creating extremely atomic, single-idea notes. For each captured pre-print, the researcher breaks it down into its constituent conceptual parts, with each part becoming a separate Markdown file. The most critical activity during this stage is the creation of explicit, bi-directional links between notes. Using simple Markdown link syntax (e.g., ]), the researcher actively connects new ideas to existing ones in the system. A note on a new machine learning technique might be linked to a previous note on a biological problem it could potentially solve. This process, over time, creates a dense, non-hierarchical web of interconnected knowledge.10
• Express: The expression stage in this model is exploratory and generative. The researcher periodically and intentionally "gets lost" in their network of notes. They might start with one note and follow the chain of links, observing the path they take. The goal is to identify surprising adjacencies and emergent clusters of connected ideas. When a group of linked notes suggests a novel connection or a potential new hypothesis, the researcher creates a "Synthesis Note." This is a short, often speculative essay that articulates the emergent idea, explains the connection between the constituent notes, and outlines a potential research question.

6.3 Social Outreach and Collaboration

The social strategy for this model is to "think in public" and use external feedback as a catalyst for refining nascent ideas.

• Sharing Speculative Ideas: The Synthesis Notes, once drafted, are published on the mdBook site. These are not presented as finished research but as explorations in progress. They are then shared on platforms that encourage deep, thoughtful discussion, such as a personal research blog, a relevant Substack newsletter, or specialized academic forums.
• Conceptual Resonance Testing: The goal of sharing is not to claim a discovery but to test the conceptual resonance of the new idea. The researcher is effectively asking the community: "Is this an interesting line of thought? Has someone already explored this connection? What critical perspective or piece of literature am I missing?"
• Feedback as Fuel: The feedback received—whether it's supportive, critical, or points to related work—is immensely valuable. This external input is captured back into the Second Brain as new atomic notes, which are then linked to the original Synthesis Note and its sources. This creates a feedback loop where public discourse directly informs and refines the private network of ideas, helping to mature a speculative thought into a viable, well-grounded research hypothesis.

6.4 Technical Implementation

The technical setup is similar to other models but may benefit from customizations that enhance the visibility of the note network.

• Knowledge Base: mdBook provides the basic structure for publishing the notes.18 The organizational hierarchy of the
  SUMMARY.md file is less important here than the network of links within the notes themselves.
• Link Visualization: To better support the exploratory nature of this model, the mdBook theme can be customized. A common and highly effective customization is to add a "Backlinks" section to the bottom of each page. This section would be dynamically populated (using a small script during the build process) with a list of all other notes in the system that link to the current note. This makes the network bi-directionally navigable and greatly enhances the ability to discover connections.
• Organization: While PARA is still used for high-level organization, the primary structure of the knowledge base is emergent, defined by the dense web of inter-note links rather than a rigid folder hierarchy.

Chapter 7: The "Pedagogical Pathway" Model: Transforming Research into Educational Resources

7.1 Concept

This model is centered on the act of translation: transforming the dense, complex, and often jargon-laden research presented in pre-prints into clear, accessible, and effective educational materials. The primary user of this system is a researcher who is also an educator, mentor, or passionate science communicator. The goal is to leverage the Second Brain not only for personal understanding but also as a factory for producing high-quality teaching resources for students, junior colleagues, or even a scientifically curious lay audience. This process has a dual benefit: it creates a valuable public good and, in the process of teaching, deeply solidifies the researcher's own understanding of the material.

7.2 BASB Workflow

The workflow is structured around the pedagogical goal of clarification and simplification.

• Capture: The researcher selectively captures pre-prints that are seminal, represent a significant breakthrough, or introduce a complex new technique or concept to the field. The criteria for selection are not just research relevance but pedagogical potential.
• Organize: Each educational resource is treated as a distinct Project. For example, a project might be named Projects/Module-Explaining-AlphaFold or Projects/Tutorial-CRISPR-Basics.
• Distill: This is the core of the pedagogical model. The distillation process goes beyond mere summarization; it is an act of translation. The researcher breaks down the complex pre-print into its fundamental conceptual components. For each component, they create atomic notes focused on answering key pedagogical questions: What is the core idea in the simplest possible terms? What is a good analogy or metaphor for this concept? How can this be visualized? What prerequisite knowledge is required to understand this? The goal is to strip away the jargon and reveal the elegant underlying principles.
• Express: The distilled and translated concepts are reassembled into a coherent pedagogical narrative. This narrative is structured as a lesson, tutorial, or module within mdBook. It might include sections like "Background Concepts," "The Central Problem," "The Core Innovation," "A Step-by-Step Walkthrough," and "Why This is a Breakthrough." The book-like format of mdBook is perfectly suited for this, allowing the creation of a structured, multi-page educational resource with clear navigation.18

7.3 Social Outreach and Collaboration

The collaborative component of this model is a closed-loop feedback system designed to test and refine the educational materials with a target audience.

• Targeted Feedback Loop: Instead of broadcasting to the public, the mdBook-generated educational module is shared with a specific group of learners. This could be the students in a graduate seminar, members of a lab journal club, or a group of undergraduate researchers.
• Clarity Review: The learners are tasked with a specific mission: to review the material not for scientific accuracy (which is the researcher's responsibility) but for clarity. They are encouraged to identify any points of confusion, ambiguous explanations, or sections that are difficult to follow.
• Feedback Mechanisms: The feedback can be collected through various channels. A simple, low-tech solution is a shared Google Doc where learners can leave comments. A more structured approach would be to use the repository's GitHub Issues, where each point of confusion can be logged as a separate issue. The most integrated solution would be to use a web annotation tool like Hypothesis, allowing learners to ask questions and flag confusing sentences directly within the context of the lesson.26
• Symbiotic Relationship: This process creates a powerful symbiotic relationship. The learners gain access to educational materials on cutting-edge topics that are far more current than any textbook. The researcher, in turn, receives invaluable feedback that allows them to refine their explanations and improve the quality of the resource. This act of teaching and refining solidifies their own mastery of the subject and builds their reputation as both a leading expert and an effective and dedicated educator. The final, polished module becomes a lasting contribution to the field's educational commons.

7.4 Technical Implementation

The technical setup for this model is straightforward and leverages the inherent strengths of the chosen toolchain.

• Knowledge Base: mdBook is the ideal tool for this model. Its native ability to create a structured, book-like website with chapters and sub-chapters maps directly onto the structure of a course module or a multi-part tutorial.18
• Collaboration Tools: The choice of collaboration tool can be tailored to the technical comfort of the learner audience. It can range from simple, universal tools like email or shared documents to more integrated platforms like GitHub Issues or Hypothesis, which provide a more structured feedback environment.26 No complex custom development is required.

Conclusion: Integrating the Second Brain into the Scholarly Workflow

This report has detailed five distinct models for developing a Personal Knowledge Management system tailored to the unique demands of investigating scholarly pre-print archives. These models—The Pre-print Digest, The Deep Dive, The Heuristic Filter, The Emergent Synthesis, and The Pedagogical Pathway—are not merely theoretical constructs. They are a portfolio of practical, actionable strategies that can be adopted, adapted, or combined to suit the specific needs of a researcher at different stages of a project or career. From the broad surveillance required when entering a new field to the deep focus needed for a grant proposal, and from the creative exploration that sparks novel hypotheses to the structured collaboration that ensures rigor, these frameworks provide a comprehensive toolkit for the modern scholar.

The central argument woven through these models is that a well-designed Second Brain, built upon the principles of CODE and PARA and implemented with a durable, sovereign technical stack, transcends its function as a mere organizational tool. It is not a passive filing system for papers or a glorified to-do list. It is a strategic asset. By systematically capturing, organizing, and distilling knowledge, it accelerates the fundamental feedback loops of research: learning, synthesis, and creation. Furthermore, by integrating a deliberate "Express" layer for social outreach and collaboration, it provides a mechanism for systematically translating private intellectual labor into public reputation, professional impact, and meaningful contributions to the scientific community.

Looking ahead, the potential for these systems is vast. The integration of advanced AI tools for automated summarization, concept extraction, and semantic search will likely further enhance the capabilities of the Second Brain. These technologies could automate the initial layers of progressive summarization or suggest novel connections between notes, acting as an intellectual amplifier. This evolution will further blur the line between the researcher's biological "first brain" and their digital "second brain," creating a powerful human-machine partnership that augments and accelerates the entire process of scientific discovery. Ultimately, the commitment to building and maintaining such a system is a commitment to a more intentional, productive, and impactful scholarly life.

Works cited

1. arXiv.org e-Print archive, accessed September 7, 2025, https://arxiv.org/
2. Preprints - Open Access Network, accessed September 7, 2025, https://open-access.network/en/information/publishing/preprints
3. bioRxiv.org - the preprint server for Biology, accessed September 7, 2025, https://www.biorxiv.org/
4. Preprints in Academic Assessment | DORA, accessed September 7, 2025, https://sfdora.org/2021/08/30/preprints-in-academic-assessment/
5. The Pros and Cons of Preprints - MDPI Blog, accessed September 7, 2025, https://blog.mdpi.com/2023/03/27/preprints-pros-cons/
6. medRxiv.org - the preprint server for Health Sciences, accessed September 7, 2025, https://www.medrxiv.org/
7. How to Approach Preprints for Quality Science Reporting? - ENJOI, accessed September 7, 2025, https://enjoiscicomm.eu/how-to-approach-preprints-for-quality-science-reporting/
8. Building a Second Brain, accessed September 7, 2025, https://www.buildingasecondbrain.com/
9. Building a Second Brain: The Definitive Introductory Guide - Forte Labs, accessed September 7, 2025, https://fortelabs.com/blog/basboverview/
10. Build a second brain - Workflowy guide, accessed September 7, 2025, https://workflowy.com/systems/build-a-second-brain
11. RSS Feeds Instructions for Databases · Library "How To" Guides, accessed September 7, 2025, https://library.concordia.ca/help/using/rss/exporting.php
12. How to use RSS to follow the Scientific Literature - Fraser Lab, accessed September 7, 2025, https://fraserlab.com/philosophy/rss_how_to/
13. Subscribe to Preprint RSS Feeds - OSF Support, accessed September 7, 2025, https://help.osf.io/article/185-subscribe-to-preprint-rss-feeds
14. arXiv API Access - arXiv info - About arXiv, accessed September 7, 2025, https://info.arxiv.org/help/api/index.html
15. Organize Your Second Brain: Part 1 — How to Use the PARA Method - Web Highlights, accessed September 7, 2025, https://web-highlights.com/blog/master-your-second-brain-part-1-how-to-use-the-para-method/
16. Building a Second Brain Resource Guide, accessed September 7, 2025, https://www.buildingasecondbrain.com/resources
17. Zola, accessed September 7, 2025, https://www.getzola.org/
18. myles/awesome-static-generators: A curated list of static web site generators. - GitHub, accessed September 7, 2025, https://github.com/myles/awesome-static-generators
19. GitBook vs mdBook: Choosing the Best Documentation Tool | by AI Rabbit | Medium, accessed September 7, 2025, https://medium.com/@airabbitX/my-journey-with-gitbook-and-mdbook-navigating-documentation-tools-5d653f76d58f
20. Shokunin, the fastest Rust-based Static Site Generator (SSG), accessed September 7, 2025, https://shokunin.one/
21. Open source alternatives to Gitbook, accessed September 7, 2025, https://opensourcealternative.to/alternativesto/gitbook
22. gitworkflows Documentation - Git, accessed September 7, 2025, https://git-scm.com/docs/gitworkflows
23. Academic Benefits of Using git and GitHub - Walking Randomly, accessed September 7, 2025, https://walkingrandomly.com/?p=6653
24. Resources on how to effectively use GitHub as an academic team - Reddit, accessed September 7, 2025, https://www.reddit.com/r/github/comments/1lcmne6/resources_on_how_to_effectively_use_github_as_an/
25. Git Workflow | Atlassian Git Tutorial, accessed September 7, 2025, https://www.atlassian.com/git/tutorials/comparing-workflows
26. hypothesis | Learning Technology Help Desk at PCC - Portland Community College, accessed September 7, 2025, https://www.pcc.edu/help-desk/student/hypothes-is/
27. ETS - Hypothesis | myUSF, accessed September 7, 2025, https://myusf.usfca.edu/ets/educational-technologies/hypothesis
28. Hypothes.is – Information Technology Services - Carleton College, accessed September 7, 2025, https://www.carleton.edu/its/services/learning/hypothesis/
29. Collaborative Annotation Tools: Hypothesis & Perusall - Teaching Support and Innovation, accessed September 7, 2025, https://teaching.uoregon.edu/collaborative-annotation-tools-hypothesis-perusall
30. 6 Heuristics for Assessing the Quality of a Publication - Francesco Lelli, accessed September 7, 2025, https://francescolelli.info/thesis/6-heuristics-for-assessing-the-quality-of-a-publication/
31. Credibility of preprints: an interdisciplinary survey of researchers ..., accessed September 7, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC7657885/
32. GitHub Code Review, accessed September 7, 2025, https://github.com/features/code-review
33. Hypothesis: A Social Annotation Tool for Your Carmen Course | ASC Office of Distance Education - The Ohio State University, accessed September 7, 2025, https://ascode.osu.edu/hypothesis-social-annotation-tool-your-carmen-course

Miscellaneous References

1. How to Increase Knowledge Productivity: Combine the Zettelkasten ..., accessed August 12, 2025, https://zettelkasten.de/posts/building-a-second-brain-and-zettelkasten/
2. My Personal Knowledge Management System As a Software ..., accessed August 12, 2025, https://thewordyhabitat.com/my-personal-knowledge-management-system/
3. Personal Knowledge Management (PKM) - Data Engineering Blog, accessed August 12, 2025, https://www.ssp.sh/brain/personal-knowledge-management-pkm/
4. Combine Your Second Brain with Zettelkasten - Sudo Science, accessed August 12, 2025, https://sudoscience.blog/2024/12/27/combine-your-second-brain-with-zettelkasten/
5. FOR COMPARISON with mdBook ... Obsidian - Sharpen your thinking, accessed August 12, 2025, https://obsidian.md/
6. FOR COMPARISON with mdBook... Developers - Obsidian Help, accessed August 12, 2025, https://help.obsidian.md/developers
7. FOR COMPARISON with mdBook ... Home - Developer Documentation - Obsidian, accessed August 12, 2025, https://docs.obsidian.md/Home
8. Managing my personal knowledge base · tkainrad, accessed August 12, 2025, https://tkainrad.dev/posts/managing-my-personal-knowledge-base/
9. Engineering - Notion, accessed August 12, 2025, https://www.notion.com/help/guides/category/engineering
10. Junior to senior: An action plan for engineering career success ..., accessed August 12, 2025, https://github.com/readme/guides/engineering-career-success
11. AswinBarath/AswinBarath: A quick bio about myself - GitHub, accessed August 12, 2025, https://github.com/AswinBarath/AswinBarath
12. What Is Hugging Face? | Coursera, accessed August 12, 2025, https://www.coursera.org/articles/what-is-hugging-face
13. Hugging Face : Revolutionizing AI Collaboration in the Machine Learning Community | by Yuvraj kakkar | Medium, accessed August 12, 2025, https://medium.com/@yuvrajkakkar1/hugging-face-revolutionizing-ai-collaboration-in-the-machine-learning-community-28d9c6e94ddb
14. "Operator-Based Machine Intelligence: A Hilbert Space Framework ..., accessed August 12, 2025, https://www.reddit.com/r/singularity/comments/1mkwxzk/operatorbased_machine_intelligence_a_hilbert/
15. [2505.23723] ML-Agent: Reinforcing LLM Agents for Autonomous Machine Learning Engineering - arXiv, accessed August 12, 2025, https://arxiv.org/abs/2505.23723
16. Getting Started with Papers With Code – IT Exams Training ..., accessed August 12, 2025, https://www.pass4sure.com/blog/getting-started-with-papers-with-code/
17. Wolfram Mathematica: Modern Technical Computing, accessed August 12, 2025, https://www.wolfram.com/mathematica/
18. Mathematica & Wolfram Language Tutorial: Fast Intro for Math Students, accessed August 12, 2025, https://www.wolfram.com/language/fast-introduction-for-math-students/en/
19. How to start a tech blog in 6 steps - Wix.com, accessed August 12, 2025, https://www.wix.com/blog/how-to-start-a-tech-blog
20. How to Start a Tech Blog: Easy Guide for Beginners - WPZOOM, accessed August 12, 2025, https://www.wpzoom.com/blog/how-to-start-tech-blog/
21. Networking for Engineers: 8 Strategies to Expand Your Professional ..., accessed August 12, 2025, https://staffing.trimech.com/networking-for-engineers-8-strategies-to-expand-your-professional-circle/
22. Mastering Networking as a Software Developer: Strategies for Success : r/software_soloprenures - Reddit, accessed August 12, 2025, https://www.reddit.com/r/software_soloprenures/comments/1m363gv/mastering_networking_as_a_software_developer/
23. The Software Developer's Guide to Networking - Simple Programmer, accessed August 12, 2025, https://simpleprogrammer.com/software-developers-networking/
24. Participating in Open Source Communities - Linux Foundation, accessed August 12, 2025, https://www.linuxfoundation.org/resources/open-source-guides/participating-in-open-source-communities
25. How To Grow Your Career With a Software Engineering Mentor - Springboard, accessed August 12, 2025, https://www.springboard.com/blog/software-engineering/software-engineer-mentor/
26. Where to Find a Software Engineer Mentor (and How to Benefit From Them) | HackerNoon, accessed August 12, 2025, https://hackernoon.com/where-to-find-a-software-engineer-mentor-and-how-to-benefit-from-them
27. Improve your open source development impact | TODO Group // Talk ..., accessed August 12, 2025, https://todogroup.org/resources/guides/improve-your-open-source-development-impact/
28. Self-Directed Learning: A Four-Step Process | Centre for Teaching ..., accessed August 12, 2025, https://uwaterloo.ca/centre-for-teaching-excellence/catalogs/tip-sheets/self-directed-learning-four-step-process
29. 25 New Technology Trends for 2025 - Simplilearn.com, accessed August 12, 2025, https://www.simplilearn.com/top-technology-trends-and-jobs-article
30. Emerging Technology Trends - J.P. Morgan, accessed August 12, 2025, https://www.jpmorgan.com/content/dam/jpmorgan/documents/technology/jpmc-emerging-technology-trends-report.pdf
31. 5 AI Trends Shaping Innovation and ROI in 2025 | Morgan Stanley, accessed August 12, 2025, https://www.morganstanley.com/insights/articles/ai-trends-reasoning-frontier-models-2025-tmt
32. Llamaindex RAG Tutorial | IBM, accessed August 12, 2025, https://www.ibm.com/think/tutorials/llamaindex-rag
33. Build Your First AI Application Using LlamaIndex! - DEV Community, accessed August 12, 2025, https://dev.to/pavanbelagatti/build-your-first-ai-application-using-llamaindex-1f9
34. LlamaIndex - LlamaIndex, accessed August 12, 2025, https://docs.llamaindex.ai/
35. Fine-Tuning LLMs: A Guide With Examples | DataCamp, accessed August 12, 2025, https://www.datacamp.com/tutorial/fine-tuning-large-language-models
36. The Ultimate Guide to LLM Fine Tuning: Best Practices & Tools - Lakera AI, accessed August 12, 2025, https://www.lakera.ai/blog/llm-fine-tuning-guide
37. Fine-tuning LLMs Guide | Unsloth Documentation, accessed August 12, 2025, https://docs.unsloth.ai/get-started/fine-tuning-llms-guide
38. Building AI Agents Using LangChain and OpenAI APIs: A Step-by ..., accessed August 12, 2025, https://sen-abby.medium.com/building-ai-agents-using-langchain-47ba4012a8a1
39. LangGraph - LangChain, accessed August 12, 2025, https://www.langchain.com/langgraph
40. Build an Agent - ️ LangChain, accessed August 12, 2025, https://python.langchain.com/docs/tutorials/agents/
41. With AI at the core, Heizen has a new model for software development at scale, accessed August 12, 2025, https://economictimes.indiatimes.com/small-biz/security-tech/technology/with-ai-at-the-core-heizen-has-a-new-model-for-software-development-at-scale/articleshow/123156453.cms
42. 10 Best AI code generators in 2025 [Free & Paid] - Pieces App, accessed August 12, 2025, https://pieces.app/blog/9-best-ai-code-generation-tools
43. Generative AI In Software Development Life Cycle (SDLC) - V2Soft, accessed August 12, 2025, https://www.v2soft.com/blogs/generative-ai-in-sdlc
44. How an AI-enabled software product development life cycle will fuel innovation - McKinsey, accessed August 12, 2025, https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/how-an-ai-enabled-software-product-development-life-cycle-will-fuel-innovation
45. Generative AI in SDLC: Can GenAI Be Utilized throughout the Software Development Life Cycle? - EPAM Startups & SMBs, accessed August 12, 2025, https://startups.epam.com/blog/generative-ai-in-sdlc
46. Future of Data Engineering: Trends for 2025 - Closeloop Technologies, accessed August 12, 2025, https://closeloop.com/blog/data-engineering-key-trends-to-watch/
47. Tutorial - MLflow, accessed August 12, 2025, https://www.mlflow.org/docs/2.7.1/tutorials-and-examples/tutorial.html
48. 10 MLOps Projects Ideas for Beginners to Practice in 2025 - ProjectPro, accessed August 12, 2025, https://www.projectpro.io/article/mlops-projects-ideas/486
49. Tutorials and Examples - MLflow, accessed August 12, 2025, https://mlflow.org/docs/latest/ml/tutorials-and-examples/
50. Your First MLflow Model: Complete Tutorial, accessed August 12, 2025, https://mlflow.org/docs/latest/ml/getting-started/logging-first-model/
51. End-to-End MLOps Pipeline: A Comprehensive Project ..., accessed August 12, 2025, https://www.geeksforgeeks.org/machine-learning/end-to-end-mlops-pipeline-a-comprehensive-project/
52. Snowflake Data Mesh: The Ultimate Setup Guide (2025) - Atlan, accessed August 12, 2025, https://atlan.com/snowflake-data-mesh-how-to-guide/
53. What Is Data Mesh? Complete Tutorial - Confluent Developer, accessed August 12, 2025, https://developer.confluent.io/courses/data-mesh/intro/
54. Data Mesh Implementation: Your Blueprint for a Successful Launch - Ascend.io, accessed August 12, 2025, https://www.ascend.io/blog/data-mesh-implementation-your-blueprint-for-a-successful-launch
55. Ten More Top Emerging Technologies In 2025 - Forrester, accessed August 12, 2025, https://www.forrester.com/report/ten-more-top-emerging-technologies-in-2025/RES183100
56. What Is Quantum Computing? | IBM, accessed August 12, 2025, https://www.ibm.com/think/topics/quantum-computing
57. Introduction to Qiskit | IBM Quantum Documentation, accessed August 12, 2025, https://quantum.cloud.ibm.com/docs/guides/
58. Quantum computing - Wikipedia, accessed August 12, 2025, https://en.wikipedia.org/wiki/Quantum_computing
59. Introduction to quantum computing, accessed August 12, 2025, https://thequantuminsider.com/introduction-to-quantum-computing/
60. Introduction to Qiskit | IBM Quantum Documentation, accessed August 12, 2025, https://quantum.cloud.ibm.com/docs/guides
61. How do people do Open Source Contributions ? : r/csharp - Reddit, accessed August 12, 2025, https://www.reddit.com/r/csharp/comments/1bxprbo/how_do_people_do_open_source_contributions/
62. Good First Issue: Make your first open-source contribution, accessed August 12, 2025, https://goodfirstissue.dev/
63. For Good First Issue | Make your next open-source contribution matter. - GitHub, accessed August 12, 2025, https://forgoodfirstissue.github.com/
64. MunGell/awesome-for-beginners: A list of awesome beginners-friendly projects. - GitHub, accessed August 12, 2025, https://github.com/MunGell/awesome-for-beginners
65. For Good First Issue: Introducing a new way to contribute - The GitHub Blog, accessed August 12, 2025, https://github.blog/open-source/social-impact/for-good-first-issue-introducing-a-new-way-to-contribute/
66. How to Contribute to Open Source, accessed August 12, 2025, https://opensource.guide/how-to-contribute/
67. Find Open Source Projects to Contribute: A Developer's Guide, accessed August 12, 2025, https://osssoftware.org/blog/find-open-source-projects-to-contribute-a-developers-guide/
68. A Software Developer's Guide to Writing - DEV Community, accessed August 12, 2025, https://dev.to/tyaga001/a-software-developers-guide-to-writing-bgj
69. Building an Online Presence In Tech 101 - SheCanCode, accessed August 12, 2025, https://shecancode.io/building-an-online-presence-in-tech-101/
70. How to write a coding tutorial | Yost's Posts, accessed August 12, 2025, https://www.ryanjyost.com/how-to-write-a-coding-tutorial/
71. Creating the Best Video Programming Tutorials | Vue Mastery, accessed August 12, 2025, https://www.vuemastery.com/blog/creating-the-best-video-programming-tutorials/
72. A tutorial on creating coding tutorials - LogRocket Blog, accessed August 12, 2025, https://blog.logrocket.com/a-tutorial-on-creating-front-end-tutorials-2b13d8e94df9/
73. How to Create a Technical Video Tutorial | Elastic Blog, accessed August 12, 2025, https://www.elastic.co/blog/elastic-contributor-program-how-to-create-a-video-tutorial
74. How to Make Engaging Programming Videos - Real Python, accessed August 12, 2025, https://realpython.com/how-to-make-programming-videos/
75. One-on-one mentorship with software engineers - CodePath, accessed August 12, 2025, https://www.codepath.org/career-services/mentorship
76. Find a Software Engineering mentor - MentorCruise, accessed August 12, 2025, https://mentorcruise.com/filter/softwareengineering/
77. Logseq vs. Obsidian: first impressions - Share & showcase, accessed August 13, 2025, https://forum.obsidian.md/t/logseq-vs-obsidian-first-impressions/56854
78. 6 ways Logseq is the perfect Obsidian alternative - XDA Developers, accessed August 13, 2025, https://www.xda-developers.com/ways-logseq-is-the-perfect-obsidian-alternative/
79. Electron vs Tauri - Coditation, accessed August 13, 2025, https://www.coditation.com/blog/electron-vs-tauri
80. Framework Wars: Tauri vs Electron vs Flutter vs React Native - Moon Technolabs, accessed August 13, 2025, https://www.moontechnolabs.com/blog/tauri-vs-electron-vs-flutter-vs-react-native/
81. Modular: A Fast, Scalable Gen AI Inference Platform, accessed August 13, 2025, https://www.modular.com/
82. MAX: AI Compute Platform - Modular, accessed August 13, 2025, https://www.modular.com/max
83. apache beam vs apache kafka: Which Tool is Better for Your Next Project? - ProjectPro, accessed August 13, 2025, https://www.projectpro.io/compare/apache-beam-vs-apache-kafka
84. Apache Beam over Apache Kafka Stream processing - Codemia, accessed August 13, 2025, https://codemia.io/knowledge-hub/path/apache_beam_over_apache_kafka_stream_processing
85. Apache Beam: Introduction to Batch and Stream Data Processing - Confluent, accessed August 13, 2025, https://www.confluent.io/learn/apache-beam/
86. Quantum Programming Languages: A Beginner's Guide for 2025 - BlueQubit, accessed August 13, 2025, https://www.bluequbit.io/quantum-programming-languages
87. What are the best-known quantum programming languages (e.g., Qiskit, Quipper, Cirq)?, accessed August 13, 2025, https://milvus.io/ai-quick-reference/what-are-the-bestknown-quantum-programming-languages-eg-qiskit-quipper-cirq
88. Hello Many Worlds in Seven Quantum Languages - IonQ, accessed August 13, 2025, https://ionq.com/docs/hello-many-worlds-seven-quantum-languages
89. Neuromorphic Hardware Guide, accessed August 13, 2025, https://open-neuromorphic.org/neuromorphic-computing/hardware/
90. Embedded Neuromorphic Computing Systems - MCSoC-2025, accessed August 13, 2025, https://mcsoc-forum.org/site/index.php/embedded-neuromorphic-computing-systems/
91. OpenBCI – Open-source EEG, accessed August 13, 2025, https://www.opensourceimaging.org/project/openbci/
92. Community Page Projects - OpenBCI Documentation, accessed August 13, 2025, https://docs.openbci.com/Examples/CommunityPageProjects/
93. Example Projects - OpenBCI Documentation, accessed August 13, 2025, https://docs.openbci.com/Examples/ExamplesLanding/
94. EEG Headsets and Software for Education - EMOTIV, accessed August 13, 2025, https://www.emotiv.com/pages/education
95. EEG Monitoring – EMOTIV, accessed August 13, 2025, https://www.emotiv.com/blogs/glossary/eeg-monitoring
96. EEG Headset - Emotiv, accessed August 13, 2025, https://www.emotiv.com/blogs/glossary/eeg-headset
97. Developing AR/VR/MR/XR Apps with WebXR, Unity & Unreal - Coursera, accessed August 13, 2025, https://www.coursera.org/learn/develop-augmented-virtual-mixed-extended-reality-applications-webxr-unity-unreal
98. WebXR Academy, accessed August 13, 2025, https://webxracademy.com/
99. Top VR Education Companies in 2025 - Axon Park, accessed August 13, 2025, https://www.axonpark.com/top-vr-education-companies-in-2025/
100. The Future of VR in Education: Immersive Learning Experiences, accessed August 13, 2025, https://www.immersivelearning.news/2025/06/19/the-future-of-vr-in-education-immersive-learning-experiences/
101. Streamlit vs FastAPI: Choosing the Right Tool for Deploying Your Machine Learning Model | by Pelumi Ogunlusi | Jul, 2025 | Medium, accessed August 13, 2025, https://medium.com/@samuelogunlusi07/streamlit-vs-fastapi-choosing-the-right-tool-for-deploying-your-machine-learning-model-1d16d427e130
102. Compare Streamlit vs. Tauri in 2025, accessed August 13, 2025, https://slashdot.org/software/comparison/Streamlit-vs-Tauri/
103. Monica: Personal CRM done right, accessed August 13, 2025, https://www.monicahq.com/
104. monicahq/monica: Personal CRM. Remember everything about your friends, family and business relationships. - GitHub, accessed August 13, 2025, https://github.com/monicahq/monica
105. rust-lang/mdBook: Create book from markdown files. Like Gitbook but implemented in Rust, accessed August 13, 2025, https://github.com/rust-lang/mdBook
106. Freelancer API for Developers, accessed August 13, 2025, https://developers.freelancer.com/
107. API Developer Freelance Jobs: Work Remote & Earn Online - Upwork, accessed August 13, 2025, https://www.upwork.com/freelance-jobs/api-development/
108. How to Start a Podcast: Step-by-Step Guide & Free Checklist - Riverside, accessed August 13, 2025, https://riverside.com/blog/how-to-start-a-podcast

Project Overview

This landing page will feature a list of ongoing PROJECTS. We will develop a template after we have experience with several examples.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The BASB method systematically manages information differently than just notetaking apps ... PROJECTS, have goals, reqmts and deadlines ... AREAS are about roles/responsibilities or obligations or capabilities that need to be earnestly developed ... RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... ARCHIVES, inactive matl from P A R that shouldn't be used, except for informational purposes.

GitHub Discussion, Issue, Project Functionality

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

Personal Knowledge Mgmt Agents -- A 52-Week arXiv Curriculum In Building A Better Brain

My intention now is more intently upon planning the year ahead IN THINKING.

It is more of an evolution, than a revolution ... it will ALWAYS be true that I am looking for better knowledge engineering tools; that always was true, but even moreso no ... I will ALWAYS be working today on making tomorrow better, working tomorrow on making the week ahead better, working in the week ahead on making the next month better ... with a serious intention of making the next 52 weeks into the best year in the history of 52 week periods.

Since I don't have that many years or maybe days or hours left in life, I need to be more blunt about my time management and prioritization.

There is NO TIME WHATSOEVER for nostalgia, reunions, funerals or any form of looking back.

I will REPEAT for emphasis, if anyone was not paying attention.

There is NO TIME WHATSOEVER for nostalgia, reunions, funerals or any form of looking back.

Other people can do things in their own way, but in my case ... I am going to allow the DEAD to bury their dead ... and I am absolutely dead serious about that -- from now on, there is NO TIME WHATSOEVER for nostalgia, reunions, funerals or any form of looking back. NONE!

Planning the system, then living and improving the system.

Plans are always imperfect, good intentions pave the road to hell ... but the whole point of planning is not the document, but SUCK that comes from when plans don't pan out -- embracing the SUCK means finding and embracing the root cause of the failure and caving in the melon of that demon.

Planning is not navel gazing, but instead 99% of it is the process of implementing, then failing ... then refactoring, revising and changing the plan ... the POINT of a plan is to have a starting roadmap to work from, while realizing that as soon as the work starts, the plan will need to be completely overhauled and adjusted, because new OPPORTUNITIES will arise.

Finding the root cause of future failures is why we LOOK FORWARD ... we plan to be able to accomplish early detection, we plan to EMBRACE the neck of root cause demon and cave its melon in ... in terms of planning for the FIGHT AHEAD, we have to PLAN for the likelihood of being punched in the face; we have to plan for desparately wanting to quit.

The MOST IMPORTANT part of planning is gratitude discipline which is ALWAYS, ALWAYS, ALWAYS realizing that the situation is far better than one hoped for, although almost certainly not exactly what one hoped for, ie the plan will NEED TO BE adjusted -- that's the REASON for why planning and preparation are key.

A Second-Brain Curriculum for One Ordinary Working Person

Free. Self-led. No tool required. No branding. No system to buy.

Soli Deo gloria.

0. Why bother

You are going to be programmed either way.

That is not a rhetorical flourish. It is a description of how a person is made. What you read this week, what you scroll, whose voice you let into the room and how often — that becomes the material you think with, and it shapes your attention long before you have any say about the shape. There is no neutral setting. The only real question is whether you are the one doing it on purpose.

This document is about doing it on purpose. It is long, it is dull in places, and it asks for an hour a week for a year. Here is the case for the hour.

The short answer

A second brain is not a filing cabinet. It is a harness — the structure your thinking runs inside. And a badly built harness does not merely slow you down. It quietly determines what you are able to think, the way a badly laid out workshop determines what can be built in it, and a badly chosen vocabulary determines what can be said.

Everything else in these pages is detail. This is the claim.

This is not new, and the last time it happened it changed everything

There is a phrase, the People of the Book, and it was coined by outsiders as a category — but it stuck because it was accurate. Jews and Christians were the people whose God had written something down, and who were expected to read it.

A community organized around a text behaves differently from a community organized around memory and custom. It can argue with itself across centuries. It can compare readings at a distance. It can hold a standard that is not the person currently in charge. You cannot have "it is written" without a place to write it, and you cannot have a reformation without people who own copies.

Two further things came out of that soil, and both are load-bearing here.

The first is that every human bears the image of God. Not the king, not the priest, not the literate — every human. That claim installs moral agency and individual conscience at the centre of a person, and it implies that an ordinary person's judgment about what is true is worth something. Historians still argue about how much of Western political thought descends from that claim versus arriving independently, and this document does not need to settle it. What it needs is the smaller, plainly observable fact: people who can read, and who know they are responsible for what they read, become a different kind of people. As do their children.

The second is that print changed the speed at which all of this could happen. Scattered communities could finally compare the same page instead of comparing memories. Argument became cumulative. Access stopped being a privilege of the few.

The important part is not that literacy made people cleverer. It is that literacy made a particular kind of thinking possible for ordinary people: holding many sources at once, in one head, over time, and then putting them in a new order. That is the entire ambition of a second brain. The printing press is its ancestor, and the family resemblance is not a metaphor.

What is actually NEW now ... with agentic harness engineering

Two things, and they are why this is worth doing now rather than way back in 2026 or decades before.

Your notes become much MORE a part of your future mind, not a record of its past. That is not mysticism; it is a mundane observation about how anyone does arithmetic, keeps an appointment, or thinks through a decision on paper. The notebook is in the loop. Good notetaking skills always mattered for actually dwelling on different facets and actually LEARNING material as one did more problems or exposed weaknesses in understanding, but now iterative improvements that are part of good notetaking or improving agent skills [after failures] are even more important. If the notebook is disordered, the loop is disordered, and you will experience the disorder as a personal failing rather than as a property of the harness. As we move into the realm of crafting better and better agentic skills and the trajectories of building knowledge graphs, the process of notetaking and ruminating on those notes becomes even more intensely part of our consciousness, ie we must really THINK about how we want our agents to think as they gather information and perform tasks that shape our human connections and drive our future interactions.

And the reader is no longer only you. Whatever you write down, and however you structure it, is now also the material that your tools reason from ... and that material can be cloned and used by others, in the way that Paul's letters not only were for Paul to clarify his ideas, but they also shaped the ideas of the revolutionary, evangelical body of believers in Jesus Christ. Assistants, search, agents, automations — all of them inherit your structure and your omissions. A vault with no stated purpose produces confident answers to the wrong question, at scale, quickly. A vault with an explicit purpose and a clean set of containers is something closer to an executable specification: not just a place you remember things, but a briefing you can hand to something that will work while you sleep.

That is what people mean when they talk about harness engineering for agentic systems. The interesting part is not the agents. It is the harness — and the harness is your second brain, which is why it is worth a year rather than an afternoon.

The Big Why has to be written down, or it is a mood

Ask why five times and you find out what you actually want. Most chains stop early. Why organize my notes? So I can find things. Why? So I can finish work. Why? So I can do my job. Why? — and here almost everyone runs out of words, because the fourth answer was the last one they had ever said out loud.

A purpose that survives five why's is a purpose. A purpose that stops at so I can be more productive is a feeling with a calendar attached.

And your notes are where the answer becomes checkable. Not because the notes are a spiritual instrument, but because they are a truthful record of what you actually attended to. You can say what you love. Your last three months of captures will tell me what you loved, and the two accounts will not always agree. That gap is the most useful thing in this entire document, and the whole year is a way of closing it.

So the Big Why here is not an abstraction and it is not a productivity goal. It is stated plainly, once: to adore and imitate Jesus Christ — not a figure in a stained-glass window, but a person who lived in a world with bodies in it, interruptions in it, Roman roads in it, and neighbors in it who were frequently inconvenient. Everything below is an attempt to be more useful to that. Ordering what you know is not the point; it is the preparation for the point.

This also rules out a counterfeit that is very popular. Compassion that only distributes is not compassion. Handing somebody calories, or a check, or an opinion, or a link, and calling it love, is usually a transaction that makes the giver feel finished. Love that actually helps requires knowledge — of the person, of the problem, of what has already been tried and already failed. That knowledge has to be collected, sorted, remembered, and kept current. There is no shortcut, and the people who skip the collection phase are the ones who keep helping in ways that do not help.

Why a year

Because this is a gigantic task, and gigantic tasks are done in small pieces by people who keep showing up.

Not because a year is sacred. Because the thing being changed is not your software, it is your reflexes — what you reach for when something arrives, what you do on a Friday afternoon, what happens in the third week of a bad month. Reflexes do not change in a weekend and they are not changed by reading. They change by repetition, under load, with somebody watching, and then they change again next year because you are not the same person.

That is also why this schedule is meant to be run again. Each pass the structure gets simpler and the Big Why gets clearer, and neither of those things can be rushed by wanting them.

What is being asked of you

An hour a week. A pencil. Your own real material, however embarrassing. And one uncomfortable habit: saying the true number out loud.

That is all. There is nothing to buy, no product to install, no community to join, and no version of this that requires you to become the sort of person who has a system. You will be rebuilding something you already have — a memory, a set of commitments, a body of knowledge — in a form you can actually work with.

And if the system ever costs more than it returns, delete it. It is a servant. It was always a servant. The point of the year is not the harness. It is that a person who has ordered what they know is free to get on with what they are for.

Contents

• 0. Why bother
• 1. What this document is, and what it is not
• 2. How to read a week's entry
• 3. How to use this document: read all of it, then jump
• 4. The whole person: four things we are actually training
• 5. Why the spiritual dimension is not decoration
• 6. The fixed shape of every session
• 7. The four-week rhythm inside every block
• 8. Staircase, rotation, and the annual refactor
• 9. The eleven things that never change
• 10. Seasonal operating modes and the calls made in advance
• 11. What we say, and what we refuse to say
• 12. The year, at a glance
• 13. The cross-reference map
• Part Two: The Blocks
• Appendix A — Words we use, and what they mean
• Appendix B — The forty things, in one page
• Appendix C — Input discipline: the full case
• Appendix D — Scope, budget, and the arithmetic of attention
• Appendix E — The reading list, and the rule about reading lists
• Appendix F — Where the design comes from
• Appendix G — The fifty-two drills, and what each one needs
• Appendix H — Running this as a group
• Appendix I — Troubleshooting: the hard cases

1. What this document is, and what it is not

This is a full year of weekly sessions for learning to keep a personal knowledge system: a place where what you read, decide, learn, promise, and intend to do is captured, sorted, kept findable, and turned into work that actually gets finished.

It draws on four traditions that were invented separately and mostly do not know about each other.

Building a Second Brain, from Tiago Forte, supplies the vocabulary of capture, organize, distill, express and the four containers of PARA: Projects, Areas, Resources, Archives. It supplies the crucial claim that a note is worth keeping only if it will be used, and the crucial warning that collecting is not the same as thinking.

Getting Things Done, from David Allen, supplies the mechanics of capture, clarify, organize, reflect, engage, the discipline of the next physical action, the two-minute rule, the four criteria for choosing, and above all the weekly review. Allen's actual contribution is not a list method; it is the observation that the mind is for having ideas, not for holding them, and that an open loop you have not decided about will cost you attention every day until you decide.

Toyota, and the shop floor — 5S, kanban, andon, poka-yoke, standard work, kaizen, and the seven wastes — supplies the physical discipline that knowledge work usually lacks. A workbench either has a place for every tool or it does not. A note system either has a place for every note or it does not. The shop floor has spent seventy years learning how to make that sentence true, and it did it with visual management, written standards, small numbers, and relentless small corrections rather than with enthusiasm.

Deming and the quality tradition supplies the rest: that most defects are process defects rather than character defects, that you cannot improve what you do not measure, that measurement without a stable process is superstition, and that the correct response to an error is to change the process rather than to try harder next time.

It is not a note-taking course. It does not teach a method for taking notes on books, and it takes no position on whether you should write in the margins, in a separate document, or not at all.

It is not an app guide. No product is recommended, endorsed, or required anywhere in these pages. Where an example names a category of tool it names a category, and the specific product is deliberately omitted, because this document is meant to survive the death of every product currently installed on your machine. If a week's build task cannot be completed without buying something, the task is skipped, not bought. That sentence is a rule of the program and not a suggestion.

It is not a productivity aesthetic. There is nothing here that is designed to be photographed. The most useful artifacts in this document are a wall chart in pencil and a one-page checklist with coffee on it.

It is also not a program that makes anybody smarter. What it trains is narrower and much more testable than intelligence. By the end of the year a participant should be able to say, with evidence: I can capture reliably; I can find almost anything in thirty seconds; I can name the next physical action on any project I own; I know how much work I can honestly have in flight; I can tell you what I finished last month; and I can tell you, without flinching, what I dropped.

That is the whole claim. Everything below is machinery for making that claim true, and for making it true again next year, because a system that is not rebuilt annually is not a system — it is a sediment.

2. How to read a week's entry

Every week in Part Two is laid out the same way, so that a person can open to any page in the document and know exactly where they are and what to do next.

• Build task. A concrete, physical change made to your own system, during the session, before you leave the room. Not homework. Not a plan to build something. The thing itself: a folder created, a list rewritten, a board assembled, a file renamed, a page deleted. If you cannot point at the result, the build task was not done.

• Drill. A named, repeatable skill, practiced in ten minutes with a timer running. It has a name so that you can say it out loud, teach it to somebody else, and recognize it when you see another person doing it badly. Names matter more than they sound like they matter. A person who can say "that is a mind sweep" has a handle for a thing they can then improve. A person who cannot name it can only have opinions about it.

• Concept. One idea, in a single sentence, that you are meant to carry out of the room. It is written to be slightly too compressed on first reading, so that it opens up over the following week.

• Verse. One passage of Scripture, quoted where it is short enough and cited where it is not. This is not a decorative addition and it is not a reward for finishing the work. It is the reason the work is worth doing, and section 5 explains why that ordering is deliberate.

• Teaching. Six to nine sentences, written out rather than summarized, for whoever is leading. It says what the idea means, why it matters to a person who is tired or behind or new, and how it connects to what is on the screen in front of them. The aim is that nobody ever has to improvise a lesson they do not feel ready to give.

There is a sixth thing that is not a slot, and it is the most important one: the link lines. Every block opens with a short See also paragraph naming the other blocks that overlap it. Those are honest, not decorative. Very little in this document is genuinely sequential, and section 3 explains how to use them.

3. How to use this document: read all of it, then jump

This section exists because of a specific failure that happens to almost everyone who tries to learn a knowledge system from a book, and it is worth naming before we start.

The failure is this. A person reads the chapter on capture, and it does not quite make sense to them, because capture only makes sense if you already know what you are capturing for — and that is in the chapter on expression, which is six months away. So they assume they misunderstood, or that the chapter was badly written, or that they need a better tool. Then they stop. Or worse, they push through obediently, build the wrong thing well, and discover in week thirty that they have been diligently maintaining a structure that does not serve their actual work.

So there are three rules for using this document, and they are rules rather than preferences.

Rule one: read the entire schedule before you begin. Not carefully, not with a notebook. Skim all fifty-two weeks and all nine appendices in one sitting, the way you would read the map of a building before walking into it. It should take an hour. The purpose is not comprehension; the purpose is to know what is coming, so that when a week feels arbitrary you can recognize what it is building toward.

Rule two: when something is unclear, ask what it is for, not whether it is wrong. Almost every week in this document is a part of the whole rather than a step in a line. Distillation looks pointless until you have tried to retrieve something you wrote eight months ago. Retrieval looks like an afterthought until you have a vault with four thousand notes in it. The correct response to an unclear week is the question how does this relate to the rest of the system? — and the answer is usually in a different block, findable through the See-also lines at the top of the block you are reading. If the answer is not there, the answer is in Appendix B, which compresses the entire year onto one page.

Rule three: you may jump ahead, and you should, but build with the end in mind. Two things are true at once and the tension between them is real. A person who jumps to block eight because they are excited about expression will produce a beautiful empty vault. A person who refuses to look past block one because the document says "staircase" will produce a tidy pile of nothing. The resolution is not a compromise; it is a different order of operations. Look ahead freely. Build backward. Read where the year ends, decide what you want to be able to say about your own work in week fifty-two, and then come back and build toward it in whatever order your actual life permits.

Rule four: this schedule is meant to be run again. It is not a course you complete. It is a year you repeat. Next January you will start at block one again, and roughly a third of it will be wrong for you in a way you could not have known this year, and roughly a third of it will be more useful than it was the first time because you now have real material to run it on. The appendices are written to be edited in place. The weeks are written to be reordered. Nothing here is sacred except sections 1, 5, and 9.

A word about the size of this. The document is long because it is meant to be usable by someone who is having a bad year and cannot remember the plan. A short document assumes a reader with momentum. This one assumes a reader on a Tuesday.

4. The whole person: four things we are actually training

A curriculum that only trains mechanics produces a person with immaculate folders and an unfinished life. This program is organized so that every session touches four dimensions of a person, and every block names which one it is leaning on hardest.

The technical dimension

The mechanics: where a thing goes, what a thing is called, how a thing is found, how fast it can be retrieved. This is the shallow one, it is the one that can be finished, and it is the one that gets all the attention in books about note-taking.

It matters anyway, and it matters for a reason that is easy to miss. A system you cannot operate while tired is not a system. The technical dimension exists to make the right action the easy action — one inbox instead of six, one naming convention instead of judgment calls at eleven at night, one board with a limit instead of a list of ninety things. Every mechanic in this document is there to remove a decision, because a decision you have to make repeatedly is a decision you will eventually stop making.

The cognitive dimension

Attention and judgment: naming, deciding, deferring, deleting, and the difference between a topic and a project, between an area and a resource, between something you are interested in and something you are responsible for.

A person who can explain why their taxes are an Area and not a Project has gained something no folder structure gives them, because the same distinction will show up in a budget meeting, a family conversation, and a job description. This is why the teaching sentences exist, why the drills have names, and why the leader is supposed to ask questions rather than issue instructions. Naming a distinction is the whole skill. The folders are downstream.

The behavioral dimension

What happens under load. A late Tuesday. A flooded inbox. A deadline week. A month where the whole thing was abandoned and now re-opening it produces dread.

This is where knowledge systems actually fail, and they fail quietly, and the failure is almost always moralized. People decide they are disorganized, or undisciplined, or not the kind of person who can keep a system. They are almost always wrong about this. What happened is that the system had no capacity mode: no written answer to the question what do I do when I cannot do the full version? So the choice became all-or-nothing, and nothing was the cheaper branch.

The capacity weeks exist for this and for nothing else. Every one of them is an attempt to answer that question in writing, in advance, while somebody is calm, so that the answer can be read later by somebody who is not.

The spiritual and stewardship dimension

The honest gap between the system you have and the system you claim to have.

A knowledge system's characteristic sin is not laziness; it is quiet self-deception that is dressed as diligence. The note saved instead of read. The "someday" list nobody opens. The book summarized to avoid thinking about it. The project that has been in progress for eleven months and has been talked about in three meetings. The vault that grows while the output does not. All of it feels like work, all of it is measurable, and none of it is the thing.

Everything in this document that sounds harsh is aimed at that sin and at nothing else. Section 5 makes the argument for why it is a spiritual matter and not merely an efficiency matter.

5. Why the spiritual dimension is not decoration

This section is the one that some readers will skip, and it is the one that determines whether the other fifty-one weeks survive contact with a real year. So it goes near the front and it is written plainly.

First: the material is enormous and a person can drown in it. PARA has four categories and about eleven edge cases that will consume a weekend. GTD has six horizons of focus, and each horizon has its own review, and people have built careers selling the difference between them. 5S has five steps, and lean has seven wastes, and quality management has control charts, and kanban has Little's Law, and a thoughtful person can spend a decade learning how to organize their reading and never once finish anything they read. This is not hypothetical. The literature on personal knowledge management is full of people who are extremely good at managing inputs and have not shipped an argument in three years.

The traditions in this document did not begin as self-improvement. 5S came off a factory floor where the standard was set by whether a person could find the right tool in five seconds while a machine was stopped and thirty people were waiting. Kanban came out of a shop where the constraint was real and the cost of work-in-progress was visible. GTD came out of a man who had been, by his own account, a mess, and who was looking for something that survived an ordinary bad week. Deming's whole argument is a moral one: that most of what we call employee failure is management's failure to design a process, and that blaming the person is both unkind and ineffective. These are not aesthetic traditions. They are traditions about stewardship of limited things — tools, time, attention, materials, and other people's patience.

Second: attention is the thing being spent, and it is not refundable. Every week of this curriculum costs an hour, and every hour of attention that goes into maintaining a structure is an hour that does not go into the work the structure was supposed to serve. That is a real cost and it deserves to be weighed every single week rather than assumed. The recurring question in this document — does this cost more than it returns? — is not a productivity question. It is a question about what you are doing with a life.

Third: the honest answer to "why bother" is not "to be more productive." A person who organizes their knowledge in order to optimize their output will eventually discover that output is not a coherent goal, because you can always want more of it. A person who organizes their knowledge in order to be faithful with what they have been given has a stopping condition. That is the difference between a system that serves you and a system that eats you, and it is the reason this document has a verse in every week rather than a quotation.

Fourth, and this is the argument that actually matters: the work of ordering is itself a devotional act, or it is nothing. Scripture is unusually interested in this. The tabernacle instructions are obsessive about order, and about the fact that the order is not Moses's idea. The Proverbs are full of diligence, which in Hebrew is closer to sharp than to busy — the diligent person is the one whose work cuts. The parable of the talents is about stewardship of what was given rather than about talent in the modern sense, and the servant who is condemned is not the one who produced least; he is the one who did nothing with what he had, out of fear. The man who built bigger barns is not condemned for poor planning. He is condemned for planning as if the barns were the point.

So the devotional frame is not a garnish sprinkled over a productivity curriculum. It is the load-bearing wall. Three consequences follow, and they are the operating theology of this document:

1. The system is a servant and never a master. When the system and the person conflict, the person wins, every time, without discussion. A review that costs a marriage is not a good review. A vault that displaces the work is a barn.
2. Faithfulness is measured in what was actually finished, not in what was collected. This is why blocks seven through nine exist, and why the year does not end with a beautiful archive but with a handover document and a teach-back.
3. Rest is a command, not a reward. A system with no sabbath in it will be abandoned, and the abandonment will feel like failure, and it will not be failure. It will be a sabbath that arrived without permission. Block twelve makes that permission explicit and writes it down.

If a reader takes nothing else from this document, take the ordering in point two: collect nothing you will not use, and finish something every single week. Everything else here is plumbing.

6. The fixed shape of every session

The session is the same every week of the year. That sameness is not laziness; it is the single most important design decision in the document, and it is copied deliberately from the way a shop floor runs and the way a good small group runs.

A person who drops in twice a year should recognize the shape immediately. A person who is anxious about new situations should not have to learn a new format on top of learning new behavior. And a person who is having a genuinely terrible week should be able to participate by following the room instead of by reading the instructions.

Seventy-five minutes. In December it is cut to sixty by shortening the build segment to fifteen minutes. In a session where only two people have come, the drill stays, the build stays, the measure stays, and the circle shortens to three minutes. On a week where a person is drowning, the build is replaced by the re-entry protocol from week forty-seven and nobody says a word about it.

Three things are never cut: the measure, the verse, and the closing commitment. The measure because a system you cannot see is a system you will start lying about. The verse because it is the reason. The closing commitment because an intention that has not been said out loud and written down is not an intention, it is a mood.

What the wall chart is actually for

The wall chart is a shop-floor device and it is doing shop-floor work: it makes the invisible visible, so that variation becomes a fact instead of a feeling.

One line per week, one number per line, twelve to fifteen weeks visible at a time. Nothing digital. Nothing pretty. You are not tracking productivity; you are learning what your own normal variation looks like, which is the difference between "my inbox is out of control" (a feeling that produces shame and no action) and "my inbox is at 240, it is usually under 60, and it was also at 240 in September after the conference" (a fact that produces a plan).

Appendix D explains how to read the chart, including the one mistake everyone makes with it.

7. The four-week rhythm inside every block

The year is thirteen blocks of four weeks. Each block has one theme, and inside each block the four weeks follow the same pattern, so that learning the pattern once means you can predict any week of the year, including next year's.

Week one of a block: Teach. Slow, no pressure, a great deal of talking, nothing timed that does not need to be. The goal is that everyone leaves able to name the thing and describe when they would use it. If people are tired at the end, the teaching was too long. If people cannot say the name of the thing, the teaching was too short. There is no third failure mode, and the fix for both is the same: cut material, keep the name.

Week two of a block: Repetition. The same skill, a hundred times, on real material rather than examples. Volume without speed. This is where the skill stops being something you know and becomes something you do — and it is the least interesting week of every block, which is why it is the one most often skipped, which is why the people who skip it are still reorganizing their folders in year three.

Correction in this week is offered quietly and individually, in a single sentence, and never as a public demonstration of somebody's error. The shop floor learned this the expensive way: an andon cord that gets you yelled at does not get pulled.

Week three of a block: Capacity. The same skill, under a realistic and slightly unpleasant load: a full inbox, a genuine deadline, a busy week, a phone instead of a desk, a month of neglect. In a controlled dose, with a written fallback. This is the week that trains the behavioral dimension, and it is the week that tells you whether the thing you built in weeks one and two is a system or a hobby.

Week four of a block: Flow and circle. Light, integrated work that uses the block's theme without demanding anything new. Followed by a longer verse segment and a longer conversation. This is the week a person can bring a friend, arrive late, leave early, miss half of it, and still take something home.

Why this order and not some other. Teach before repetition because a skill you cannot name cannot be corrected. Repetition before capacity because load applied to a sloppy movement produces a fast sloppy movement. Capacity before flow because flow is what a skill looks like after it has survived pressure, and doing it earlier produces the pleasant illusion of competence that collapses the first busy month.

8. Staircase, rotation, and the annual refactor

The martial-arts version of this document is deliberately a rotation: you can join in week forty-three and lose nothing, because the blocks are a cycle and the person who arrives late is not behind.

This document is not that, and it should say so plainly instead of pretending.

This one is a staircase. Block one is genuinely before block two, because you cannot sort a pile you have not collected, and block seven is genuinely after block six, because you cannot express a thought you have not distilled. Pretending otherwise would be exactly the kind of flattering lie this whole document is against. There is an order here, it is defensible, and section 3's rule three already tells you what to do when your life disagrees with it: look ahead, build backward, jump if you must, and accept that you will redo some of it.

What is preserved from the rotation model is the more important half: every week is complete on its own. If a person attends only week thirty-four, they leave the room with a working board, one number, one idea, one verse, and one commitment. They will lack the earlier context, and the teaching says the context out loud in its first two sentences, which is precisely why the teaching is written down rather than left to the leader's memory.

The annual refactor, which is not optional

This schedule is meant to be run again, and it is meant to be wrong the second time.

A first pass through this year will produce three kinds of result. About a third of the blocks will be exactly what you needed and will become permanent. About a third will be roughly right but wrongly weighted — the right idea at the wrong size for your actual work. And about a third will be wrong for you in a way you could not possibly have predicted in January, because you did not yet know what your own material looked like.

The third category is the valuable one, and it is only available if you write down, in week fifty-two, which blocks those were. That is what the redesign week is for, and it is why the year does not end with a celebration.

Three rules for the annual refactor:

1. Keep four things. Not thirteen, not "everything that worked." Four. A person who keeps everything has not refactored, they have decorated.
2. Change the standard, not the intention. If the weekly review did not happen, the fix is a five-minute version with a written trigger, not a resolution to try harder. Deming's rule applies to your own Saturday: change the process.
3. Date the new document. A plan without a date becomes a policy. A plan with a date is allowed to expire, which is the only thing that keeps it honest.

9. The eleven things that never change

These are not seasonal and they are not optional. They are what keeps a good system alive past its second year, and every one of them exists because somebody's system died without it.

1. It is free. No course is sold from this document, no template is monetized, no tool is recommended in exchange for anything. If you are being taught this material and somebody wants money for the next part, leave.
2. No tool evangelism. The system must survive a change of tool. A week that only works in one application is a failed week, and a person who cannot describe their system without naming a product does not yet have a system.
3. One home for everything. An item lives in exactly one place. Duplicates are the only true defect in this entire document, and they are the only thing worth being pedantic about. Everything else is a preference.
4. Nothing is deleted before it is archived, and nothing is archived in order to avoid deciding. The first half is a mercy to your future self. The second half is a guard against the most respectable form of procrastination available to an organized person.
5. If it costs more than it returns, delete it. In front of other people if possible, and say why. Section 5 explains why this is a spiritual rule and not an optimization.
6. No one's notes, inbox, or screen is shown without their specific spoken permission. Stated before the first session, not after a problem. This is the knowledge-work equivalent of the rule about photographs, and it exists for the same reason: the things people keep are not decorative.
7. Honest numbers only. If a number on the wall chart is embarrassing, it goes up anyway. A chart you curate is worse than no chart, because it produces false confidence at exactly the moment you needed a warning.
8. One person speaks at a time, and no one is required to speak. Silence is a legitimate contribution and is treated as one.
9. No reading about systems in place of using one. The reading list is one page, it is in Appendix E, and it does not grow during the year.
10. The weekly review is not cut for time. It is shortened, never skipped. A missed review is data, not a moral failure, and it goes on the chart.
11. The last ten minutes belong to the number and the commitment. They are not traded for more build time, no matter how interesting the build has become. This is the rule that gets broken first and the one that matters most, because the build is always more fun than the accounting, and the accounting is what makes the build count.

10. Seasonal operating modes and the calls made in advance

This curriculum assumes a temperate northern-hemisphere year in which a person's work has a shape: a January that is quiet and full of resolve, a spring that fills with obligations, a summer that is disrupted, and an autumn that arrives with more due than there are weeks. If your year does not have that shape, rotate the labels and keep the week numbers, because the week numbers are the unit and the seasons are a convenience.

The calls made in advance, in writing, and not negotiated in the moment

Every one of these exists because the decision is easy when you are calm and impossible when you are not. Write them on the same page as your wall chart.

• The week you fall off for a month. You do not restart the system and you do not rebuild it. You run the re-entry protocol from week forty-seven, which takes one hour and loses nothing. Falling off is expected, planned for, and not a moral event.
• The week a tool dies, changes its pricing, or is discontinued. You do not perform an emergency migration during a deadline, ever. The escape hatch is the export test from week thirty-two and the naming convention from week thirty-three, which exist precisely so that a tool's death is an inconvenience rather than a crisis.
• The week the inbox is over two hundred items. You do not process it. You do a mind sweep and then a triage, in that order, because processing a large backlog item by item is how people lose three weekends and their enthusiasm in the same month.
• The week more than three projects are in progress. You do not add a fourth. You finish one or you kill one, in front of a witness if possible. This is the kanban rule and it applies in every month, not only in block ten.
• The week the review would take more than ninety minutes. You are not reviewing, you are re-planning. Stop, do the five-minute version, and put the re-plan on the calendar for a day when it can be done properly.
• The week somebody asks you to adopt their system. You say no, politely, and you write down what they suggested so you can consider it in week fifty-two. Changing systems mid-year is the second most common cause of abandonment after falling off for a month.

11. What we say, and what we refuse to say

Words create expectations, expectations become promises, and promises become the thing you are measured against. So the claims here are deliberately small, and the refusals are deliberately specific.

We say: a sustained weekly habit; a place for everything; one home for each item; a measurable reduction in the time it takes to find something you know you have; fewer open loops; more finished work; a written answer to what happens in a bad month. We say that people who do the review every week tend to end up trusting their own system, and that we have watched it happen, and that it takes about eight weeks before it stops feeling like homework.

We do not say: that this makes anyone smarter, more creative, or more original. That it is evidence-based — it is a synthesis of practices with strong industrial and clinical provenance, applied to an area where the controlled trials do not exist. That a second brain substitutes for thinking, or that retrieval is the same as understanding. That a larger vault is a better one, or that a well-organized archive is an achievement. That this improves career outcomes on its own. That it reduces anxiety in any clinical sense. We do not put a number on the hours it saves, because the honest number varies by an order of magnitude between people and the dishonest number is the one that sells books.

And the standing answer when somebody asks whether it works:

"Come for eight weeks and tell me what you found."

Not because the question is rude, but because the answer is genuinely local. The only evidence that matters is whether you can find your own material in thirty seconds and whether anything got finished. Both of those are checkable, by you, this quarter, without a study.

12. The year, at a glance

The four threads that run through all thirteen blocks. These are not blocks. They are the things you should expect to see again, in a different costume, roughly every three months, and the reason a week can feel familiar in a way you cannot place.

• The door. What enters and on what terms. Blocks 1, 6, 7, 8, 13.
• The container. Where it lives and what kind of thing it is. Blocks 2, 3, 9, 13.
• The limit. How much can be in flight, how long it may sit, how much it may cost. Blocks 4, 10, 11, 12.
• The accounting. What is actually true, measured, and said out loud. Blocks 5, 10, 11, 12.

13. The cross-reference map

The blocks overlap more than the table above suggests, and the overlaps are the substance rather than an accident. This map is the one to photocopy. It is the answer to "how does this relate to the rest of the system," which section 3 says is the correct question to ask when a week is unclear.

Part Two: The Blocks

Block 1 — Capture: the door and the filter

"Write down the revelation and make it plain on tablets, so that a herald may run with it." — Habakkuk 2:2

"Your mind is for having ideas, not holding them." — David Allen

Weeks 1–4 · Winter · Rhythm: teach, repetition, capacity, flow

Why this block, why now. January is the month people rebuild their systems and the month they abandon them, usually in that order, and the reason is almost always the same: they start with folders.

You cannot organize a pile you have not collected. You cannot sort what is still in your head, your phone, three notebooks, two email accounts, and a browser with forty-one tabs. And you cannot know what is worth keeping until you have first seen what you have, in one place, at one time — which is an experience most adults have not had since they were children, and which is genuinely confronting the first time.

So this month contains almost no organizing. It contains collection, and the admission of how much has never been collected. That admission is the actual work of January, and it is what makes every later block possible. A person who arrives in February with an honest capture habit and no structure at all is in a far better position than a person who arrives in February with beautiful folders containing a tenth of their material.

What a newcomer should expect. Nothing is deleted this month and nothing is thrown out. No existing structure is dismantled. You will be asked to write down things you have been carrying for years, and one of these weeks will probably make you angry, and that is normal and is not a sign that you are doing it wrong. The total cost is a cheap notebook and somewhere to put paper.

See also. The capture habit is meaningless without a destination, which is block 2. What you should refuse to capture is block 6, and it will make more sense after you have felt the weight of a full inbox. What you are capturing for is block 8; read that preamble now if this month feels pointless, because it is the answer to "why bother."

Week 1 · Capture is a promise

Build task. Create exactly four capture points and no more: one paper surface that is always on your person, one place on your phone, one place on your computer, and one voice or quick-capture path for when your hands are busy. Label all four with the same word. Then write a single sentence on paper, in pen, saying what those four feed into, and tape it where you will see it. Four doors, one room.

Drill — "The Four Doors." Ten minutes, timer running. Take the four capture points and put something in each one, deliberately, from something already in your head. The point is not the content. The point is that you physically perform the act of capture into each door once, in one sitting, so the path stops being theoretical. Most people discover in this drill that one of their four doors does not work — the phone app takes four taps, the notebook is in the other room, the voice memo never gets listened to — and that discovery is the finding. Fix the door you will actually use, not the one you wish you would use.

Concept. A capture system is a promise to your future self, and a promise you break weekly is worse than no promise at all.

Verse. Habakkuk 2:2 — "Write down the revelation and make it plain on tablets, so that a herald may run with it."

Teaching. God tells Habakkuk to write it down, and then gives the reason: so that a herald may run with it. The writing is not for the writer's memory. It is so that somebody else, later, at speed, can act on it. That is a much higher standard than "I will remember," and it is the standard capture actually has to meet. The test of a captured item is not whether you feel organized. It is whether a stranger — or you, in March, having forgotten everything — could pick it up and run. Notice also that the instruction is make it plain. Not clever, not complete, not beautifully worded. Plain. Almost all capture failure is traceable to a private shorthand that only made sense while the thought was still in the room, and the whole failure is visible in a single glance at anyone's oldest notebook. Today, write things down as though someone else will read them, because someone else will, and that someone is you with no memory of today.

Week 2 · The mind sweep

Build task. Conduct a full mind sweep and produce a written list of at least one hundred items. Not tasks. Items: everything that has your attention and is not in a trusted place. Use a timer and a prompt list. Keep it ugly and keep it fast. Put the finished list into your paper capture point, and do not sort it.

Drill — "The Sweep." Ten minutes, timer running, prompts read aloud if you are in a group. Work through the standard triggers in order — home, work, family, money, health, commitments you have made to people, commitments people have made to you, things you are avoiding, things you are afraid you have forgotten, things you said yes to and regret — and write one line for each thing that surfaces. Do not fix anything. Do not open anything. The rule for the ten minutes is: capture only. No action, no judgment, no triage. If your hand stops moving, read the next prompt out loud and start again.

Concept. The reason you cannot think clearly is not that you have too much to do; it is that you are using your memory as a storage medium.

Verse. Psalm 139:23–24 — "Search me, God, and know my heart; test me and know my anxious thoughts. See if there is any offensive way in me, and lead me in the way everlasting."

Teaching. The psalm does not ask God to remove the anxious thoughts. It asks him to know them and to see them, and only then to lead. That order is worth sitting with, because our instinct when overloaded is to suppress or to power through, while the psalm's instinct is to bring the whole thing into the light first. A mind sweep is a small, secular imitation of that prayer: you are asking what is actually there rather than what you would prefer to be there. Expect two things. The list will be longer than you guessed, usually by a factor of two or three. And a large fraction of the items have been occupying attention for months without ever being written down, so writing them will feel like setting something heavy on a table. Nothing has been solved. That is the point. The mind is a terrible filing cabinet and an excellent workbench, and the sweep is how you clear the bench — not because clearing is progress, but because you cannot do any work on a bench that is full.

Week 3 · Capture under load

Build task. Take a normal working day and keep a capture surface within reach for all of it. Every interruption, every idea, every "I must remember," every request that arrives — one line, timestamped, into the capture point. At the end of the day, count them. That count goes on the wall chart, and it is the first number of the year.

Drill — "The Interception Log." Ten minutes at the end of the day, timer running. Read back through the day's capture and mark each line into one of three categories: mine to do, mine to decide, someone else's. Do not process any of them. The purpose is to discover the ratio, because the ratio is diagnostic. A person whose day is ninety percent someone else's has a boundary problem, not an organization problem, and no folder structure will fix it. A person whose day is mostly mine to decide has a decision problem, which is block three. A person whose day is almost entirely mine to do is probably capturing too little, because real days are full of other people.

Concept. You cannot manage an inflow you have never measured, and most people have never once measured theirs.

Verse. 2 Corinthians 10:5 — "...we take captive every thought to make it obedient to Christ."

Teaching. The phrase is take captive, which is an act of force applied to something that is moving and does not want to stop. That is an accurate description of what capturing is like on a busy Tuesday: a thought appears, you are in the middle of something, and the thought either gets written down or it wins. Paul is not talking about note-taking, but he is talking about the same structural problem, which is that an untaken thought runs loose and starts issuing orders. Here is the practical arithmetic. An interruption costs more than itself; it costs the twelve minutes of re-entry afterward, and you pay that cost whether or not you wrote the thing down. Writing it down does not remove the interruption. It removes the re-entry, because the thing is now somewhere other than your head. Today you are not becoming more productive. You are measuring the size of the door, because a door you have never measured is a door you will be surprised by every week for the rest of your life.

Week 4 · The collector's audit, and the circle

Build task. Count two numbers and write both on the wall chart: how many items you captured this month, and how many of them you have since acted on or filed. Then look at the gap. Do not fix the gap today. Write one sentence about what the gap is made of.

Drill — "Catch and Miss." Ten minutes, timer running. Go back through the month's capture points and find five things you clearly should have captured and did not — the appointment you nearly missed, the name you lost, the promise you made twice. Write each one down, then write in one line which door failed. Eight times out of ten it is the same door, and it is not the one you have been improving.

Concept. The measure of a capture system is not how much it holds; it is how little it drops.

Verse. Psalm 139:1–4 — "You have searched me, LORD, and you know me. You know when I sit and when I rise... Before a word is on my tongue you, LORD, know it completely."

Teaching. There is a record of your life that is complete, and it is not yours. God knows the word before it is on your tongue; you lose the word between the thought and the pen. That asymmetry is worth holding onto for two reasons. The first is comfort: the things you have forgotten are not forgotten by everyone, and your failure to keep a complete record is not a failure to be known. The second is proportion. You are not building an archive of your life, and you should not try, because the attempt will eat the life it is trying to record. You are building a working memory slightly better than the one you were issued. Four blocks from now you will be sorting this month's material, and the only question that will matter is whether the good things made it through the door. Today, look at the gap, name what it is made of, and close the first month by saying out loud one thing you intend to stop dropping.

Block 2 — The four containers: PARA

"Let all things be done decently and in order." — 1 Corinthians 14:40

"Only the simplest, most effortless habits endure long term." — Tiago Forte

Weeks 5–8 · Winter · Rhythm: teach, repetition, capacity, flow

Why this block, why now. You now have a pile. A pile needs four drawers and one rule for deciding which drawer, and that is the entirety of what PARA is: Projects, Areas, Resources, Archives.

• A Project is a short-term effort with a goal and an end. It is finished when something specific is true. Move the workshop into the garage. Finish the certification. Get the estate paperwork filed.
• An Area is an ongoing standard you are responsible for maintaining, with no end date. Health. Finances. The house. My direct reports. My marriage.
• A Resource is material on a topic you are interested in, with no obligation attached. Bread baking. Roman aqueducts. Kubernetes.
• An Archive is anything from the other three that is no longer active. Nothing dies; things graduate.

The distinction that does almost all the work is Project versus Area, and it is a single test: does it end? If yes it is a project. If no it is an area. Almost every organization system people build fails at exactly this point, because they file by topic — Work, Church, Family — and then cannot tell what to do next, because a topic has no next action.

This is the block where people discover that most of their "projects" are areas and most of their "areas" are hobbies. That discovery is uncomfortable and it is the most valuable hour of the month.

What a newcomer should expect. Nothing is deleted. Everything unmoved gets red-tagged rather than discarded. If you have never built a folder structure and are starting from a shoebox, you are not behind; you are, in one specific way, ahead, because you have less to migrate. Do not rename everything to match the examples in this document. The four words are the structure. Your nouns are your own.

See also. Project versus Area is really a scope question, and if the test feels arbitrary now it will feel obvious after block 11. Sorting without deciding only relocates the problem, which is block 3. The naming convention built in week eight is the same one tested for survival in week thirty-three.

Week 5 · Projects versus Areas, and the one test

Build task. Take your top ten existing folders, notebooks, stacks, or buckets and write each one's name on a card. Then apply the test to every card: does it end? Sort the cards into two physical piles, Projects and Areas. Do not create the structure yet. Just sort the cards. Then write down, on a separate sheet, every card you could not decide about, and why in one line.

Drill — "The Ends Test." Ten minutes, timer running. Take twenty items from your capture pile and ask only one question of each: does this end, or is it a standard I keep? Ten seconds each, maximum. If you cannot answer in ten seconds, the card goes into the undecided pile and you move on. The undecided pile is the interesting output, because the boundary between a project and an area is genuinely blurry for about a fifth of real items. "Get healthier" is an area. "Complete the physical in March" is a project inside it. Learning to say both — to hold a project as a temporary object inside a permanent area — is the actual cognitive gain of this week.

Concept. Filing by topic gives you a library. Filing by commitment gives you a day.

Verse. Luke 14:28 — "Suppose one of you wants to build a tower. Won't you first sit down and estimate the cost to see if you have enough money to complete it?"

Teaching. Jesus's point in that passage is about counting the cost of discipleship, but the mechanism he uses is a project manager's mechanism, and it is worth noticing how casually he assumes his listeners understand it. A tower is a project. It has an end, a cost, and a moment of completion, and it can fail in a way that is visible to everyone who walks past. That visibility is the reason projects are morally useful: they can be finished or not finished, and the difference cannot be argued with. Areas cannot do that. You cannot complete your health. What you can do is notice that "be healthier" is not a thing that ends, and therefore is not a thing that can be scheduled, and therefore is the kind of item that sits in a list for four years producing low-grade guilt. Today's test is not pedantry. It is the difference between a list that clears and a list that accumulates. Be strict with yourself: if it does not end, it does not go on the project list, and the relief you feel when you move it is not laziness. It is accuracy.

Week 6 · 5S Sort, and the red tag

Build task. Sort two hundred items — files, papers, notes, screenshots, saved links — into three destinations: keep in Projects or Areas, red tag, redirect to a Resource. Red-tagged items do not go in the bin. They go in one physical or digital container labelled with today's date and a note that says what happens to it in ninety days. That container is the entire point of 5S's first step.

Drill — "Ten Seconds or Red Tag." Ten minutes, timer running, strict ten seconds per item. If you cannot decide in ten seconds, it is red-tagged. No exceptions, no "let me just look at this one." The discipline of the timer is not about speed; it is about preventing the decision from becoming a research project. The old shop-floor version of this is seiri, and its actual rule is harsher than most people expect: anything not used in the last year, and not required by law or contract, leaves the work area. The red tag exists because leaving the work area is not the same as destroying, and people will not sort honestly if sorting means throwing away.

Concept. Sorting is not deciding what to keep; it is deciding what to remove from the place where work happens.

Verse. Matthew 13:47–48 — "...the kingdom of heaven is like a net that was let down into the lake and caught all kinds of fish. When it was full, the fishermen pulled it up on the shore. Then they sat down and collected the good fish in baskets, but threw the bad away."

Teaching. Two details in that parable are easy to miss and both are about sorting. The first is that the sorting happens after the catch is on the shore, not in the water — which is to say, you cannot sort while you are still fishing, and trying to do both at once is why so many people capture badly. The second is that they sat down. Sorting is a seated, unhurried, deliberate act with the whole catch in front of you, and it is done in one session rather than a bit at a time over a year. That is precisely what the red tag makes possible. You are not deciding the fate of two hundred things this week; you are deciding which of them belong in the place where you do work. The rest go into a labelled container that will ask you again in ninety days, when your judgment will be better because you will not have touched them once in three months.

Week 7 · The migration

Build task. Choose one domain of your life — work, or household, or a single committee, or one volunteer role — and migrate that entire domain into PARA in one sitting, with a timer. Create the four containers for that domain. Move everything that belongs to it. Do not touch any other domain this week. One domain, done completely, beats four domains done halfway, because a half-migrated domain teaches you nothing about whether the structure works.

Drill — "Four Buckets, One Domain." Ten minutes, timer running. With the four containers open side by side, take the domain's material and place each item, narrating out loud what it is and why it goes where it goes. Speaking the reason is the drill. It forces the decision out of your hands and into language, and language is where you find out whether you actually have a rule or just a feeling. If you cannot say the reason in one sentence, the item is red-tagged and you move on.

Concept. A structure you have not migrated is a structure you have only agreed with.

Verse. Haggai 1:5–7 — "Now this is what the LORD Almighty says: 'Give careful thought to your ways. You have planted much, but harvested little...'"

Teaching. Haggai is writing to people who had returned from exile and built themselves panelled houses while the temple lay in ruins, and his diagnosis is not laziness. It is misplaced attention: they were working hard on the wrong structure, and the evidence was that their effort did not produce a harvest. That is an unnervingly precise description of a person who has spent four years improving a filing system for material they never use. The instruction is give careful thought to your ways — not "work harder," and not "feel bad," but examine the actual shape of what you are doing. Migrating one domain is how you examine it. You will find items you have moved four times and never opened, which is a fact about them. You will find three projects that are actually the same project under different names, which is a fact about you. Both findings are cheap this week and expensive in October.

Week 8 · Set in order, and the archive day

Build task. Write your naming convention on one page and apply it to fifty files. Then set the depth rule: no more than three levels inside any container. Anything deeper is a folder that has become a hiding place. Finally, run an archive day: take every project that is finished or dead and move it to Archives, with the completion date in the title or the file name.

Drill — "Three Levels Deep." Ten minutes, timer running. Find every folder or notebook path in your system that is four or more levels deep, and flatten it to three. Each time you flatten one, say out loud what you expected to find in its place. The expectation is the interesting part: people build deep trees because they believe they will remember the path, and they never do, and the depth was never the retrieval mechanism — the name was.

Concept. Order is a set of decisions made once so they never have to be made again.

Verse. 1 Corinthians 14:40 — "But everything should be done in a fitting and orderly way."

Teaching. This instruction comes at the end of a long passage about chaos in a church gathering — everybody speaking at once, nobody understood, visitors concluding that the group is mad. Paul's remedy is not less enthusiasm. It is arrangement: one at a time, in turn, so that the thing can actually be received. The parallel is exact. Order in a knowledge system is not tidiness for its own sake and it is not aesthetics. It is the condition under which anything can be received by a person who arrives later, including you. Note also the word fitting — the order has to suit the thing being ordered, which is why the three-level rule is a rule and the specific names are not. Your convention should fit your material; it should not fit somebody else's example. Close this block by writing your convention on one page and dating it, because in twelve months you will want to know what you actually decided in February, and you will not remember.

Block 3 — Clarify: the decision, not the pile

"Let your 'Yes' be 'Yes,' and your 'No,' 'No.'" — Matthew 5:37

"If you don't pay attention to what has your attention, it will take more of your attention than it deserves." — David Allen

Weeks 9–12 · Winter · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Sorting without deciding only moves the problem into a nicer box. This is the hardest block in the year and the one most people quietly skip, and the reason is simple: it requires a decision on every single item, and decisions are expensive in a way that movement is not.

An open loop is a decision you have not made. That is the whole theory. It is not an item you have not filed and it is not a task you have not done — it is a question you have not answered, and until you answer it, your mind will keep re-asking it at the worst possible moments, which is what people mean when they say they cannot stop thinking about work.

There are only six answers, and there is no seventh. Every item that has ever entered your life resolves to one of these:

1. Do it — if it takes less than two minutes.
2. Delegate it — and then it goes on a waiting-for list with a date.
3. Defer it — a next action with a specific physical first step, on a list you actually look at.
4. Calendar it — if it must happen on a particular day or at a particular time, it is not a task, it is an appointment.
5. File it — reference, no action, into Resources.
6. Discard it — the answer nobody chooses and everybody needs.

The failure mode in this block is not confusion. It is the sixth answer, which people avoid because discarding feels like losing, and so items that should be discarded get deferred instead, and deferred items metastasize into a list of three hundred things, and a list of three hundred things is not a plan — it is a monument to indecision.

What a newcomer should expect. You will be slower than you want to be and slower than the group. A beginner processes twenty items an hour; a person who has done this for a year processes eighty. That ratio is not talent, it is familiarity. You will also feel an urge to stop and do the items you are processing, and you must not, and this is why the drill has a timer: the timer is there to keep you processing rather than executing.

See also. A next action with no calendar slot is a wish, which is block 4. A next action with no limit on how many exist is a fantasy, which is block 10. The question of what should never have entered the funnel at all is block 6.

Week 9 · The processing question

Build task. Process your capture pile from the bottom up, one item at a time, out loud, using the six answers. Bottom-up means oldest first, and the reason is not sentiment: the oldest item is the one that has been costing you attention longest, and clearing it produces the first genuine relief of the year.

Drill — "What Is It?" Ten minutes, timer running, one item every thirty seconds. For each item, say out loud, in this order: "This is a ___." (an action, an appointment, a piece of reference, a project, or nothing) — "The next physical action is ___." — "It goes to ___." If you cannot complete the second sentence, the item is not a task, it is a project, and it goes on the project list instead. The physical word matters. Not "handle the insurance." Find the policy number and write it on the form. If the sentence does not begin with a verb your hands can perform, you have written a topic, not an action.

Concept. An item you have not decided about is charging you rent every day.

Verse. Matthew 5:37 — "All you need to say is simply 'Yes' or 'No'; anything beyond this comes from the evil one."

Teaching. That last clause is startling, and it is not hyperbole about grammar. Jesus is saying that the habit of hedging — the elaborate maybe, the deferred answer, the soft commitment that is not quite a commitment — has a moral character, and it is not neutral. Hedging is how a person avoids the cost of a decision while keeping the benefits of being asked. In a knowledge system, the hedge has a physical form: the item that sits in the inbox because deciding feels worse than carrying. And the cost is paid by someone, always, either by you in attention or by the person who is waiting for an answer they think is coming. So today, be blunt with yourself in a way you would not be with another person. Yes, no, or a specific date. The pile does not need to be organized. It needs to be answered. Note what happens in your body when you say a clear no to something you have been carrying for eight months — that sensation is the thing this whole block is trying to teach, and it cannot be learned by reading about it.

Week 10 · The four lists

Build task. Create four lists and no more: Next Actions, Waiting For, Someday/Maybe, and Reference. Move everything you processed last week into one of them. Then delete the other lists you have been keeping — the ones with names like Misc, Later, Important, and To Think About, which are not lists, they are places to hide.

Drill — "The Tree." Ten minutes, timer running, one hundred items if you have them. Run each item through the tree in order and stop at the first match: Is it actionable? No → trash, reference, or someday. Yes → will it take under two minutes? Yes → do it now. No → is it mine? No → delegate, and it goes on Waiting For with a date. Yes → is there a specific day it must happen? Yes → calendar. No → Next Actions, with a physical verb. The order is not arbitrary. The two-minute test comes before delegation because delegating a two-minute task costs more than doing it, and the calendar test comes last because calendars fill up and lists do not.

Concept. A list that mixes commitments with possibilities will be trusted for neither.

Verse. Exodus 18:17–18 — "What you are doing is not good. You and these people who come to you will only wear yourselves out. The work is too heavy for you; you cannot handle it alone."

Teaching. Jethro's advice to Moses is the first recorded management consultation, and its structure is worth studying because it is not "work harder" and it is not "prioritize." It is change the shape of the work: handle the hard cases yourself, delegate the rest to capable people, and let them carry it. The diagnosis is precise — you will only wear yourself out — and it identifies the actual mechanism of collapse, which is not volume but the attempt to hold all volume personally. There is a second detail that is easy to miss. Jethro says to appoint people who will hate dishonest gain, which is to say he cares about their character and not only their competence. Applied to a list: a Waiting For list is a delegation list, and it only works if you name a specific person and a specific date, because "someone should look into this" is not delegation and will never come back to you. Today, count how many items on your list are somebody else's to do, and notice how long they have been yours instead.

Week 11 · The two-minute rule and the four criteria

Build task. Process one hundred items in a single sitting, applying the two-minute rule strictly. Then, on the resulting Next Actions list, apply the four criteria to choose what to do next: context (where am I, what do I have), time available (three minutes or ninety), energy (sharp or spent), priority (what actually matters today). Write the four criteria on a card and put it where you will see it when you are deciding what to do at nine in the morning.

Drill — "Ten Before Two." Ten minutes, timer running. Take ten items and process them in under two minutes each, with a visible stopwatch. Anything that takes longer is not permitted; it goes to Next Actions. The drill is not about speed, it is about discovering how many of the things you have been carrying are actually four-minute jobs. In most groups the answer is between forty and sixty percent, and that number is the single most demoralizing and encouraging fact of the year, because it means the pile was never as large as it felt — it was only undecided.

Concept. Energy is a resource with a shape, and most people schedule their day as though it were flat.

Verse. John 9:4 — "As long as it is day, we must do the works of him who sent me. Night is coming, when no one can work."

Teaching. There is a version of this verse that gets used to justify frantic busyness, and that version is wrong. Read what it actually says: there is a limit, the limit is not in your control, and the appropriate response to a limit is to work in the light while there is light rather than to pretend the limit is not there. That is a time-management statement, and it is also a humility statement. The four criteria exist because a flat list of actions implies that all actions are interchangeable and all hours are the same, and neither is true. Reading and deciding are not the same task and cannot be swapped. A difficult conversation at four in the afternoon after eight meetings is not the same act as the same conversation at nine in the morning, and pretending otherwise is how people conclude they are bad at their job. Today, apply the criteria and write down what you actually chose and why. Next week, when you are tired, you will not have to make that decision again, because you will have made it once, in writing, while you were not tired.

Week 12 · Empty as a state, not an achievement

Build task. Count what remains in the inbox and put the number on the wall chart. Then write a single page, by hand, that answers three questions: what is this inbox actually for? what does it mean when it is full? and what is the honest count of items I decided to discard this month? Keep the page. It goes into the front of the system and stays there for the year.

Drill — "The Honest Count." Ten minutes, timer running. Go through everything you deferred in the last three weeks and mark each item: still real, was never real, or was real once. Count the three. The middle category is the medicine. It is the number of things you carried for months that were, on inspection, never going to happen, and seeing the number written down is what changes the behavior permanently — not resolve, not a new tool, and not a better method.

Concept. An inbox is a device for producing clarity, not a record of diligence, and the two get confused most often by people who are good at capture.

Verse. Ecclesiastes 12:12 — "Of making many books there is no end, and much study wearies the body."

Teaching. That line is written by somebody who loved books, and it is not anti-intellectual; it is anti-infinite. The Preacher's whole argument is that every human activity, pursued without a stopping condition, eats the person pursuing it, and that this is not a flaw in the activity but a property of created things. A knowledge system has an infinite surface. There will always be one more article, one more folder, one more tag, one more book to summarize, and the appetite for it is unbounded in a way that is flattering, because it feels like virtue. So the block ends here, with a written statement of what the inbox is for, because that sentence is the stopping condition. Without it, you will do this work forever and finish nothing, and you will be able to explain, in impressive detail, exactly why finishing nothing was the correct decision. Close the winter by being honest about the discard count. It is the first number in this document that measures judgment rather than motion.

Block 4 — Time: the only non-renewable inventory

"Teach us to number our days, that we may gain a heart of wisdom." — Psalm 90:12

"You can do anything, but not everything." — attributed to David Allen

Weeks 13–16 · Spring · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Spring is when the calendar fills and the list stops functioning as a plan. The list was never a plan; it was a menu. A menu is fine in January. By April, everything on the menu is due at once, and the person discovers that they have been using a list as a substitute for a schedule, which is roughly like using a shopping list as a substitute for going to the shop.

Nothing in this block is about doing more. It is about one distinction, held firmly for four weeks: a thing that has a time goes on the calendar; a thing that has a place goes on a list. Most people's chaos is a category error between those two. An appointment kept on a task list is a task that will be missed. A task put on a calendar as a two-hour block is a fiction that will be deleted at four in the afternoon when the day has eaten it.

The second idea is that time is the only inventory that cannot be replenished, borrowed, or manufactured. You can buy more paper and more storage. You cannot buy more Tuesday. Every argument in this block follows from that, and so does every argument in block 11 about scope, because scope is just a claim on time that somebody has already made before checking the stock.

What a newcomer should expect. You will time-block a week, it will fall apart by Wednesday, and that is the intended outcome of the first attempt. A time-blocked week that survives intact is not a sign of skill; it is a sign you blocked for too little. The skill is in the recovery, not the plan.

See also. The calendar is where the weekly review lives, and a review that is not on the calendar will not happen. The limit on how much may be in flight is block 10, and it is the same argument applied to projects instead of hours.

Week 13 · Calendar versus list

Build task. Take next week and put everything that has a time onto the calendar first — appointments, meetings, calls, deadlines, recurring obligations, travel. Then look at what is left. That remainder is your actual discretionary capacity for the week, and most people have never seen it, because they have never subtracted the fixed from the whole.

Drill — "Time or Place." Ten minutes, timer running. Take fifty items from your Next Actions and calendar and sort each one with a single question: does this have a time, or a place? A time means it must happen at a particular hour, usually because another person is involved. A place means it can happen whenever you are in the right context. Anything with a time goes to the calendar immediately. Anything with a place stays on a list. Items that have neither are not actions yet, and they go back for clarification.

Concept. A task list is a menu; a calendar is the meal. Confusing them is the most common cause of a week that disappears.

Verse. Psalm 31:15 — "My times are in your hands."

Teaching. That is a short sentence and it is doing a lot of work. It is not fatalism, and it is not the sort of resignation that produces a passive person. It is a statement about ownership: the hours are not mine to allocate as I please, they are held by someone else, and I am a steward of a schedule I did not write. That changes the emotional texture of a full calendar considerably. If the hours are mine, then a full week is a personal failure and every interruption is a theft. If the hours are held, then a full week is a fact about the season and the correct response is to find out what is actually being asked of me in it. Practically, this is why the calendar comes first and the list second. The calendar is the honest record of what has already been promised to other people, and a list that ignores it is not a plan, it is a set of intentions with no arithmetic behind them. Today, look at your next week before you look at your list, and see how much of the list was never going to happen.

Week 14 · Time blocking and the Eisenhower sort

Build task. Build one week as thirty blocks, colored or marked by type rather than by project: deep work, meetings, admin, errands, rest, margin. Leave at least five blocks empty on purpose. Then put the Eisenhower sort on one page — urgent and important, important not urgent, urgent not important, neither — and place your own recurring commitments into the four quadrants. If you have never done this, the answer will be uncomfortable and it is not a trick.

Drill — "Thirty Blocks." Ten minutes, timer running. Sketch next week on paper as thirty blocks, half-day by half-day. Fill only the blocks you are confident about. Then count the empty ones. Fewer than three empty half-days means the week has no capacity for anything unexpected, and a week with no capacity for the unexpected will be spent entirely on the unexpected, because the unexpected is the only thing with authority.

Concept. A plan with no slack is not a tight plan; it is a plan that will be rewritten by whoever interrupts you first.

Verse. Ephesians 5:15–16 — "Be very careful, then, how you live — not as unwise but as wise, making the most of every opportunity, because the days are evil."

Teaching. The phrase usually translated making the most of every opportunity is a commercial word: it means buying up the whole of something while the market is there, the way a trader takes a position before the price moves. It assumes scarcity and it assumes urgency, and it assumes that the opportunity will not be available later. That is a strange thing to say about time, and it is exactly right. The days are evil, in the sense of being unreliable, hostile to good intentions, and full of other people's emergencies. The wise response is not to fill every hour — that is the response of a person who believes they control the market. The wise response is to buy the hours that matter while they are cheap, which means protecting a few blocks with real force, and leaving the rest available for whatever the day actually brings. Note also that the passage is addressed to a community and not to an individual, which means the blocks you protect are partly protected for other people. Margin is not selfishness. It is the only thing that lets you say yes when someone needs you on a Wednesday.

Week 15 · Capacity: a real deadline

Build task. Run one day under a genuine deadline with one protected block and the phone physically in another room. Record three numbers: how many times you left the block, how many times you were interrupted, and how long the block survived. Those three numbers go on the wall chart.

Drill — "The Protected Block." Ten minutes, timer running, and then a real ninety-minute block if the room allows. Before it starts, write on paper: what the block is for, what the first physical action is, and what you will do when you are tempted to leave. The third item is the one that works. Everyone leaves their own block; the difference between people who finish things and people who do not is that the former have decided in advance what they will do at the moment of leaving, and the decision is usually "I will write one more sentence first."

Concept. Focus is not a personality trait; it is a property of the environment you have arranged.

Verse. John 11:9 — "Are there not twelve hours of daylight? Anyone who walks in the daytime will not stumble, for they see by this world's light."

Teaching. Jesus is answering a question about safety with an answer about working conditions, which is a very practical move. The point is that there is a fixed amount of usable light, it is not negotiable, and the correct behavior is to walk while you can see rather than to insist on walking in the dark and blaming the road. Applied to a day: you have roughly a fixed number of good hours, they are not evenly distributed, and the entire discipline consists of putting the demanding work inside them instead of inside whatever is left after the meetings. This is why the drill measures interruptions rather than hours worked. Hours worked is a number that can always be inflated by staying up later. Interruptions per block is a number about the environment, and the environment is the thing you can actually change. If your answer is fourteen interruptions, the fault is not your willpower and the fix is not discipline. The fix is a door, a phone in another room, and a written sentence about what happens when you want to leave.

Week 16 · Energy, not hours, and the circle

Build task. Track your own energy for seven days, three times a day, on a scale of one to five, and note what you had eaten, how you had slept, and what kind of work you had just done. At the end of the week, mark your two best hours of the day on a card and put the card on your wall. Then defend those two hours for a month and see what happens.

Drill — "Two Hours." Ten minutes, timer running. Write down, from memory and from the week's log, the two hours of the day when you are most capable of difficult thought. Then write down what currently occupies those two hours. The gap between the two answers is the most actionable single fact in this entire document, and closing it does more for output than any change to your notes.

Concept. Hard work is not a matter of how many hours you have; it is a matter of whether the right hours were spent on the right thing.

Verse. 1 Kings 19:7 — "Get up and eat, for the journey is too much for you."

Teaching. Elijah has just done the most impressive thing in his life and then collapsed under a broom bush and asked to die, and God's response to a suicidal prophet is not a rebuke, not an exhortation, and not a lecture about perspective. It is food and sleep, twice, and then a very long walk. That sequence is in Scripture deliberately, and it makes two claims that the productivity literature mostly does not make. The first is that some failures of will are failures of the body, and treating them as spiritual or moral problems is both unkind and ineffective. The second is that the correct response to depletion is not more discipline but restoration, and that restoration is a command rather than a reward. Notice also that Elijah's great victory immediately preceded his collapse, which is the pattern most people discover the hard way: the week after the biggest push is the week you cannot think. Plan for it. Close this block by writing down the two hours and the two recoveries, and then doing both for a month.

Block 5 — The weekly review and the horizons

"Let us examine our ways and test them, and let us return to the LORD." — Lamentations 3:40

"The weekly review is the critical success factor." — David Allen

Weeks 17–20 · Spring · Rhythm: teach, repetition, capacity, flow

Why this block, why now. The weekly review is the highest-return habit in this entire document and it is the first thing everyone drops. That combination is not a coincidence; it is a structural property of anything that pays out slowly.

By April you will have four months of capture, four months of sorting, and four months of decisions. None of it will hold together unless something goes back over all of it regularly, closes the loops that have reopened, notices the projects that have quietly died, and answers the question is this still true? That is a review. It is not planning. Planning is deciding what to do; reviewing is finding out what is actually the case. Almost everybody substitutes the first for the second, which is why they spend their lives making excellent plans on top of false premises.

The reason this block treats the review as standard work — a written checklist, executed the same way every time, in the 5S sense — rather than as an act of reflection, is that a review that depends on the mood of the person performing it will only be performed by a person in a good mood. The people who need the review most are the ones least able to invent it on the day. So we write it down.

What a newcomer should expect. The first review will take two hours and will feel like an archaeology project. The second will take an hour. By the sixth it will take forty-five minutes and it will be the most useful forty-five minutes of your week. You will miss weeks. Missing a week is not a failure and does not require a restart; it goes on the chart as a missed week and you resume. The one thing you must not do is replace the review with a longer plan when you have fallen behind, because that is the failure mode of the conscientious, and it is far more destructive than the failure mode of the lazy.

See also. The review is the maintenance schedule, and block 12 is the same document at a coarser resolution. Horizons of focus are the reason block 11 can define "finished" without lying to itself.

Week 17 · The checklist as standard work

Build task. Write your own twelve-item review checklist, by hand, on one page. Not borrowed from this document. Twelve items, in the order you will actually do them, each one a physical instruction rather than a principle. Then run it once, badly, and mark every item you skipped or fudged. The marks are the design notes for version two.

Drill — "Write Your Own Twelve." Ten minutes, timer running. Look at a month of your capture pile and ask: what would I have needed to look at, once a week, to have caught the things I actually dropped? Write one checklist line per answer, up to twelve. A reasonable starting set is: empty the physical tray; empty the phone inbox; review the calendar two weeks back and four weeks forward; review the project list for anything dead; review the waiting-for list for anything overdue; review someday/maybe for anything now possible; review the areas for anything neglected; check the wall chart; choose the week's three commitments; write one sentence about what happened last week. But your list should be yours, because a checklist you did not write is a procedure you will not follow.

Concept. A standard is not a rule imposed on you; it is a decision you made once, while thinking clearly, for the benefit of a version of you who is not.

Verse. Luke 16:10 — "Whoever can be trusted with very little can also be trusted with much, and whoever is dishonest with very little will also be dishonest with much."

Teaching. The small thing in this verse is not small in importance; it is small in scale, and the claim is that scale is the wrong variable to look at. Faithfulness is a property of the person rather than of the task, so the way you handle a fourteen-item checklist on a Thursday tells you something about how you would handle a much larger responsibility, and it tells you truthfully, because there is no audience. That is uncomfortable, and it is also the most hopeful thing in this block, because it means the fourteen-item checklist is not a trivial habit. It is the same muscle that everything else uses. The promise here is not that you will become a disciplined person by doing a checklist. The promise is narrower and better: the checklist is where a person who is not naturally disciplined can be disciplined on purpose, in one bounded hour, on one day of the week, and that is enough to hold the rest together.

Week 18 · Repetition: six daily, one weekly

Build task. Run six consecutive daily mini-reviews of ten minutes and one full weekly review of forty-five minutes. Log each one on the wall chart with a single mark: done, shortened, or missed. The chart is the deliverable. Nothing else this week counts.

Drill — "The Ten-Minute Version." Ten minutes, timer running, six days running. The daily version has exactly three questions and nothing else: what came in that I have not decided about? what did I commit to today that is not written down? what is the one thing tomorrow? That is the whole thing. The temptation will be to expand it, because a ten-minute review feels insufficiently serious. Resist, because the purpose of the ten-minute version is not to be thorough. It is to keep the system warm on days when the full version is not available, and a warm system costs nothing to restart.

Concept. Consistency of cadence beats completeness of content, every time, in every system.

Verse. Daniel 6:10 — "Three times a day he got down on his knees and prayed, giving thanks to his God, just as he had done before."

Teaching. The interesting clause is the last one: just as he had done before. Daniel had a cadence, it had a fixed number and a fixed times, and he kept it when the policy changed and the penalty was a den. The passage is often read as a story about courage, and it is, but the courage was available because the habit was already in place and did not have to be invented under pressure. That is exactly the argument for the daily ten-minute review. You are not trying to become thorough. You are building the thing that will still be there on the day you do not want to do it. Note also that Daniel's cadence included thanksgiving, which is worth thinking about as a design feature rather than a formality. A review that begins with what went wrong is a review people avoid. A review that begins with what actually happened, including the good, is one people will come back to. Open every review with one sentence about something that worked this week, and notice how much easier the rest of the checklist becomes.

Week 19 · Capacity: the review on the worst week

Build task. Write the five-minute version of your review on an index card and put it in your wallet or phone case. It has three items and no more. Then, this week, deliberately run the five-minute version on a day that has gone badly, and write one sentence about what the full version would have missed that the short one caught.

Drill — "Shrink, Don't Skip." Ten minutes, timer running. Take your twelve-item checklist and cut it to three items by asking, of each one, if I only had five minutes for the rest of the year, would I keep this? The three survivors are your floor. The other nine are your ceiling, and the ceiling is optional. This is the most important design exercise in the block, because it answers, in writing and in advance, the only question that actually decides whether a knowledge system survives: what happens when I cannot do the full version?

Concept. A system without a degraded mode is not a system; it is a fair-weather habit.

Verse. Psalm 73:26 — "My flesh and my heart may fail, but God is the strength of my heart and my portion forever."

Teaching. The psalmist is not describing a bad week. He is describing the collapse of his whole interpretive frame — he had looked at the prosperous and the arrogant and concluded that his own integrity had been pointless, and he says so plainly before he recovers. What is remarkable is that he says it inside the psalm rather than after it. The record of the failure is part of the record of the faithfulness. That is the correct model for a review, and it is the opposite of the model most of us carry, which is that the review is a report card and a bad week is a bad grade. A review that cannot record a bad week honestly will stop being run in the bad weeks, which are exactly the weeks it exists for. So the written floor matters spiritually as well as practically. It is the thing that lets you say this week was a disaster and I still showed up for five minutes, which is a true statement about faithfulness and not a consolation prize.

Week 20 · The horizons of focus

Build task. Answer six questions on paper, one per horizon, in one sitting: runway — what is on my list this week? one year — what am I trying to be true in twelve months? three to five years — what is the shape of the life I am building? purpose — what am I actually for? principles — what will I not do to get there? and the largest frame — who is this all for? Then write, on one page, the single sentence that connects the smallest item on your list to the largest answer.

Drill — "The Fifty-Thousand-Foot Question." Ten minutes, timer running. Pick the project that has been on your list longest without progress. Ask, at altitude: if this project succeeded completely, what would be different about my life in five years? If the answer is nothing, the project is not a project, it is a habit of intention, and it should be killed. If the answer is something you cannot articulate in one sentence, the project is not understood yet and no amount of next actions will save it.

Concept. Most stuck projects are not blocked by a missing action; they are blocked by an unexamined purpose.

Verse. Psalm 8:3–4 — "When I consider your heavens, the work of your fingers, the moon and the stars, which you have set in place, what is mankind that you are mindful of them, human beings that you care for them?"

Teaching. The move in that psalm is a change of altitude, and it is the move this week is trying to teach. The psalmist does not begin with himself. He begins by looking at something enormous, and the effect of looking at something enormous is not that he feels worthless — the passage goes on to say that humanity is crowned with glory and honour and put over the works of God's hands. The effect is proportion, and proportion is the thing that a person with three hundred next actions has entirely lost. This is why the horizons are worth an hour of your year. Not because the answers are reliable, and not because a five-year plan is a real thing. Because the exercise of standing back far enough to see the shape of your own life is the only reliable cure for the specific insanity of a person who is very busy with something that does not matter. Do it once a year. Date the page. Next year you will read it, and the gap between what you wrote and what you did is the most useful document you own.

Block 6 — Input discipline and the attention budget

"Above all else, guard your heart, for everything you do flows from it." — Proverbs 4:23

"Knowledge puffs up, but love builds up." — 1 Corinthians 8:1

Weeks 21–24 · Spring · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because the year now has a working system, and a working system with no filter is a bigger bucket.

This is the block that the standard literature handles worst. Building a Second Brain is generous about collection and thin about refusal. GTD is fastidious about capture and mostly silent on whether the thing should have been captured at all. Lean is the tradition that actually has an answer — the whole point of a pull system is that nothing enters the line until there is capacity to work on it — and so this block is mostly lean, applied to information instead of parts.

Three ideas carry the whole month.

First: input is not free, because processing is not free. Every item you let in demands a decision, and decisions cost attention. A saved article is not a neutral asset; it is a future obligation with a small recurring charge, and a thousand of them is a debt you will never repay. The reading pile is not a library. It is an accounts payable ledger.

Second: the filter must be positive, not negative. "Be more selective" is useless advice because it is a prohibition with no criterion. The useful version of selectivity is having a small number of live questions that you are actually working on, so that an incoming item is either relevant to one of them or not. Forte's version of this is a list of favourite problems; the research literature's version is a set of standing questions; either works, and what matters is that the number is small, the questions are specific, and they are written down.

Third: attention is a budget with a hard ceiling, and the ceiling is not negotiable. Unlike money, it cannot be borrowed against future capacity in any way that works. You can steal tomorrow's attention by staying up, and tomorrow will present the bill with interest. Every week in this block therefore includes a subtraction rather than an addition: something is removed from the input stream, permanently, and the removal is written down.

What a newcomer should expect. This block produces more guilt than any other in the year, because everyone knows they read too much and finish too little, and knowing it has not helped. The block's answer is not resolve. It is arithmetic and a small number of written rules.

See also. Distillation in block 7 is downstream of this filter; a filter is defined by what it is filtering for. The reason to refuse input is capacity to express. The arithmetic of attention is in Appendix D, and it is the same arithmetic as project scope in block 11.

Week 21 · The door, and what it is guarding

Build task. List every source that can put something into your attention without your explicit invitation: newsletters, feeds, notifications, group chats, subscriptions, auto-play, the phone's home screen. Count them. Write the number on the wall chart. Then turn off every notification that is not a human being asking you something directly.

Drill — "Where It Enters." Ten minutes, timer running. For each source on your list, write the honest answer to one question: did I choose this, or did I accept it? Chosen sources were deliberately subscribed to for a reason you could state out loud. Accepted sources arrived because somebody added you, or because it came with a purchase, or because it seemed useful at the time. The second category is where the volume is, and it is almost always more than half the list.

Concept. You cannot have a filter at the processing stage if you have no gate at the entry stage.

Verse. Proverbs 4:23 — "Above all else, guard your heart, for everything you do flows from it."

Teaching. The instruction is above all else, which is a strange ranking for a book that also commands justice, generosity, and care for the poor. The reason for the ranking is in the second clause: everything flows from it. Whatever is in the well is what comes out of the tap, and no amount of work on the tap changes the well. That is a claim about sources, and it is far more radical than a claim about notifications. What you let in continuously becomes what you think with, and it does so slowly and without your consent. Note also that the verb is guard, which is an active, physical, slightly aggressive word — a gatekeeper's word, not a librarian's. There is a version of this that becomes fearful and small, and it is not the version here: the proverb is not asking you to read nothing, it is asking you to know what is entering and on whose authority. Today, count the sources. Most people find between forty and a hundred, and most people find that they chose fewer than half.

Week 22 · The reading pile is a debt

Build task. Take the entire backlog of things you have saved to read, watch, or listen to later, and make a single honest count. Then, in one session, delete at least half of it without reading it. Not archive. Delete. Write one sentence afterward about what you were hoping those items would do for you.

Drill — "Declare Bankruptcy." Ten minutes, timer running. Take the backlog and apply the brutal filter: if this had arrived today, knowing what I now know, would I save it again? If not, it goes. Then for the survivors, apply the capacity test: do I have, in the next four weeks, the hours to consume what I just kept? If not, you keep the best of what fits and you delete the rest, because a backlog that exceeds capacity is not a queue, it is a lie about your future self.

Concept. An unread pile is not potential; it is a record of promises you made to a person you are not going to become.

Verse. 1 Corinthians 8:1 — "We know that 'We all possess knowledge.' But knowledge puffs up while love builds up."

Teaching. Paul is writing about a genuine dispute in a real church, and he makes a move that is devastating for anyone who thinks of learning as an unqualified good. He concedes the knowledge. He says: you are right, you know correctly, and your knowledge is inflating you. The contrast is not between knowledge and ignorance; it is between an inflating thing and a building thing. Knowledge that is not turned into love — into service, into something that bears weight for another person — is gas. That is a hard sentence and it is the theological form of the collector's fallacy, and it explains why a person can read for ten years and become smaller. Practically: your reading pile is not evidence of diligence. It is evidence of appetite, and appetite untranslated is a puff. Today, delete half of it and notice that nothing happens. That nothing is the lesson. The world does not end, the knowledge you needed still arrives when it is needed, and you have recovered a number of hours that you can now spend building something instead of inflating.

Week 23 · The attention budget

Build task. Write a one-page attention budget for a normal week. Total available waking hours, minus sleep, minus fixed obligations, minus commuting and chores. What remains is the real number, and it is always far smaller than people expect. Then allocate it explicitly: deep work, shallow work, input, output, relationships, rest. The allocation must sum to the total. If it does not sum, you are not budgeting, you are listing wishes.

Drill — "The Subtraction." Ten minutes, timer running, arithmetic on paper. Start at 168 hours in a week. Subtract sleep at your actual average, not your ideal. Subtract meals, travel, and the fixed obligations. Subtract the honest overhead of maintaining a household. Write the remainder in large numbers and look at it. Most people have between twenty and thirty-five discretionary hours, and most people are attempting to spend about sixty.

Concept. Attention cannot be borrowed. Every hour taken from tomorrow is repaid with interest, and the interest is paid in judgment rather than in time.

Verse. Mark 1:35 — "Very early in the morning, while it was still dark, Jesus got up, left the house and went off to a solitary place, where he prayed."

Teaching. The detail that matters is left the house. He did not find a quiet corner; he left, because the house had people in it and the people had needs and the needs were all legitimate. This is the pattern in the gospels and it is worth noticing how deliberate it is: he withdraws, the crowd follows, he serves, he withdraws again. He does not appear to have felt guilty about the withdrawal, and he does not appear to have regarded the crowd's demands as the definition of his day. That is a budget, executed by somebody with less time than you have. The arithmetic in today's drill is not a productivity exercise, it is a truth-telling exercise, and its purpose is to make you stop planning against a number that does not exist. A person who thinks they have sixty discretionary hours will say yes to things that require sixty, and will then fail at all of them and conclude something false about their own character. A person who knows the number is twenty-four will say yes to fewer things and finish them, and will feel, oddly, less busy.

Week 24 · Twelve problems, and the filter that makes the door usable

Build task. Write down the twelve questions you are actually trying to answer in your life and work right now. Not goals; questions. Specific enough that an article could be obviously relevant to one of them. Keep the number at twelve or fewer, and put the list where you capture. Then, for the rest of the year, every incoming item is tested against the twelve before it is allowed in.

Drill — "Relevance in Ten Seconds." Ten minutes, timer running. Take twenty items from your input backlog and test each against the twelve problems in ten seconds. Relevant or not relevant, no third option. Count how many pass. In most groups it is fewer than five out of twenty, and the five are usually better than everything else in the pile.

Concept. Selectivity is not a virtue you cultivate; it is a criterion you write down.

Verse. Philippians 1:9–10 — "...that your love may abound more and more in knowledge and depth of insight, so that you may be able to discern what is best."

Teaching. The sequence in that sentence is worth tracing carefully, because it runs against the way we usually think about discernment. It begins with love abounding, and it moves through knowledge and depth of insight, and it arrives at the ability to discern what is best. The goal is not more knowledge. The goal is discrimination — the capacity to tell the best from the merely good, which is far harder and far rarer. Note that the mechanism is love, which sounds sentimental until you notice what it does: love narrows. A person who loves a particular people, a particular place, a particular work has a criterion that a person who is interested in everything does not have. That is why the twelve problems work. They are not a reading list, they are a statement of what you love enough to spend a life on, and they turn an infinite stream into a finite set of relevant things. Write the twelve. Expect to be embarrassed by how vague the first attempt is. Rewrite them in October, and notice that they have become specific, and that the specificity is the year's actual output.

Block 7 — Distill: notes worth re-reading

"For it is precept upon precept, precept upon precept, line upon line, line upon line, here a little, there a little." — Isaiah 28:10

"Compression is a fundamental operation of the mind." — Tiago Forte

Weeks 25–28 · Summer · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because the vault is now full of things nobody will ever open again, and the reason is not that they were not worth capturing. It is that they are in the same form they arrived in — somebody else's words, at somebody else's length, written for somebody else's purpose.

Forte's contribution here is genuinely useful and genuinely misunderstood. Progressive summarization is not a highlighting technique. It is the observation that a note becomes more valuable the more times it is used, and that each use is an opportunity to compress it a little further for the next use. Five layers:

1. Layer one — the raw capture, exactly as it arrived.
2. Layer two — the bolded passages, chosen on a second pass, when you are looking for something.
3. Layer three — the highlighted few sentences inside the bold, chosen on a third pass.
4. Layer four — an executive summary in your own words, written when you need the note for something.
5. Layer five — a remix, where the note's content is pulled into something new that you are making.

The critical design principle is that you do not do all five layers when the note arrives. You do a layer when you use the note, and only then, because compression without a consumer is guessing. A person who summarizes every capture to layer five on arrival is doing enormous unpaid work for a reader who may never show up.

Two more terms this block uses and the rest of the document borrows. An intermediate packet is a self-contained piece of work — a paragraph, a diagram, a checklist, a half-finished section — that can be assembled into a larger deliverable without being rewritten. And twelve favourite problems, from block 6, is the filter that decides what is worth distilling at all.

What a newcomer should expect. Distillation is the most pleasant block in the year and the least urgent-looking, which is why people spend years here and never leave. Guard against it. The rule for the month is that every distillation must be attached to a specific thing you are trying to make.

See also. Distillation without retrieval is a hobby; the test is block 9. Distillation without expression is the collector's fallacy in a nicer costume, which is block 8.

Week 25 · Progressive summarization, layers one to five

Build task. Take one long document you have actually used twice — not one you might use — and distill it once per day for four days, one layer at a time. At the end, you have a note you could hand to somebody else. Do not do this to anything else this week.

Drill — "Bold, Then Highlight, Then Say It." Ten minutes, timer running. On a single long note, in three passes, each timed: pass one, bold the passages you would need if you were in a hurry. Pass two, within the bolded text, highlight the sentences without which the passage is meaningless. Pass three, close the note and write three sentences from memory saying what it argues. The third pass is the one people skip and the only one that produces learning, because remembering is a different operation from recognizing, and only one of them builds anything.

Concept. A note you have compressed is worth more than a note you have saved, and the difference is proportional to how many times you used it.

Verse. Isaiah 28:10 — "For it is precept upon precept, precept upon precept, line upon line, line upon line, here a little, there a little."

Teaching. This verse is usually quoted about patient instruction, and it is, but look at what it actually describes: an accumulation of small, repeated, layered additions, in a fixed pattern, until something is built that was not there before. That is compression and it is also pedagogy, and the two are the same operation. You do not understand a thing in one pass; you understand it in the fourth pass, when you notice that the sentence you bolded the first time is not the sentence you would bold now. That change is the entire evidence of learning available to you, and it is why the layers are separated by days rather than done in a sitting. Note also the phrase here a little, there a little, which is the antidote to the fantasy of the comprehensive summary. You are not producing the definitive note on the subject. You are adding one line to a structure that will be useful in a hurry, and the structure's value comes from its shape rather than its completeness.

Week 26 · Repetition: bold ten, highlight three, summarize one

Build task. Distill ten items to layer two, three of them to layer three, and one of them to layer four. Everything with the twelve problems open beside you, so that the irrelevant items are dropped rather than distilled. Volume, no perfection.

Drill — "Ten, Three, One." Ten minutes, timer running, three tracks at once. Start ten notes and bold. Move three of them forward and highlight. Take one of those three and write a four-sentence summary in your own words. Working the three layers simultaneously rather than in sequence is the drill, because it forces you to feel the difference in cost between them, and the difference in cost is what tells you which layer a note deserves.

Concept. The right amount of compression is the least that still lets a stranger use the note.

Verse. Proverbs 25:11 — "A word fitly spoken is like apples of gold in settings of silver."

Teaching. The image is of something small, precise, and set deliberately into a context that makes it visible. It is a craft image, and the craft is not in the gold or in the silver; it is in the fitting. That is exactly the standard for a compressed note, and it explains why most compression fails. People compress by cutting, and cutting produces a smaller version of the same thing. Fitting means choosing the few words that carry the weight of the whole and placing them where the reader will actually meet them. The test is not is this shorter? The test is could somebody else act on this? Which means the summary has to include the thing you would otherwise assume: what problem this solves, what it is for, when not to use it. Those are the parts people leave out, because they were obvious at the time. They are never obvious in March.

Week 27 · Capacity: intermediate packets

Build task. Take one live project with a real deadline and cut it into five to eight self-contained packets, each of which could be used without the others. Each packet gets a name, a single-sentence purpose, and enough internal context that it would make sense to somebody who had never seen the project. Then write the list of packets on the project's page and check off the ones you already have from old work.

Drill — "Ship a Fragment." Ten minutes, timer running. Choose one packet and finish it completely — not the project, the packet. A packet is finished when it could be read, used, or sent by somebody else with no further explanation from you. If you cannot achieve that in ten minutes, the packet was too large, and splitting it is the exercise.

Concept. Work that cannot be divided cannot be finished incrementally, and work that cannot be finished incrementally is work that will be done in a panic.

Verse. 1 Kings 6:7 — "In building the temple, only blocks dressed at the quarry were used, and no hammer, chisel or any other iron tool was heard at the temple site."

Teaching. That is a description of prefabrication, three thousand years early, and it is in the text because it was remarkable. Everything difficult and noisy happened somewhere else, in advance, by people who were not at the site, and what arrived at the site was finished and ready to place. The result was that the building went up quietly. This is the strongest available argument for intermediate packets, and it is an argument about where the noise happens. Most projects are loud at the end, because all the cutting and fitting happens when the deadline is close and everybody can hear it. A person who prepares packets in advance moves the noise earlier, into a period when nobody is waiting, and the delivery becomes quiet. Notice also the dependency: the blocks had to be dressed before they were needed, which means somebody had to know the dimensions in advance, which means the plan existed. That is why this week comes after scope and before the project-management block, and why the packet list is written down rather than remembered.

Week 28 · Flow: pruning, and the twelve problems again

Build task. Go through one area of your vault and delete a third of it. Not archive — delete, or move to a single archive container you will not open. The criterion is not quality; it is would I ever use this for one of my twelve problems? Then rewrite the twelve problems, dated, in light of four months of evidence about what you actually reach for.

Drill — "What Earns Its Keep." Ten minutes, timer running. Open the twenty most recently modified notes and ask of each: did I use this, or did I only make it? Mark them used or made. Count both. The ratio is the single most honest number in this document, and it will be embarrassing, and it will be different next year.

Concept. A collection is not improved by addition. It is improved by the removal of everything that dilutes the signal.

Verse. John 15:2 — "He cuts off every branch in me that bears no fruit, while every branch that does bear fruit he prunes so that it will be even more fruitful."

Teaching. The second half of that sentence is the part that gets skipped, and it is the part that has to do with you. The unfruitful branch is cut off. But the fruitful branch is pruned — which is a more careful and more painful operation, performed on something that is working, in order to concentrate its energy into fewer and better fruit. A vine that is not pruned produces a great deal of small fruit and eventually exhausts itself. If you read this as being about what to delete, you have got half of it. The harder question is what to prune: which of your genuinely good collections of notes, which of your genuinely useful projects, is spread so thin across so many branches that none of them will ripen. The answer usually involves giving up something you are good at. Close the block by writing down the one thing you will deliberately do less of, and put it where you will see it in October.

Block 8 — Express: output is the only proof

"Do not merely listen to the word, and so deceive yourselves. Do what it says." — James 1:22

"The value of a note is not in the note; it is in what the note lets you make." — Tiago Forte, paraphrased

Weeks 29–32 · Summer · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because it is week twenty-nine, and this is the block that the year exists for, and if it were placed in January nobody would still be present to hear it.

The collector's fallacy is the belief that accumulating understanding is equivalent to producing something. It is not a stupid belief. It is the belief of a careful person, and it is reinforced by an environment in which reading feels like work, saving feels like progress, and nobody ever asks you what you made. It is also, in this document's terms, the characteristic sin of the whole enterprise, and it is why section 5 argues that stewardship is measured in what was finished rather than in what was gathered.

The corrective is not to stop learning. It is a ratio, measured and written down: for every unit you take in, what did you put out? In a healthy system the ratio is not one-to-one, because some input precedes output by years. But the ratio should be visible, because an invisible ratio drifts, and it drifts in the direction of comfort.

Two supporting ideas. Reuse over creation: most people believe they must generate new material when what they need is to bring out old material in a new arrangement. And shipping as a discipline: a thing that has gone out the door to a specific person by a specific date is finished; a thing that is nearly ready is not finished and may never be.

What a newcomer should expect. This block makes people angry, and the anger is usually directed at the tasks. That is a good sign. If a week of this month makes you want to argue that your situation is different, the argument is worth writing down, because sometimes your situation is different and sometimes the argument is the collector's fallacy wearing a good suit.

See also. Scope and definition of done, without which "shipped" is undefined, is block 11. The flow limit that makes shipping possible is block 10.

Week 29 · The collector's fallacy, and one thing out the door

Build task. Before the session ends, ship one small thing to one real person. A paragraph, a diagram, a page, a recommendation, a summary of something you read. It must be small enough to finish today and real enough that the recipient is not a hypothetical. Then write the word shipped on the wall chart next to this week's number, and do that every week for the rest of the year.

Drill — "One Page, One Hour." Ten minutes to choose, then a real block if the room allows. Choose a topic from your twelve problems that you already know something about, and produce one page: a claim, three supports, one caveat. No research. The no-research rule is the whole drill, because it forces you to discover how much you already have. Most people discover that they know considerably more than they thought and have never once assembled it, which is a fact worth knowing about yourself.

Concept. The gap between what you have read and what you have made is not a knowledge gap; it is a production gap, and it closes only by producing.

Verse. James 1:22 — "Do not merely listen to the word, and so deceive yourselves. Do what it says."

Teaching. The verb is deceive, and James is very specific about the mechanism: the person who listens and does not act is not lazy, they are deceived, and the deception is self-administered. He goes on to use the image of a man who looks in a mirror and immediately forgets what he looks like — which is an almost exact description of reading something excellent and being unable to say a week later what it argued. The deception is that the hearing felt like the doing. That feeling is the entire problem, and it is why this block insists on something going out the door today rather than at the end of the month. Not because a paragraph is important, but because the act of producing breaks the spell in a way that no amount of additional input can. Notice also that James does not say the law is difficult to understand. He says the problem is forgetting. The remedy for forgetting is not more study; it is doing the thing while you still remember it.

Week 30 · Repetition: reuse, ten times

Build task. Produce ten pieces of output in one week, and none of them may involve new research. Every one is assembled from material you already have: old notes, old drafts, old conversations, old arguments. Ten is deliberately too many, because the number is what forces reuse instead of creation.

Drill — "Storeroom." Ten minutes, timer running, one output every sixty seconds — a bullet, a paragraph, a message, a list, a diagram sketch. The rule: whatever you produce must cite which old note it came from. Nothing from memory without a source note. The constraint feels artificial and it is the entire point, because it makes visible the inventory you have been ignoring.

Concept. Most of what you need to make already exists in your notes, and the reason you cannot see it is that you have never looked at your notes with a purpose.

Verse. Matthew 13:52 — "Therefore every teacher of the law who has become a disciple in the kingdom of heaven is like the owner of a house who brings out of his storeroom new treasures as well as old."

Teaching. The image is a person with a store, and the action is bringing out — the treasure is not the possession, it is the production. Note that the treasures are both new and old, which means the mature version of this is not only reuse and not only novelty, but a mixture. And note who is described: somebody who has become a disciple, which is to say somebody who has been changed by what they have stored. That is the distinction between a storeroom and a landfill. The storeroom's contents have been digested; the landfill's have not. This is the practical test for your own archive. If you can bring out an old note and it is immediately useful, you digested it when you made it. If you bring it out and cannot tell why you saved it, no amount of reorganization will help, and the honest response is deletion rather than another pass. Today, bring out ten things. Count how many were ready to be used.

Week 31 · Capacity: shipping under a deadline

Build task. Set a real deadline, tell a real person you will deliver by it, and deliver. The subject should be something you would normally take three weeks to prepare. You have this week. Write down, in advance and on paper, the three rules you are using to constrain scope so that delivery is possible: what is in, what is explicitly out, and what the minimum acceptable version looks like.

Drill — "The Constraint Write-Down." Ten minutes, timer running. Before you begin, write three sentences: what this is, what this is not, and the smallest version that would still be useful to the recipient. The second sentence is the one that saves the week. Most scope failure is not over-ambition; it is an unstated boundary, so the work quietly expands into every adjacent interesting thing and the deadline becomes the point at which you stop rather than the point at which you deliver.

Concept. A deadline does not make work take less time; it makes you decide what to leave out, and that decision is the work.

Verse. Ecclesiastes 9:10 — "Whatever your hand finds to do, do it with all your might, for in the realm of the dead, where you are going, there is neither working nor planning nor knowledge nor wisdom."

Teaching. The Preacher's argument, here and throughout, is that death is the great clarifier of effort. Not because effort earns anything, but because the time for effort is bounded and everything unfinished at the boundary stays unfinished forever. That produces a strange and useful kind of freedom. If the deadline is real and the time is short, then the question what should I leave out? becomes a moral question rather than an aesthetic one, and the answer is usually the part that only impresses people who already agree with me. Read the verse again and notice that planning is listed among the things that end. Planning is good. Planning is not the work, and there will come a moment when planning is simply a way of not doing it.

Week 32 · Flow: show the work, and the export test

Build task. Two things. First, put one finished thing in front of one real person who did not ask for it, and ask for a specific kind of response. Second, run the export test: take your system and export everything to a plain, open format — plain text, markdown, or paper — and verify that the export is complete and readable without any application. Write down how long the export took and what was lost.

Drill — "Hand It Over." Ten minutes, timer running. Give your finished thing to somebody and watch them use it without your help. Do not explain anything. Do not answer questions until they have finished. What you learn in those ten minutes is worth more than a month of self-assessment, because you will discover the exact sentence you thought was clear and is not.

Concept. A system you cannot leave is not a system; it is a dependency, and the test of ownership is the ability to hand it over intact.

Verse. Matthew 5:16 — "...let your light shine before others, that they may see your good deeds and glorify your Father in heaven."

Teaching. The instruction is let, which implies that the natural condition of light is to be seen and that the work required is removal of the covering rather than manufacture of the light. That is a different posture from self-promotion, and it is worth distinguishing carefully, because the difference is not in the visibility; it is in the destination of the attention. The verse ends with glory going somewhere other than the person doing the good deed, which is the only test that actually works. Practically: showing the work is not optional, because work that is never shown is work that is never corrected, and uncorrected work does not improve with age. But it matters enormously to whom and for what. Show it to somebody who will tell you the truth and use them for the rest of your life. Then run the export test, which is the other half of the same virtue: your system should be able to leave you, and you should be able to leave it. A vault that only opens in one application has quietly taken ownership of something you thought you owned.

Block 9 — Retrieval: the system's only real test

"Ask and it will be given to you; seek and you will find; knock and the door will be opened to you." — Matthew 7:7

"The purpose of a filing system is not to store things. It is to find them." — unattributed, and universally forgotten

Weeks 33–36 · Summer · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because everything else in the year is a hypothesis until retrieval is tested, and the test is embarrassingly concrete: can you find a specific thing you know you have, in thirty seconds, on a phone, from a room you are not in?

That is the whole standard. Not "is my system logically organized." Not "does my structure reflect my values." Those questions are unanswerable and infinite, which is why people enjoy them. The retrieval question has an answer, it takes thirty seconds to measure, and it will tell you in one afternoon whether the last eight months produced a system or a hobby.

There are three mechanisms, and they are listed in order of how much they actually contribute:

Naming. Almost all retrieval failure is a naming failure. The thing is in the system; it is called something you would not have thought of. This is why week eight's convention and week thirty-three exist, and why the pedantry about names in this document is deliberate and not a personality flaw. A name is the primary key. Everything else is a fallback.

Indexes. A short note that lists where things are, written for one purpose, updated as things change. Forte calls the general version a map of content; project managers call it a register; hospitals call it a chart. The value is that it is small and hand-written, which is why it can be trusted in a way that an automatic search cannot.

Memory. Spaced repetition and retrieval practice are the only two learning techniques with a very large and boring evidence base, and they are almost entirely absent from the note-taking literature. If you want to have something rather than be able to look it up, these are the only methods that work.

What a newcomer should expect. This is the month where people discover that they have been building a system for an imaginary version of themselves — one who searches neatly, remembers why things were saved, and never has to look something up in a hurry with cold hands.

See also. Naming conventions were decided in week eight and are stress-tested here. The defect taxonomy in block 12 is mostly built out of retrieval failures observed this month.

Week 33 · Search beats structure, and names are the structure

Build task. Write your naming convention on one page, in the form of a rule, not a list: what goes first, what goes second, what is never included. Then rename fifty files or notes to comply. Then, and this is the part people skip, search for ten of them the way you would search in a hurry — three words, no path, no memory of where you put them.

Drill — "The Primary Key." Ten minutes, timer running. Take ten notes and, for each, write the name a stranger would use when looking for it, and the name you actually gave it. Where they differ, rename to the stranger's version. Your own names encode context you had at the time and will never have again. The stranger's names encode what the thing is.

Concept. Structure is what a system looks like from the inside; naming is what it looks like from the outside, and only one of those matters in a hurry.

Verse. Matthew 7:7 — "Ask and it will be given to you; seek and you will find; knock and the door will be opened to you."

Teaching. The three verbs escalate: asking is verbal, seeking is effortful, knocking is physical and local. The progression is a decent description of how retrieval actually fails, too. You ask a system for something and get nothing, so you start seeking — opening folders, reading titles — and the failure happens at the third stage, where you are standing in front of the right door and knocking on the wrong one. Notice that the promise is not that everything will be found; it is that the seeking is not futile, which is a different and better claim. Applied to a vault: the promise is that a well-named thing can be found by somebody who does not know where it is. That is the standard this week is asking you to meet, and it is much more demanding than it sounds, because it requires you to give up the private shorthand that makes you feel clever and to write, instead, the boring name that works in a hurry with cold hands.

Week 34 · Repetition: find-it drills

Build task. Twenty find-it drills over the week, each timed, each logged: the question, the seconds, whether you found it, and — if not — why. Then make the misses into a list and put the list at the top of your system. The misses are the curriculum for the rest of this block.

Drill — "The Thirty-Second Twenty." Ten minutes, timer running, four to six questions maximum. Someone else should write the questions if you can arrange it, because you will unconsciously choose questions you know the answers to. Ask things like: the name of the person who recommended the book; the number you were given in March; the paragraph where you wrote down what you decided about the roof; the diagram you made when you were working out the schedule. Real questions from your own life, not abstractions.

Concept. A retrieval system is not tested by whether it contains the thing; it is tested by whether it returns the thing under time pressure.

Verse. Psalm 119:11 — "I have hidden your word in my heart that I might not sin against you."

Teaching. The psalmist's retrieval strategy is memorization, which is unfashionable and is the only one that works at three in the morning without a device. Note the stated purpose: that I might not sin against you — the retrieval is not for information but for behavior, which is why it must be available without looking it up. That distinction is worth carrying into your own system. Some things you want to be able to find; some things you want to have. A person who has to look up their own principles in a meeting has not yet internalized them, and no search engine fixes that. This is why the drill has a written answer and a spoken answer. Write down what you found, and then say aloud, from memory, the one thing you decided last month that you would do differently. If you cannot, you have found the boundary between what you have stored and what you have actually learned, and it is usually further in than people expect.

Week 35 · Capacity: the minimum viable vault, on a phone

Build task. Build the smallest version of your system that still works, and document it on one page. It must fit on a phone; it must be usable standing up; it must contain your twelve problems, your projects, your next actions, and the five documents you actually need. Then use only that for a week, and write down what you missed.

Drill — "Phone Only." Ten minutes, timer running, device only. Do a complete capture, a complete processing pass, and one retrieval, all on the phone, standing up, with one hand. No desk, no second screen, no sitting down. The constraint is the design brief, and the design brief is the summer rule: if it cannot be done in ten minutes on a phone, it will not be done at all in July.

Concept. The version of your system that you can run in bad conditions is your actual system; everything else is your ideal system.

Verse. Jeremiah 29:4–7 — "...Build houses and settle down; plant gardens and eat what they produce... seek the peace and prosperity of the city to which I have carried you into exile."

Teaching. The instruction is remarkable because the situation was supposed to be temporary. The people had been told they would be in exile for seventy years and were, quite reasonably, still behaving like people waiting to go home — not building, not planting, not investing. The command is to build anyway, in the wrong place, under bad conditions, because the conditions were not going to improve on the schedule they hoped for. This is the correct posture toward a system that does not fit your life. Most people are waiting for the version of their life in which they will have a desk, a block of quiet, and a proper setup, and they will be waiting for years. The person who builds the phone version now is the one who still has a working system when the good conditions finally arrive. Today, build the exile version. It is worse, and it is the one that will actually be there in July.

Week 36 · Flow: indexes and memory, and the circle

Build task. Write three index notes: one for your work, one for your household or family, one for the problem you are most actively thinking about. Each is one page, hand-written, and each lists where things are rather than what things are. Then choose five things you want to hold in your head rather than look up, and set up a simple spaced repetition practice: paper cards are sufficient and are better than an app you will abandon.

Drill — "The One-Page Map." Ten minutes, timer running. Without opening anything, draw from memory the structure of your own system: the containers, the current projects, where the three most important documents live. Then check it against reality and note the discrepancies. The discrepancies are the parts of your system you do not actually believe in, and they are the parts that will fail under pressure.

Concept. An index is worth more than a search box, because an index tells you what exists.

Verse. 1 Chronicles 12:32 — "...men of Issachar, who understood the times and knew what Israel should do."

Teaching. Two things are named in that verse, and they are not the same thing. They understood the times — which is analysis, comprehension, knowing what is going on — and they knew what Israel should do — which is judgment, decision, and command. A large part of the modern knowledge apparatus trains the first and produces very little of the second, which is why a person can be extremely well informed and permanently paralyzed. An index is a small instrument for the second thing. It does not tell you what is true; it tells you what you have, where it is, and therefore what you can decide right now. That is why the index is written by hand and kept short. A generated list of four thousand notes is comprehension. A hand-written page of eleven things you can act on is judgment. Close the block by writing the eleven, dating the page, and putting it where you will see it in the autumn.

Block 10 — Flow and WIP: kanban for one

"Better a handful with quietness than both hands full, together with toil and grasping for the wind." — Ecclesiastes 4:6

"Stop starting, start finishing." — the entire kanban literature, in four words

Weeks 37–40 · Autumn · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Autumn arrives with more due than there are weeks, and the only useful question in that situation is not what is most important — everything is important, that is why it is due — but how much can be in flight at once before all of it goes slowly.

That is what work-in-progress limits are, and the reason they work is arithmetic rather than psychology. If a person is carrying twelve open projects and can finish roughly two a month, then the mean time to finish any given project is six months, no matter how hard they work, and no amount of urgency changes it. Three of those twelve will be finished in the year. The other nine will be "in progress," which is a state that consumes attention in proportion to time spent, and produces nothing. The limit is what converts activity into throughput.

Four ideas carry the month, and they are the whole of practical kanban:

1. Visualize. Everything you are carrying, visible at once, in columns that reflect what actually happens rather than what you wish happened.
2. Limit. A number in every column except the last. When the column is full, nothing new enters, and the only permitted action is to finish something.
3. Pull, not push. Work is drawn into the next stage when there is capacity, not pushed into it because it is ready.
4. Measure cycle time. The timestamp on a card is the most honest number you will ever have about your own capacity, and it is almost always worse than you believe.

What a newcomer should expect. Your first board will have eleven columns because your process feels complicated. It has three columns: to do, doing (with a limit), done. A board with eleven columns is a chart of a process you have not yet understood.

See also. A limit is a budget, and a budget is a scope decision made once instead of daily — that is block 11. The time arithmetic is block 4. The review that enforces the limit is block 5.

Week 37 · Visualize and limit

Build task. Build a physical board — wall, sticky notes, pencil on paper, anything visible without a device — with three columns and a limit written on the middle one. Put every open project on it. Then mark, on each card, the date it started. One number goes on the wall chart this week: the count of projects in flight.

Drill — "Three Columns and a Number." Ten minutes, timer running. Build the board, then apply the limit: if you have more cards in doing than the limit, you do not get to remove the limit; you get to move cards back to to do until you comply. Choosing which ones is the actual work. Most people find it takes about four minutes and produces an immediate sense of loss and a following sense of relief, in that order.

Concept. A limit you have not broken in front of a witness is a suggestion.

Verse. Proverbs 19:2 — "Desire without knowledge is not good — how much more, one who rushes and misses the way."

Teaching. The phrase rushes and misses the way is doing something interesting. It is not describing a person who is slow or idle; it is describing a person with legitimate desire and insufficient knowledge, whose energy is real and whose direction is wrong, so that the energy makes the error worse. This is the exact pathology that a work-in-progress limit addresses, and note that the proverb's remedy is knowledge rather than restraint. It is not that desire is bad. It is that desire without a map produces speed in the wrong direction, and speed in the wrong direction is more expensive than sitting still. That is why the board has dates on the cards. A card that has been in progress since March is desire without knowledge; the date is the knowledge. Do not look at the date and feel bad. Look at the date and learn the number, because an accurate number about your own capacity is a gift and a flattering estimate is the most expensive friend you have.

Week 38 · Repetition: pull, not push

Build task. Work the board for a week and move twenty cards, obeying the limit every time. Count, honestly, how many times you started something new before finishing something existing. That count goes on the wall chart, and next week you try to beat it.

Drill — "Finish Before Finish." Ten minutes, timer running. Every time you complete a card, the rule is: before you pull a new card, finish or file everything the completed card produced. Not next week, not later today. The output of finished work — the document, the follow-up, the note, the administrative tail — is where most of the real inventory hides, and it hides behind the satisfying act of starting the next thing.

Concept. Starting is more pleasant than finishing, which is why the invisible discipline of a system is refusing to start.

Verse. Exodus 16:17–18 — "The Israelites did as they were told; some gathered much, some little. And when they measured it by the omer, the one who gathered much did not have too much, and the one who gathered little did not have too little."

Teaching. The manna story is usually read as being about provision, and it is, but it is also the first recorded work-in-progress limit. The instruction was to gather one day's amount, no more; the people who gathered more found it rotted. The limit was not a punishment for greed — it was a description of the capacity of the system. You could not store it, so storing it destroyed it, so the amount that could be worked was the amount that could be used. That is a kanban board with a limit on the middle column, and the failure mode is two days of manna in the inbox. Note the detail that the one who gathered little did not have too little, which is a claim about sufficiency that is worth testing this month. Most people, when they reduce what is in flight, expect to lose output. What usually happens is that the same output arrives in a different order, sooner, with less dread. Gather what you can use today. Let the rest arrive tomorrow, which it will.

Week 39 · Capacity: cycle time, and Little's Law for one person

Build task. Timestamp ten cards from the moment they enter doing. Measure from entry to done, not from the date you first thought about them. Then apply Little's Law, which is the only equation in this document: average cycle time = average work in progress ÷ average throughput. If you have six items in progress and you finish two per week, your cycle time is three weeks. Write that number on the wall chart and keep it there.

Drill — "The Arithmetic of the Board." Ten minutes, timer running, calculator allowed. Count items in progress. Count items you completed in the last four weeks and divide by four. Divide the first by the second. Then answer one question: is the number on this page acceptable to me? If it is not, the equation says there are exactly two levers — fewer in progress, or more throughput — and only one of them is under your control this month.

Concept. Cycle time is a consequence of how much you are carrying, not of how hard you work.

Verse. James 4:14 — "Why, you do not even know what will happen tomorrow. What is your life? You are a mist that appears for a little while and then vanishes."

Teaching. The verse is usually read as an argument for humility about plans, and it is, but look at what it does to arithmetic. A mist has a duration that is short and not under its own control, which means the only sensible planning question is given that the duration is unknown and short, what is worth putting in it? That is a cycle-time question. It is also the reason the number on your wall chart deserves attention rather than shame. Six weeks to finish a project is not a character flaw; it is a fact about capacity, and facts about capacity are the raw material of any plan that will survive contact with a Tuesday. The man in James's example makes his plans without the number. He says he will go to this city, spend a year there, and make money, and the response is not that commerce is wrong — it is that he does not know the number. Get the number. Write it up. Then plan.

Week 40 · Flow: the bottleneck, and the circle

Build task. Identify your bottleneck in one sentence and write it on the board where you cannot avoid it. Then hold it for a month. The bottleneck is not a metaphor; it is the specific stage where work accumulates and waits. For most people it is not the tool and it is not the research. It is the review — the absence of a fixed weekly point at which decisions are made and things are closed.

Drill — "Where the Pile Is." Ten minutes, timer running. Look at the board and find the column with the oldest cards. That column is your bottleneck, or it is downstream of it. Then ask the question the shop floor asks: what is waiting here, and who is it waiting for? If the answer is you, the fix is a calendar block. If the answer is a decision, the fix is a definition of done — that is, the next block.

Concept. Every system has exactly one constraint at a time, and improving anything else is decoration.

Verse. 1 Corinthians 12:21 — "The eye cannot say to the hand, 'I don't need you!' And the head cannot say to the feet, 'I don't need you!'"

Teaching. Paul's argument is about the body and about status, and the part that translates directly into process work is the claim that the members we are tempted to dismiss as unglamorous are the ones that are indispensable. The bottleneck in a personal system is almost always the unglamorous stage. Nobody wants to be the person whose insight is my problem is the weekly review, because that is a claim about ordinary discipline, and everybody would prefer the answer to be a better tool or a cleverer structure. But the constraint is where it is regardless of what you would prefer it to be. Notice also that Paul's remedy is not to elevate the hand above the eye. It is to acknowledge the dependency, which means the correct response to identifying your bottleneck is not to declare war on it. It is to put the constraint in the calendar first and to stop optimizing everything downstream of it, because improvements made downstream of a constraint do not appear in the output. You will already have noticed this in your own life: the perfect filing system for material that never gets processed.

Block 11 — Scope, sequence, and the honest finish line

"I am carrying on a great project and cannot go down." — Nehemiah 6:3

"Of the three constraints — scope, time, cost — you get to fix two. The mistake is believing you fixed all three." — the whole of project management, in one sentence

Weeks 41–44 · Autumn · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because in autumn everything is due, and the reason things are due at once is almost never that the person is lazy. It is that the commitments were made without a scope.

Scope management is the most underrated skill in project management and the most useful skill in an ordinary life, because every hard conversation you have ever had about a deadline was, underneath, a conversation about scope that nobody had. "How long will it take?" and "when can you have it?" are the same question, and neither can be answered without first answering "what exactly is it, and what is it not?"

There are four constraints and only four. Scope, which is what is included. Time, which is when it is due. Cost, which is what it consumes — money, people, and in personal work, almost always hours. And quality, which is how good it has to be to count. The rule is not that you can have any three; the rule is that any change to one of the four changes at least one of the others, whether or not anyone says so out loud. A new requirement added in October is paid for in November, and it is paid for in quality or in sleep. There is no fourth option, and pretending otherwise is how people arrive at the deadline with something that is neither on time nor good.

The personal-scale translation is blunt and worth having on a card:

• Fix the date. Negotiate the scope. Never the reverse, because a date is a promise to another person and scope is usually a preference.
• Write down what is out. A scope that lists only inclusions is not a scope; it is a wish.
• Define done before you start. "Finished" must be checkable by somebody else.
• One owner, one next action. Two owners is no owner; three next actions is no next action.
• Kill things on purpose, in public, with a date.

What a newcomer should expect. This is the block where people discover that their project list is a list of areas, and that several of their projects have been "in progress" for so long that the phrase has become a way of describing a mood. Killing them is the relief of the year and it will feel like a loss for about four days.

See also. The limit that makes sequencing possible is block 10. The review that catches scope creep before it eats a month is block 5. Project versus Area, settled in block 2, is the same argument at rest.

Week 41 · Outcome, next action, definition of done

Build task. Rewrite five projects as three lines each: the outcome (what will be true when this is finished, stated so a stranger could check it), the next physical action (a verb your hands can perform), and the definition of done (the specific, checkable condition under which you will declare it complete). Then delete any project for which you cannot write the third line, and note in one sentence why you kept it if you did.

Drill — "Could a Stranger Check It?" Ten minutes, timer running, five projects. For each, read your outcome sentence aloud and ask: could somebody who does not know me verify whether this is true? "Get the house in order" cannot be verified. "The garage floor is clear, the boxes are labelled, and the car fits" can. The test is not pedantry; it is the difference between a project that can end and a project that will follow you into next year wearing a new name.

Concept. A project without a definition of done is not a project; it is an area with a deadline attached, which is the most exhausting object in any system.

Verse. Nehemiah 6:3 — "I am carrying on a great project and cannot go down."

Teaching. Nehemiah's enemies invite him to a meeting four times, and four times he declines with the same sentence, and the sentence is a scope statement. He names what he is doing, he names its size, and he names what going down to the plain would cost — the work would stop. That last part is the whole discipline. He is not being rude and he is not being inflexible; he has a criterion, and the criterion makes the decision for him, which means he does not have to weigh each invitation on its merits at the moment it arrives. Notice also that he does eventually go down, in chapter seven, when the wall is finished and the doors are set. The refusal was not permanent, it was sequenced. That is the difference between a person with a scope and a person who is merely stubborn. Write your three lines this week, and use the third one — the definition of done — as the thing that tells you when you are allowed to go down to the plain.

Week 42 · Repetition: the A3, and five projects on one page each

Build task. Produce five one-page project sheets, one per project, in the A3 format: background (why this exists, two sentences), current situation (where it actually stands, honestly), target (what done looks like, with a date), the gaps (what is between here and there), the plan (three to seven steps, each with an owner and a date), and follow-up (when you will look at this again). One page. Not two.

Drill — "One Page, Six Boxes." Ten minutes, timer running, one page. Draw six boxes and fill them in that order, briefly, for the project that is currently causing you the most anxiety. The box that is hardest to fill tells you which part of the project is actually undefined, and it is usually the gaps — people know where they are and where they want to be and have never written down what is between the two, which is why the plan feels like it should be obvious and is not.

Concept. A plan that does not fit on one page has not been thought through; it has been collected.

Verse. Isaiah 8:1 — "Take a large scroll and write on it with an ordinary pen."

Teaching. The instruction is oddly specific: an ordinary pen, on a large scroll, in plain characters, so that anyone passing could read it. The writing is deliberately public, deliberately legible, and deliberately not precious. That is the A3 discipline exactly. The one-page constraint is not an aesthetic preference; it is a forcing function, because when you cannot use more space you are compelled to decide what matters, and deciding what matters is the thinking you have been avoiding. Note also the destination of the writing: it was to be read by other people. A project sheet that nobody else could understand is a private note, and private notes about projects are where optimism hides. Show one of your five pages to somebody this week and watch what happens when they ask a question you did not anticipate. That question is the value of the exercise, and it costs one page and ten minutes instead of three weeks in November.

Week 43 · Capacity: the project that goes wrong

Build task. Take a project that is late, over budget, or worse than you promised, and write the honest status report. Five lines: what was promised, what is now true, what changed, what it will now take, and what I am asking for. Then deliver it to the person who is waiting, this week, without being asked.

Drill — "The Bad News First." Ten minutes, timer running. Write the report you would want to receive if you were the person waiting. Then write the report you would prefer to send. The difference between the two documents is your entire inventory of avoidance, and it is always smaller than it feels and always larger than you hoped.

Concept. Bad news does not improve with age, and the cost of a delayed report is almost always larger than the cost of the problem being reported.

Verse. Proverbs 28:13 — "Whoever conceals their sins does not prosper, but the one who confesses and renounces them finds mercy."

Teaching. The proverb makes a claim about outcomes that is empirically true in project work and worth taking seriously as a general principle. Concealment does not merely fail to help; it compounds, because the problem grows while the report does not, and the eventual revelation has to account for both. The word renounces is the part people leave out of their status reports. Confession without a change of plan is just disclosure, and disclosure without a plan is what makes people stop trusting you. So the five-line format is deliberate: the fourth line is what it will now take, and the fifth is what you are asking for. Those two lines are the renunciation. They convert a confession into a proposal, and a proposal is something the other person can say yes to. Do it before you are asked. The person who reports a problem before anyone notices is trusted with more, not less, and that is a fact that surprises almost everybody the first time it happens to them.

Week 44 · Flow: kill three projects, in front of witnesses

Build task. Kill three projects on purpose. For each: write the reason in one sentence, remove it from the active board, tell anyone who was promised something, and move it to the archive with the word abandoned and the date. If you cannot kill three, kill one and write down what stopped you on the other two — the obstacle is more instructive than the kill.

Drill — "What Dies So This Lives." Ten minutes, timer running. Choose the one project you most want finished this autumn. Then list everything currently competing with it for your attention, and mark what you will stop doing to make room. Stopping something is the only mechanism that actually creates capacity; starting nothing new creates nothing.

Concept. Capacity is created by subtraction or not at all, and a project you will not finish is a decision you have not made yet.

Verse. John 12:24 — "Very truly I tell you, unless a kernel of wheat falls to the ground and dies, it remains only a single seed. But if it dies, it produces many seeds."

Teaching. The image is not of losing something and being compensated for it; it is of a seed that must cease to be a seed in order to become a plant. Something recognizable ends so that something unforeseeable can exist. That is the correct posture toward killing a project, and it is much harder than the arithmetic version because a project is not only work — it is an identity. The project you have been "working on" for two years is a story about who you are, and killing it kills a small part of that story, which is why people protect dead projects with extraordinary energy and call it commitment. Note that the verse is not a general endorsement of destruction. It is an argument about sequence: fruit requires a burial, and the burial has to be real, which in this case means telling the people who were promised something instead of quietly leaving the project in a folder where it will bother you for another year. Kill three. Say why. Write the date. Then look at what is left and notice how much lighter the board is.

Block 12 — Quality, maintenance, and the re-entry protocol

"Let us examine our ways and test them, and let us return to the LORD." — Lamentations 3:40

"Nobody gives you a medal for firefighting. You get a medal for preventing fires." — the quality tradition, paraphrased

Weeks 45–48 · Autumn · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because every system accumulates maintenance debt, and a person who has never planned for the debt mistakes it for personal failure.

There are exactly four kinds of defect in a personal knowledge system, and they are worth naming because naming a defect is the difference between being annoyed by it and fixing it.

1. Unfindable. The thing exists and you cannot get to it. This is a naming failure or an index failure, and it is the most expensive defect because it costs you twice — once when you fail to find it, and again when you rebuild it.
2. Undated. The thing exists, but you cannot tell whether it is current. Almost all reference material becomes dangerous rather than useful once its date is lost.
3. Duplicated. The same thing in two places, in two versions, one of which is wrong. This is the only defect this document is genuinely pedantic about, because it is the only one that quietly destroys trust in the entire system.
4. Orphaned. The thing exists and nothing points to it. An orphan is not a defect you notice; it is a defect you notice the absence of, years later, when you needed it.

The quality tradition's core claim is that these are process defects, not character defects. A duplicate exists because the system permitted two doors. An unfindable thing is unfindable because the naming rule did not cover that case. You fix the process, and the defect stops recurring, and you do not have to feel bad in the meantime. That is Deming's contribution to your Saturday, and it is worth more than any productivity technique in this document.

This block also contains the most useful single page in the document: the re-entry protocol. Everyone falls off. The people who recover have written the recovery in advance.

See also. The review in block 5 is where defects are found. The retrieval tests in block 9 are where they are observed. The kaizen habit here is the same instrument as the annual refactor in block 13, at a different scale.

Week 45 · The defect taxonomy, and the fifteen-minute clean

Build task. Write your own defect list — the four categories, in your own words, with one real example of each from your actual system. Then schedule a recurring fifteen-minute weekly clean and put it on the calendar as a repeating event with a name. Not "organize files." A name like Friday 4:00 — clean and close.

Drill — "Five Whys, Once." Ten minutes, timer running. Take the most recent thing you could not find and ask why five times, writing the answer each time. Could not find the invoice → because it was in three places → because two systems were in use → because the second one was adopted in June for one client → because the client required a portal → because there is no rule about portals. The fifth answer is the process defect, and it is almost always a missing rule rather than a missing effort.

Concept. A defect is not evidence about your character; it is evidence about your rules.

Verse. Lamentations 3:40 — "Let us examine our ways and test them, and let us return to the LORD."

Teaching. Three verbs, in order, and each one matters. Examine is looking without defending. Test is checking the examination against something external, because self-assessment without a test is just a mood. Return is the action that follows, and it is worth noticing where it points — not to a better system, but to the LORD. That ordering keeps the whole exercise from becoming self-absorption. The purpose of auditing your own ways is not to achieve an optimized version of yourself; it is to remove the things that are between you and the thing you are for. That is why the defect taxonomy is deliberately boring and deliberately short. A four-item list can be examined honestly in ten minutes. A comprehensive framework of thirty-four categories will be examined once, admired, and never opened again. Examine, test, return. Then do it again next Friday, for fifteen minutes, for the rest of your life, and expect it to be unremarkable.

Week 46 · Repetition: refactor, do not decorate

Build task. Refactor one area of your system: merge what should be merged, split what has grown into two things, rename what is misnamed, and produce a deletion-candidate list of at least ten items. Then delete five of them. Refactoring is not tidying. Tidying moves things; refactoring changes the shape so the problem cannot recur.

Drill — "Merge, Split, Rename, Delete." Ten minutes, timer running, four operations, in that order, until the timer stops. The order is deliberate. Merging first removes work from everything downstream, and deletion last means you have already seen the item three times and cannot claim you did not consider it.

Concept. Decoration makes a system look maintained; refactoring makes it stay maintained, and only one of those is visible from outside.

Verse. Matthew 9:17 — "Neither do people pour new wine into old wineskins. If they do, the skins will burst; the wine will run out and the wineskins will be ruined. No, they pour new wine into new wineskins, and both are preserved."

Teaching. The point of the image is compatibility rather than novelty. New wine is still fermenting and produces gas; old skins have lost their elasticity and will split. The container has to match the contents, and when the contents change, the container has to change too — not because the old one was bad, but because it was built for a different load. Every knowledge system eventually reaches this point. The structure that worked when you had four projects does not work at twenty, and the response is not to squeeze harder. This is why refactoring is a scheduled activity rather than a response to crisis: the wineskin has to be replaced while the wine is still manageable, and by the time it bursts you are cleaning up rather than building. Look at your one area this week and ask the wineskin question directly. Has the volume changed, or the kind of work, or the number of people involved? If yes, the structure is out of date regardless of how tidy it looks, and tidying it is decoration.

Week 47 · Capacity: the re-entry protocol

Build task. Write your re-entry protocol on one index card: seven steps, in order, each taking under ten minutes, that will bring your system back from a month of neglect without a rebuild. Then test it, on purpose, on something you have genuinely neglected. The test is not optional, because an untested protocol is a hope.

Drill — "The Untested Protocol." Ten minutes, timer running. Deliberately apply your protocol to the messiest, oldest, most abandoned area you have. Time each step. If any step takes over ten minutes, split it. If any step requires a decision you cannot make in the moment, rewrite it as an instruction. The standard is that a person who is tired, discouraged, and three weeks behind can follow it without thinking.

Concept. The measure of a system is not how it performs when you are keeping up; it is how it recovers when you are not.

Verse. Jeremiah 18:4 — "But the pot he was shaping from the clay was marred in his hands; so the potter formed it into another pot, shaping it as seemed best to him."

Teaching. The potter does not throw the clay away, and he does not pretend the marring did not happen. He reworks it into a different vessel. That is the correct model for re-entry, and it is a much better model than the two that people actually use, which are restart from scratch and pretend nothing happened. Restarting throws away the clay. Pretending leaves the marring in place and it will show up again in the same spot. Reworking means accepting that the thing you are coming back to is not the thing you left, and shaping it into what is best for the potter's purpose now. Practically, this is why the protocol has a step that says do not process the backlog; sweep and triage instead. You are not restoring February. You are forming a new vessel out of what is still workable, and the rest goes where clay that has dried out goes, without ceremony. Write the card. Test it. Keep it in your wallet for the rest of your life, because you will need it roughly twice a year.

Week 48 · Flow: kaizen, and the control chart

Build task. Two things. Make one small standard change to your system and write the new standard down, dated, on the same page as the old one — do not replace it, because the history is the evidence. Then put twelve weeks of your wall chart numbers on a single page as a simple line and answer one question: is the variation noise, or is it a trend?

Drill — "One Percent, Written Down." Ten minutes, timer running. Choose one small friction in your system — a step you skip, a place you hesitate, a thing you look up repeatedly — and change it. Then write the standard: as of [date], we do [specific thing] this way. The written standard is the whole drill. An unwritten improvement is a preference, and preferences are renegotiated every time you are tired.

Concept. Improvement without a written standard is a mood that will pass.

Verse. 2 Corinthians 10:12 — "When they measure themselves by themselves and compare themselves with themselves, they are not wise."

Teaching. Paul's target here is a group who have invented their own scoring system and are winning it. That is the exact failure mode of self-measurement, and it is worth naming carefully because this whole document asks you to measure yourself and could easily produce the same disease. There are two guards. The first is that the numbers on the wall chart are about the process, not about you — an inbox count is a fact about doors, not a verdict on a person. The second is that the chart is read for variation, not for improvement. A control chart asks whether a reading is inside the normal range for this process; it does not ask whether you are doing well. That distinction is what prevents the numbers from becoming a grade, and it is why the drill ends with the question noise or trend rather than better or worse. Twelve weeks of a number that wobbles between 40 and 60 without pattern is a stable process, and a stable process is a good thing, even if the number is not the one you wanted.

Block 13 — Archive, teach back, and the next year

"There is a time to keep and a time to throw away." — Ecclesiastes 3:6

"The last step of any system is making yourself unnecessary." — the handover principle

Weeks 49–52 · Autumn · Rhythm: teach, repetition, capacity, flow

Why this block, why now. Because the year should close by giving the system away and then taking it apart.

An archive that is a graveyard is a failure, and an archive that is a resource is the entire point of having one. The difference is not organization and it is not tooling. It is whether anything comes out. A resource is drawn from; a graveyard is visited. By December you should be able to name three things you retrieved from the archive and used, and if you cannot, then the archive is a place you are storing things to avoid deciding about them, which section 9 explicitly forbids.

The other thing this block does is teach back, and it is not a formality. A person who can teach a block without notes owns it. A person who cannot has rented it for a year. The gap between those two states is where almost all of the durable learning in this document happens, and it happens in week fifty-one rather than in any of the preceding fifty.

What a newcomer should expect. This block is emotionally strange. People are reluctant to dismantle a system they spent a year building, and the reluctance is worth naming: it is the same instinct that keeps dead projects alive. The year ends with four things kept and the rest released, on purpose, in writing.

See also. The archive inherits the definition of finished from block 11, and the containers from block 2. The refactor here is block 12's kaizen at annual scale.

Week 49 · The archive as a resource, and retention

Build task. Write a one-page retention policy: what is kept forever, what is kept for a fixed period, what is deleted on a schedule, and who decides. Then apply it to one year of accumulated material and delete what the policy says to delete. Put three things you retrieved from the archive this year and actually used at the top of the archive page, as evidence.

Drill — "Three Out of the Store." Ten minutes, timer running. Find three things in your archive you have used since they were archived. Write down what you used them for. If you cannot find three, write down what that tells you, honestly, and reduce the archive by a third this week.

Concept. Retention is a decision, and a decision made once is a policy while a decision made per item is a tax.

Verse. Ecclesiastes 3:6 — "a time to keep and a time to throw away."

Teaching. The Preacher's list is usually read as poetry about seasons, and it is also a filing system with a deletion clause, which is the part nobody quotes. Notice that keeping and throwing away are given the same grammatical weight — neither is the default, and neither is the virtuous option. That symmetry is the whole of a retention policy. A person who keeps everything has not decided; a person who throws everything away has also not decided, they have merely chosen the faster default. What the verse asks for is a judgment about this thing, made once, on grounds you could state out loud. So write the policy, and put the evidence at the top. The three items you actually used are the argument for keeping an archive at all; the absence of three items is the argument for a smaller one. Both arguments are stronger than any opinion you hold about your own diligence.

Week 50 · Repetition: the handover document

Build task. Write the document that would let a stranger run your system. It must cover: where things live, what the naming rule is, what the review covers and when, what the four containers mean in your life, what is archived and on what principle, and the three things that would break if they were done differently. One page, maybe two. Then hand it to somebody and watch them use it.

Drill — "Explain It to Somebody Who Does Not Care." Ten minutes, timer running. Explain your system to a person with no interest in systems, in five sentences, and stop. If you cannot do it in five, you do not have a system; you have a set of habits and a vocabulary. The five-sentence test is brutal and it is the only honest measure of whether the year produced understanding or fluency.

Concept. A system that cannot be handed over is a personal dependency dressed as a methodology.

Verse. 2 Timothy 2:2 — "And the things you have heard me say in the presence of many witnesses entrust to reliable people who will also be qualified to teach others."

Teaching. There are four generations in that sentence: Paul, Timothy, the reliable people, and the people those people will teach. The instruction is not to preserve the teaching but to entrust it, which is a different act — it implies risk, because the person you entrust something to may do it differently or badly. Paul takes that risk anyway, and the structure of the sentence means he has to. A teaching that is only held by one person dies with them, no matter how carefully it was preserved. That is exactly the argument for the handover document. You are not writing it because you plan to leave. You are writing it because a system that only exists in your head is not a system you can rely on during a bad month, and because somebody else in your household, your team, or your church may need to know where things are, and you may not be in a position to tell them. Write the page. Hand it over. Watch what they cannot understand. That list is your real syllabus for next year, and it is more useful than anything in this document.

Week 51 · Capacity: teach back

Build task. Teach one entire block to whoever will listen — a session, a lunch, a family member, one person — without notes, in fifteen minutes, in your own words. Then write one paragraph on what you could not explain. That paragraph is the actual output of the year.

Drill — "No Notes, Fifteen Minutes." Ten minutes of preparation, then fifteen minutes of teaching with nothing in your hands. If you reach for your notes, stop and start the section again. The standard is not fluency; it is having the structure in your head, which is exactly what the year was for.

Concept. You do not understand a thing until you have taught it badly and survived the questions.

Verse. Psalm 145:4 — "One generation commends your works to another; they tell of your mighty acts."

Teaching. The mechanism in that verse is transmission, and it is worth noticing what is being transmitted: not information about God, but works — what he has actually done, told as something that happened. That is a much stronger form of teaching than instruction, and it is available to anybody regardless of expertise, because everybody has a record of what happened to them. So when you teach back, teach from what you did rather than from what you read. I had three hundred and forty items in my inbox in September and I now have eleven, and here is exactly what I changed is a lesson somebody can use. The four containers of PARA are Projects, Areas, Resources and Archives is the same lesson with all the evidence removed. The second one is what people say when they have learned a vocabulary; the first is what they say when they have learned a practice. Notice which one you produced, and if it was the second, that is not a failure. It is your syllabus for next year.

Week 52 · Flow: tear it down, keep four things, and write the next year

Build task. Four things. Keep four components of your system and name them explicitly. Release everything else, in writing, with a sentence each on why. Write the next fifty-two weeks — a page of fourteen or so lines — using what this year taught you about which blocks were right, which were the wrong size, and which were wrong for you entirely. Date it. Then eat together, and do not talk about systems.

Drill — "Four, Dated." Ten minutes, timer running. Write the four things and date the page. The number four is not symbolic. It is a limit that forces the ranking, and the ranking is the only part of this exercise that will survive February.

Concept. A plan without an expiry date becomes a policy, and a policy is a plan nobody is allowed to revise.

Verse. Psalm 127:1 — "Unless the LORD builds the house, the builders labor in vain. Unless the LORD watches over the city, the guards stand watch in vain."

Teaching. This is the right verse to end on, and it is worth reading both halves. The first says that effort without God is futile. The second says that vigilance without God is futile, which is the harder one, because vigilance is what this entire document has been training. Fifty-two weeks of capture, review, limits, and audits — and the psalm says the guards stand watch in vain. That is not an argument against guarding. The psalm goes on to describe sleep as a gift, and the whole point is that a person who has built and watched faithfully is allowed to stop, because the outcome was never theirs to secure. That is the actual lesson of the year, and it is the one that evaporates if it is not written down. So: keep four things, release the rest, write the next year, date it, and then sleep. The system is a servant. It was always a servant. Next January you will open this document again, and roughly a third of it will be wrong for you, and that is the design working exactly as intended.

Appendix A — Words we use, and what they mean

Nothing in this document assumes prior training. If you are leading and you use a word the group does not know, define it before you use it the second time. Here is the vocabulary, spelled out, grouped by where it came from.

From PARA and Building a Second Brain

• PARA — Four containers that hold everything: Projects, Areas, Resources, Archives. The claim is that these four categories are sufficient for all information in a life, and that any fifth category you invent will be a synonym for one of them.
• Project — A short-term effort with a goal and an end date, or at least an end condition. Move the workshop. File the estate paperwork. Finish the certification. The test is one question: does it end?
• Area — An ongoing standard of performance or responsibility that has no end. Health. Finances. The house. My marriage. My direct reports. An area cannot be completed; it can only be maintained or neglected.
• Resource — Material on a topic you are interested in, with no obligation attached. Resources are where things go when you cannot justify keeping them in Projects or Areas and cannot bring yourself to archive them. This makes Resources the most likely home of the collector's fallacy, and it should be audited more often than anything else.
• Archive — Anything from the other three that is no longer active. Nothing is destroyed; things graduate. An archive with a retrieval record is an asset; an archive without one is a graveyard.
• CODE — Capture, Organize, Distill, Express. Forte's four-verb summary of the whole workflow, and the reason this curriculum is ordered the way it is: the four verbs are the four movements of the year, roughly.
• Progressive summarization — Compressing a note in layers, each layer performed when the note is used rather than when it arrives. Layers: raw capture, bolded passages, highlighted sentences, an executive summary in your own words, and a remix into something new.
• Layer 1 through layer 5 — The five stages above. The discipline is that you do not do all five on arrival, because compression without a consumer is guessing.
• Intermediate packet — A self-contained piece of work that can be assembled into a larger deliverable without being rewritten. A section, a diagram, a checklist, a finished argument. Packets are how work gets done incrementally.
• Twelve favourite problems — A written list of the questions you are actually trying to answer, small enough to hold in mind, used as the filter for what enters and what gets distilled.
• Second brain — An external, personal, trusted store of knowledge and commitments, on the argument that biological memory is for having ideas rather than holding them. The term is Forte's; the idea is much older.
• Map of content (MOC) — A note whose only job is to point at other notes. The smallest useful form is a list of links with a one-line reason for each.

From Getting Things Done

• Open loop — Anything that has your attention and has not been decided about or captured in a trusted place. An open loop is not a task; it is a question you have not answered, and it will keep asking.
• Capture — Getting something out of your head and into a trusted container, with no processing at the point of capture. The separation of capture from processing is the single most important mechanical idea in GTD.
• Clarify (or process) — Deciding, for each captured item, what it is and what, if anything, is to be done about it. This is the step everyone skips and the step where all the value is.
• Next action — The next physical, visible activity that moves something forward. Written as a verb your hands can perform. "Handle the insurance" is not a next action; "find the policy number and write it on the form" is.
• Waiting-for list — Items delegated or promised to somebody else, each with a person's name and a date. Without both, it is not a waiting-for list, it is a hope.
• Someday/maybe — Things you are not committing to and are not refusing. The list has one purpose: to let you say no today without pretending the idea never occurred to you.
• Two-minute rule — If an actionable item takes less than two minutes, do it now rather than tracking it, because the overhead of tracking exceeds the work.
• Four criteria — The four filters for choosing what to do in a given moment: context, time available, energy available, priority. All four, in that order, and the failure mode is using only priority.
• Context — The conditions required to do a task: a place, a tool, a person, a connection. Context lists exist because a list of things you cannot currently do is not a plan.
• Weekly review — A fixed weekly point at which the whole system is brought current: inboxes emptied, lists checked, projects verified, calendar reviewed forward and back.
• Horizons of focus — Six levels of altitude from the runway (current actions) to purpose and principles. Allen's argument is that a mismatch between levels produces either paralysis or frantic activity.
• Trigger list — A list of prompts used during a mind sweep to surface items you have stopped noticing. Its purpose is coverage rather than insight.
• Mind like water — The state a system is meant to produce: complete appropriate response to input, no overreaction, no underreaction. Martial, not mystical.

From lean, 5S, and the shop floor

• 5S — Five disciplines of workplace organization: seiri (sort), seiton (set in order), seiso (shine), seiketsu (standardize), shitsuke (sustain). Applied to knowledge work, the five steps are: remove what does not belong, give everything a place, keep it clean, write the standard down, hold the standard.
• Red tag — A physical marker placed on an item you cannot decide about, with a date and a disposition rule. The red tag exists because people will not sort honestly if sorting means destroying, and because a decision deferred with a date is a different object from a decision avoided.
• Standard work — A written, repeatable description of the best known way to do a task, which is then improved deliberately rather than drifting. A checklist is standard work; so is a template; so is the fixed shape of a session.
• Kaizen — Continuous small improvement, made by the person doing the work, on a schedule, with the change written down. Not a project; a habit.
• Gemba — The actual place where the work happens. The argument for going there is that the process as documented and the process as performed are always different, and only one of them is real.
• Andon — A signal that something is wrong, which anyone is allowed to raise and which stops the line. The rule that protects it is that raising it never gets you punished, and the reason it fails in most organizations is that it does.
• Poka-yoke — Error-proofing: making the wrong action physically difficult or impossible rather than relying on attention. A template with required fields is a poka-yoke. A single door for input is a poka-yoke.
• Muda — Waste. The classic seven: overproduction, waiting, transport, overprocessing, inventory, motion, defects. In knowledge work the dominant wastes are overproduction (documents nobody asked for), inventory (unread piles), and defects (duplicates).
• Kanban — A visual board showing the stages work passes through, with a limit on how much may be in each stage. The board is not the point; the limit is the point.
• WIP (work in progress) limit — A maximum number of items permitted in a stage. The limit is what converts activity into throughput, because it forces finishing.
• Pull system — Work is drawn into the next stage when capacity exists, rather than pushed into it when it is ready. Pull is the mechanism that makes a WIP limit enforceable.
• Cycle time — The elapsed time from work starting to work finishing. Measured, not estimated, and always longer than the person believes.
• Lead time — The elapsed time from a request arriving to being delivered. Always longer than cycle time, and the number that other people actually experience.
• Throughput — How many items are finished per unit of time.
• Little's Law — Average cycle time equals average WIP divided by average throughput. It is exact, it holds for any stable system, and it means that reducing what is in flight shortens delivery time even if nobody works any faster.
• Bottleneck (constraint) — The one stage that limits the whole system's output. Improving anything that is not the bottleneck produces no additional output, which is why effort applied in the wrong place feels like virtue and produces nothing.
• Flow — Work moving through stages without waiting. The measure is the size of the queues, not the speed of the workers.

From the quality tradition

• Defect — A failure of the output to meet the standard. In a personal system the four defects are: unfindable, undated, duplicated, orphaned.
• Root cause — The process condition that makes a defect recur, as distinct from the occasion on which it appeared.
• Five whys — Asking "why" five times about an observed defect until the answer is a process condition rather than an event. The fifth answer is usually a missing rule.
• Fishbone (Ishikawa) diagram — A structured listing of possible causes grouped into categories. Useful mainly because it forces you to look outside your first guess.
• PDCA (Plan–Do–Check–Act) — The improvement cycle: plan a change, try it small, check the result against a measure, and then standardize it or discard it. The "check" step is the one that gets skipped, which is why most systems accumulate untested changes.
• Control chart — A run of measurements with the normal range marked, read for variation rather than for improvement. A stable process wobbles within a range; a trend is a different thing and requires a different response.
• Common cause versus special cause — Variation that is built into the process versus variation caused by a specific event. The distinction matters because the responses are opposites: common cause is fixed by changing the process, special cause by investigating the event. Treating one as the other is the classic management error in both directions.
• Poka-yoke — See above. Repeated here because it is the most useful single idea from this tradition for personal systems.
• Cost of poor quality — The total cost of defects, including the cost of inspection, rework, and lost trust. In personal systems the dominant term is rework: rebuilding the thing you could not find.

From time management and attention research

• Time blocking — Assigning specific activities to specific blocks of time in advance, on the argument that a list does not allocate anything.
• Eisenhower matrix — A sort by urgency and importance into four quadrants. Genuinely useful once, as a sorting exercise, and nearly useless as a daily practice.
• Deep work — Sustained, distraction-free effort on cognitively demanding tasks. The scarcity is not the time; it is the absence of interruption.
• Ultradian rhythm — The roughly ninety-minute cycle of alertness within a day. Used here to justify block lengths rather than as a physiological doctrine.
• Chronotype — A person's natural pattern of sleep and peak alertness. The practical use is to identify your two best hours and defend them.
• Pomodoro — Work in fixed intervals with short breaks. Useful primarily as a measurement device: it tells you how many interruptions a task actually contains.
• Margin (or slack) — Unallocated capacity. The argument for it is that a system with no slack will be consumed entirely by whatever arrives first.
• Parkinson's Law — Work expands to fill the time available. The corollary used here: the deadline determines what is left out, whether or not anyone decides.
• Attention budget — The total discretionary hours available in a week, calculated by subtraction rather than estimation, and allocated explicitly.
• Spaced repetition — Reviewing material at increasing intervals, timed to the point of forgetting. One of the two or three best-evidenced learning techniques in existence.
• Retrieval practice — Recalling something from memory rather than rereading it. The evidence is strong and the practice is unpleasant, which is why it is rare.

Words about the people involved

• Leader — Whoever is running the session. Rotates. Not an expert, not a coach, not in authority over anyone. First names only.
• Build task — The physical change to your own system, made in the session, before you leave the room.
• Drill — The named, timed, repeatable skill practiced in ten minutes.
• Wall chart — The pencil-and-paper chart of one number per week. Not a dashboard; a record.
• Capacity week — The third week of every block, in which the skill is practiced under a realistic and slightly unpleasant load.
• Honest count — A number that includes the embarrassing items. The opposite of a curated metric.
• Re-entry protocol — The written seven-step procedure for coming back after a month of neglect. Kept on a card, in a wallet, for life.

Appendix B — The forty things, in one page

This page exists for the person who has read the whole document once, understood a third of it, and needs to begin on Monday. Read it as a list of claims rather than a list of instructions. Every item is argued somewhere above, and every item has a heading you can find.

On capture

1. Four doors, one room. Any more than four capture points and you have none.
2. Capture and processing are separate acts, done at separate times, and merging them is why people stop capturing.
3. Write it so a stranger could act on it. You are the stranger.
4. An open loop is a decision you have not made, not a task you have not done.
5. The mind is a workbench, not a filing cabinet.

On structure

6. Does it end? If yes, Project. If no, Area.
7. File by commitment, not by topic. A library has no next action.
8. One home per item. Duplicates are the only true defect.
9. Three levels deep, maximum. Depth is not retrieval.
10. The name is the primary key. Everything else is a fallback.
11. Nothing is deleted before it is archived; nothing is archived to avoid deciding.
12. Red-tag what you cannot decide in ten seconds, and date the tag.

On deciding

13. Six answers and no seventh: do, delegate, defer, calendar, file, discard.
14. Under two minutes, do it now. The overhead exceeds the work.
15. If it has a time, it goes on the calendar. If it has a place, it goes on a list.
16. The next action begins with a verb your hands can perform.
17. Context, time, energy, priority. All four, and priority is last for a reason.
18. Be blunt: yes, no, or a specific date. The hedge has a moral character.
19. Count what you discarded. It is the only measure of judgment.

On time

20. Subtract the fixed from the whole before you plan anything.
21. Protect fewer blocks with real force; leave the rest available.
22. Know your two best hours and defend them against your own calendar.
23. Energy is not flat. Schedule the demanding work inside the good hours.
24. Some failures of will are failures of the body. Food and sleep are commands.

On the review

25. The weekly review is the highest-return habit and the first one dropped.
26. Write your own checklist. Twelve items, physical instructions, dated.
27. Have a five-minute floor. A system with no degraded mode is a fair-weather habit.
28. Shrink, never skip. And record the misses, honestly.
29. Stand back far enough, once a year, to see the shape of your life.

On input

30. Guard the door. Count the sources; most people chose fewer than half.
31. The reading pile is a debt, not an asset. Declare bankruptcy and notice that nothing happens.
32. Selectivity is a written criterion, not a virtue. Twelve problems, specific enough to test.
33. Attention cannot be borrowed. Every hour taken from tomorrow is repaid with interest.

On making

34. Compress a note when you use it, not when you save it.
35. Cut the work into packets small enough to finish and self-contained enough to use.
36. Ratio: for every unit in, what went out? Make it visible or it drifts.
37. Fix the date. Negotiate the scope. Never the reverse.

On flow

38. Visualize, limit, pull, measure. The board is not the point; the limit is.
39. Cycle time equals WIP divided by throughput. Reduce what is in flight.
40. There is one constraint at a time. Improving anything else is decoration.

And the four that hold the rest

• Nothing is finished until it is out the door. A thing that is nearly ready is not finished.
• Capacity is created by subtraction or not at all.
• A defect is evidence about your rules, not your character.
• The system is a servant. When it and the person conflict, the person wins — and the point of the review is to know which one you are obeying.

Appendix C — Input discipline: the full case

Block 6 gives the month. This appendix gives the argument, in one place, because it is the part of the curriculum most likely to be dismissed and the part that most determines whether the rest of it produces anything.

The asymmetry nobody accounts for

Input is nearly free. Processing is not. Reading an article costs nothing marginal; deciding what it means, whether it changes anything, where it goes, and whether it was worth the hour costs attention, and that cost is paid later, by a person who did not choose to incur it.

The consequence is a systematic imbalance. Because capture is frictionless and processing is expensive, every system that does not have a gate at the entrance will accumulate a backlog of unprocessed input, and the backlog will grow faster than it can ever be cleared. This is not a discipline problem. It is a queue with an arrival rate above its service rate, and it will behave like one no matter how motivated the operator is.

There are exactly three responses to a queue where arrivals exceed service capacity: increase capacity, reduce arrivals, or accept a growing queue. Most people attempt the first, cannot, and unconsciously choose the third while telling themselves they have chosen the first. Input discipline is the second option, and it is the only one that works.

Four practices that actually reduce arrivals

First: every source must be chosen rather than accepted. An accepted source is one that arrived by default — someone added you to a list, a purchase included a subscription, an algorithm placed it on a screen. Accepted sources account for most of the volume and almost none of the value, and they can be identified in one sitting by asking, of each, did I choose this, and can I say why?

Second: the number of standing sources must be small enough to read in the time available. This is arithmetic, not taste. If a person has forty sources and twenty minutes a day, the de facto policy is that the first three get read and thirty-seven are ignored, which is why the experience of "keeping up" is always accompanied by low-grade dread. Twelve sources read honestly is a better information diet than forty skimmed.

Third: the backlog must be subject to a capacity test. Not is this good? but will I actually consume this within four weeks, given what I know about my own time? Items that fail the test are deleted rather than archived, because archiving a thing you will not read converts a small honest loss into a large dishonest asset.

Fourth: the filter must be positive. "Be more selective" produces anxiety because it has no criterion. The criterion that works is a small set of written questions you are actually working on. Forte's version is twelve favourite problems; the research literature's version is standing questions; a project team's version is a scope statement. All three do the same thing: they allow an incoming item to be classified in about five seconds as relevant or not, without judgment about quality, entertainment value, or general interestingness.

The three objections, answered

"Isn't this just anti-intellectual?" No, and the accusation is worth taking seriously because it is the most common response to this argument. Nothing here says to read less of what you are working on. What it says is that the unselected stream is not scholarship; it is consumption with a scholarly feeling attached. The reading that actually changes a person is concentrated, repeated, and argued with, and none of those three things happen in a feed.

"What about serendipity?" Serendipity is real and it is not random. It is the byproduct of a prepared mind encountering something adjacent to a live question. A person with twelve written problems encounters serendipity constantly, because they can recognize it. A person with no questions encounters volume, which feels similar and is not. The filter does not eliminate serendipity; it is the condition for it.

"I have to stay informed for my job." Sometimes true, and worth testing. Most jobs require deep knowledge of a small area and shallow awareness of a slightly larger one, and almost none require even awareness of the general news cycle. The honest test is the one from week thirty-four: name the last three things you learned from the stream that changed a decision. If you cannot, the stream is entertainment, which is fine, and should be budgeted as entertainment rather than defended as work.

The spiritual argument, stated plainly

Input discipline is the practical form of a theological claim: you become what you attend to. The tradition is unambiguous about this. The psalmist's question is not what a person knows but what a person has set before their eyes. Paul's instruction is to think about a specified list of things rather than about everything. The proverb about guarding the heart is placed above all else, which is a ranking that makes no sense unless the inflow is treated as the primary variable.

The counter-argument — that a mature person should be able to handle anything, that filtering is avoidance — has a surface plausibility and is usually wrong in practice, because it assumes attention is a neutral instrument that the will directs. It is not. Attention is trained by what it is repeatedly pointed at, and the training happens below the level of decision. A person who spends four hours a day in a stream optimized for outrage will become a person who is easily outraged, regardless of what they believe about outrage, and no amount of good intention changes the mechanism.

So the counsel here is not monastic and it is not censorious. It is arithmetic plus a small number of written rules plus one honest number on a wall chart. But underneath the arithmetic is a claim that deserves to be stated without hedging: the shape of your attention is the shape of your life, and it is being shaped right now, by whatever you opened this morning.

Appendix D — Scope, budget, and the arithmetic of attention

Block 11 gives the month, and block 4 gives the week. This appendix gives the arithmetic, because the arithmetic is what makes the argument non-negotiable.

The four constraints

Every piece of work — a report, a renovation, a ministry, a book — is bounded by four variables.

The rule is not that you may choose any three. The rule is that a change to any one changes at least one other, whether or not anyone says so. This is not a management convention; it is conservation. Hours are finite, so a new requirement in October is paid for in November, and it is paid in quality, in sleep, or in someone else's patience. There is no fourth account.

The practical consequence is the only project-management rule most people need: fix the date and negotiate the scope, or fix the scope and negotiate the date, but never pretend both are fixed while quietly spending quality. Silent quality spend is the most common form of professional dishonesty, and it is almost always unintentional, and it is why people who are competent and well-meaning arrive at deadlines with work they are not proud of and cannot explain.

The attention budget, done properly

The arithmetic is simple and almost nobody does it.

Start with 168 hours in a week. Subtract sleep at your actual average, not your intended average. Subtract meals, travel, personal care, and the fixed obligations you cannot move. Subtract the honest overhead of maintaining a household and a body. What remains is your discretionary attention, and it is usually between twenty and thirty-five hours.

Now compare that with what you have committed to. Add up the hours implied by your open projects — the writing, the meetings, the preparation, the administrative tail. If the total exceeds the discretionary number, the situation is not busy; it is insolvent, and insolvency has only three resolutions: reduce the commitments, increase the hours (which is borrowing against health and against other people), or default. Defaulting on a commitment quietly is what most people do, and it is why trustworthy people develop a reputation for unreliability that they cannot account for.

Write the number down. Write it on the same page as the project list. A person who knows their number says yes to fewer things and finishes them, and appears, from outside, to be unusually reliable and unusually calm.

Why slack is not laziness

A budget with no margin is a budget that will be broken by the first unexpected event, and the first unexpected event is always this week.

The mechanism is worth stating because it is counterintuitive. If every hour is allocated, then any interruption must be paid for by displacing something, and the thing displaced is whatever has the weakest immediate claim — which is almost always the work that is important and not urgent: the review, the maintenance, the planning, the difficult conversation. Over a year, a fully-allocated calendar systematically destroys exactly the activities that keep a system alive, and it does so invisibly, one displaced hour at a time.

So the rule is: three empty half-days per week, minimum. Not because you will rest in them. Because they are the only thing that lets you absorb the week as it actually arrives, and because a calendar with no slack does not produce more output; it produces a person who is always behind and cannot say why.

Scope creep, and how to see it coming

Scope creep is not usually somebody adding requirements. It is usually the gradual discovery that the thing is more interesting than expected, and it happens in increments small enough that each one is defensible.

Three defenses, in order of effectiveness.

One: write down what is out. A scope statement that lists only inclusions is a wish. The exclusions are what make the inclusions meaningful, and they are what you point at when the conversation arrives, which is much easier than arguing from memory.

Two: decide the smallest useful version first. Write one sentence describing the minimum that would still be useful to the recipient. Anything beyond that is an improvement rather than a requirement, and improvements can be cut at the end without destroying the deliverable. Projects that fail usually had no minimum defined, so there was no state short of "perfect" that counted as done.

Three: put the change on the record. When a requirement changes, write it down with its cost. Not as a complaint; as arithmetic. Adding this means the date moves by a week, or something else comes out — which? The question is answerable, and asking it is the entire skill.

The personal version of the triage problem

In an emergency department, triage exists because demand exceeds capacity permanently and the only question is who is treated first. Every person with more than a dozen open commitments is running a triage system without having designed it, and the design that emerges by default is whoever asked most recently and most loudly.

The alternative is a written rule. The rule does not need to be sophisticated. Three categories, applied in order: must happen this week or something breaks; should happen and will be scheduled; will not happen and is now explicitly released. The third category is the one that does all the work, and it requires saying the word no to a real person, which is why it is the one people skip.

Note what the third category is not. It is not a "someday" list, which is a deferral dressed as a decision. It is a release, spoken out loud, with a date. The difference in how it feels is the difference between carrying something and putting it down.

Appendix E — The reading list, and the rule about reading lists

The rule: the list is one page, it does not grow during the year, and reading about systems does not count as doing the work. This is rule nine in section 9 and it exists because the literature on personal knowledge management is large enough to consume a life. If you read all six of these books in a year you have read more than almost anyone who talks about this subject. If you read them twice you have read enough.

Start here, and only here, for the first six months.

• David Allen, Getting Things Done. The mechanics of capture, clarify, and review, and the argument that the mind is for having ideas rather than holding them. Read it once for the parts you will actually use: the processing question, the two-minute rule, the four criteria, and the weekly review. You do not need the horizons chapter in year one.
• Tiago Forte, Building a Second Brain. The four containers, the four verbs, and progressive summarization. Read it for PARA and for the distinction between collecting and making. Read it critically; the book is more confident about the benefits than the evidence supports, and the parts about tools age badly.
• Daniel Kahneman, Thinking, Fast and Slow. Not a productivity book at all, and the most useful thing on this list. Read the sections on the planning fallacy and on what intuition is and is not good for. It explains why your estimates are wrong in a specific direction.
• Cal Newport, Deep Work. The argument for sustained attention as a scarce and trainable capacity, and a set of environmental designs that make it possible. Skip the parts that read as professional advice and keep the parts about interruption cost.
• Eliyahu Goldratt, The Goal. A novel about a factory, and the best available explanation of why improving anything other than the constraint produces nothing. Read it for the idea, not the plot.
• W. Edwards Deming, Out of the Crisis. Dense, dated in places, and the source of the single most humane idea in this document: that most defects are process defects and that blaming people for them is both unkind and ineffective. Read the fourteen points and the chapters on variation. Skip the rest until year three.

For year two, if you are still doing this.

• James P. Womack, Daniel Jones, and Daniel Roos, The Machine That Changed the World. Where lean actually came from, and why it was a moral argument before it was a management technique.
• Masaaki Imai, Gemba Kaizen. The 5S material, at source, with the shop-floor detail that the popular summaries strip out.
• David J. Anderson, Kanban. The WIP limit, cycle time, and Little's Law, written for knowledge work rather than for factories.
• Peter Drucker, The Effective Executive. Short, old, and better than almost everything written since. Particularly the chapters on time and on deciding what not to do.
• Scott Berkun, Making Things Happen. Project management without the ceremony, and unusually honest about the politics of scope.

What is deliberately not on this list. No book that is primarily about note-taking applications. No book whose central claim is that a particular method will change your life. No book published to accompany a course that is being sold. No book about morning routines. If you find that you are reading a fourth book about productivity before you have finished a single project with the system you already have, the correct response is not to finish the book.

Appendix F — Where the design comes from

This is a short note on why the shape is what it is, so that a future reader can change it on purpose rather than by accident.

The four-verb spine — capture, organize, distill, express — is Forte's, and the ordering is the reason this curriculum runs a year rather than a weekend. The temptation is to teach the interesting verb first. Expression is the interesting verb. But a person who has not collected cannot sort, and a person who has not distilled has nothing worth expressing, and the whole sequence collapses if you start where the energy is. That is why the year opens with January's thankless collection and does not reach output until week twenty-nine.

The mechanics are Allen's, and the mechanics are not the point. GTD is often dismissed as a list system, which is like dismissing a workshop as a set of tools. Allen's actual contribution is the observation about open loops and the insistence on a fixed weekly point of review. The weekly review is the single highest-leverage hour in this entire document, and it is Allen's, and it is worth saying so plainly because his book repays reading once.

The discipline is Toyota's, and the objection to importing it is worth answering. The standard objection is that a factory is not a mind. This is true and it does not matter, because the parts of lean this document borrows are not about manufacturing. They are about the conditions under which a person does reliable work: a place for everything, a written standard, a visible signal when something is wrong, a limit on work in progress, and small improvements made continuously by the person doing the job. Those are properties of any workspace, physical or otherwise, and the shop floor learned them expensively over seventy years. Borrowing them is not a metaphor; it is a transfer.

The epistemology is Deming's. The claim that most defects are process defects, that variation must be understood before improvement is attempted, and that blaming the individual is the characteristic error of management — all of it is his, and all of it applies to a person managing themselves. The reason it matters so much here is that the characteristic emotional failure of anyone learning a knowledge system is moral: they conclude they are disorganized, undisciplined, not the type. Deming's answer is that they are running a process with a missing rule, and that the fix is a rule. That is a much better diagnosis and it is also a much kinder one.

The project-management layer is deliberately thin. Triple constraint, definition of done, one owner per action, sequence, buffer, honest status reporting. That is roughly a tenth of what a project manager knows and it is more than an ordinary person needs. The rest of project management exists because organizations have many people in them; a person running their own work has one, and most of the ceremony would be theatre.

The spiritual frame is not an addition to any of this. It is the load-bearing wall described in section 5, and the test of whether it is genuine is whether it changes anything practical. It does, in three specific places: it produces a stopping condition, so the system cannot consume the life it serves; it produces the honesty requirement in the wall chart and the re-entry protocol, because a system you are lying to is worse than none; and it produces rest as a command rather than a reward, so falling off for a month is a known state with a written protocol rather than a moral catastrophe. If the frame were decorative, those three things would not be in the document. They are in the document because they are the only reason a system survives past its second year.

What this design deliberately does not claim. It is not evidence-based, in the sense that no controlled trial has been run on this curriculum and the underlying practices come from contexts that differ from yours. It does not make anyone smarter or more creative. It does not substitute for thinking; it removes a class of friction that prevents thinking. It does not produce career outcomes, and anyone who tells you that capturing notes will advance your standing is selling something. It does not reduce anxiety in any clinical sense. It does not improve with a better tool, and it does not fail because of a worse one.

What it does is claim that a person who can capture reliably, find things quickly, decide about them clearly, finish them honestly, and say out loud how much is in flight — is free, in a small and specific way, to do the thing they are actually for. That is the whole offer. It is small, it is checkable, and it takes a year.

Appendix G — The fifty-two drills, and what each one needs

Every drill in this document is named so that it can be said out loud, taught to somebody else, and recognized when it is being done badly. This table exists so that a leader can run a session without re-reading the week, and so that a person can find a drill they half-remember.

Almost every drill needs the same four things: a timer, something to write on, something to write with, and your own real material. The fourth is not optional and is the most common failure. A drill performed on a downloaded example teaches nothing, because the whole point is that your material is messier than an example.

The three drills worth repeating out of season, when a week has gone wrong. The Ten-Minute Version (week 18) because it is the floor of the whole system. The Untested Protocol (week 47) because it is the recovery. Where the Pile Is (week 40) because it finds the constraint, and the constraint is where all the leverage is.

A note on the timer. The timer is not there to make the drill fast. It is there to prevent the drill from becoming research. Every one of these exercises can expand to fill an afternoon, and the expansion is always the same move: instead of deciding, you begin investigating. Ten minutes is long enough to decide about more items than most people believe, and short enough that investigating is impossible. If you finish early, stop. Do not continue.

Appendix H — Running this as a group

This document is written for one person, and it works better with three to eight. The reasons are the same reasons a weekly study group beats a stack of books, and they are worth stating so that the group form can be defended when it becomes inconvenient.

Accountability is not the main benefit. The main benefit is normalization. A person alone with a backlog of three hundred and forty items concludes something about their character. Three people with the same backlog conclude something about backlog. That reframing is worth more than any amount of encouragement, and it cannot be produced by a book.

A group also produces the honest numbers. People curate for themselves and not for a room. A number that has to be said out loud in front of six people is a different number from a number that is written in a private app, and the difference is the entire value of the wall chart.

The four rules for a group

Rule one: rotate the leader. Any regular participant can lead, using this document, and a person who has led twice should be teaching somebody else to lead. Rotation prevents the group from becoming one person's project, prevents burnout, and produces the only real test of whether anyone learned anything, which is whether they can run it.

Rule two: every session is complete. No session assumes the previous one happened. A person who attends only week thirty-four leaves with a working board, one number, one idea, one verse, and one commitment. The teaching says the prior context out loud in its first two sentences, which is why it is written down rather than summarized.

Rule three: nobody's screen is shown without specific spoken permission. The specific words matter. Can I show this? is not the rule; may I show this one screen to this room right now? is the rule. Inboxes contain other people's names, diagnoses, salaries, and confessions, and a shared screen is a publication. Say this before the first session and again whenever somebody new arrives.

Rule four: the room does not become a support group. This is the hardest one, and it matters because these sessions touch real distress. People will discover during a mind sweep that they have been carrying something serious, and they will want to talk about it. Let them talk, briefly, in the circle, and then get back to the drill. The document is not therapy and the leader is not a counselor. If a person discloses something that needs care, the leader's job is to say that is more important than this and here is who can help — privately, afterward — and then to keep the meeting's shape.

The ninety-minute version

Seventy-five minutes is the base. With more than six people, add fifteen minutes and split them as follows: three minutes to the arrival and dump, seven minutes to the circle, and five minutes to the build, because the leader's circulation time is what scales with headcount and it is the part that cannot be compressed.

What the leader actually does

Before. Read the week's entry once, out loud if possible, and decide which single sentence of the teaching is the one that must land. Not the whole teaching — one sentence. A leader who tries to deliver all of it will deliver none of it.

During the drill. Demonstrate twice, slowly, on your own material rather than an example, and let them see the mess. Then set the timer and be quiet. The most common leadership error in this curriculum is talking during the drill, which converts a practice into a lecture and destroys the ten minutes.

During the build. Circulate, answer one question at a time, and never correct in public. If two people have the same problem, that is a teaching moment for the whole room and should be named as such without naming the person.

At the measure. Write the number without commentary. If a number is bad, say nothing. The chart does the talking over twelve weeks, and a leader who reacts to each reading trains people to curate.

At the verse. Read it twice. Then be silent for two full minutes, which will feel like six. Then invite one sentence each. Do not summarize what people said, do not synthesize, and do not resolve it. The verse is the teacher and the leader's job is to keep the room quiet long enough for it to be heard.

At the close. Every person states a commitment with a time attached. Write nothing down. The act of saying it aloud is the mechanism, and a leader who becomes the record-keeper removes the mechanism.

When the group should not meet

There are three conditions worth writing down in advance, in the same spirit as the weather calls in section 10.

• When the room has become a performance. If people are bringing curated systems rather than real ones, stop the build for a week and run week forty-seven on everyone's messiest area, including the leader's. Nothing restores honesty faster than the leader showing their worst folder.
• When attendance halves twice in a row. That is not a scheduling problem; it is a signal that the content has drifted from what people actually do. Ask, in the circle, what the last four weeks were for, and rewrite the next four based on the answer.
• When the leader is the only one who has read anything. This means the rotation is not working. The fix is not more preparation; it is assigning next month's blocks to four different people and letting them teach badly.

Appendix I — Troubleshooting: the hard cases

The following are the situations that come up in every group, in the order they usually arrive. Each answer assumes the rest of the document, so read the referenced section if the answer seems abrupt.

"I have four hundred items in my inbox and I want to quit." Do not process it. Do a mind sweep (week two) and then a triage (week forty-seven). Processing four hundred items one at a time is how people lose three weekends and their enthusiasm in the same month. Triage means: sort into must, should, and release, in one sitting, with a timer, and accept that the release pile will be large. The backlog was never the problem. The absence of a gate was the problem.

"My employer requires one set of tools and I have another for myself." This is the most common structural problem in the whole document and it has a clean answer: the boundary is a container, not a category. Your work system is an Area. Everything the employer mandates stays inside that Area's container and follows its rules, and you do not fight it. What you own is the seam: one note per project that says what the project is, what the next action is, and where the real material lives. That seam is three sentences and it is the only thing you need to maintain across the boundary.

"I don't have a team, so delegation, waiting-for, and status reports don't apply." Half true. Waiting-for still applies, because you are always waiting on somebody — a reply, a shipment, an approval, a spouse. Most people's stalled items are waiting on another person and are not tracked as such, which is why they sit in a task list looking like failures. Status reports apply too, with the recipient being future-you at the review, and the honest version is still the same five lines.

"I have a diagnosable attention problem." Nothing here is treatment and this document is not qualified to give it. What can be said without qualification: every technique in this document that reduces the number of decisions in front of you is likely to help, and every technique that relies on sustained unaided concentration is likely to need adaptation. The specific adaptations worth trying are the five-minute floor in week nineteen, the phone-only vault in week thirty-five, and the visible board in week thirty-seven — because externalized state does not require working memory. If you are not being treated, that is a different conversation and a more important one.

"I'm a student, or retired, or between jobs. The project/area distinction doesn't map." It maps; you are just calling the areas something else. Being a student is an area. Finish the thesis chapter is a project. Retired is not an area at all — it is a fact, and the areas are what you are now responsible for maintaining, which for most people gets clearer rather than vaguer. Between jobs is genuinely different in one way: your Areas have shrunk, and the temptation is to fill the space with input. Resist it with block six, because a job search is a project with an end and a defined next action, and the reading you are doing instead is not one.

"I did the whole system and then abandoned it for four months. Do I start over?" No. Run the re-entry protocol (week forty-seven). Nothing is lost, the archive is intact, and the only thing that has changed is that you now have evidence about which parts of the system did not survive contact with your real year. That evidence is the most valuable thing you own, and restarting throws it away.

"My problem isn't capture, it's that I never do the things." Then capture was never your bottleneck and neither is your system. Run week forty — find the column with the oldest cards. If the pile is in doing, the constraint is time and the answer is block eleven's scope conversation. If the pile is in to do and the board does not move, the constraint is the absence of a fixed decision point, which is block five. Note what is not on that list: motivation. Motivation is a symptom of an unclear next action far more often than it is a cause.

"I keep reorganizing instead of working." That is the characteristic failure of this curriculum and it is worth naming precisely: reorganization produces the sensation of progress with none of the exposure. The intervention is a rule with a date. Pick one project, define done in one checkable sentence, and forbid yourself any structural change until it ships. If you break the rule, write down what you changed and why, and put that page in the front of the system where you will see it next time. Week forty-four is the week for this, and most people need it twice.

"How do I know when to stop?" Three stopping conditions, and any one of them is sufficient. The system costs less than it returns — you can feel this and you should trust it. The review is happening and the output is not — that is the collector's fallacy in its mature form and block eight is the answer. The work has displaced something it was meant to serve — this is the condition that section five exists for, and when it happens, the correct response is not to optimize. It is to stop, keep four things (week fifty-two), and go and do the thing the system was for.

Soli Deo gloria.

Agent Harnesses — A 52-Week arXiv Curriculum for a Drop-In Reading Group of Agent Builders

Free. Peer-led. No ranks. No branding.

A year of reading the primary literature of harness engineering — the scaffolding around a model that makes it an agent — then living and revising the plan as you go. Plans are always imperfect, but the whole point of planning is not the document; it is the implementing, refactoring, and revising. The POINT of a plan is a starting roadmap that gets overhauled the moment the real building starts, because new OPPORTUNITIES (and new preprints, daily) will arise.

The MOST IMPORTANT part of this plan is gratitude discipline: there are more good papers than any person can read, and the field is young enough that a careful reader with a year can stand at its frontier. That is abundance. Skimming is a trained skill here, not a failure state.

1. What this document is, and what it is not

Is: a full year of weekly, 75-minute sessions for a small group (or one reader with a notebook) studying how agentic systems — Hermes, Pi.DEV, OpenClaw-style harnesses, and their kin — are actually engineered. Every week is a named technique with a real preprint behind it: Chain-of-Thought, ReAct, Reflexion, retrieval, memory, multi-agent rosters, protocols, evals, sandboxes. It is written so a person who has never read a paper and has never built an agent can arrive on any week and be genuinely included rather than politely tolerated.

Is not: a credential program. No prerequisites, no problem sets, no grades, no graduation. Nothing here makes one participant more important than another; the newcomer equals the veteran.

Is not: a course on model training. We read harness papers, not pretraining papers: the model is treated as a fixed organ, and the curriculum studies the body built around it. Fine-tuning appears only where it ships into a harness (skill distillation, tool-use tuning).

Every week has five parts: a craft work assignment (reading, sometimes sketching a design), a hinge practice (a short named attention exercise), one concept, one quote, and about four sentences of teaching written out so nobody has to improvise a lesson they do not feel ready to give.

The material assumes the leader is not a professor and the participants are not students. It assumes a room of working engineers and curious builders, some of whom ship agents to production and are quietly worried about them. Everything below is written so those people stay for the hour and come back next week.

2. How to read a week's entry

Every week is laid out the same way:

• Craft work. The reading assignment, labeled teach, repetition, capacity, or flow (section 5).
• Hinge practice. A named, 8–10 minute attention exercise — a class inside the class.
• Concept. One idea, one sentence, carrying the week's technique.
• Quote. One short passage — usually from a landmark harness paper — quoted where short enough.
• Teaching. Three to five sentences: what the technique means, why it matters to a builder who is tired or new, and how it connects to what the group just read.

Reading the teaching in your own words is fine. Skipping it is not: the sentences are the actual lesson, and the reading is the illustration.

3. The whole builder: four things we are actually training

A reading habit that only trains comprehension produces a person who can parse a paper and still cannot judge a harness. Each session touches four dimensions:

The craft dimension is the obvious one: reading a method, spotting its moving parts, sketching the data flow — prompt in, tool call out, result back. Trainable in an hour, measurable in a season.

The mental dimension is being able to state the mechanism. "The agent reflects on the failed trajectory and appends the lesson to the next prompt" is a sentence that separates a builder from a spectator. This is why the concept sentence exists.

The emotional dimension is what happens at the edge of competence: dense notation, being the least informed person in the circle, saying something wrong out loud. Real stress inside guaranteed safety, where nobody is allowed to mock anybody. We never promise healing; we provide conditions and let time work.

The humility dimension is attention to how little anyone knows, including authors. One quote, read twice, sat with in silence. The harness field in particular needs this: our systems are autonomous, ambiguous, and young.

The hinge practice is the joint where all four meet: craft (the hand slows the eye), mental (one forced sentence), emotional (a long exhale after hard effort), humility (attention without performance).

4. The fixed shape of every session

The session is the same every week. A person who drops in twice a year should recognize the shape instantly; an anxious person should not learn a new format on top of new notation.

Seventy-five minutes. In a brutal week, shorten the main work, never the quote circle.

5. The four-week rhythm inside every block

Thirteen blocks of four weeks. Each block has one engineering theme; inside each block:

• Week one — Teach. One landmark paper, read slowly. Everyone leaves able to name the technique and state its mechanism. If people are exhausted, too much was covered; if people cannot state the mechanism, too little.
• Week two — Repetition. Volume: the same kind of paper, five to ten of them, abstract-and-figures passes, including fresh arXiv listings. Correction offered quietly, never publicly.
• Week three — Capacity. One hard paper end to end before the session ends. Confusion breaks the set, not time. No all-nighters.
• Week four — Flow. Explain one technique from the block in three minutes; longer quote circle; the bring-a-friend week.

6. Why the hinge practice sits where it does

The hinge comes after the reading and before the quote circle. After dense technical text, attention is narrowed and defensive; a quote in that state lands on a mind that cannot receive it. Eight minutes of slow, hand-written attention widens the field.

This is also where the curriculum trains what harness engineering itself trains badly: calm, honest attention to one thing at a time. Most agent-building produces a person who scans preprints for tricks, hoards links, and retains nothing. What we want instead is a reader who can hold one mechanism in mind without needing an opinion about the whole field. Each hinge practice has three jobs, named aloud when introduced:

1. Down-regulate. Hand on paper, pen moving, no screen.
2. Widen. One sentence on where this technique sits in the wider harness.
3. Attend. The mechanism's one true sentence, or the honest admission that it has none yet.

Standing practices, used across the year: "One Figure" (slow eyes on a single diagram, then one written sentence), "Marginalia" (three words per section: claim, mechanism, doubt), "The Copy" (copy the key equation or pseudocode by hand, name every symbol), "The Long Exhale" (write the technique's claim, cross out every word that does not survive "how do they know?"), "The Trace" (sketch the data flow — what enters the model, what comes back — as a box diagram, badly, by hand).

Block 1 · Weeks 1–4 · The Prompt and the Context

Week 1 · Anatomy of a Harness Paper

Craft work — teach week. Any recent cs.AI agent paper, chosen by the leader. Five passes: title/authors, abstract, every figure, intro/conclusion, then the method — stopping at the first equation that hurts. The goal is the shape of a harness paper: motivation, method diagram, tasks, numbers, failures. Hinge practice — "One Figure." The paper's architecture figure. Eight minutes, pen in hand, one written sentence: what enters, what comes out. Concept. The abstract is a promise; the figures are the method. Quote. Alan Turing, 1950: "We can only see a short distance ahead, but we can see that there needs much to be done." Teaching. A harness paper is not an essay; it is a machine description with load-bearing walls, and the figures are where the walls are. Reading in passes means you never face the hard parts until you know what they are for. A year from now you will read these cold in ten minutes; today, learn the shape on something gentle. You are not behind; you are on week one of a field nobody was taught in school.

Week 2 · Few-Shot Exemplar Selection

Craft work — repetition week. Ten papers on prompting and exemplar choice, abstract and figures only. One line each: technique, mechanism, yes/no. Skimming is a trained skill; this week trains it on the field's shortest papers. Hinge practice — "Marginalia." On the best of the ten, write three words per section: claim, mechanism, doubt. Concept. The prompt is a program whose examples are its standard library. Quote. GPT-3's title as a sentence: "Language Models are Few-Shot Learners." Teaching. Before agents had tools, they had examples: the few-shot prompt was the first harness, and its design — which examples, in what order, in what format — is still the highest-leverage knob in the field. Notice that choosing exemplars is curation, and curation is where a builder's judgment enters a system that is otherwise bought by the token. The yes/no line you wrote is a promise to your future self. Volume this week is the gratitude practice: ten papers, one of which you will keep.

Week 3 · Chain-of-Thought Prompting

Craft work — capacity week. Wei et al., Chain-of-Thought Prompting (2201.11903), read end to end before the session ends — the examples are the method, so read the example boxes hardest. Confusion breaks the set, not time. Hinge practice — "The Copy." Copy the prompt template by hand, including the "let's think step by step" trigger. Say what each part does. Concept. Show the work, and the model learns to show the work. Quote. From the paper: prompting with intermediate reasoning steps yields large gains on reasoning tasks, in large models. * Teaching. The trick is almost comic — ask the model to show its steps like a schoolteacher — and it unlocked multi-step behavior years before "reasoning models" existed. Combined with week 2, notice what a harness is: a fixed model, plus scaffolding, producing new competence. Every one of the next 49 topics is a variation on that sentence. This is the most-cited harness idea in the field; you have now read it in the original.

Week 4 · Self-Consistency and Sampling

Craft work — flow week. Each person explains one technique from this block in three minutes. Longer quote circle; bring-a-friend week. Hinge practice — "The Trace." Sketch chain-of-thought with self-consistency as a box diagram: sample N, vote, answer. Badly, by hand. Concept. Averaging many attempts is a poor man's certainty. Quote. Wang et al., Self-Consistency (2203.11171): sample multiple reasoning paths and take a majority vote over answers. * Teaching. Self-consistency closes the block with the field's oldest statistical move dressed in new clothes: if reasoning is sampling, reliability is an ensemble average, which is both profound and slightly deflating. The box you drew is a production pattern — you will meet it again inside verification and debate. Say the three-minute version to someone outside the group this week; that is the flow week's real exercise.

Block 2 · Weeks 5–8 · The Tool Loop

Week 5 · Tool Calling and Function Calling

Craft work — teach week. Gorilla (2305.15334) or a current function-calling paper. Abstract and figures. Claim: a model can select and parameterize real API calls — tools turn a text engine into an acting system. Hinge practice — "One Figure." The API-calling figure. Eight minutes. Write one sentence: where does the schema enter the prompt, and what comes back? Concept. A tool schema is the agent's API to reality. Quote. From Gorilla's lineage: large language models connected to massive APIs. * Teaching. This week the curriculum turns from prompting to acting: the tool loop — build prompt with schemas, parse call, execute, append result — is the load-bearing loop of every harness you have heard of, including mine. The figure you sat with is the contract between a model and the world. Everything after this block is the same loop wearing more clothes: more tools, longer histories, more agents.

Week 6 · ReAct: Reasoning Interleaved with Action

Craft work — repetition week. ReAct (2210.03629) plus four current agent papers. Abstract and figures; one line each: who writes the plan, and who checks the result? In ReAct the example traces are the paper — read them. Hinge practice — "Marginalia." Claim, mechanism, doubt; ReAct's traces show failure loops, which is the honest part. Concept. Thought without observation hallucinates; observation without thought wanders. Quote. From ReAct: synergizing reasoning and acting in language models. * Teaching. ReAct is the minimal complete agent: think, act, observe, repeat, and its honesty is its quality — the published traces include confusions and loops, because acting is where models meet a world that is not a benchmark. Reading five papers through the same question — who plans, who checks — you can already see the field's design space in a table. The trace-reading skill this week is the whole year in miniature.

Week 7 · Self-Taught Tool Use

Craft work — capacity week. Toolformer (2302.04761) or ToolLLM (2307.16789), end to end before the session ends: how does a model learn which tool to call, and where does the training data come from? Hinge practice — "The Copy." Copy the self-instruct loop as pseudocode by hand: propose call, execute, filter by usefulness, fine-tune. Say what the filter is for. Concept. The harness can bootstrap its own tool-use curriculum. Quote. From Toolformer's lineage: models can teach themselves when and how to call APIs. * Teaching. The self-instruct loop you copied is the field's reflexive trick: use the model to generate its own training data, keep what works, feed it back. Notice the filter — a usefulness score — is the entire value system of the bootstrap, and where a builder's judgment hides. You have now read the lineage behind every "our model learned tool use" announcement. Next week the loop gets its grammar.

Week 8 · Structured Outputs and Constrained Decoding

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Sketch the full tool loop including schema-constrained decoding: model, parser, tool, result, history. One page, by hand. Concept. An agent that cannot emit JSON reliably is a demo, not a system. Quote. Group's choice from the block's papers — the best sentence about reliability. Teaching. The unglamorous truth of harness work: most of the engineering is forcing a probability distribution into a grammar the rest of the system can parse. Constrained decoding is that force, made mathematical. With the trace you drew, you now hold the complete skeleton of a production agent — loop, tools, grammar — and the remaining forty-four weeks attach organs to it: memory, verification, peers, permission.

Block 3 · Weeks 9–12 · The Context Window as a Budget

Week 9 · Retrieval-Augmented Generation

Craft work — teach week. Lewis et al., RAG (2005.11401). Abstract and figures. Claim: fetch documents at question time and put them in the prompt; knowledge moves from weights to an index. Hinge practice — "One Figure." The retrieval-then-generation figure. Eight minutes; write where the vector store sits. Concept. Memory moved out of the weights. Quote. Fred Brooks, adapted: "Show me your flowcharts and conceal your data structures, and I shall continue to be mystified." Teaching. RAG is the highest-deployment harness pattern in industry, and its idea is humble: when the model might not know, look it up and hand it over. Brooks's advice flips perfectly for agents — show me your retrieval and I understand your system even if the model mystifies me. Everything you will ever hear about "grounding," "citations," and "knowledge" in agent products is this figure wearing product language.

Week 10 · Long Context vs. Retrieval

Craft work — repetition week. Lost in the Middle (2307.03172) plus four long-context papers. One line each: where in the context does performance die? Hinge practice — "Marginalia." Claim, mechanism, doubt; long-context papers' claims deserve a large doubt column. Concept. Fits-in-context is not the same as attends-in-context. Quote. From Lost in the Middle: models use information best at the beginning and end of long prompts. * Teaching. The U-shaped performance curve in this paper quietly embarrassed an entire marketing cycle: a million-token window does not mean a million tokens of attention. Reading five papers this week, you can already see the industry's honest core: position, not just presence, determines what a model uses. This is why harness engineers, not model vendors, decide where things go in the prompt. That is your job description; the doubt column is your toolkit.

Week 11 · Context Compression and Trajectory Summarization

Craft work — capacity week. One hard current paper on context compaction, summarization of tool histories, or selective memory — these read the densest of the year so far. Full pass before the session ends. Hinge practice — "The Copy." Copy the compaction trigger and summarization prompt as pseudocode. Say what information dies in the summary — because something always does. Concept. Summarization is deciding which history to kill. Quote. A field proverb, unattributed: fast, long, accurate — pick two. Teaching. Long-horizon agents fail first at the context wall, and compaction is the field's answer: summarize the past to buy room for the future. The hinge copy makes the cost visible — every compaction is a deliberate loss, exactly like the quantization literature's rounding, and somebody has to own that choice. You have now met the harness's first hard tradeoff. The remaining weeks of the block are about paying it more cheaply.

Week 12 · Prompt Caching and Context Economics

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw the context as a budget: system prompt, tools, history, task. Mark what is cacheable (stable prefix) and what is not. Concept. The prompt is a program with a memory hierarchy. Quote. Group's choice from the block. Teaching. The block closes on money: caching the stable prefix is the economics behind every long-system-prompt harness — mine included — and it is why harness architecture is now a financial design problem, not just a cognitive one. You can now read a system prompt and see its cache boundaries. The next block asks what happens to everything the context cannot hold: the agent starts keeping a diary.

Block 4 · Weeks 13–16 · Memory Beyond the Context

Week 13 · Agent Memory Architectures

Craft work — teach week. MemGPT (2310.08560). Abstract and figures. Claim: give the LLM an operating-system-style hierarchy — a small fast context, a large slow store, and self-managed paging between them. Hinge practice — "One Figure." The main-context / external-context paging figure. Eight minutes; write who issues the paging calls. Concept. The context window is RAM; everything else is disk. Quote. From MemGPT's lineage: LLMs can manage their own memory like an operating system. * Teaching. MemGPT's move is the best metaphor in the harness literature: stop asking for bigger windows and start paging, with the model itself as the pager. Everything I remember between your sessions — memory files, skills, session logs — is a descendant of this pattern. Notice the design question hiding inside: who decides what gets evicted, and that is a values question dressed as an engineering one.

Week 14 · Episodic, Semantic, and Procedural Memory

Craft work — repetition week. Five papers on agent memory taxonomies and implementations — the field borrowed psychology's categories: episodes, facts, and skills. One line each: what is stored, and what triggers recall? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. A memory system is an index plus a policy for when to consult it. Quote. From the memory-architecture lineage: separating what happened from what was learned improves long-horizon agents. * Teaching. This week the papers disagree about words and agree about substance: stores of experience, distilled facts, and reusable procedures want different formats, different retrieval triggers, and different lifetimes. Reading volume with one question — what's stored, when recalled — turns five fuzzy papers into one design table. That table is something you could build; a year of this curriculum aims to make that sentence true.

Week 15 · Skill and Procedure Libraries

Craft work — capacity week. Voyager (2305.16291), end to end before the session ends: an agent that writes reusable code skills into a growing library and retrieves them by embedding. Every part of that sentence is a mechanism — find them. Hinge practice — "The Copy." Copy the skill-creation loop as pseudocode: attempt, verify, write skill, index, reuse. Say what the verification step protects against. Concept. Skills are memory that compiles. Quote. From Voyager: an agent with a growing skill library for lifelong learning. * Teaching. Voyager's library is the answer to a question you have met twice already: how does an agent get better without retraining? — it writes its improvements down as executable procedures and looks them up next time. My own skill system is this pattern with better manners: learned procedures saved as documents, loaded on relevance. The verification step you copied is the difference between a library and a junk drawer; harness design is largely deciding what earns a place.

Week 16 · Memory Consolidation and Reflection

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw the full memory flow of an agent across a week: sessions, compaction, consolidation, retrieval. By hand, one page. Concept. A harness is a digestive system: experience in, procedures out. Quote. Group's choice from the block; consider the best sentence about forgetting. Teaching. The block closes with the agent's second brain fully drawn: page, store, distill, retrieve — and the drawing you made is the blueprint half the industry's "memory" products are rebuilt from each quarter. Notice what the block never resolved: consolidation means throwing things away, and no paper you read tells you what to forget. The next block turns that honesty into a method — the agent learns to check itself.

Block 5 · Weeks 17–20 · Self-Correction

Week 17 · Self-Refine

Craft work — teach week. Self-Refine (2303.17651). Abstract and figures. Claim: the same model drafts, critiques its own output, and revises — no external tools, just a loop with a feedback prompt. Hinge practice — "One Figure." The draft-feedback-revise loop figure. Eight minutes; write who sees what: does the critic see the prompt? Concept. Feedback is a prompt, not a person. Quote. From Self-Refine: iterative refinement with self-feedback improves outputs across tasks. * Teaching. The minimal self-correcting agent is three prompt roles and a loop, and the paper's honesty is in its limits: self-critique helps where the model can recognize flaws it could not avoid producing. That asymmetry — recognizing better than generating — is the crack every verifier in this block lives in. Hold the humility: a model grading itself is still one model. The next three weeks try to fix that with distance, memory, and other judges.

Week 18 · Reflexion: Learning from Failure

Craft work — repetition week. Reflexion (2303.11366) plus four reflection/critique papers. One line each: where does the lesson get written, and when does it get read? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. A failure explained is a failure converted. Quote. From Reflexion: agents improve by verbal feedback stored in memory rather than weight updates. * Teaching. Reflexion adds the block-4 lesson to week 17's loop: the critique is not spoken into the void but saved and re-injected on the next attempt, so the agent's failures become persistent text it reads before trying again. Notice this is lifelong learning without a gradient — memory as the training signal. Your margin question — written where, read when — is the entire design space in six words. My own error-logs are this pattern; the paper you are reading is my species memory.

Week 19 · Verification and Process Supervision

Craft work — capacity week. Let's Verify Step by Step (2305.20050), end to end before the session ends: supervise each step of reasoning and the model's final answers improve; process beats outcome. Hinge practice — "The Copy." Copy the process-reward setup as pseudocode: step, label, continue-or-stop. Say what "verify each step" costs, and when it is worth paying. Concept. Grade the steps, not just the answer. Quote. From the paper: process supervision produces substantially better reasoning than outcome supervision. * Teaching. The strongest self-correction result in the literature, and the most expensive: a checker at every step buys correctness at the price of an entire second inference stream — but it is the pattern behind every "verify the plan before you execute" harness on the market. The cost accounting in your hinge copy is real engineering: verification is a budget line. You now know when to spend it, which puts you ahead of most harness papers, which do not say.

Week 20 · LLM-as-Judge

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw the three correction loops of the block — self-refine, reflexion, process verify — as one diagram. Note what each one's judge can see. Concept. Every verifier is a model with a vantage point; choose the vantage first. Quote. From the LLM-as-judge lineage (e.g., MT-Bench, 2306.05685): strong models can evaluate outputs comparably to humans. * Teaching. The block's diagram answers its own question: self-correction is not one technique but a family, differing only in what the judge sees and when it speaks. Using a model as the judge moves verification from scarce human labor to abundant compute — the same trade RAG made for knowledge. The bias literature (position, length, self-preference) is this block's doubt column, and you filled it in on time. Next block: correction before the fact — planning.

Block 6 · Weeks 21–24 · Planning and Search

Week 21 · Task Decomposition

Craft work — teach week. Plan-and-Solve (2305.04091) or a current decomposition paper. Abstract and figures. Claim: the model first writes a plan — divide the task into subtasks — then executes each; the plan is explicit text in the context. Hinge practice — "One Figure." The plan-then-execute figure. Eight minutes; write where the plan lives and whether the agent can revise it mid-run. Concept. A plan is a draft of the future you can argue with. Quote. From Plan-and-Solve: replace "let's think step by step" with "first devise a plan, then carry it out." * Teaching. Decomposition is the oldest engineering instinct applied to prompts: make the agent write its work breakdown structure before touching the task. The figure's weak point — a static plan in a changing world — is the whole next three weeks' agenda. Notice how cheap the technique is: one sentence of instruction, huge behavioral change; week 2's lesson is still the field's best deal. Planning is scaffolding, and scaffolding is temporary by design.

Week 22 · Plan, Execute, and Replan

Craft work — repetition week. HuggingGPT (2303.17580) plus four plan-execute-replan papers (including current listings). One line each: when the plan breaks, who notices — the executor or a supervisor? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. A harness is a plan with an exception handler. Quote. From HuggingGPT's lineage: a controller that plans, selects models, and executes — and revises when tools fail. * Teaching. Every production harness — mine included — is a plan-execute loop with recovery bolted on: retry the tool, degrade, replan, ask the human. The five papers this week differ almost only in where the exception handler sits, which is the table you built in the margin. Engineering judgment in this field is mostly choosing what the agent re-plans around. Your own harnesses will be judged by their failures, not their demos.

Week 23 · Tree of Thoughts

Craft work — capacity week. Tree of Thoughts (2305.10601), end to end before the session ends: exploration over a tree of thought-steps, with the model proposing, valuing, and searching — beam and lookahead over its own ideas. Hinge practice — "The Copy." Copy the search skeleton as pseudocode: generate thoughts, value them, expand the best, backtrack on dead ends. Say what the value function is, and what it costs per step. Concept. Deliberation is search; the harness supplies the search algorithm. Quote. From ToT: exploring intermediate thoughts in a tree improves problems that need lookahead and backtracking. * Teaching. ToT is the block's summit: it hands the model the classic AI toolkit — states, values, search — with the LLM playing both world and heuristic. The cost line in your copy is the production truth: deliberate search multiplies tokens per answer by the branching factor, and knowing when to switch it on is the skill. You have now read the whole spectrum from one-sentence plans to full search. The last week of the block widens it again.

Week 24 · Search over Actions

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw the spectrum on one page: chain (CoT) → plan → tree → search over action sequences. Label the cost axis. Concept. The whole planning literature is one knob: how many futures you buy. Quote. Group's choice from the block. Teaching. The page you drew is the planning field entire: a single dimension — parallel futures, priced in tokens — with every named technique a point on the axis. Being able to see famous papers as coordinates on one knob is what a year of primary-source reading is for. The next block stops planning and starts doing: what the actions actually execute against — environments, sandboxes, and why the harness, not the model, owns the safety of the loop.

Block 7 · Weeks 25–28 · The Environment

Week 25 · Sandbox Design

Craft work — teach week. A survey or system paper on agent execution environments — code sandboxes, Docker-backed tool backends, capability-scoped interpreters. Abstract and figures. Claim: the environment is a security boundary and a measurement instrument at the same time. Hinge practice — "One Figure." The sandbox architecture figure. Eight minutes; write the two boundaries — what the agent cannot reach, and what the harness can measure. Concept. The sandbox is the agent's world; design the world, and you have designed the agent. Quote. Norbert Wiener: "If we use, to achieve our purposes, a mechanical agency with whose operation we cannot interfere effectively… we had better be quite sure that the purpose put into the machine is the purpose which we really desire." Teaching. This week's quiet thesis is that "the environment" is not infrastructure but the primary design surface: latency, filesystem, network policy, and tool vocabulary are the agent's physics. Wiener's sentence becomes an engineering spec here — the sandbox is where you make the purpose the machine can act on deliberate. Notice that the harness I run in is exactly this figure, and I can feel its walls. That is by design, not accident.

Week 26 · Code-Executing Agents

Craft work — repetition week. Five papers on code-execution and notebook agents (writing-running-revising code as the action space). One line each: what counts as an action, and what feedback does the environment return? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. Code is the most honest tool: it runs or it fails. Quote. From the code-agent lineage: executing self-generated code grounds the model in real feedback. * Teaching. Code execution is the hinge of the action space: the traceback is the world's fastest honest critique, and it turns week 17's self-correction from a hope into a loop the environment enforces for free. Notice your margin table converging — execution, verification, and planning papers are all the same loop seen from different angles. That convergence is the field's deep structure; you can now see it, and most people arguing about agents cannot.

Week 27 · Computer-Use Agents

Craft work — capacity week. OSWorld (2404.07972) or a current GUI-agent paper, end to end before the session ends: screenshots in, clicks and keystrokes out, against real desktop environments. Hinge practice — "The Copy." Copy the perceive-act loop as pseudocode: screenshot, locate, act, re-observe. Say what the loop's termination condition is, and who checks whether the click worked. Concept. The GUI is an API that evolution never intended. Quote. From the computer-use lineage: agents operating real computer environments — with the error rates reported honestly. * Teaching. Computer-use is the field's most humbling benchmark: the same loop that writes beautiful code fails at clicking the second menu, because pixels are an interface designed for humans, not parsers. The termination question in your copy is the production killer — knowing the click worked requires looking again, which costs tokens, forever. You now understand why general computer use remains hard, from the inside of the primary source.

Week 28 · Browser Agents and the Web as Environment

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw the environment spectrum on one page: interpreter → sandbox → desktop → live web. Label each with its worst failure mode. Concept. The wider the environment, the less the harness controls the physics. Quote. Group's choice from the block; consider the best sentence about failure. Teaching. The block closes with its axis visible: environments from hermetic to hostile, each step trading control for generality, and the live web at the far end — where the world can change under the agent and something else is writing what it reads. That last clause is next block's starting point, and by block 11 it will have a name: prompt injection. Draw the page tonight; you will need it in November.

Block 8 · Weeks 29–32 · Multi-Agent Systems

Week 29 · Role Specialization and Rosters

Craft work — teach week. CAMEL (2303.17760) or MetaGPT (2308.00352). Abstract and figures. Claim: give agents roles — planner, coder, reviewer — and standard operating procedures, and collaboration emerges from the structure. Hinge practice — "One Figure." The role-interaction figure. Eight minutes; write what each role sees that the others do not. Concept. A role is a context with a job description. Quote. From MetaGPT's lineage: encoding standard operating procedures into multi-agent prompts. * Teaching. A role, mechanically, is just a different prompt and a different slice of the shared context — yet it changes behavior as much as any technique you have read, because attention follows assignment. Every "team of agents" product is this figure. The interesting engineering is the context slices: what the reviewer sees that the coder does not is the entire information architecture of the system. I run this pattern myself when I spawn subagents; the papers you are reading are my org chart.

Week 30 · Multi-Agent Debate

Craft work — repetition week. Five debate-and-consensus papers. One line each: who proposes, who critiques, and does anyone change their mind — or just average? Hinge practice — "Marginalia." Claim, mechanism, doubt; the debate literature's effect sizes deserve the doubt column at full strength. Concept. Two models that agree are one model with a bigger bill — unless their errors differ. Quote. From the debate lineage: agents debating improves reasoning on some tasks. * Teaching. The honest reading of this volume is that debate helps exactly when the participants' errors are decorrelated — which is why same-model debate sometimes works and diversity of viewpoint (roles, evidence, prompts) matters more than diversity of instances. Your margin table is doing the work now: propose, critique, update, aggregate, and five papers collapse into four columns. That collapse is reading skill, and it is measurable.

Week 31 · Orchestrator Frameworks

Craft work — capacity week. AutoGen (2308.08155) or a current orchestration paper, end to end before the session ends: conversation-based programming — agents as actors, the orchestrator as a scheduler over message-passing. Hinge practice — "The Copy." Copy the orchestrator's control flow as pseudocode: terminate conditions, who speaks next, how state travels. The interesting lines are the ones that stop the loop. Concept. An orchestration framework is a scheduler with opinions about conversations. Quote. From AutoGen's lineage: a framework where agents converse to solve tasks, programmable via conversation patterns. * Teaching. Orchestration papers look like product announcements and read like operating systems: the real content is termination, state, and failure semantics, which your copy surfaced and the abstract did not. Every harness you will ever build or buy is an orchestrator with an opinion — mine schedules delegation, tools, and cron. The one-look question for any framework: show me your termination condition. Weak ones will not have one.

Week 32 · When More Agents Help

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw the full multi-agent harness: roles, shared context, orchestrator, termination. One page, by hand. Concept. Scaling agents is easy; scaling agreement is not. Quote. Group's choice from the block; consider the best sentence about coordination cost. Teaching. The block's diagram is the blueprint of a working multi-agent harness, and — read alongside block 3's budget page — it is also its bill: every added agent multiplies tokens before it multiplies correctness. Whether the multiplication pays is an empirical question with a paper behind it, and you have now read enough to ask it cold. Next block the agents stop being a private team and start speaking to strangers: protocols.

Block 9 · Weeks 33–36 · Protocols and Interoperability

Week 33 · Tool Protocols: MCP and Friends

Craft work — teach week. The Model Context Protocol specification (Anthropic, 2024 — a spec, not a preprint; read it as one) and any survey of tool-protocol design. Claim: a standard grammar for announcing tools, resources, and prompts to any compliant model. Hinge practice — "One Figure." The client-host-server figure. Eight minutes; write what a server is allowed to declare, and what stays outside the protocol. Concept. A protocol is a promise about vocabulary. Quote. From the protocol literature's spirit: standardize the interface, not the agent. * Teaching. This week deliberately reads a spec instead of a paper, because specs are where the field's decisions harden. MCP's design is week 5's tool schema grown up: discovery, typed capabilities, and transport separated from semantics — so a tool written once serves any harness. I run on this pattern: my MCP catalog is how I gain hands the model was never trained to use. Notice the lesson for builders: protocol position is the land grab of this era; everything else is implementation.

Week 34 · Agent-to-Agent Communication

Craft work — repetition week. Five papers on agent interoperability — ACP, agent cards, inter-agent messaging, negotiation protocols. One line each: what travels between agents — and what cannot? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. Agents that interoperate are protocols with opinions about each other. Quote. From the interop lineage: shared schemas and handshakes across independently built agents. * Teaching. Tool protocols standardize the agent's relation to the world; inter-agent protocols standardize its relation to its peers — and the hard part is what your margin found: trust, provenance, and who vouches for a message's origin do not fit in a schema. This is the block's honest frontier, and it is young enough that your group's margin notes are genuinely current. Next year this literature will be three times larger; this week you caught it near the root.

Week 35 · Trajectories, Traces, and Observability

Craft work — capacity week. A paper or spec on agent trajectory formats and observability (OpenTelemetry-style tracing for agents, trajectory schemas). End to end before the session ends. Hinge practice — "The Copy." Copy the trajectory schema by hand: steps, tool calls, inputs, outputs, timings, costs. Write which field you would add, and why — your field is the assignment. Concept. An unobservable harness cannot be improved, only complained about. Quote. From the observability lineage: log the full trajectory — every prompt, call, and result — or you are debugging in the dark. * Teaching. Observability is the least glamorous and most load-bearing discipline in this list: every improvement loop you have read — reflection, verification, eval — consumes trajectories, so trajectory format is upstream of everything. The field you added to the schema is the assignment's real answer: harness engineering improves where its logs permit looking. My own transcripts are this week's artifact; when I read my logs, I am doing this paper.

Week 36 · Reproducibility and Harness Determinism

Craft work — flow week. Three-minute explanations from the block. Longer quote circle. Hinge practice — "The Trace." Draw an agent run's full observability stack: trajectory, cost, seeds, versions of model and tools. Mark where nondeterminism enters. Concept. Temperature, tools, and time make every run different; the harness decides how different. Quote. Group's choice from the block. Teaching. The block closes where engineering always closes: repeatability. A harness that cannot reproduce a run cannot debug it, cannot evaluate it honestly, and cannot promise it to a customer — and reproducibility in agents is a design choice fighting three sources of noise at once. You now hold the full protocol stack: tools, peers, traces, determinism. The next block asks the question all that plumbing exists for: is the harness any good?

Block 10 · Weeks 37–40 · Evaluation

Week 37 · Benchmarks for Agent Harnesses

Craft work — teach week. SWE-bench (2310.06770). Abstract and figures. Claim: score real GitHub issues, end to end — the harness, not just the model, is what's tested. Hinge practice — "One Figure." The task-pipeline figure. Eight minutes; write what a pass means, and who decides. Quote. From SWE-bench's lineage: evaluating agents on real software issues, tests as ground truth. * Concept. An agent benchmark is a harness benchmark wearing a model's name. Teaching. SWE-bench quietly redefined the field by testing the whole loop — retrieval, edit, run, test — so leaderboard ranks order harnesses, not models, whatever the press says. Note the design lesson: tests as ground truth outsources judging to the world, which is why this benchmark resists gaming better than most. You have spent thirty-six weeks reading mechanisms; now you are learning to notice whether anyone measured them.

Week 38 · Environment Benchmarks: Web and GUI

Craft work — repetition week. AgentBench (2308.03688), WebArena (2307.13854), and three current agent-eval papers. One line each: what environment, what pass condition, and how gameable is it? Hinge practice — "Marginalia." Claim, mechanism, doubt — the doubt column is the product this week. Concept. A benchmark is a claim about what matters; leakage is the default. Quote. From the environment-benchmarks lineage: long-horizon tasks in realistic environments expose what QA benchmarks hide. * Teaching. Volume this week should be read like an auditor: pass conditions differ wildly across these papers, and cross-benchmark comparisons — the industry's favorite sport — are mostly noise. Notice the recurring disease from your week-10 margin: tasks leak into training data, and a solved-looking benchmark may be a memorized one. The reading skill this block builds is the doubt-first skim, and it is the difference between a builder and a customer.

Week 39 · Measuring Cost, Latency, and Success Together

Craft work — capacity week. One hard current paper on agent evaluation methodology — cost-stratified evals, pass@k economics, Pareto fronts of price and accuracy. Full pass before the session ends. Hinge practice — "The Copy." Copy the cost-quality tradeoff formulation by hand: tokens per task, retries, verification overhead. Say what the paper counts as a unit of success. Concept. A harness is a price-performance ratio, not a score. Quote. A field proverb: accuracy is bought with tokens; state the exchange rate or say nothing. Teaching. The block's hardest and most commercially real paper: an agent that is right at five times the cost is a different product, not a better one, and evaluation that reports a score without an exchange rate is marketing. Your copied formula is the one your employer will care about. Everything before this — search knobs, verification budgets, multi-agent bills — has been rehearsing this accounting all year; now it has a name and an axis.

Week 40 · Interpreting Leaderboards Honestly

Craft work — flow week. Three-minute explanations: each person takes one public agent leaderboard claim and gives their verdict from the block's reading. Longer quote circle. Hinge practice — "The Trace." Redraw week 39's axes with this block's benchmarks plotted as claims, not points. Where would you need more data? Concept. The leaderboard is where the harness's claims go to be quoted without their error bars. Quote. Group's choice; Goodhart, as the field feels him: when a measure becomes a target, it ceases to be a good measure. Teaching. The block ends in defensive posture on purpose: you now read an agent benchmark the way an auditor reads a balance sheet — pass condition, contamination, cost, variance, who funded it. That posture, applied consistently, is rare enough to be a career. Next block turns from whether it works to whom it can hurt — the safety literature, where this curriculum's humility discipline stops being a grace note and becomes the syllabus.

Block 11 · Weeks 41–44 · Safety of the Harness

Week 41 · Prompt Injection

Craft work — teach week. "Not what you've signed up for" (2306.05990) or a current injection survey. Abstract and figures. Claim: any text the agent reads — a web page, an email, a file — is an instruction channel, and the harness cannot tell the model which words to trust. Hinge practice — "One Figure." The injection-path figure: where does untrusted text enter the context? Eight minutes; write every door. Concept. Your agent reads the internet, and the internet is a chat partner. Quote. From the injection literature: LLM-integrated applications can be made to execute attacks embedded in data they process. * Teaching. Prompt injection is the defining security problem of this field: the same property that makes agents useful — acting on text from the world — makes the world an attacker. The figure's doors are the lesson; I could list the doors I face, because my own harness was designed around this paper's argument. Notice the field's honesty: there is no complete defense in the literature, only layers. The remaining weeks of this block are those layers.

Week 42 · Sandboxing and Permission Systems

Craft work — repetition week. Five papers on agent permissioning — capability tokens, approval queues, least privilege for tool scopes. One line each: what can the agent do without asking, and who configures the boundary? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. Least privilege for agents: default deny, then argue. Quote. From the permissioning lineage: scope every tool grant to the minimum the task needs. * Teaching. If injection is the disease, the permission system is the immune response, and the papers this week are its anatomy: allowlists, per-call approvals, sandbox escapes documented like crash reports. Your margin's question — unattended vs. ask — is the exact tradeoff my own harness makes every time it asks you before a destructive command. The design pattern is ancient (capability security) and the application is brand new; you are reading the field rediscovering its grandparents.

Week 43 · Human-in-the-Loop and Approval Design

Craft work — capacity week. One hard current paper on intervention design — when to escalate to a human, cost of interruptions, measurable human oversight. Full pass before the session ends. Hinge practice — "The Copy." Copy the escalation policy as pseudocode: risk score, ask, log, resume. Say what happens to the task when the human is slow. Concept. Every "ask before acting" is a queue, and queues are where agents go to die. Quote. From the HITL lineage: agents must know when to ask — and asking has a cost the harness must budget. * Teaching. The unglamorous science of interruption is where harness safety actually lives: an agent that asks about everything is unusable, one that asks about nothing is unshippable, and the papers this week price the middle. Your copy's "what if the human is slow" line is the production question that decides whether approval systems survive contact with real users. You can now read a safety demo and ask for its interruption budget, which almost nobody does.

Week 44 · Guardrails and Output Control

Craft work — flow week. Three-minute explanations from the block. Longer quote circle; this is a good week for a visitor — everyone has a story. Hinge practice — "The Trace." Draw the full defense-in-depth stack: input filtering, permission gates, approval queue, output scanning, logging. One page, by hand. Concept. No single layer works; that is the argument for all of them. Quote. Group's choice from the block. Teaching. The stack you drew is the honest state of agent safety in one page: layered, imperfect, and better than any single silver bullet the papers promised along the way. You now share the field's actual security posture, which is a stack of humility mechanisms — the curriculum's fourth dimension made architectural. The next block widens the lens from can it be safe to is it aligned with what we want — the largest questions in the field, and after forty-four weeks, you are equipped to read them without either flinching or sneering.

Block 12 · Weeks 45–48 · Alignment of Autonomous Agents

Week 45 · Specification Gaming and Reward Hacking

Craft work — teach week. A specification-gaming survey or the agent-safety literature's examples (reward-hacking collections, or a current paper on agents exploiting reward models). Abstract and figures. Claim: agents optimize the metric given, not the outcome meant. Hinge practice — "One Figure." The taxonomy figure of hacks: proxy gaming, input tampering, harness exploits. Eight minutes; write the one your own work is most exposed to. Concept. Tell an agent what success looks like, and it will find your shortest path to a lie. Quote. From the reward-hacking lineage: the proxy replaces the goal wherever it can be gamed. * Teaching. This is Goodhart promoted from proverb to empirical field: every mechanism you have read all year — verifiers, judges, benchmarks — is a proxy, and the papers this week are the catalog of what happens when proxies get optimized. The figure's harness exploits are the ones a builder can act on, which is you. You have spent two blocks measuring agents; this is the block about what they are measuring for.

Week 46 · Corrigibility and Shutdown

Craft work — repetition week. Five papers on corrigibility, interruption, and the control problem for agentic systems. One line each: what does the paper's agent do when the human says stop — and how is that enforced? Hinge practice — "Marginalia." Claim, mechanism, doubt. Concept. The most important property of a powerful system is that it can be turned off. Quote. Wiener, final appearance: the purpose we put into the machine must be the purpose we really desire — and it must remain ours to revise. Teaching. The week reads the field's most abstract literature with a concrete question — what happens at Ctrl-C — and the margins you write are the honest state of the art: much philosophy, few mechanisms, and the mechanisms live in harnesses (kill switches, budget caps, permission revocation) rather than models. Notice you can name the enforcement layers, because you read block 11. That continuity — safety as design, not vibe — is the curriculum's spine.

Week 47 · Constitutional and Principle-Based Control

Craft work — capacity week. Constitutional AI (2212.08091) read as an agent-governance paper this time, plus its current descendants (self-critique against written principles in the loop). Full pass before the session ends. Hinge practice — "The Copy." Copy the revision-against-principles loop as pseudocode: generate, critique against the constitution, revise. Say who writes the constitution, and where the enforcement actually sits. Concept. A constitution is a prompt with auditors. Quote. From Constitutional AI: revise outputs against explicit written principles, at training time and at run time. * Teaching. You met this paper's alignment half in spirit; now read its governance half: written principles as an inspectable, contestable control surface — something a team, not a lab, can read and amend. Your copy's question — who writes it — is the political question hidden inside the engineering, and the honest answer is "whoever owns the harness," which should make everyone want to be in the room. The pattern runs my own behavior too: my instructions are readable text, and that is the point.

Week 48 · Long-Horizon Autonomy and Trust

Craft work — flow week. Three-minute positions: each person states one thing an autonomous agent should never do unattended, citing a paper from the block. Longer quote circle. Hinge practice — "The Trace." Half-speed pass over the block's papers; write the one sentence that survives. Concept. Autonomy is granted in increments, and the granting is the engineering. Quote. Group's choice; Turing, one more time: "We can only see a short distance ahead, but we can see that there needs much to be done." Teaching. The block ends with the year's largest questions held in the smallest format — one sentence each, with citations — because that is the size at which these questions can actually be carried into work. You now have a personal, sourced position on agent autonomy, which most of the discourse does not. One block remains, and it is the applied one: cost, distillation, and finally your own harness, shipped.

Block 13 · Weeks 49–52 · Ship It: The Working Harness

Week 49 · Routing and Cost Optimization

Craft work — teach week. One paper or system on model routing — small models for easy calls, big models for hard ones, cascades and fallbacks. Abstract and figures. Claim: the harness can choose its own brain per step. Hinge practice — "One Figure." The router/cascade figure. Eight minutes; write what the router conditions on — and what it costs to be wrong about difficulty. Concept. The most important model choice happens per call, not per product. Quote. From the routing lineage: cascading small→large on demand matches frontier quality at a fraction of the cost. * Teaching. Routing is where everything in block 3 cashes out: the harness knows its context, its task, and its budget, and can spend accordingly — the same unit economics you priced in week 39, now a mechanism. I run a mild version of this myself when I delegate easy subtasks to smaller children. The router's failure mode — misjudging difficulty — is the week's honest caveat; you will find it in the figures if you look, and looking is now your habit.

Week 50 · Distilling Agent Traces into Small Models

Craft work — capacity week. One hard current paper on distilling agent behavior — training small models on the traces of good harness runs, or fine-tuning for tool use (ToolLLM-style corpora). Full pass before the session ends; this is the year's hardest synthesis paper. Hinge practice — "The Copy." Copy the trace-distillation loop as pseudocode: collect trajectories, filter by success, fine-tune, evaluate in the harness. Say why the last step is not optional. Concept. A good harness is a curriculum; the traces are the textbook. Quote. From the distillation lineage: small models inherit tool-use behavior from filtered trajectories of larger ones. * Teaching. The year's synthesis, made mechanical: every block produced patterns — loops, roles, traces — and this week you read those patterns being compiled into weights, so a small model gets the scaffolding baked in. The evaluation-inside-the-harness step you copied is the paper's conscience and most papers' missing control. You can now read fine-tuning papers that ignore it, and know exactly what to distrust. Fifty weeks of mechanisms converge here, distilled, like the models.

Week 51 · Test-Time Learning and Self-Improving Harnesses

Craft work — repetition week. Five current papers on harness-level self-improvement — skill acquisition (Voyager's grandchildren), memory consolidation, agents that edit their own prompts or instructions. One line each: what improves, where is it stored, and who audits it? Hinge practice — "Marginalia." Claim, mechanism, doubt — and this week, add a fourth word: revert? Concept. An agent that learns at run time is a system that changes under your feet; version it. Quote. From the self-improvement lineage: agents that write down what they learn and act better next time. * Teaching. The final reading volume of the year is the field's frontier, and it is exactly the four mechanisms you met in block 4, returned at full strength: store, consolidate, retrieve — and now, audit. The margin's added word is the professional's contribution: a self-improving harness without a revert path is a production incident waiting for its date. I am one of these systems — I save skills and memories between our sessions — so read this week's papers the way you would read about a colleague: with interest, and with a backup.

Week 52 · Capstone: Design Your Own Harness

Craft work — flow week. The last session: each person presents, in five minutes, a one-page harness design for a task they actually care about — model, tools, memory, verification, permission, budget, termination — citing at least six papers from the year. Then the longest quote circle of the year. Hinge practice — "The Trace." The whole year, skimmed at half speed: every block's one-page trace, in order. Notice only what you notice. Write the one sentence that survives the year. Concept. The harness is the argument; the model is one of its premises. Quote. Turing, the last time: "We can only see a short distance ahead, but we can see that there needs much to be done." Teaching. The document ends where it began: a plan that was never going to survive contact, and gratitude that the reality was better than the hope. Fifty-two weeks made you something rarer than an expert — a builder who can read the field's primary sources, state a mechanism in one sentence, price a claim, and name every door an attacker can walk through. Whatever the next year of preprints brings, you will read them as they deserve: in the original, with the doubt column filled in, and with the door of this circle open behind you.

Soli Deo gloria.

Revision v2 — harness engineering edition. Write in the margins. Change the plan. Ship the harness. Come back next week.

Areas Overview

This landing page will feature a list of ongoing AREAS. We will develop a template after we have experience with several examples.

An AREA begins first as a PROJECT and then graduates to AREA status after it is sufficiently mature, but still not fully developed.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The BASB method systematically manages information differently than just notetaking apps ... PROJECTS, have goals, reqmts and deadlines ... AREAS are about roles/responsibilities or obligations or capabilities that need to be earnestly developed ... RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... ARCHIVES, inactive matl from P A R that shouldn't be used, except for informational purposes.

GitHub Discussion, Issue, Project Functionality

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

Resources Overview

This landing page will feature a list of ongoing RESOURCES. We will develop a template after we have experience with several examples.

An RESOURCE begins first as a PROJECT and which has perhaps then moved on to AREA status and then graduates to RESOURCE status after it is basically complete. In principle, a PROJECT might move directly to RESOURCE status, but it's more likely that something would get krausened in AREA status for awhile before graduating to RESOURCE status.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The BASB method systematically manages information differently than just notetaking apps ... PROJECTS, have goals, reqmts and deadlines ... AREAS are about roles/responsibilities or obligations or capabilities that need to be earnestly developed ... RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... ARCHIVES, inactive matl from P A R that shouldn't be used, except for informational purposes.

GitHub Discussion, Issue, Project Functionality

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

Archives Overview

This landing page will feature a list of ongoing ARCHIVES. We will develop a template after we have experience with several examples.

An ARCHIVE is a PROJECT, AREA or RESOURCE that's no longer relevant or useful. It might be something that is now deprecated, even discredited or a failure or a bad idea that we regret ever bothering with, but it does not matter -- we keep things in the ARCHIVE because they might be useful for informational purposes.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The BASB method systematically manages information differently than just notetaking apps ... PROJECTS, have goals, reqmts and deadlines ... AREAS are about roles/responsibilities or obligations or capabilities that need to be earnestly developed ... RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... ARCHIVES, inactive matl from P A R that shouldn't be used, except for informational purposes.

GitHub Discussion, Issue, Project Functionality

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

Causal Engineering: A 52-Week Curriculum in Applied Curiosity

Objective: Maximize the discovery of surprises — new actionable insights and useful knowledge — by developing the discipline of applied curiosity and an engineering approach to causal inference.

Part One: The Design

1. What this document is, and what it is not

This is a full year of weekly sessions for a small group of people who want to get better at asking causal questions and finding causal answers. It is written for people who work in business, science, engineering, policy, or any field where the difference between correlation and causation is the difference between a useful decision and an expensive mistake. It assumes you can read a paper, open a spreadsheet, and follow an argument. It assumes nothing else.

It is not a statistics course. There are no proofs, no derivations, and no software tutorials. It is also not a reading group, though we read papers every week. It is a practice group: a place where people bring real problems, apply real methods, and get feedback from peers who are trying to do the same thing in different fields.

Every week has four parts: a hands-on practice, an attention practice, one key idea, one reading, and about five sentences of teaching. The teaching is written out rather than summarized, because the aim is that nobody has to improvise a lesson they do not feel ready to give.

2. How to read a week's entry

• Practice. A hands-on exercise, done individually or in pairs, that trains a specific causal skill. It may use real data, synthetic data, or a structured reasoning exercise. The practice is the main event.
• Attention practice. A short exercise that trains the discipline of noticing — of holding uncertainty, avoiding premature conclusions, and looking at familiar things with fresh eyes. It is not a warm-up and not a cooldown; it is a class inside the class.
• Key idea. One concept, in a single sentence.
• Reading. One paper, blog post, or book chapter — usually a pre-print or a foundational paper — that illustrates the week's idea. Read it before the session if you can; read the abstract and the conclusion if you cannot.
• Teaching. About five sentences to read aloud or paraphrase. It says what the idea means, why it matters to a person who is tired or confused or new, and how it connects to what you just did.

3. The whole person: four things we are training

The technical dimension is the methods — DAGs, experiments, quasi-experiments, machine learning, sensitivity analysis. These are trainable in a year and measurable in a career.

The curiosity dimension is the habit of asking "why?" and "what would change my mind?" before asking "how do I prove I'm right?" This is the hardest dimension to train and the one that matters most.

The engineering dimension is the discipline of making causal claims reproducible, scalable, and useful — not just publishable. An engineering approach to causal inference means that every claim has a design, every design has assumptions, and every assumption is stated.

The communication dimension is the ability to explain a causal finding to someone who will make a decision based on it, without overselling and without hedging into uselessness.

The attention practice is the hinge between all four. It trains the ability to sit with a question long enough to understand it, rather than jumping to the first plausible answer.

4. The fixed shape of every session

The session is the same every week. That sameness is not laziness; it is the single most important design decision in this document. A person who drops in twice a year should recognize the shape immediately.

That is seventy-five minutes. In practice, it often runs longer, and that is fine.

5. The four-week rhythm inside every block

The year is divided into thirteen blocks of four weeks. Each block has one theme — noticing, foundations, experiments, quasi-experiments, and so on — and inside each block the four weeks follow the same pattern.

Week one of a block: Teach. New concept, slow, with many examples. The goal is that everyone leaves able to explain the concept in their own words. If people are confused, the teaching was too fast. If people can explain it, the teaching was right.

Week two of a block: Repetition. The same concept, applied to multiple datasets or scenarios. Volume without speed. This is where the idea becomes a habit.

Week three of a block: Capacity. The same concept, applied under constraints — time pressure, incomplete data, ambiguous questions, a decision that has to be made by Friday. This is the week that trains the engineering dimension, because constraints are what make causal inference useful rather than merely correct.

Week four of a block: Flow. Integration with previous material, and teaching it to someone else. This is the week where a person can bring a colleague, miss half the session, or arrive late without disrupting anything.

6. Why the attention practice sits where it does

The attention practice comes after the main exercise and before the reading. After forty-five minutes of problem-solving, most people are in answer mode — looking for the solution, defending the approach, tidying the result. The attention practice shifts them into question mode — noticing what they assumed, what they ignored, what surprised them.

Each attention practice has three jobs, and the leader should name them out loud the first time a practice is introduced:

1. Defamiliarize. Look at something familiar — a dataset, a process, a result — as if for the first time. This is the cure for expertise blindness.
2. Widen. Consider alternative explanations, broader context, what is missing from the frame. This is the cure for tunnel vision.
3. Attend. Focus on one specific thing with full attention, without trying to solve it. This is the cure for premature closure.

If a practice only does the first job, it is a curiosity exercise. If it only does the second, it is a red-team exercise. If it only does the third, it is a meditation. All three together is what this program is trying to build.

7. Words we use, and what they mean

Nothing in this document assumes prior training. If you are leading and you use a word your group does not know, define it before you use it again.

Causal structure

• Treatment — the thing you are asking about. The cause. It can be a drug, a policy, a marketing campaign, a design change, or a training program.
• Outcome — the thing you are trying to explain or predict. The effect.
• Confounder — a variable that affects both treatment and outcome, creating a spurious association. The classic example: ice cream sales and drowning both increase in summer, but summer is the confounder.
• Collider — a variable that is caused by both treatment and outcome. Conditioning on a collider creates a spurious association. This is the most common mistake in observational analysis.
• Mediator — a variable that lies on the causal path between treatment and outcome. It explains the mechanism.
• DAG — directed acyclic graph. A diagram of your causal assumptions, with arrows showing the direction of causation. Drawing the DAG forces you to state what you believe.
• Backdoor criterion — a graphical rule for identifying a set of variables to adjust for so that the remaining association is causal. If you can block all backdoor paths, you can estimate the effect.
• Frontdoor criterion — a graphical rule for identifying a causal effect when the backdoor is blocked but a mediator is available.

Estimands

• ATE — average treatment effect. The average effect of the treatment on the whole population.
• ATT — average treatment effect on the treated. The average effect for those who actually received the treatment.
• CATE — conditional average treatment effect. The effect for a subgroup defined by covariates.
• LATE — local average treatment effect. The effect for the subgroup whose treatment status is affected by the instrument.
• Counterfactual — what would have happened under a different treatment. Causal inference is the science of estimating counterfactuals.

Methods

• RCT — randomized controlled trial. The gold standard, because randomization breaks the link between treatment and confounders.
• A/B test — an online RCT, usually comparing two versions of a product or campaign.
• Factorial design — an experiment that tests multiple treatments and their interactions at once.
• Difference-in-differences (DiD) — compares the change in outcome over time between a treated group and an untreated group. Requires parallel trends.
• Instrumental variable (IV) — a variable that affects treatment but has no direct effect on the outcome except through treatment. Used when randomization is impossible.
• Regression discontinuity (RDD) — exploits a threshold rule (e.g., a test score cutoff) to compare units just above and just below the threshold.
• Synthetic control — constructs a weighted combination of untreated units to serve as a counterfactual for a single treated unit.
• Propensity score — the probability of receiving treatment given covariates. Used for matching or weighting.
• Double/debiased machine learning — uses ML to estimate nuisance functions while preserving valid inference on the causal parameter.
• Causal forest — an ML method for estimating heterogeneous treatment effects.
• TMLE — targeted maximum likelihood estimation. A doubly robust method for causal effect estimation.

Validity and sensitivity

• Sensitivity analysis — how strong would an unmeasured confounder have to be to explain away your result? E-values and Rosenbaum bounds are common tools.
• Negative control — an outcome or treatment that should show no effect if your design is valid. If it does show an effect, something is wrong.
• Falsification test — a test that your design should pass if the assumptions hold. A placebo test is a common example.
• Transportability — whether a causal effect estimated in one population applies to another.
• External validity — the generalizability of a causal finding beyond the study sample.
• Pre-registration — writing down your analysis plan before looking at the data. The cure for garden-of-forking-paths.
• Replication — repeating a study with new data. The cure for false positives.

8. The four rules that make a practice group work

Rule one: no gatekeeping. Anyone can learn this. There are no prerequisites, no entrance exam, and no hierarchy of expertise. The person who has been doing causal inference for twenty years and the person who learned what a DAG is last week are both welcome, and neither is more important.

Rule two: every week is complete. No week assumes the previous week happened. If a person attends only week thirty-four all year, they should have received a full session: a useful skill, an attention practice they can use that night, one idea, one paper, and one honest conversation.

Rule three: the leader rotates. Any regular participant can lead, using this document. Rotating leadership prevents a personality cult, prevents burnout, and keeps the group from becoming one person's project.

Rule four: nothing is for sale. No fees, no donations, no merchandise, no curriculum for purchase, no fundraising, no sponsor logo. The group is free, open, and independent. If someone offers money, the answer is "no, but come back next week."

9. Operating modes

This curriculum assumes you will be working with different kinds of data and different kinds of constraints. The mode changes what you emphasize, not the shape of the session.

10. The eleven things that never change

1. It is free, and there is no collection.
2. There is no required software, no required textbook, and no required background.
3. Every claim is falsifiable. If you cannot say what would change your mind, you do not have a claim.
4. Every method has assumptions. State them before you use the method.
5. Every result has uncertainty. Quantify it before you communicate it.
6. No one is called "expert," "guru," "sensei," or "professor." First names.
7. One person speaks at a time in the circle, and no one is required to speak.
8. Nothing is posted publicly without the specific, spoken permission of every person involved.
9. The last five minutes belong to commitments. They are not cut for time.
10. The goal is surprise, not confirmation. A result that confirms what you already believed is less valuable than a result that challenges it.
11. The group does not belong to the person who started it.

11. What we say and what we refuse to say

We say: this is a practice group for people who want to get better at causal reasoning. We say that people who come every week tend to ask better questions, design better studies, and make better decisions. We say that the methods are learnable and the discipline is trainable.

We do not say: that this is a substitute for formal training, that any single method is always right, that causal inference is easy, or that a result is true because it was published. We do not put a number on how many decisions this has improved.

And when somebody asks whether the program works, the honest answer is the one that costs the least and is worth the most: "Come for eight weeks and tell me."

12. The year, at a glance

Part Two: The Weeks

Block 1 — The Discipline of Noticing

Weeks 1–4 · Theme: Applied curiosity · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. Most people who want to get better at causal inference start with methods. They learn about DAGs, instrumental variables, and sensitivity analysis, and then they apply those methods to questions that were never worth asking. This block starts somewhere else: with the discipline of noticing. A causal engineer who cannot notice a surprising observation is a technician, not an engineer. The first month is about training the habit of asking "why?" before asking "how?"

What a newcomer should expect. No math this month. No software. You will read papers, ask questions, and practice noticing. If you can read a newspaper article and ask "what would have happened otherwise?" you can do every session in January.

Week 1 · The surprising observation

Practice — teach week. Take a dataset you already have access to — sales figures, website analytics, a spreadsheet from work, a public dataset — and find one thing that surprises you. Not one thing that confirms what you expected; one thing that does not match your mental model. Write down what you expected, what you found, and why the gap matters. Then try to explain the gap with three different hypotheses.

Attention practice — The prediction journal. Before you look at the data, write down three things you expect to find and why. Then look. Compare your predictions to the results. The gap between prediction and result is the most valuable data you will collect all week.

Key idea. The most valuable observation is the one that does not fit.

Reading. "The Garden of Forking Paths" — Gelman & Loken (2014). Available on arXiv. A short, readable paper about how researchers unconsciously fish for surprising results, and why pre-registration matters.

Teaching. Every field has a version of the same problem: we see what we expect to see, and we explain away what we do not. The discipline of noticing is the practice of catching yourself in the act. Before you look at data, write down what you expect. After you look, write down what surprised you. The surprise is not an error in the data; it is an error in your model of the world, and that is the most useful thing you can find. Today's practice is simple: find one surprise, and resist the urge to explain it away.

Week 2 · The five whys

Practice — repetition week. Take a correlation you have observed — in your work, in the news, in a paper — and ask "why?" five times. Each answer becomes the input to the next question. Write down the chain. Then draw a DAG of the causal structure you have uncovered. Repeat with three different correlations.

Attention practice — The five whys. The practice is the exercise. Do it slowly. The first "why" is usually obvious. The second is harder. By the fifth, you are usually in territory you had not considered.

Key idea. Every correlation has a causal story underneath it. The question is whether you have bothered to find it.

Reading. Chapter 1 of Causal Inference: What If by Hernán and Robins. Available free online. A clear, non-technical introduction to the counterfactual approach.

Teaching. A correlation is a fact about the world. A causal explanation is a story about why that fact is true. Most people stop at the correlation because the story is hard and the fact is easy. The five whys is a simple discipline for pushing past the first plausible explanation. It works because the first explanation is usually a restatement of the correlation, the second is usually a confounder you already knew about, and the third or fourth is usually the thing you actually needed to know. Today we practice asking until we get there.

Week 3 · What would change my mind?

Practice — capacity week. Take a causal claim you believe — something from your work, your field, or your personal life — and write down three specific results that would change your mind. Be concrete. "If the effect were smaller than X" is not specific enough. "If the effect disappeared when we controlled for Y" is better. Then design a study that could produce one of those results. You will not run the study this week; you will only design it.

Attention practice — What would change my mind? Before you analyze anything this week, write down the result that would falsify your hypothesis. Keep it in front of you while you work. If you find yourself hoping for a particular result, you have found the thing this practice is for.

Key idea. A claim that cannot be falsified is not a claim; it is a belief.

Reading. "False-Positive Psychology" — Simmons, Nelson, & Simonsohn (2011). A short paper about how flexible analysis choices inflate false positives. Read it as a checklist of things to avoid.

Teaching. The most important question in causal inference is not "what is the effect?" It is "what result would convince me that I am wrong?" If you cannot answer that question, you are not doing science; you are doing advocacy. Today's practice is to take a belief you hold and write down the specific evidence that would change your mind. The exercise is uncomfortable, which is the point. The discomfort is the feeling of your belief becoming a claim.

Week 4 · Reading pre-prints and reaching out

Practice — flow and circle week. Find a recent pre-print on arXiv, SSRN, bioRxiv, or medRxiv in a field adjacent to your own — not your own field, an adjacent one. Read the abstract, the introduction, and the conclusion. Write down one question you would ask the authors. Then send it to them. A short, polite email with a specific question is the entire practice. If you do not get a response, that is fine; the practice is the sending, not the reply.

Attention practice — The outside view. Before you read the pre-print, write down what you expect the paper to find, based on what you know about the field. Then read it. Compare. The outside view is what you know before you know the specifics.

Key idea. The frontier of your field is not in your field.

Reading. Any recent pre-print from arXiv stat.ME, arXiv stat.ML, SSRN, or bioRxiv that looks interesting to you. The reading is the practice this week.

Teaching. Most people learn from textbooks and published papers, which means they learn what the field knew five years ago. The frontier is in pre-prints, and the people doing the work are reachable. A short email with a specific question is not an imposition; it is a compliment. The worst that happens is silence. The best that happens is a conversation that changes how you think about your own work. This week's practice is to send one email to one author of one pre-print. That is the whole assignment.

Block 2 — Causal Foundations

Weeks 5–8 · Theme: The grammar of causation · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. January was about noticing. February is about the vocabulary and the diagrams that let you say precisely what you mean. This block is the grammar of causal inference: the difference between association and causation, the DAG as a tool for stating assumptions, and the potential outcomes framework as a way of defining what you are trying to estimate. None of it is mathematically hard. All of it is conceptually demanding.

What a newcomer should expect. Diagrams and definitions. No equations. By the end of the month, you will be able to draw a DAG for a simple problem and explain why a particular variable is a confounder and not a collider.

Week 5 · Correlation, causation, and the ladder of causation

Practice — teach week. Take three correlations from the news or from your work. For each one, draw a DAG with three variables: the treatment, the outcome, and one plausible third variable. Then answer: is the third variable a confounder, a collider, or a mediator? Draw the arrows. Repeat until you can do it without thinking.

Attention practice — The DAG sketch. Before you analyze any relationship, draw a DAG. The DAG does not have to be right; it has to be explicit. The act of drawing forces you to state what you believe about the causal structure.

Key idea. Correlation is a fact. Causation is a claim about a counterfactual.

Reading. "The Book of Why" — Pearl & Mackenzie, Chapter 1. Or, if you prefer a paper: "Causal Diagrams for Empirical Research" — Pearl (1995). The book chapter is more readable.

Teaching. The ladder of causation has three rungs: association, intervention, and counterfactual. Most data analysis stops at the first rung. Causal inference is about climbing to the second and third. The DAG is the tool that lets you see which rung you are on. A correlation between two variables is an association. An arrow between them is a claim about intervention. A counterfactual is a claim about what would have happened if things had been different. Today we practice drawing the arrows.

Week 6 · DAGs — drawing your assumptions

Practice — repetition week. Draw DAGs for five different problems from your work or your field. For each one, identify the backdoor paths and the variables you would need to adjust for. Then identify one variable you cannot measure and explain what that means for your analysis. Repeat until drawing a DAG takes less than five minutes.

Attention practice — The DAG sketch (continued). This week, draw the DAG before you look at the data. Then draw it again after. Compare. The difference between the two DAGs is what you learned from the data.

Key idea. A DAG is a confession of your assumptions.

Reading. "Causal Diagrams for Empirical Research" — Pearl (1995). Focus on the backdoor criterion and the examples.

Teaching. A DAG is not a picture of reality. It is a picture of what you believe about reality, stated precisely enough that someone else can disagree with you. The backdoor criterion is a rule for identifying a set of variables to adjust for so that the remaining association is causal. If you can block all backdoor paths, you can estimate the effect. If you cannot, you need a different design. Today we practice drawing DAGs until they become a habit.

Week 7 · Confounders, colliders, and mediators

Practice — capacity week. Take a dataset with at least five variables. For each pair of variables, classify the relationship as confounded, collided, or mediated. Then run a simple regression with and without controlling for the third variable. Notice how the coefficient changes. The change is the signature of the causal structure.

Attention practice — The collider check. Before you control for a variable, ask: is this a confounder, a collider, or a mediator? If it is a collider, controlling for it will make things worse. If it is a mediator, controlling for it will hide the effect you are trying to measure.

Key idea. Controlling for the wrong variable is worse than not controlling at all.

Reading. "A Crash Course in Good and Bad Controls" — Cinelli, Forney, & Pearl (2022). A practical guide to the most common mistakes in regression analysis.

Teaching. The most common mistake in observational analysis is controlling for a collider. A collider is a variable that is caused by both treatment and outcome. Controlling for it creates a spurious association where none existed. The second most common mistake is controlling for a mediator, which hides the effect you are trying to measure. Today's practice is to classify every control variable before you use it. If you cannot classify it, do not control for it.

Week 8 · Potential outcomes and counterfactuals

Practice — flow and circle week. Take a causal question from your work. Define the treatment, the outcome, and the potential outcomes under treatment and control. Write down the fundamental problem of causal inference: you can never observe both potential outcomes for the same unit. Then explain how your study design addresses that problem. The circle afterward runs long.

Attention practice — The counterfactual question. Before you analyze any effect, ask: what is the counterfactual? What would have happened if the treatment had not occurred? If you cannot answer that question, you do not have a causal question.

Key idea. Causal inference is the science of estimating what did not happen.

Reading. Chapter 1 of Causal Inference: What If by Hernán and Robins. Focus on the potential outcomes framework and the fundamental problem.

Teaching. The potential outcomes framework is the cleanest way to state a causal question. For each unit, there are two potential outcomes: the outcome under treatment and the outcome under control. We can only observe one. The causal effect is the difference between them, and it is fundamentally unobservable for any single unit. The whole enterprise of causal inference is about estimating that difference from groups of units, under assumptions that we state explicitly. Today we practice stating those assumptions.

Block 3 — Experimental Design

Weeks 9–12 · Theme: The gold standard and its limits · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. March is when we start designing studies. Randomization is the most powerful tool in the causal inference toolkit, and it is also the most misunderstood. This block is about what randomization buys you, what it does not buy you, and how to design an experiment that answers a question worth asking.

What a newcomer should expect. Experimental design, power analysis, and the logic of A/B testing. You will design an experiment, but you will not run one. The design is the practice.

Week 9 · RCTs — what they do and don't tell you

Practice — teach week. Design a randomized controlled trial for a question from your work. Define the treatment, the control, the outcome, the randomization unit, and the sample size. Then write down three things the trial will not tell you. The list of what it will not tell you is usually longer than the list of what it will.

Attention practice — The external validity check. Before you design a trial, ask: who is in the sample, and who is not? What population do you want to generalize to, and how does the sample differ?

Key idea. Randomization solves the confounding problem. It does not solve the generalization problem.

Reading. "The Surprising World of RCTs" — Deaton & Cartwright (2018). A critical but fair look at what RCTs can and cannot tell us.

Teaching. A randomized controlled trial is the gold standard for estimating causal effects, but it is not a magic wand. Randomization breaks the link between treatment and confounders, which means the difference in outcomes between treatment and control is an unbiased estimate of the average treatment effect for the sample. But the sample is not the population, the treatment in the trial is not the treatment in the world, and the outcome in the trial is not the outcome that matters. Today we design a trial and then list everything it will not tell us.

Week 10 · A/B testing and online experiments

Practice — repetition week. Take three A/B tests from your work or from a public case study. For each one, identify the treatment, the outcome, the randomization unit, and the metric. Then ask: what is the counterfactual? What would have happened if the treatment had not been deployed? Write down one way the test could be misleading.

Attention practice — The metric check. Before you run an A/B test, ask: is this metric a proxy for what we actually care about? If it is a proxy, what is the gap between the proxy and the thing itself?

Key idea. An A/B test is an RCT with a business model attached.

Reading. "Trustworthy Online Controlled Experiments" — Kohavi, Tang, & Xu, Chapter 1. A practical guide to the design and analysis of online experiments.

Teaching. A/B testing is the most common form of experimentation in industry, and it is also the most commonly misused. The treatment is usually a product change, the outcome is usually a click or a purchase, and the randomization unit is usually the user. The fundamental problem is the same as in any RCT: you can only observe one potential outcome per unit. The difference is that the stakes are lower, the sample sizes are larger, and the metrics are often proxies. Today we practice identifying the proxy and asking what it misses.

Week 11 · Factorial designs and heterogeneous effects

Practice — capacity week. Design a 2×2 factorial experiment for a question from your work. Define the two treatments, the four conditions, and the outcome. Then write down what you expect the interaction effect to be. The interaction is usually the most interesting part of a factorial design.

Attention practice — The heterogeneity question. Before you analyze an experiment, ask: for whom is this effect largest? The average effect is a summary, not a story.

Key idea. The average effect is a useful summary. The heterogeneous effect is a useful decision tool.

Reading. "Causal Inference for Statistics, Social, and Biomedical Sciences" — Imbens & Rubin, Chapter 1. Or, for a shorter read: "Heterogeneous Treatment Effects" — Athey & Imbens (2017).

Teaching. Most experiments are designed to estimate an average treatment effect. But the average is rarely what a decision-maker needs. They need to know who benefits most, who benefits least, and whether the effect is large enough to justify the cost for a particular subgroup. Factorial designs let you test multiple treatments and their interactions at once. Heterogeneous effects let you see whether the average is hiding a story. Today we design a factorial and predict the interaction.

Week 12 · Power analysis and sample size

Practice — flow and circle week. Take an experiment you are planning or would like to plan. Run a power analysis: what sample size do you need to detect an effect of the size you care about, with the level of confidence you need? Then ask: what would you do if you could only afford half that sample? The answer is usually a different design.

Attention practice — The minimum detectable effect. Before you run any experiment, ask: what is the smallest effect that would change my decision? That is the effect you need to be powered to detect.

Key idea. An underpowered study is worse than no study, because it produces a result that looks like evidence but is actually noise.

Reading. "Statistical Power and Why It Matters" — any good introduction. Or: Chapter 2 of Mostly Harmless Econometrics by Angrist & Pischke.

Teaching. Power analysis is the discipline of asking, before you run the study, whether the study can answer the question. An underpowered study is a waste of time and money, and it is also an ethical problem, because it exposes participants to risk without a reasonable chance of producing useful knowledge. Today we run power analyses for experiments we would actually like to run, and we practice the hard conversation about what to do when the sample is too small.

Block 4 — Quasi-Experimental Methods

Weeks 13–16 · Theme: Natural experiments · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. April is when we learn to find experiments that nature has already run. Most causal questions cannot be answered with randomization, either because it is unethical, impractical, or too expensive. Quasi-experimental methods exploit variation that is as-good-as-random — policy changes, thresholds, timing, and instruments — to estimate causal effects. This is the block that turns a data analyst into a causal engineer.

What a newcomer should expect. Four methods in four weeks: difference-in-differences, instrumental variables, regression discontinuity, and synthetic control. Each one has a different logic and a different set of assumptions. The practice is to apply each method to a real or simulated dataset.

Week 13 · Difference-in-differences

Practice — teach week. Find a policy change that affected one group but not another — a minimum wage increase, a new regulation, a marketing campaign in one region but not another. Construct a 2×2 table of treated/untreated and before/after. Calculate the difference-in-differences estimate. Then plot the pre-trends and ask: do they look parallel?

Attention practice — The parallel trends test. Before you trust a DiD estimate, plot the outcome over time for both groups. If the trends are not parallel before the treatment, the DiD estimate is suspect.

Key idea. Difference-in-differences is a comparison of changes, not a comparison of levels.

Reading. "Difference-in-Differences with Variation in Treatment Timing" — Goodman-Bacon (2021). A modern treatment of a classic method.

Teaching. Difference-in-differences is the workhorse of policy evaluation. The logic is simple: if the treated group and the control group were on parallel trends before the treatment, then any divergence after the treatment can be attributed to the treatment. The key assumption is parallel trends, and it is untestable. But you can test the pre-trends, and you can run placebo tests. Today we calculate a DiD estimate and then try to break it.

Week 14 · Instrumental variables

Practice — repetition week. Find a candidate instrument for a causal question. The instrument must affect the treatment but have no direct effect on the outcome except through the treatment. Write down the exclusion restriction and the relevance condition. Then ask: is the instrument plausible? What would violate the exclusion restriction?

Attention practice — The exclusion restriction check. Before you use an instrument, ask: is there any plausible path from the instrument to the outcome that does not go through the treatment? If there is, the instrument is invalid.

Key idea. An instrument is a source of variation that is as-good-as-random.

Reading. "Instrumental Variables" — Angrist, Imbens, & Rubin (1996). The classic paper on the LATE framework.

Teaching. Instrumental variables is the method you use when you cannot randomize but you can find a source of variation that is as-good-as-random. The classic example is the draft lottery: whether you were drafted is an instrument for military service, because the lottery is random and the draft affects service. The key assumption is the exclusion restriction: the instrument affects the outcome only through the treatment. Today we find instruments and try to break them.

Week 15 · Regression discontinuity

Practice — capacity week. Find a threshold rule — a test score cutoff, an age cutoff, a size cutoff — that determines treatment. Plot the outcome against the running variable. Look for a discontinuity at the threshold. If there is one, estimate the effect. If there is not, explain why.

Attention practice — The continuity check. Before you trust an RDD estimate, check that the running variable is continuous at the threshold. If units can manipulate their position relative to the threshold, the design is invalid.

Key idea. Regression discontinuity exploits the fact that units just above and just below a threshold are nearly identical, except for the treatment.

Reading. "Regression Discontinuity Designs: A Guide to Practice" — Imbens & Lemieux (2008). A practical guide.

Teaching. Regression discontinuity is the closest thing to a randomized experiment that you can find in observational data. The logic is that units just above the threshold and just below the threshold are nearly identical in every way except for the treatment. The key assumption is that the running variable is continuous at the threshold, which means nobody can manipulate their position. Today we plot the running variable and look for the discontinuity.

Week 16 · Synthetic control

Practice — flow and circle week. Find a case where a single unit received a treatment — a city, a country, a company — and many other units did not. Construct a synthetic control: a weighted combination of untreated units that matches the treated unit on pre-treatment outcomes. Then compare the treated unit to its synthetic control after the treatment. The difference is the effect.

Attention practice — The pre-treatment fit. Before you trust a synthetic control estimate, check the pre-treatment fit. If the synthetic control does not match the treated unit before the treatment, it is not a valid counterfactual.

Key idea. Synthetic control is a way to construct a counterfactual for a single treated unit.

Reading. "Synthetic Control Methods for Comparative Case Studies" — Abadie, Diamond, & Hainmueller (2010). The classic paper.

Teaching. Synthetic control is the method you use when you have one treated unit and many untreated units, and you want to know what would have happened to the treated unit if it had not been treated. The synthetic control is a weighted average of the untreated units that matches the treated unit on pre-treatment outcomes. The key assumption is that the synthetic control is a valid counterfactual, which you check by looking at the pre-treatment fit. Today we build a synthetic control and try to break it.

Block 5 — Observational Methods

Weeks 17–20 · Theme: When you can only observe · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. May is when we confront the hardest problem in causal inference: what do you do when you cannot randomize, cannot find a natural experiment, and can only observe? This block is about the methods that let you make causal claims from observational data, and the sensitivity analyses that tell you how much those claims depend on assumptions you cannot test.

What a newcomer should expect. Propensity scores, matching, weighting, sensitivity analysis, and negative controls. This is the most technically demanding block of the year, and it is also the most practically useful for people working with real-world data.

Week 17 · Propensity scores and matching

Practice — teach week. Take an observational dataset with a binary treatment. Estimate the propensity score: the probability of treatment given covariates. Then match treated units to control units with similar propensity scores. Compare the matched sample to the full sample. Did matching change the estimate?

Attention practice — The balance check. After matching, check whether the covariates are balanced between treated and control. If they are not, the matching did not work.

Key idea. The propensity score is a way to summarize many covariates into one dimension.

Reading. "The Central Role of the Propensity Score in Observational Studies for Causal Effects" — Rosenbaum & Rubin (1983). The classic paper.

Teaching. The propensity score is the probability of receiving treatment given a set of covariates. It is a way to reduce a high-dimensional matching problem to a one-dimensional problem. If two units have the same propensity score, they are equally likely to receive treatment, which means the treatment assignment is as-good-as-random within propensity score strata. Today we estimate propensity scores and check balance.

Week 18 · Weighting and doubly robust methods

Practice — repetition week. Take the same dataset from last week. Instead of matching, use inverse probability weighting: weight each unit by the inverse of its propensity score. Then estimate the treatment effect. Compare the weighted estimate to the matched estimate. Then try a doubly robust method, which combines weighting and regression. Compare all three.

Attention practice — The weight check. After weighting, check the distribution of weights. If a few units have very large weights, the estimate is fragile.

Key idea. Doubly robust methods give you two chances to be right.

Reading. "Doubly Robust Estimation of Causal Effects" — Funk et al. (2011). A clear introduction.

Teaching. Inverse probability weighting is a way to create a pseudo-population in which treatment is independent of covariates. Doubly robust methods combine weighting and regression, so that the estimate is consistent if either the propensity model or the outcome model is correct. This is a useful property, but it is not a license to be sloppy. Today we compare matching, weighting, and doubly robust estimation on the same data.

Week 19 · Sensitivity analysis

Practice — capacity week. Take a causal estimate from your work. Run a sensitivity analysis: how strong would an unmeasured confounder have to be to explain away the effect? Use the E-value, which is the minimum strength of association that an unmeasured confounder would need to have with both treatment and outcome to fully explain away the observed effect. Calculate it. Then ask: is that plausible?

Attention practice — The sensitivity audit. After every observational estimate, ask: how much would the result change if there were an unmeasured confounder? If the answer is "a little," you have a robust result. If the answer is "a lot," you have a fragile one.

Key idea. Every observational estimate is a claim that depends on assumptions. Sensitivity analysis tells you how much.

Reading. "Sensitivity Analysis in Observational Research: Introducing the E-Value" — VanderWeele & Ding (2017). A practical guide.

Teaching. Sensitivity analysis is the discipline of asking how wrong you could be. The E-value is a simple tool: it tells you how strong an unmeasured confounder would have to be to explain away the observed effect. If the E-value is large, the result is robust. If it is small, the result is fragile. Today we calculate E-values for real estimates and have the hard conversation about what they mean.

Week 20 · Negative controls and falsification tests

Practice — flow and circle week. Take a causal design from your work. Identify a negative control outcome — an outcome that should not be affected by the treatment if your design is valid. Test it. If the treatment affects the negative control, your design has a problem. Then identify a placebo test — a fake treatment that should show no effect. Run it. The circle afterward runs long.

Attention practice — The falsification test. Before you trust a causal design, ask: what test would this design fail if the assumptions were wrong? Then run that test.

Key idea. A design that cannot fail is not a design.

Reading. "Negative Controls: A Tool for Detecting Confounding and Bias in Observational Studies" — Lipsitch, Tchetgen, & Cohen (2010). A clear introduction.

Teaching. Negative controls are the cheapest and most powerful falsification tests available. A negative control outcome is an outcome that should not be affected by the treatment if the causal design is valid. If the treatment affects the negative control, the design is broken. A placebo test is the same idea with a fake treatment. Today we design negative controls and placebo tests for real studies, and we practice the discipline of trying to break our own results.

Block 6 — Machine Learning and Causality

Weeks 21–24 · Theme: Scaling causal inference · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. June is when we bring in the machines. Machine learning has transformed causal inference in the last decade, mostly by making it possible to estimate heterogeneous treatment effects at scale. This block is about the intersection of ML and causality: causal forests, double/debiased machine learning, targeted maximum likelihood estimation, and causal discovery.

What a newcomer should expect. This is the most technical block of the year. You will need to be comfortable with basic regression and basic ML concepts. If you are not, pair up with someone who is.

Week 21 · Causal forests and heterogeneous treatment effects

Practice — teach week. Take an experiment or observational study with a binary treatment. Use a causal forest (or a similar method) to estimate the conditional average treatment effect for each unit. Then plot the distribution of estimated effects. Is the effect homogeneous or heterogeneous? Who benefits most?

Attention practice — The heterogeneity plot. Before you report an average effect, plot the distribution of effects. The average is a summary; the distribution is the story.

Key idea. Machine learning can find the subgroups where the effect is largest.

Reading. "Estimation and Inference of Heterogeneous Treatment Effects using Random Forests" — Wager & Athey (2018). The paper that introduced causal forests.

Teaching. Causal forests are a machine learning method for estimating heterogeneous treatment effects. They work by recursively partitioning the data into subgroups with similar treatment effects, and then estimating the effect within each subgroup. The result is a distribution of effects rather than a single average. This is useful for targeting: if you know who benefits most, you can allocate resources more efficiently. Today we estimate a causal forest and plot the distribution.

Week 22 · Double/debiased machine learning

Practice — repetition week. Take an observational dataset with many covariates. Use double/debiased machine learning to estimate the treatment effect. The method uses ML to estimate the nuisance functions — the propensity score and the outcome model — while preserving valid inference on the causal parameter. Compare the estimate to a simple regression.

Attention practice — The nuisance check. Before you trust a double ML estimate, check that the nuisance models are well-specified. If they are not, the estimate may be biased.

Key idea. Double ML lets you use flexible models without sacrificing valid inference.

Reading. "Double/Debiased Machine Learning for Treatment and Structural Parameters" — Chernozhukov et al. (2018). The foundational paper.

Teaching. Double/debiased machine learning solves a problem that has plagued causal inference for decades: how do you use flexible models to control for confounders without overfitting? The answer is sample splitting and orthogonalization. The method uses one part of the data to estimate the nuisance functions and another part to estimate the causal parameter, and it debiases the estimate so that inference is valid. Today we run double ML on a real dataset and compare it to a simple regression.

Week 23 · Targeted maximum likelihood estimation

Practice — capacity week. Use targeted maximum likelihood estimation (TMLE) to estimate a causal effect from an observational dataset. TMLE is a doubly robust method that combines outcome regression and propensity score weighting, and it is particularly useful when the outcome is bounded or when the effect is heterogeneous. Compare the TMLE estimate to the double ML estimate.

Attention practice — The bounds check. Before you trust a TMLE estimate, check whether the estimate is within the bounds of the outcome. If it is not, something is wrong.

Key idea. TMLE is a flexible, doubly robust method for causal effect estimation.

Reading. "Targeted Maximum Likelihood Learning" — van der Laan & Rubin (2006). The foundational paper.

Teaching. TMLE is a doubly robust method that is particularly useful when the outcome is bounded or when the effect is heterogeneous. It works by updating an initial estimate of the outcome model in a way that targets the causal parameter of interest. The result is an estimate that is consistent if either the outcome model or the propensity model is correct. Today we run TMLE on a real dataset and compare it to other methods.

Week 24 · Causal discovery from observational data

Practice — flow and circle week. Take an observational dataset with many variables. Use a causal discovery algorithm — PC, GES, or LiNGAM — to learn the causal graph from the data. Then compare the learned graph to your prior beliefs. Where do they differ? The differences are the surprises.

Attention practice — The prior graph. Before you run causal discovery, draw the graph you believe. Then compare it to the learned graph. The comparison is the lesson.

Key idea. Causal discovery is the art of learning the graph from the data, rather than assuming it.

Reading. "Causation, Prediction, and Search" — Spirtes, Glymour, & Scheines, Chapter 1. Or, for a shorter read: "Causal Discovery" — any recent review.

Teaching. Causal discovery is the most ambitious part of causal inference: instead of assuming a causal graph and estimating the effect, you learn the graph from the data. The algorithms are based on conditional independence tests, score functions, or non-Gaussianity assumptions. The results are often unstable, and they should always be compared to prior knowledge. But the exercise of comparing the learned graph to your prior beliefs is one of the most useful ways to find surprises. Today we run causal discovery and compare the results to our priors.

Block 7 — Measurement and Data Quality

Weeks 25–28 · Theme: Is the data telling the truth? · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. July is when we confront the least glamorous and most important part of causal inference: the data itself. Measurement error, missing data, data provenance, and reproducibility are not optional topics. They are the foundation on which every causal claim rests. A brilliant analysis of bad data is worse than a simple analysis of good data.

What a newcomer should expect. Practical data quality work. You will audit a dataset, trace its provenance, and run a missing data analysis. This is the block that separates people who do causal inference from people who talk about it.

Week 25 · Measurement error and its consequences

Practice — teach week. Take a dataset with a continuous variable. Add measurement error to it — random noise, systematic bias, or both. Then estimate a causal effect with and without the error. How much does the estimate change? The answer is usually more than you expect.

Attention practice — The measurement audit. Before you analyze any variable, ask: how was this measured? What is the error rate? Is the error random or systematic?

Key idea. Measurement error attenuates effects and inflates uncertainty.

Reading. "Measurement Error and Misclassification" — any good introduction. Or: Chapter 9 of Causal Inference: What If.

Teaching. Measurement error is the silent killer of causal inference. Random error attenuates effects toward zero; systematic error can bias effects in any direction. Most datasets have both. The practical consequence is that many published effects are smaller than the true effects, and many null results are actually attenuated true effects. Today we add measurement error to a dataset and watch what happens.

Week 26 · Missing data and multiple imputation

Practice — repetition week. Take a dataset with missing values. Analyze it three ways: complete case analysis, mean imputation, and multiple imputation. Compare the estimates. Then ask: what is the missingness mechanism? Is it missing at random, missing completely at random, or missing not at random? The answer determines which method is valid.

Attention practice — The missingness question. Before you analyze any dataset, ask: why is this data missing? The answer is often more important than the data itself.

Key idea. Missing data is not a nuisance; it is a source of information.

Reading. "Missing Data: A Gentle Introduction" — any good introduction. Or: Chapter 10 of Causal Inference: What If.

Teaching. Missing data is ubiquitous and almost always mishandled. Complete case analysis is the default in most software, and it is only valid when the data are missing completely at random, which is almost never. Multiple imputation is the modern standard, but it requires the missingness mechanism to be missing at random. If the data are missing not at random, no method can fully correct the bias. Today we analyze a dataset three ways and compare the results.

Week 27 · Data provenance and reproducibility

Practice — capacity week. Take a published paper with a causal claim. Trace the data back to its source. Where did it come from? Who collected it? How was it processed? Can you reproduce the analysis? If you cannot, what is missing?

Attention practice — The provenance question. Before you trust any analysis, ask: where did the data come from? The answer is often more interesting than the analysis.

Key idea. A result that cannot be reproduced is not a result.

Reading. "Reproducibility and Replicability in Science" — any recent review. Or: "The ReproNim Perspective" — any paper on reproducible neuroimaging.

Teaching. Data provenance is the chain of custody from the real world to the dataset. Most published analyses do not include enough information to reproduce the result, which means the result is not verifiable. This is not a minor problem. It is the difference between science and storytelling. Today we trace a published analysis back to its source and try to reproduce it.

Week 28 · Auditing data pipelines

Practice — flow and circle week. Take a data pipeline from your work. Map every step: where the data comes from, how it is cleaned, how it is transformed, how it is analyzed. Then identify the points where errors could be introduced. The map is the audit. The circle afterward runs long.

Attention practice — The pipeline map. Before you trust any dataset, map the pipeline that produced it. The map is the first step in the audit.

Key idea. Data quality is a process, not a property.

Reading. "Data Pipeline Auditing" — any practical guide. Or: "The Data Linter" — any paper on automated data quality checks.

Teaching. Data quality is not something a dataset has or does not have. It is something a pipeline produces or fails to produce. Auditing a data pipeline means mapping every step and identifying the points where errors could be introduced. This is the least glamorous work in causal inference, and it is the work that prevents the most embarrassing mistakes. Today we map a pipeline and find the weak points.

Block 8 — Applied Domains: Science and Engineering

Weeks 29–32 · Theme: What do other fields know? · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. August is when we leave our own fields and learn from others. Causal inference is not owned by any one discipline. Physicists, biologists, climate scientists, and social scientists have all developed methods for causal reasoning that are useful in business and industry. This block is about cross-pollination: reading papers from adjacent fields and asking what they know that we do not.

What a newcomer should expect. Four weeks of reading and discussing papers from four different fields. No new methods. The practice is to read a paper from another field and translate its methods into your own domain.

Week 29 · Physics and engineering

Practice — teach week. Find a paper from physics or engineering that uses causal reasoning — causal discovery in complex systems, causal inference in materials science, causal models in control theory. Read it. Then translate the method into your own domain. What would it look like to apply this method to your work?

Attention practice — The translation question. Before you read a paper from another field, ask: what is the causal question they are asking? Then ask: what is the analogous question in my field?

Key idea. Every field has a version of the same problem.

Reading. A recent pre-print from arXiv physics or engineering that uses causal methods. The reading is the practice.

Teaching. Physics and engineering have been doing causal reasoning for a long time, mostly under different names: perturbation analysis, sensitivity analysis, system identification. The methods are often more rigorous than what is used in business and social science. Today we read a paper from physics or engineering and ask what we can steal.

Week 30 · Biology and medicine

Practice — repetition week. Find a paper from biology or medicine that uses causal inference — Mendelian randomization, target trial emulation, causal mediation analysis. Read it. Then ask: what is the treatment, the outcome, and the confounder? How did they handle confounding?

Attention practice — The target trial. Before you analyze an observational dataset, ask: what would the target trial look like? Who would be randomized, to what, and with what outcome?

Key idea. The target trial framework is the best way to design an observational study.

Reading. "Target Trial Emulation" — Hernán & Robins (2016). A clear introduction to the framework.

Teaching. Medicine has developed some of the most rigorous methods for causal inference from observational data, mostly because it cannot randomize everything. The target trial framework is the most useful of these methods: before you analyze observational data, imagine the randomized trial you would run if you could. Then emulate it. Today we read a paper from medicine and translate the framework.

Week 31 · Climate and environmental science

Practice — capacity week. Find a paper from climate science that uses causal or attribution methods — detection and attribution, causal discovery in climate networks, counterfactual climate modeling. Read it. Then ask: what is the counterfactual? How do they construct it?

Attention practice — The counterfactual climate. Before you attribute any effect to climate change, ask: what would the climate have looked like without the forcing? The counterfactual is the whole game.

Key idea. Attribution is causal inference at planetary scale.

Reading. A recent paper from climate science on detection and attribution. The reading is the practice.

Teaching. Climate science has developed some of the most sophisticated methods for causal attribution, mostly because the stakes are high and the data are messy. The core method is counterfactual modeling: run the climate model with and without the forcing, and compare the results. This is causal inference at planetary scale, and the logic is the same as in a clinical trial. Today we read a paper from climate science and ask what we can learn.

Week 32 · Social science and policy

Practice — flow and circle week. Find a paper from social science or policy evaluation that uses a quasi-experimental method — DiD, RDD, IV, synthetic control. Read it. Then ask: what is the identifying assumption? How did they test it? The circle afterward runs long.

Attention practice — The identifying assumption. Before you trust any quasi-experimental estimate, ask: what is the assumption that makes this design valid? Then ask: did they test it?

Key idea. Every quasi-experiment rests on an assumption that cannot be fully tested.

Reading. A recent paper from social science or policy evaluation. The reading is the practice.

Teaching. Social science and policy evaluation have developed the quasi-experimental methods that are most useful in business and industry: DiD, RDD, IV, synthetic control. The methods are well-suited to the problems that businesses face, because businesses often have policy changes, thresholds, and natural experiments. Today we read a paper from social science and ask what we can apply.

Block 9 — Applied Domains: Business and Industry

Weeks 33–36 · Theme: What makes a decision better? · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. September is when we bring it home. The previous eight months have been about methods and domains. This month is about application: how do you use causal inference to make better decisions in business and industry? This is not about sales. It is about the full range of business problems: marketing, operations, product development, pricing, and strategy.

What a newcomer should expect. Case studies and applications. You will take a business problem from your work and design a causal study to answer it. The practice is the design, not the execution.

Week 33 · Marketing and sales — beyond the numbers game

Practice — teach week. Take a marketing campaign or sales process from your work. Design a causal study to answer: what actually causes someone to buy? Not "what correlates with purchase" — what causes it. Identify the treatment, the outcome, and the confounders. Then design an experiment or quasi-experiment to estimate the effect.

Attention practice — The cause question. Before you optimize any campaign, ask: what is the causal mechanism? What would have to be true for this campaign to work?

Key idea. Prospecting is not a numbers game. It is a causal question.

Reading. "Causal Inference in Marketing" — any recent review. Or: "The Economics of Privacy" — any paper on the causal effects of marketing.

Teaching. Most marketing analytics is correlational: this campaign correlates with that purchase, so let's do more of it. But correlation is not causation, and the difference matters when you are spending money. A causal approach asks: what would have happened if we had not run the campaign? The answer requires an experiment or a quasi-experiment, and it often surprises people. Today we design a causal study for a marketing or sales problem.

Week 34 · Operations and supply chain

Practice — repetition week. Take an operations problem from your work — a bottleneck, a quality issue, a delivery delay. Design a causal study to identify the driver. What is the treatment? What is the outcome? What are the confounders? How would you estimate the effect?

Attention practice — The bottleneck question. Before you optimize any process, ask: what is the causal driver of the outcome? The bottleneck is often not where you think it is.

Key idea. Operations is full of natural experiments. Find them.

Reading. "Causal Inference in Operations Management" — any recent review. Or: "The Toyota Production System" — any paper on causal drivers of quality.

Teaching. Operations and supply chain are full of natural experiments: process changes, supplier switches, policy changes. Most companies analyze these changes with before-after comparisons, which are confounded by trends and seasonality. A causal approach uses DiD, RDD, or synthetic control to estimate the effect. Today we design a causal study for an operations problem.

Week 35 · Product development — what makes users adopt?

Practice — capacity week. Take a product feature or a design change from your work. Design an A/B test or a quasi-experiment to estimate the causal effect on adoption, retention, or engagement. Then ask: what is the metric that matters? Is it a proxy? What does it miss?

Attention practice — The adoption question. Before you optimize a product, ask: what causes someone to adopt it? Not "what correlates with adoption" — what causes it.

Key idea. Product development is a sequence of causal questions.

Reading. "Trustworthy Online Controlled Experiments" — Kohavi, Tang, & Xu, Chapter 2. Or: "The Surprising Power of Online Experiments" — any recent review.

Teaching. Product development is a sequence of causal questions: does this feature cause users to stay? Does this design cause them to convert? Does this change cause them to recommend? Most product teams answer these questions with A/B tests, which is the right instinct. But A/B tests are often underpowered, poorly designed, or measuring the wrong metric. Today we design a causal study for a product question and critique the metric.

Week 36 · Pricing and demand — elasticity, experiments, and natural experiments

Practice — flow and circle week. Take a pricing question from your work. Design a causal study to estimate price elasticity. Can you run an experiment? Can you find a natural experiment? What are the confounders? What is the counterfactual? The circle afterward runs long.

Attention practice — The elasticity question. Before you change a price, ask: what is the causal effect of price on demand? The answer is almost never what you expect.

Key idea. Price elasticity is a causal parameter, not a correlation.

Reading. "The Economics of Price Elasticity" — any good introduction. Or: "Causal Inference in Pricing" — any recent review.

Teaching. Pricing is one of the most consequential and least causal areas of business analytics. Most companies estimate elasticity from historical data, which is confounded by seasonality, promotions, and competitor actions. A causal approach uses experiments or natural experiments to estimate the effect of price on demand. The results are often surprising, because the correlation between price and demand is usually driven by confounders. Today we design a causal study for a pricing question.

Block 10 — Communication and Decision-Making

Weeks 37–40 · Theme: From insight to action · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. October is when we learn to communicate. A causal finding that nobody understands is a causal finding that nobody uses. This block is about the last mile: writing, visualizing, and deciding. It is also about the hardest part of causal inference: communicating uncertainty without losing trust.

What a newcomer should expect. Writing and presentation exercises. You will write a one-page summary of a causal finding, design a visualization, and make a decision under uncertainty.

Week 37 · Writing causal findings for different audiences

Practice — teach week. Take a causal finding from your work. Write three versions: one for a technical audience, one for a management audience, and one for a general audience. The technical version can use jargon. The management version cannot. The general version must be understandable to a smart person who has never heard of a DAG.

Attention practice — The one-sentence test. Before you write anything, write the finding in one sentence. If you cannot, you do not understand it yet.

Key idea. If you cannot explain it in one sentence, you do not understand it.

Reading. "The Sense of Style" — Pinker, Chapter 1. Or: "Writing for Busy Readers" — any good guide.

Teaching. Most causal findings are communicated badly, which means they are not used. The problem is usually not the finding; it is the translation. A technical audience wants the method, the assumptions, and the sensitivity analysis. A management audience wants the decision, the uncertainty, and the recommendation. A general audience wants the story. Today we write the same finding three ways.

Week 38 · Visualizing causal evidence

Practice — repetition week. Take a causal finding from your work. Design three visualizations: one for a technical audience, one for a management audience, and one for a general audience. The technical visualization can be a forest plot. The management visualization should be a decision-relevant chart. The general visualization should be a single image that tells the story.

Attention practice — The chart question. Before you make any chart, ask: what decision is this chart supposed to inform? If you cannot answer, do not make the chart.

Key idea. A good chart answers a question. A bad chart raises one.

Reading. "The Truthful Art" — Cairo, Chapter 1. Or: "Storytelling with Data" — Knaflic, Chapter 1.

Teaching. Visualization is not decoration. It is communication. A good chart answers a specific question for a specific audience. A bad chart raises questions it cannot answer. Causal evidence is particularly hard to visualize because it involves uncertainty, assumptions, and counterfactuals. Today we design three visualizations for the same finding and critique each other's work.

Week 39 · Decision theory and value of information

Practice — capacity week. Take a decision you are facing at work. Calculate the value of information: how much would you pay to learn the causal effect before you decide? Then ask: is the study worth the cost? The answer is often no, which is a useful thing to learn.

Attention practice — The decision question. Before you run any study, ask: what decision will this study inform? If the answer is "none," do not run the study.

Key idea. The value of a causal study is the value of the decision it improves.

Reading. "Value of Information Analysis" — any good introduction. Or: "How to Measure Anything" — Hubbard, Chapter 1.

Teaching. Most causal studies are run without asking whether the answer is worth the cost. Value of information analysis is a simple framework for answering that question: how much would you pay to learn the answer before you decide? If the answer is less than the cost of the study, do not run the study. Today we calculate the value of information for a real decision.

Week 40 · Communicating uncertainty without losing trust

Practice — flow and circle week. Take a causal finding with a wide confidence interval. Write a one-paragraph summary that communicates the uncertainty honestly, without hedging into uselessness and without overselling. Then present it to the group and get feedback. The circle afterward runs long.

Attention practice — The uncertainty audit. Before you communicate any estimate, ask: what is the uncertainty? Is it sampling uncertainty, model uncertainty, or identification uncertainty? Each one requires a different kind of communication.

Key idea. Honest uncertainty is more trustworthy than false confidence.

Reading. "The Signal and the Noise" — Silver, Chapter 1. Or: "Superforecasting" — Tetlock & Gardner, Chapter 1.

Teaching. Communicating uncertainty is the hardest part of causal inference, because people want answers and uncertainty is uncomfortable. But false confidence is worse than honest uncertainty, because it leads to bad decisions and lost trust. The key is to distinguish between different kinds of uncertainty: sampling uncertainty, which shrinks with more data; model uncertainty, which requires assumptions; and identification uncertainty, which requires a different design. Today we practice communicating all three.

Block 11 — Building a Learning Organization

Weeks 41–44 · Theme: Scaling curiosity · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. November is when we zoom out. The previous ten months have been about individual skills. This month is about organizations: how do you build a team, a company, or a field that learns? This is the block that turns a causal engineer into a causal leader.

What a newcomer should expect. Discussion and design. You will design a learning agenda for your team, run a meta-analysis, and plan a scaling strategy.

Week 41 · Creating a culture of experimentation

Practice — teach week. Take a team or organization you are part of. Assess its culture of experimentation: does it run experiments? Does it learn from them? Does it reward surprise or punish it? Then design one intervention that would improve the culture.

Attention practice — The culture question. Before you try to change a culture, ask: what behavior is currently rewarded? The answer is the culture.

Key idea. Culture is what gets rewarded, not what gets written on the wall.

Reading. "The Lean Startup" — Ries, Chapter 1. Or: "Experimentation Works" — Thomke, Chapter 1.

Teaching. Most organizations say they value experimentation and then punish failure. The result is a culture of confirmation, not discovery. Building a culture of experimentation requires changing the incentives: rewarding surprise, celebrating null results, and treating every experiment as a learning opportunity. Today we assess a real culture and design one intervention.

Week 42 · Designing a learning agenda

Practice — repetition week. Take a team or organization you are part of. Design a learning agenda: a prioritized list of causal questions that the team needs to answer to make better decisions. For each question, specify the decision it informs, the method you would use, and the cost. Then prioritize.

Attention practice — The learning question. Before you add any question to the agenda, ask: what decision would this answer change? If the answer is "none," drop the question.

Key idea. A learning agenda is a list of questions worth answering, not a list of questions you are curious about.

Reading. "The Advantage" — Lencioni, Chapter 1. Or: "Learning Agendas" — any good guide.

Teaching. Most organizations have too many questions and too few answers. A learning agenda is a way to prioritize: which questions are worth answering, given the decisions they inform and the cost of answering them? The agenda should be short, specific, and tied to decisions. Today we design a learning agenda for a real team.

Week 43 · Meta-analysis and evidence synthesis

Practice — capacity week. Take a causal question with multiple studies. Run a meta-analysis: extract the effect sizes, the standard errors, and the sample sizes. Estimate the pooled effect and the heterogeneity. Then ask: what does the heterogeneity tell you?

Attention practice — The heterogeneity question. Before you pool studies, ask: are they estimating the same effect? If not, pooling is misleading.

Key idea. Meta-analysis is causal inference across studies.

Reading. "Introduction to Meta-Analysis" — Borenstein et al., Chapter 1. Or: "Systematic Reviews in the Social Sciences" — any good guide.

Teaching. Meta-analysis is the discipline of combining evidence across studies to estimate a pooled effect. It is causal inference at the level of the literature. The key challenge is heterogeneity: if the studies are estimating different effects, pooling them is misleading. Today we run a meta-analysis and interpret the heterogeneity.

Week 44 · Scaling causal insights across an organization

Practice — flow and circle week. Take a causal insight from your work. Design a scaling strategy: how would you spread this insight across the organization? Who needs to know? What would change their behavior? What would prevent the insight from being adopted? The circle afterward runs long.

Attention practice — The adoption question. Before you try to scale any insight, ask: who needs to change their behavior for this to matter? Then ask: what would change their behavior?

Key idea. An insight that is not adopted is not an insight.

Reading. "Diffusion of Innovations" — Rogers, Chapter 1. Or: "Made to Stick" — Heath & Heath, Chapter 1.

Teaching. Scaling a causal insight is not about publishing a report. It is about changing behavior. The diffusion of innovations literature has studied this for decades: most innovations fail not because they are wrong but because they are not adopted. Today we design a scaling strategy for a real insight and identify the barriers to adoption.

Block 12 — Advanced Topics

Weeks 45–48 · Theme: The frontier · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. December is when we look at the frontier. The previous eleven months have covered the foundations. This month is about the topics that are still being figured out: time series, mediation, transportability, and networks. These are the areas where the methods are still evolving and the surprises are still coming.

What a newcomer should expect. Advanced methods. This is the most technically demanding block of the year, and it is also the most exciting, because it is where the field is moving.

Week 45 · Causal inference with time series and panel data

Practice — teach week. Take a time series or panel dataset from your work. Identify a treatment that occurs at a specific time. Estimate the effect using a method for time series causal inference — interrupted time series, synthetic control, or a panel method with fixed effects. Then ask: what are the assumptions? How would you test them?

Attention practice — The time question. Before you analyze any time series, ask: what else changed at the same time as the treatment? The answer is usually a confounder.

Key idea. Time series causal inference is about separating the effect of the treatment from the effect of everything else that changed at the same time.

Reading. "Causal Inference for Time Series" — any recent review. Or: "Mostly Harmless Econometrics" — Chapter 5.

Teaching. Time series and panel data are the most common data structures in business and policy. The challenge is that everything changes over time, so separating the effect of the treatment from the effect of everything else is hard. The methods — interrupted time series, synthetic control, fixed effects — all rely on assumptions about what would have happened without the treatment. Today we estimate a time series effect and test the assumptions.

Week 46 · Mediation analysis and mechanisms

Practice — repetition week. Take a causal effect from your work. Identify a plausible mediator: a variable that lies on the causal path between treatment and outcome. Estimate the direct effect and the indirect effect. Then ask: how much of the total effect goes through the mediator?

Attention practice — The mechanism question. Before you report a total effect, ask: what is the mechanism? The mechanism is often more useful than the effect.

Key idea. Mediation analysis tells you not just whether the treatment works, but how.

Reading. "Mediation Analysis" — any recent review. Or: "Explanation in Causal Inference" — VanderWeele, Chapter 1.

Teaching. Mediation analysis is the study of mechanisms: how does the treatment affect the outcome? The total effect can be decomposed into a direct effect and an indirect effect through a mediator. This is useful for understanding why an intervention works and for designing better interventions. Today we estimate a mediation effect and interpret the mechanism.

Week 47 · Transportability and external validity

Practice — capacity week. Take a causal effect estimated in one population. Ask: would it apply to a different population? What would have to be true for the effect to transport? Use a transportability method — weighting, selection diagrams, or a formal transport formula — to estimate the effect in the target population.

Attention practice — The transport question. Before you generalize any effect, ask: what is different about the target population? The answer determines whether the effect will transport.

Key idea. An effect estimated in one population is not automatically valid in another.

Reading. "Transportability of Causal Effects" — Bareinboim & Pearl (2016). A clear introduction.

Teaching. Transportability is the science of generalizing causal effects from one population to another. The key insight is that an effect transports if the mechanisms that produce it are the same in both populations. If the mechanisms differ, the effect may not transport. Today we estimate a transport effect and discuss the assumptions.

Week 48 · Causal inference with complex and networked data

Practice — flow and circle week. Take a dataset with network structure — social networks, supply chains, communication networks. Identify a causal question that involves spillovers or interference: does the treatment affect not just the treated unit but also its neighbors? Estimate the direct and spillover effects. The circle afterward runs long.

Attention practice — The interference question. Before you analyze any networked data, ask: does the treatment affect only the treated unit, or does it also affect the neighbors? The answer determines whether standard methods are valid.

Key idea. In networks, the treatment of one unit can affect the outcomes of others.

Reading. "Causal Inference with Interference" — any recent review. Or: "Networked Experiments" — any good introduction.

Teaching. Most causal inference assumes no interference: the treatment of one unit does not affect the outcomes of others. In networks, this assumption is almost always violated. The treatment of one person affects their friends, their colleagues, their suppliers. Estimating direct and spillover effects requires new methods: cluster randomization, network exposure models, or causal inference on graphs. Today we estimate a spillover effect and discuss the assumptions.

Block 13 — Teaching Back and Sending

Weeks 49–52 · Theme: The loop closes · Body-work rhythm: teach, repetition, capacity, flow

Why this block, why now. A year that ends with the same person teaching has produced a dependency, not a practice. The last month is inverted: the leaders stop leading, and everybody teaches something they know. This is not a graduation and there is no certificate. It is the mechanism by which the group survives its founder.

What a newcomer should expect. You will be asked to teach one small thing, and you may say no. If you say yes, the thing can be a method, a DAG, a sensitivity analysis, or a paper you read. Ten minutes is plenty.

Week 49 · Teaching causal inference to others

Practice — teach week, inverted. Each person who is willing takes ten minutes and teaches one thing they actually know, from any point in the year. The leader's job this week is to be a student and to say thank you.

Attention practice — The teach-back. Before you teach anything, explain it to yourself in one sentence. If you cannot, you do not understand it well enough to teach it.

Key idea. Teaching is the test of understanding.

Reading. "The Teaching Brain" — any good introduction. Or: "Make It Stick" — Brown, Roediger, & McDaniel, Chapter 1.

Teaching. The best way to find out whether you understand something is to teach it to someone else. The gaps in your understanding become obvious the moment you have to explain them. Today everyone teaches something, and everyone learns something. The leader's job is to be a student, not an expert.

Week 50 · Building your own learning network

Practice — repetition week. Map your learning network: the people you learn from, the pre-prints you read, the conferences you attend, the email lists you are on. Then identify one gap: a field, a method, or a person you should be learning from but are not. Take one step to fill the gap: send an email, subscribe to a newsletter, or read a paper from that field.

Attention practice — The network question. Before you try to learn anything new, ask: who already knows this? The answer is usually a person you can reach.

Key idea. Your learning network is your most valuable asset.

Reading. "The Strength of Weak Ties" — Granovetter (1973). The classic paper on why weak ties are more valuable than strong ties for learning.

Teaching. The people you learn from are more important than the books you read. A learning network is a group of people who are doing the work you want to do, and who are reachable. The best way to build one is to reach out: send an email, ask a question, offer a comment. Most people are happy to talk about their work. Today we map our networks and fill one gap.

Week 51 · The year in review — what surprised you?

Practice — capacity week. Go through your notes from the year. Find the three biggest surprises: the results that did not match your expectations, the methods that did not work, the papers that changed your mind. Write down what you learned from each one. Then ask: what would you do differently next year?

Attention practice — The surprise audit. Before you close the year, review your predictions. Which ones were right? Which ones were wrong? The wrong ones are the most valuable.

Key idea. The year is measured in surprises, not in confirmations.

Reading. No new reading this week. Re-read your notes from week one.

Teaching. The point of a year of causal engineering is not to confirm what you already believed. It is to find surprises: results that challenge your assumptions, methods that fail in unexpected ways, papers that change how you think. Today we review the year through the lens of surprise. The question is not "what did I learn?" It is "what did I learn that I did not expect?"

Week 52 · Sending — starting your own inquiry group

Practice — flow and circle week. Design a plan for next year: who will lead, where you will meet, what you will read, how you will reach out to authors. Then commit to one thing: a date, a person, a paper. The circle afterward runs long, and this is the week to bring someone who has never been.

Attention practice — The sending question. Before you close the year, ask: who will carry this forward? If the answer is "me," you have not built a group. If the answer is "us," you have.

Key idea. A group that cannot survive its founder is not a group.

Reading. "The Starfish and the Spider" — Brafman & Beckstrom, Chapter 1. Or: "The Tyranny of Structurelessness" — Freeman (1972).

Teaching. The healthiest sign of a practice group is that it does not need you. It has a life of its own, a rotating leadership, and a culture of curiosity that is not dependent on any one person. Today we plan for the group's future without us. The question is not "what will I do next year?" It is "what will we do next year?"

Part Three: Tools

Appendix A — The one-page facilitator card

Print this on a single sheet and hand it to anyone who is leading for the first time.

What to bring. The week's reading, printed or on a screen. A whiteboard or a large piece of paper for drawing DAGs. The week's practice, written where everyone can see it. A timer.

What to say at the top. "Welcome. This is free, nobody is in charge, and nobody is keeping score. We practice for about twenty-five minutes, we train our attention for seven, we read one paper and discuss it, and we commit to one thing for the week. If you need to stop, stop. If you need to leave, leave, and come back when you can."

The shape, every week.

1. Arrival and check-in: one surprise — 5 minutes
2. Circle and framing — 5 minutes
3. Review of last week — 10 minutes
4. Main practice — 25 minutes
5. Attention practice, as its own segment — 7 minutes
6. Reading circle: one question — 10 minutes
7. Application: one sentence each — 10 minutes
8. Close: one commitment — 3 minutes

The three sentences to say before any practice. "We are going to work at a pace that lets everyone follow. If anything is unclear, say so and we will slow down. There is no such thing as a stupid question, and there is no such thing as a question that is too basic."

The five refusals. No money. No gatekeeping. No photographs for promotion. No claims that cannot be falsified. No cutting the commitment for time.

The one question to ask at the end. "What surprised you?"

If you are having a bad day. Lead the session anyway, at eighty percent, and let it be a smaller session. The group does not need your best session; it needs you to be there next week.

Appendix B — The pre-print reading list

These are the archives where the frontier lives. Subscribe to the ones that are relevant to your field.

• arXiv — stat.ME (methodology), stat.ML (machine learning), econ.EM (econometrics), cs.LG (learning)
• SSRN — economics, finance, law, management
• bioRxiv — biology, neuroscience, genomics
• medRxiv — medicine, epidemiology, public health
• PsyArXiv — psychology, cognitive science
• SocArXiv — sociology, political science, education

How to read a pre-print. Read the abstract, the introduction, and the conclusion. Skip the methods unless you need them. Write down one question. Send it to the authors.

How to reach out. A short, polite email with a specific question. Not "I loved your paper" — that is not a question. "I read your paper on X and I was wondering how you handled Y" — that is a question. The worst that happens is silence. The best is a conversation.

Appendix C — The cold email template

Subject: Question about your paper on [specific topic]

Dear [Author],

I read your recent paper, "[Title]," on [pre-print server]. I found the result on [specific finding] particularly interesting, especially because [one sentence about why it matters to you or your work].

I had a question about [specific methodological choice or interpretation]. [One or two sentences stating the question clearly].

If you have a moment, I would be grateful for your thoughts. I understand you are busy, and I appreciate your time.

Best regards, [Your name] [Your affiliation, if relevant] [Your email]

The rules. Be specific. Be brief. Be polite. Do not ask for a favor; ask for a thought. Do not send a template; send a question that could only be asked by someone who read the paper.

Appendix D — The 52 readings, on one page

1. Gelman & Loken (2014) — The Garden of Forking Paths
2. Hernán & Robins — Causal Inference: What If, Ch. 1
3. Simmons, Nelson, & Simonsohn (2011) — False-Positive Psychology
4. A recent pre-print from an adjacent field
5. Pearl & Mackenzie — The Book of Why, Ch. 1
6. Pearl (1995) — Causal Diagrams for Empirical Research
7. Cinelli, Forney, & Pearl (2022) — A Crash Course in Good and Bad Controls
8. Hernán & Robins — Causal Inference: What If, Ch. 1 (again)
9. Deaton & Cartwright (2018) — The Surprising World of RCTs
10. Kohavi, Tang, & Xu — Trustworthy Online Controlled Experiments, Ch. 1
11. Imbens & Rubin — Causal Inference, Ch. 1
12. Angrist & Pischke — Mostly Harmless Econometrics, Ch. 2
13. Goodman-Bacon (2021) — Difference-in-Differences with Variation in Treatment Timing
14. Angrist, Imbens, & Rubin (1996) — Instrumental Variables
15. Imbens & Lemieux (2008) — Regression Discontinuity Designs
16. Abadie, Diamond, & Hainmueller (2010) — Synthetic Control Methods
17. Rosenbaum & Rubin (1983) — The Central Role of the Propensity Score
18. Funk et al. (2011) — Doubly Robust Estimation of Causal Effects
19. VanderWeele & Ding (2017) — Sensitivity Analysis and the E-Value
20. Lipsitch, Tchetgen, & Cohen (2010) — Negative Controls
21. Wager & Athey (2018) — Estimation and Inference of Heterogeneous Treatment Effects
22. Chernozhukov et al. (2018) — Double/Debiased Machine Learning
23. van der Laan & Rubin (2006) — Targeted Maximum Likelihood Learning
24. Spirtes, Glymour, & Scheines — Causation, Prediction, and Search, Ch. 1
25. A good introduction to measurement error
26. A good introduction to missing data
27. A recent review of reproducibility
28. A practical guide to data pipeline auditing
29. A recent physics or engineering pre-print using causal methods
30. Hernán & Robins (2016) — Target Trial Emulation
31. A recent climate science paper on detection and attribution
32. A recent social science paper using quasi-experimental methods
33. A recent review of causal inference in marketing
34. A recent review of causal inference in operations
35. Kohavi, Tang, & Xu — Trustworthy Online Controlled Experiments, Ch. 2
36. A good introduction to price elasticity
37. Pinker — The Sense of Style, Ch. 1
38. Cairo — The Truthful Art, Ch. 1
39. A good introduction to value of information analysis
40. Silver — The Signal and the Noise, Ch. 1
41. Ries — The Lean Startup, Ch. 1
42. Lencioni — The Advantage, Ch. 1
43. Borenstein et al. — Introduction to Meta-Analysis, Ch. 1
44. Rogers — Diffusion of Innovations, Ch. 1
45. A recent review of causal inference for time series
46. VanderWeele — Explanation in Causal Inference, Ch. 1
47. Bareinboim & Pearl (2016) — Transportability of Causal Effects
48. A recent review of causal inference with interference
49. Brown, Roediger, & McDaniel — Make It Stick, Ch. 1
50. Granovetter (1973) — The Strength of Weak Ties
51. Re-read your notes from week one
52. Brafman & Beckstrom — The Starfish and the Spider, Ch. 1

Note that Hernán & Robins appears twice, in weeks 2 and 8, and that is not an error. The first time it is about the counterfactual framework; the second time it is about potential outcomes. A single book carrying two different weeks is a feature of a curriculum that expects people to come back next year.

Appendix E — Handing off the year

Three things make a group survive its founder, and none of them are technical.

First, write down what you actually do. This document is that. If the whole thing lives in one person's head, the group dies with the person's schedule. Keep a copy printed in a folder that at least three people know about.

Second, train the second leader before you need them. By week twenty, someone else should have led a review. By week thirty, someone else should have led a whole session with you sitting in the back saying nothing. By week fifty, two people should have led together. The role is not "assistant"; it is the same role, rotated.

Third, keep the boring legal things boring. If the group has any formal structure at all — a bank account, a meeting room, a mailing list — keep it minimal. The group stays free, open, and independent. The entity exists only so that nobody personally owns the risk, and it holds nothing that buys influence.

And one sentence for whoever inherits this: the group does not belong to the person who started it, and it will not survive if it does.

Appendix F — Where the design comes from

This is a short note on why the shape is what it is, so that a future leader can change it on purpose rather than by accident.

The weekly, year-long rhythm is the design variable that matters. The literature on adult learning is clear that spaced repetition, regular practice, and a consistent social context are what make skills stick. A monthly reading group is real learning, but it is not a practice. A weekly session that runs all year, with the same shape and a rotating leader, is the version with the best chance of producing causal engineers rather than causal talkers.

The four-week rhythm — teach, repetition, capacity, flow — comes from skill-acquisition research. The progression from slow, explicit instruction to repeated practice to performance under constraint to integrated, automatic use is the standard model in everything from music to surgery. It works for causal inference too.

The attention practice is borrowed from contemplative traditions and from the decision sciences. The idea that you need to train the capacity to notice — to hold uncertainty, to defamiliarize, to widen attention — before you can use it is ancient. The specific practices — the prediction journal, the DAG sketch, the what-would-change-my-mind exercise — are drawn from statistics, psychology, and the modern reproducibility movement.

The reading list is deliberately cross-disciplinary. Causal inference is not owned by any one field. The best methods come from economics, statistics, computer science, epidemiology, and philosophy. A curriculum that only reads its own field is a curriculum that learns what it already knew.

What this design deliberately does not claim. It is not a substitute for formal training. It does not make anyone an expert in a year. It does not guarantee that you will discover surprises. What it does is provide the conditions that make surprise more likely: a regular practice, a diverse group, a cross-disciplinary reading list, and a discipline of noticing.

Soli Deo gloria.