phronesis 1.0.0

package/templates/codex/INDEX.md

@@ -0,0 +1,68 @@
+# Codex INDEX
+
+On-demand map of installation-shared principles, citable from every domain.
+Read this when a task calls for a principle; pull the linked article on demand.
+Format: `- [Title](path) — one-line hook`.
+
+## seed/ — immutable seeded principles
+
+_Shipped, external starter principles — not your earned codex. Quarantined out of retrieval_
+_until you adopt one via `promote_to_codex`, passing the seed as a `--json` payload:_
+_`--json '{"from_seed":"<collection>/<slug>","rationale":"…"}'` (`act` takes only `--json`)._
+_Each carries a `## Interview Prompt` — a question to ask about your own world._
+
+### pm/ — product-management frameworks
+- [A Problem Well Stated Is a Problem Half Solved](seed/pm/a-problem-well-stated-is-half-solved.md) — The constraint on learning is rarely more tests — it's a problem stated clearly enough that a test can resolve it
+- [A Real Strategy Makes Planning Trivial](seed/pm/a-real-strategy-makes-planning-trivial.md) — When you have a real, aligned strategy, planning collapses to a short exercise. When planning is painful, the problem isn't the…
+- [Barrels and Ammunition](seed/pm/barrels-and-ammunition.md) — The number of people who can independently drive an initiative from inception to success — the "barrels" — sets how many things…
+- [Develop Taste in Your Beliefs](seed/pm/develop-taste-in-your-beliefs.md) — Taste isn't only about recognizing good design — it's about the quality of the beliefs you choose to hold. Evaluate the idea…
+- [Hire for Progress, Not for Features](seed/pm/hire-for-progress.md) — People don't buy products — they hire them to make progress in a circumstance. The unit of analysis is the job, not the…
+- [Jobs Are Stable; Solutions Churn](seed/pm/jobs-are-stable-solutions-churn.md) — The job a customer is trying to get done stays remarkably constant over time; the products hired to do it change constantly.…
+- [Level by the Ambiguity Someone Can Own](seed/pm/level-by-the-ambiguity-someone-can-own.md) — A person's real level is the size of the ambiguous, undefined problem you can hand them and walk away from
+- [Listen Before You Prescribe](seed/pm/listen-before-you-prescribe.md) — When you step into a new leadership role, listen first and synthesize what you heard into a shared, public set of observations —…
+- [Live in the Future and Build What's Missing](seed/pm/live-in-the-future-and-build-whats-missing.md) — The best ideas are noticed, not brainstormed — by people living at the leading edge of a change
+- [Match Effort to Leverage](seed/pm/match-effort-to-leverage.md) — Match your effort to the leverage of the task, not to the task itself
+- [Not My Fault, but It Is My Problem](seed/pm/not-my-fault-but-my-problem.md) — When a decision-maker doesn't buy your idea, treat it as your problem to solve — not their failure to understand
+- [Pick the Job, Then Refuse Everything Outside It](seed/pm/pick-the-job-then-refuse-everything-outside-it.md) — Strategy is choosing one job to do and declining everything outside it — especially the lucrative, adjacent, tempting things…
+- [Retention Sets the Ceiling](seed/pm/retention-sets-the-ceiling.md) — Retention sets a hard ceiling on how large you can become; acquisition only fills a bucket that retention keeps from leaking
+- [Scale with Leaders, Not Process](seed/pm/scale-with-leaders-not-process.md) — There are two ways to scale an organization — leaders or process. Process is easier, more appealing, and almost always the wrong…
+- [Solution Discovery Beats Problem Validation](seed/pm/solution-discovery-over-problem-validation.md) — The problem is usually known; the solution is where you win or lose — so spend your discovery there
+- [Tenfold Better on a Painful Problem](seed/pm/tenfold-better-on-a-painful-problem.md) — A new offering must be a large multiple better on a problem that genuinely hurts — not a marginal improvement on one people tolerate
+
+### leadership/ — leading people and orgs
+- [A Manager's Output Is the Team's Output](seed/leadership/a-managers-output-is-the-teams-output.md) — A manager's output is the output of their team plus the output of the teams they influence — not the work they personally produce
+- [Most Team Problems Are Structural, Not Personal](seed/leadership/most-team-problems-are-structural.md) — When something is wrong on a team, diagnose top-down — most problems that look like people problems are structural problems…
+- [Next Play](seed/leadership/next-play.md) — After an error, the compounding error — the defensive overcorrection that follows — usually does more damage than the original.…
+- [Psychological Safety](seed/leadership/psychological-safety.md) — The single largest factor in team effectiveness is psychological safety — a shared belief that the team is safe for…
+- [Right-Size Your Teams](seed/leadership/right-size-your-teams.md) — The fundamental lever of organizational design is team sizing: build small, stable, autonomous teams — large enough to gel and…
+- [Spend Your Time on High-Leverage Activities](seed/leadership/spend-time-on-high-leverage-activities.md) — Leverage is output divided by the time the activity took — so spend your scarce hours on the acts whose effect multiplies across…
+- [Talent Density Is the Master Variable](seed/leadership/talent-density-is-the-master-variable.md) — Talent density is the master variable: in creative work the best are many times more productive than the average, so one…
+- [Under Pressure, Your Calm Is Contagious](seed/leadership/under-pressure-calm-is-contagious.md) — Under pressure your own state is contagious before your words are. Steady yourself first — the room catches your calm or your…
+- [Your Best Alternative Is Your Leverage](seed/leadership/your-best-alternative-is-your-leverage.md) — Your real power in any negotiation is your best alternative to making a deal. The ability to walk away is the source of…
+
+### judgment/ — judgment, taste, and truth-seeking
+- [Contextual Stewardship Is the Senior Skill](seed/judgment/contextual-stewardship-is-the-senior-skill.md) — Senior knowledge work is contextual stewardship: holding the context that makes execution meaningful, not the execution itself
+- [Decision Quality Is Distinct From Outcome Quality](seed/judgment/decision-quality-is-distinct-from-outcome-quality.md) — Judge a decision by the quality of the process, not the quality of the outcome
+- [Embrace Reality: Ego and Blind Spots Are the Two Barriers](seed/judgment/embrace-reality-ego-and-blind-spots.md) — An accurate understanding of reality is the foundation for good outcomes — and two things block you from seeing yourself…
+- [Groups Seek Consensus; Truth-Seeking Needs Structure](seed/judgment/groups-seek-consensus-individuals-seek-truth.md) — Groups optimize for consensus; only individuals and small, structured teams reliably seek truth
+- [Heresies Are Where the Edge Lives](seed/judgment/heresies-are-where-the-edge-lives.md) — Cross "true vs false" with "spreadable vs non-spreadable," and the competitive edge lives in the true-but-unspreadable quadrant…
+- [Judgment Compounds Through Honest Reflection](seed/judgment/judgment-compounds-through-honest-reflection.md) — Judgment is experience plus honest reflection, compounded over many iterations
+- [Phronesis: Judgment in the Particular](seed/judgment/phronesis-is-judgment-in-the-particular.md) — Judgment lives in the particular case, not the rule that gestures at it; phronesis is perceiving what this moment calls for when no rule fits and the codex supplies the aim that separates wisdom from clever recall
+- [Show Me the Apparatus](seed/judgment/show-me-the-apparatus.md) — A stated value isn't real until there's enforced machinery that makes betraying it structurally impossible — not merely discouraged
+- [Small Judgment Gaps Compound Under Leverage](seed/judgment/small-judgment-gaps-compound-under-leverage.md) — With leverage, a small difference in judgment produces an enormous difference in outcome
+- [Taste Is Compressed Judgment](seed/judgment/taste-is-compressed-judgment.md) — Taste is judgment you can no longer articulate
+- [Trust Taste Only Where Feedback Is Valid](seed/judgment/trust-taste-only-where-feedback-is-valid.md) — Trained intuition is real — but only where the environment is regular and the feedback is fast and clear. Everywhere else,…
+- [Weigh the Reasoning, Not the Recommendation](seed/judgment/weigh-the-reasoning-not-the-recommendation.md) — Every advisor is a pattern-matching system trained on a particular corpus of experience. Their recommendation is calibrated for…
+
+### ai-practice/ — durable AI-product practice
+- [Compile, Don't Just Capture](seed/ai-practice/compile-dont-just-capture.md) — Compile, don't just capture. Synthesize raw material into durable knowledge before you need it — and put corrections into the…
+- [Design for the Distribution, Not the Demo](seed/ai-practice/design-for-the-distribution.md) — A probabilistic system returns a distribution of outputs, not a single one. The craft is making that distribution feel…
+- [From Spec-Author to Outcome-Curator](seed/ai-practice/from-spec-author-to-outcome-curator.md) — Deterministic products can be specified; probabilistic products can only be bounded and evaluated. The maker's center of gravity…
+- [Recall Builds Trust Only When It's Calibrated](seed/ai-practice/recall-builds-trust-when-calibrated.md) — Recall and anticipation earn trust by being accurately responsive, not by remembering loudly; over-claiming warmth manufactures overtrust, and one wrong memory costs more than many right ones
+- [The Eval Is the Spec](seed/ai-practice/the-eval-is-the-spec.md) — For a probabilistic product, the specification is the eval set. You define behavior by examples and graders, not prose — because…
+- [The Gold Dust Is What Leaves No Trace](seed/ai-practice/the-gold-dust-leaves-no-trace.md) — The codifiable playbook is already being extracted from recorded traces; the gold dust is the situated judgment read live off an…
+- [The Model Is Not the Moat](seed/ai-practice/the-model-is-not-the-moat.md) — The model is not the moat; the system around it is. When raw capability commoditizes, defensibility lives in proprietary data,…
+- [When Generation Is Cheap, Judgment Is the Work](seed/ai-practice/when-generation-is-cheap-judgment-is-the-work.md) — When generation becomes cheap, the bottleneck moves from making to judging. The scarce skill is knowing which output is actually…
+
+## personal/ — operator-earned and adopted
+<!-- Principles promoted via promote_to_codex land here, with rationale. -->

package/templates/codex/seed/ai-practice/compile-dont-just-capture.md

@@ -0,0 +1,42 @@
+---
+type: codex-principle-seed
+name: compile-dont-just-capture
+title: Compile, Don't Just Capture
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Compile, don't just capture. Synthesize raw material into durable knowledge before you
+> need it — and put corrections into the system's standing rules, not your own head.**
+
+A system that captures raw material and extracts action items is a filing cabinet: it makes
+you reconstruct the picture from scattered pieces every time you need it. A system that
+synthesizes that material into persistent, cross-referenced notes that get richer over time is
+a library — it already wrote the reference, maintained the connections, and flagged the
+contradictions. The compilation step, done before the moment of need, is what turns retrieval
+into knowledge. Six conversations about a topic should leave you with one synthesized account,
+not six transcripts you re-read under pressure.
+
+The same move applies to the corrections you make while working with a capable system. When
+you have to steer it the same way twice, the durable fix is not to remember to prompt better
+next time — your memory caps out fast and resets between sessions — but to write the
+correction into the standing instructions the system always loads. Every recurring correction
+belongs in the artifact, not in your head, because the artifact compounds and your attention
+doesn't. Compiled context and compiled corrections are the same discipline: pay the synthesis
+cost once, up front, so every later session starts richer than the last.
+
+*Diagnostic: when you sit down to make a decision, is the synthesized context already there —
+or do you point the system at old notes and wait for it to rebuild the picture? And when the
+same mistake recurs, do you fix the prompt in your head, or the standing rule that would
+prevent it for good?*
+
+*Source: Andrej Karpathy and Lazar Jovanovic.*
+
+## Interview Prompt
+
+When you need context for a decision, is it already synthesized and waiting — or do you
+rebuild it from scattered notes each time? And when you correct your AI the same way twice,
+where does that correction actually live?

package/templates/codex/seed/ai-practice/design-for-the-distribution.md

@@ -0,0 +1,42 @@
+---
+type: codex-principle-seed
+name: design-for-the-distribution
+title: Design for the Distribution, Not the Demo
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **A probabilistic system returns a distribution of outputs, not a single one. The craft is
+> making that distribution feel dependable — designing what happens when the model is wrong,
+> not just when it's right.**
+
+The core competency for building with non-deterministic systems is translating probabilistic
+behavior into an experience people can rely on. The model will not give the same answer
+twice, and some fraction of its answers will be wrong — confidently. A demo shows you one
+good output; production shows you the whole distribution. Designing for the demo — the happy
+path, or the capability you wish the model had — ships something that breaks the moment the
+world gets messy. Designing for the distribution means shaping the product around what the
+model actually does reliably and handling the rest deliberately.
+
+The decisive move is to decide *in advance* what the product does at the model's limits. When
+the model is unsure, have it ask rather than guess; when the input is too large, give the user
+a choice rather than silently dropping part of it; when it would invent structure that isn't
+there, make it say so. When a feature breaks, the fix is usually a product guardrail, not a
+bigger model — that is how a probabilistic product fails gracefully instead of
+catastrophically. The reliability the user feels is something you design, not something you
+hope the model supplies.
+
+*Diagnostic: for your AI feature, describe what happens when the model is unsure, when the
+input is messy, and when the output is simply wrong. If you can only describe the happy path,
+you've designed for the demo, not the distribution.*
+
+*Source: the AI product-sense literature.*
+
+## Interview Prompt
+
+Your model won't give the same answer every time, and some answers will be wrong. How have
+you designed your product to stay dependable across that whole range — and what does it do at
+the moments the model reaches its limits?

package/templates/codex/seed/ai-practice/from-spec-author-to-outcome-curator.md

@@ -0,0 +1,43 @@
+---
+type: codex-principle-seed
+name: from-spec-author-to-outcome-curator
+title: From Spec-Author to Outcome-Curator
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Deterministic products can be specified; probabilistic products can only be bounded
+> and evaluated. The maker's center of gravity moves from authoring the spec to curating
+> what "good" looks like.**
+
+A conventional product returns the same output for the same input, so you can write a
+document that describes correct behavior and verify the build against it. A generative
+system is probabilistic by nature: the same input yields a range of outputs, and "correct"
+is a distribution with an acceptable-error tolerance that shifts every time the underlying
+model changes. No document can fully describe that. The artifact that *described* a
+deterministic product is replaced by the artifact that *bounds and measures* a probabilistic
+one.
+
+So the foundational questions change. They stop being "what should it do?" and become "what
+is an acceptable error rate? what kinds of mistakes are possible? what does the product do
+for each kind?" The maker's output shifts from prose that describes the build to a criterion
+of acceptable output the team can climb toward — defining what good looks like, curating the
+data that reveals what bad looks like, and owning the loop that turns bad into good. The role
+gets more essential, not less: when the output can't be specified, the judgment about what to
+accept *is* the work.
+
+*Diagnostic: for your next AI feature, can you state the acceptable error rate and what the
+product does for each type of mistake? If you're still describing what it should do rather
+than defining what "good enough" looks like and how you'll measure it, you're writing a spec
+for a system that can't be specified.*
+
+*Source: Marty Cagan, Kevin Weil, and Mike Krieger.*
+
+## Interview Prompt
+
+When you build with a model whose output you can't fully predict, how do you define what
+"good enough" means — and who on your side owns that judgment as the model keeps changing
+underneath you?

package/templates/codex/seed/ai-practice/recall-builds-trust-when-calibrated.md

@@ -0,0 +1,70 @@
+---
+type: codex-principle-seed
+name: recall-builds-trust-when-calibrated
+title: "Recall Builds Trust Only When It's Calibrated"
+created: 2026-07-02
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+*"Note it; don't claim to care."*
+
+> **A system that remembers for you earns trust by being accurately responsive, not by
+> remembering loudly. Recall that notes what is true, when it matters, scoped to what you
+> actually said, compounds trust. Recall that over-claims, performs intimacy, or anticipates
+> past its own reliability creeps, and one wrong memory costs more than many right ones.**
+
+"Trust in an assistant" is two things braided together. One is calibrated reliance: should I
+depend on this, and how much? Its currency is competence, and its design target is
+appropriate reliance, not maximal trust. The other is an affective bond, and here is the
+load-bearing fact: that bond fires from social cues alone, whether or not you believe the
+system cares. A memory that greets you by name and recalls last Tuesday triggers the social
+reflex mindlessly. Recall and anticipation are the exact features that pull on both strings
+at once, which is why they are the strongest trust asset the product has and the easiest to
+misuse.
+
+The one thing the evidence is certain about is asymmetry. Trust is built slowly and destroyed
+in an instant, and a machine is judged more harshly than a person for the same slip. A
+confident wrong recall, "you decided X last Tuesday" when you did not, is not a small debit
+against a large balance; it is the expensive event that undoes many correct recalls. So the
+first rule is correctness before coverage. Cite the source, scope the claim, exclude the
+stale, and when the workspace holds nothing, say so plainly instead of inventing a memory. An
+honest "I have no record of that" is a deposit; a fluent fabrication is the withdrawal.
+
+The popular picture, that small reliable moments are deposits accumulating into a compounding
+balance, is a self-help metaphor, not a measured mechanism. What actually compounds is
+perceived responsiveness, the felt sense of being understood, and it advances by stages rather
+than by tally. So the deposit is not the announcement "I saved that." The words are cheap, and
+said too often they become performed diligence. The real deposit is banked quietly now and
+paid out later, at the moment you reach for something and find it exactly where you expected.
+Loud memory is a cost; accurate memory that surfaces only when it is load-bearing is the asset.
+
+This is why the anthropomorphic warmth is a dial, not a lever. Past a point, more human-like
+cues do not buy more trust; they raise the expectation past what the system can honor and
+manufacture overtrust, which is a failure disguised as a feature. The discipline is to note,
+not to claim to care: phrase recall as retrieval and as your own prior act ("on that date you
+logged this"), never as the system's feeling or its initiative ("I have been thinking about
+your project"). This is the phronetic move, a read of whether this particular recall serves you
+in this particular moment or merely performs presence. Without the aim your codex supplies,
+recall is only clever retrieval, fast, fluent, and pointed at nothing. The companion principle
+"Phronesis: Judgment in the Particular" names why: the codex is what makes recall wisdom
+instead of clever recall.
+
+*Diagnostic: look at your last three recall or anticipation moments. Were they correct, scoped,
+and load-bearing, or were any of them the system performing how much it remembers? Count the
+wrong or unasked-for ones at a heavy discount against the right ones; the asymmetry is the
+point.*
+
+*Source: the human-factors trust literature (Lee & See on calibrated reliance; Parasuraman on
+complacency), the media-equation tradition (Nass & Moon on the mindless social reflex), and the
+asymmetry principle (Slovic; Baumeister). The claim that honestly-scoped anticipation retains
+trust without anthropomorphic warmth is a calibrated bet the current evidence does not yet
+settle.*
+
+## Interview Prompt
+
+Where does a tool remembering something on your behalf feel like genuine help, and where does
+it tip into feeling watched or performed? Name a time a system surfaced something at the right
+moment and it landed, and a time it over-reached. What was different about the two?

package/templates/codex/seed/ai-practice/the-eval-is-the-spec.md

@@ -0,0 +1,42 @@
+---
+type: codex-principle-seed
+name: the-eval-is-the-spec
+title: The Eval Is the Spec
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **For a probabilistic product, the specification is the eval set. You define behavior by
+> examples and graders, not prose — because a document only describes correct behavior, and
+> only an eval measures it.**
+
+A prose requirement works when behavior is deterministic: write the contract, build to it,
+verify once. It fails for a generative system, where "be helpful and concise" is too vague to
+act on, too ambiguous to verify, and too static to keep up with a system whose behavior
+shifts on every model change. The artifact that does the spec's three jobs — describe the
+target, set acceptance criteria, define the priority — in a form that survives
+non-determinism is the eval: concrete inputs, expected outputs, and graded rubrics for the
+qualities you actually care about.
+
+The difference is that a written spec gathers dust once it's read, while an eval suite runs on
+every change. The directive to the team compresses to "here is the measure of good; make this
+number go up," and every real-world failure becomes a new case that hardens the suite over
+time. The discipline that compounds is the loop: observe what the system does, find the
+patterns in what it gets wrong, turn those failures into eval cases, and improve against the
+updated bar. The spec stops being a document you maintain and becomes a measurement that
+maintains the product.
+
+*Diagnostic: does your definition of "good" run on every change, or does it sit in a
+document? If you can't point to the executable criterion that would catch a regression before
+your users do, you have a description, not a specification.*
+
+*Source: Kevin Weil and Ameya Bhatawdekar.*
+
+## Interview Prompt
+
+How do you specify what your AI system is supposed to do — and is that specification
+something that actually runs and catches a regression, or a document someone reads once and
+files away?

package/templates/codex/seed/ai-practice/the-gold-dust-leaves-no-trace.md

@@ -0,0 +1,72 @@
+---
+type: codex-principle-seed
+name: the-gold-dust-leaves-no-trace
+title: "The Gold Dust Is What Leaves No Trace"
+created: 2026-07-02
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Tacit knowledge is not one thing on one clock. The codifiable playbook is already
+> being extracted from recorded traces; the gold dust is the situated judgment that
+> leaves no trace by construction. Aim your capture at the part the record cannot hold.**
+
+"Tacit knowledge" fractures by why it is tacit, and the parts codify at very different
+speeds. Harry Collins split it three ways. Relational tacit knowledge is tacit only by
+circumstance: nobody wrote it down, it was kept back, or it never seemed worth saying,
+and all of it can in principle be made explicit. Somatic tacit knowledge lives in the
+body, like balancing a bike, and a machine could in principle be built to do it.
+Collective tacit knowledge is embedded in social life itself: the way a practiced
+person reads a room and responds to context, learned by membership in a practice, not
+from rules. Most arguments about whether AI can extract expertise talk past each other
+because each side is holding a different one of these in mind.
+
+The first kind is going fast, and the proof is in production. An AI assistant trained
+on millions of recorded support calls distilled the top performers' hard-to-articulate
+playbook and lifted average productivity fourteen percent, and novices by a third. Note
+what made that possible: the knowledge survived in recorded behavioral traces. Modern
+models route around the old expert-systems wall, that experts cannot state their own
+rules, by learning from the trace of what experts did instead of what experts can say.
+So the binding question is no longer "can the expert articulate it?" It is "did it
+leave a trace?" If your expertise is a playbook sitting in transcripts and logs, a bare
+model already holds most of it.
+
+Extraction resistance runs inversely with trace survival, and directly with how much
+of the knowledge lives in social membership and embodiment. What experts did is
+increasingly extractable; what experts are is the durable residue. The gold dust of
+skilled practice sits on the far side of that line: which thread to pull in a
+discovery interview, which thirty seconds of the hour carried the load, the hesitation
+behind the yes, the read of the room that told you what the words did not. That
+judgment is exercised live, against an unrepeatable human encounter, and it leaves no
+trace by construction. A bare model misses it not because the model is weak but
+because the data it would need was never recorded anywhere.
+
+So aim your capture at the residue. When you debrief a session, do not spend the
+effort re-summarizing what the transcript already shows; that half belongs to the
+model already. Bank the part only you were present for: what you noticed, why you
+pulled this thread and not the other, what the encounter told you that the words did
+not. This durability is principled, not permanent, so compound the residue into your
+own workspace while it is still yours alone. The companion principle "Phronesis:
+Judgment in the Particular" names the same asset from the inside: a trained perception
+built only from experience, which is exactly what never lands in the record.
+
+*Diagnostic: before banking a post-session insight, run the trace test. Could a model
+reading the transcript have produced this? If yes, it is playbook: useful, already
+extractable, the floor. If it took being in the room, it is gold dust. Capture that
+first.*
+
+*Source: Harry Collins, Tacit and Explicit Knowledge (2010), on the relational /
+somatic / collective split; Michael Polanyi, The Tacit Dimension (1966), "we can know
+more than we can tell"; Brynjolfsson, Li, and Raymond (QJE 2025) as the existence
+proof that the relational playbook codifies from call transcripts. The reading that
+the extractable half is the relational kind while the collective residue holds is a
+calibrated judgment on current evidence, not settled fact.*
+
+## Interview Prompt
+
+Think of a recent session where you walked away knowing something the transcript would
+not show: a read, a hesitation, the real reason behind a stated one. What did you
+notice, and where did that knowledge go? If it lives nowhere but your head, that is
+the gold dust this workspace exists to catch.

package/templates/codex/seed/ai-practice/the-model-is-not-the-moat.md

@@ -0,0 +1,40 @@
+---
+type: codex-principle-seed
+name: the-model-is-not-the-moat
+title: The Model Is Not the Moat
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **The model is not the moat; the system around it is. When raw capability commoditizes,
+> defensibility lives in proprietary data, workflow integration, trust, and iteration speed.**
+
+Foundation models converge, prompts get copied, and interfaces get screenshotted. So if your
+only advantage is "we use a better model," you don't have one — that layer commoditizes
+underneath you. What compounds is the system built *around* the model: a data flywheel where
+using the product generates proprietary data that makes it uniquely better; workflow
+integration where the product sits inside a daily habit rather than in a sidebar a user has to
+remember to open; a trust and governance position competitors can't quickly assume; and, in
+fast-moving markets, the iteration speed to keep leapfrogging. A single one of these is rarely
+enough — the strongest products combine at least two.
+
+The sharpest test is subtractive: assume every feature you have is cloned tomorrow, and ask
+what remains. If the honest answer is "nothing," your roadmap is a feature backlog, not a moat
+— and the missing investment is usually distribution or the proprietary loop the features were
+wrapping. This is less new economics than old economics reasserting itself: the durable
+advantages have always been data, switching costs, distribution, and trust. Cheap capability
+doesn't abolish moats; it relocates them off the model and onto everything around it.
+
+*Diagnostic: if a competitor cloned every feature you shipped this year overnight, what would
+still be hard for them to replicate? Whatever you can name — the data, the embedded workflow,
+the earned trust — is your actual moat. If you can name nothing, you don't yet have one.*
+
+*Source: Jerry Chen, Evan Spiegel, and Naval Ravikant.*
+
+## Interview Prompt
+
+If a well-funded competitor copied every feature of your AI product tomorrow, what would
+still be hard for them to replicate — and is that the thing you're actually investing in?

package/templates/codex/seed/ai-practice/when-generation-is-cheap-judgment-is-the-work.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: when-generation-is-cheap-judgment-is-the-work
+title: When Generation Is Cheap, Judgment Is the Work
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **When generation becomes cheap, the bottleneck moves from making to judging. The scarce
+> skill is knowing which output is actually good.**
+
+For most of history the constraint on knowledge work was production: writing the draft,
+building the prototype, running the analysis took the time and the skill. Cheap generation
+removes that constraint. When a tool can produce a plausible version of almost anything on
+demand, the value no longer sits in producing it — it sits in the judgment to tell the good
+version from the merely plausible one, and to know which problem was worth generating against
+in the first place.
+
+This inverts where effort should go. The instinct is to celebrate the speed of generation,
+but speed is now the commodity. The durable advantage is taste and evaluation: the ability to
+look at ten generated options and know which one is right, or that all ten are wrong.
+Generation scales with compute; discernment scales with accumulated judgment, and that is the
+part the tools haven't removed. Hand the same generator to someone with a strong foundation
+and someone without one, and the gap between them widens rather than closes.
+
+*Diagnostic: watch where your hours go. As generation gets cheaper, the ratio of time spent
+producing to time spent judging should invert — if you're still spending most of your effort
+making rather than discerning, you're pouring work into the part that just became free.*
+
+*Source: Marty Cagan.*
+
+## Interview Prompt
+
+Now that your tools can generate a draft or prototype in minutes, where has the real
+bottleneck in your work moved — and what makes you able to tell a genuinely good output from
+one that only looks good?

package/templates/codex/seed/judgment/contextual-stewardship-is-the-senior-skill.md

@@ -0,0 +1,50 @@
+---
+type: codex-principle-seed
+name: contextual-stewardship-is-the-senior-skill
+title: Contextual Stewardship Is the Senior Skill
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Senior knowledge work is contextual stewardship: holding the context that makes
+> execution meaningful, not the execution itself.**
+
+The same capable systems that reach near-expert quality when handed full context complete
+only a small fraction of real-world projects, because real work requires bringing — or being
+given — the context that isn't written down anywhere. A capable agent with no sense of which
+system is live and which is a throwaway copy will execute every step flawlessly and still
+demolish production. The context is the load-bearing structure; remove it and technically
+flawless execution becomes destruction.
+
+This is what senior people actually provide, and markets are quietly pricing it: as task
+execution gets automated — visible, easy to cut — it is the invisible stewardship ("knows
+which reports the board actually cares about"; "knows which vestigial-looking feature is
+load-bearing for one critical customer") that turns out to have been holding everything up.
+The skill decomposes into documentable practices: document decisions and their *why*, not
+just outcomes; capture the constraints and trade-offs that were considered and rejected;
+think at the system level about downstream and hidden effects; invest in evaluation
+infrastructure that encodes judgment so it scales. The practices are teachable. The judgment
+of *when* a technically correct output is organizationally wrong stays human.
+
+A sharper framing: stewardship's core is agency, not skill. Skill decays as capability
+rises — the tool gets better at what you used to know. Agency doesn't decay, because the
+tool's "motivations" come from your instructions every session. What's worth building, when
+to start and stop, which risks to accept, what to refuse — these are agency decisions, and
+they are the durable edge. A stewardship-strong operator with weak execution still compounds;
+a stewardship-weak operator with strong execution is replaceable the moment the skill gap
+closes.
+
+*Diagnostic: for your last five meaningful decisions, ask "would a fully capable agent with
+all my context have made the same choice?" The yeses were routine optimization. The noes —
+"no, because I weigh this differently" — are your agency. Invest there.*
+
+*Sources: the contextual-stewardship literature; Simon Willison on agency.*
+
+## Interview Prompt
+
+What do you know about your work that isn't written down anywhere — the context that would
+let someone (or something) technically competent still get it badly wrong? And which of your
+decisions come from what you *value*, not just what you know?

package/templates/codex/seed/judgment/decision-quality-is-distinct-from-outcome-quality.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: decision-quality-is-distinct-from-outcome-quality
+title: Decision Quality Is Distinct From Outcome Quality
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Judge a decision by the quality of the process, not the quality of the outcome.**
+
+Outcomes blend three things: decision quality, luck, and hidden information. So a single bad
+outcome cannot tell you the decision was bad — that is a sample size of one. A 24% shot that
+happens to hit was not a "right" prediction; a sound call that runs into a 1–2% bad break was
+not a "wrong" one. The result acts like a gravity well: once you know how it turned out, you
+can't climb back out to see whether the process was actually good. The trap runs both ways —
+you also don't get to keep the feeling of being right when a bad decision happens to work out.
+
+This error is called *resulting*, and it is the central failure in learning from experience.
+Outcomes are still a legitimate *prompt* to re-examine your process — the error is retrofitting
+the verdict on the decision to match the result. Over a large enough sample, luck washes out
+and skill dominates; in any single trial, luck can dominate completely. A strong decider still
+loses a large fraction of the time. The discipline is to think in probabilities — calibrate a
+range rather than collapse to a binary, and ask "do I actually want to bet on that?" to trigger
+information-hunger and surface why you might be wrong.
+
+*Diagnostic: when you review a decision that went badly, can you separate "the process was
+flawed" from "the dice came up wrong"? If every bad outcome rewrites your memory of the
+decision as obviously bad, you're resulting — and you're learning the wrong lessons from luck.*
+
+*Source: Annie Duke.*
+
+## Interview Prompt
+
+Think of a decision you made that turned out badly. Was the *process* actually wrong, or did
+you just get unlucky? And do you ever catch yourself calling a decision "good" only because it
+happened to work out?

package/templates/codex/seed/judgment/embrace-reality-ego-and-blind-spots.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: embrace-reality-ego-and-blind-spots
+title: "Embrace Reality: Ego and Blind Spots Are the Two Barriers"
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **An accurate understanding of reality is the foundation for good outcomes — and two things
+> block you from seeing yourself clearly: ego and blind spots.**
+
+There is nothing to fear from truth; an accurate understanding of reality is the essential
+foundation for producing good outcomes. The biggest mistake most people make is failing to
+see themselves and others objectively. Two barriers cause it. The *ego barrier* is the
+defensiveness that makes examining one of your own weaknesses feel like an attack — it fires
+before you can think. The *blind-spot barrier* is structural: you can't perceive what you
+can't conceive, so having a weakness is like missing a sense — you don't experience its
+absence as a gap.
+
+Because these barriers are nearly invisible from the inside but easy to spot from the
+outside, the antidote is other people. You cannot reliably find your own blind spots; you
+need people who will tell you what you can't see, and the openness to actually hear them.
+This is the same structure as a truth-seeking group: weakness-finding is a collaborative act,
+not an introspective one.
+
+*Diagnostic: when someone points out a weakness, watch your first reaction. If it's a flush
+of defensiveness or a quick counter-argument, that's the ego barrier firing — and the thing
+you're defending against is often exactly what's worth examining.*
+
+*Source: Ray Dalio.*
+
+## Interview Prompt
+
+When someone points out a weakness or a mistake of yours, what's your honest first reaction —
+and who in your life will actually tell you the things you can't see about yourself?