# Lockfile URL: https://mechanisticmindset.com/wiki/lockfile Tags: core-framework, system-design # Lockfile #core-framework #system-design ## What It Is A rule such as “no unjustified runs” can mean something precise to the person who wrote it. They remember the examples that led to the rule. A new agent, a new hire or the same person six months later receives only the words, without the judgments needed to apply them. A **lockfile** retains that missing context in a versioned bundle: **the skill, the golden set, the verifier and the rejection ledger**. They travel together as a unit that can be copied and adapted. The skill describes the procedure, while the other pieces establish what a successful use actually looks like and which failures must not recur. The name comes from software packaging. A manifest can request a recent library version and produce a different build on each machine. A lockfile pins exact versions so that the build reproduces byte for byte. The four-piece quality bundle does the same for the meaning of “good”: it pins the definition at a particular moment and makes it checkable. [Taste Compilation](/wiki/taste-compilation) describes the process that turns felt judgments into language and machinery. The lockfile is the artifact that process produces. It is the reusable unit of value in a generation system, owned and versioned and executable by a future model. Prompts, models and individual outputs are rented or depreciating; this bundle retains the part that can continue compounding. It is worth more than any individual output it produces. ## The Four Pieces | Piece | Contents | Function | What fails without it | |---|---|---|---| | Skill | Procedure and sequence | It tells the agent how to work. | Each run invents a process. | | Golden set | Selected examples of actual quality | It shows what words cannot fully specify. | Instructions arrive without the taste needed to apply them. | | Verifier | Mechanical gates and invariants | It makes quality checkable. | Quality depends on an impression rather than an enforceable condition. | | Rejection ledger | Failures and the axes on which they failed, recorded verbatim | It retains the boundary revealed by each rejection. | The same failures have to be rediscovered. | A skill must never be stored or shipped alone. Versioning the four pieces together keeps the definition of good from drifting independently across its procedure, examples and checks. The ledger preserves the original rejection. “This felt cheap and lazy” carries a reaction that “insufficient polish” removes. The intensity is part of the evidence, so tidying it can destroy information. The ledger is a small [accrual substrate](/wiki/accrual-substrate); the whole bundle makes [memory into the system](/wiki/memory-is-the-substrate). Each execution is temporary, but the pinned judgments persist. ## Why Distilled Rules Fail Will reached the annotated-example requirement after a craft corpus failed to transfer through its rulebook: > "The distilled rules are TRASH. Never give distilled rules — we need ANNOTATED EXAMPLES. ... Never give pure rules. Always give examples — and counterexamples. Explain the examples." Distillation compresses remembered instances into a rule. The author's taste supplies the missing context when they read it, but another reader has no such context. “No unjustified runs” may refer to a dozen specific failures for its author and still permit all of those failures in a newcomer’s interpretation. The wording transfers while the judgment remains behind. Annotated examples carry the judgment by showing the event and explaining why it passes or fails. The generator must not write its own golden examples: AI-written examples do not teach the target register. Three failed versions of a register document produced that lesson. AI-written examples reproduced the register the document was meant to exclude; the version that held quoted the target corpus verbatim and derived observable properties from it. Actual members of the target distribution establish the standard. A model's impression of that distribution cannot stand in for them, because it would certify the very tendencies the gate exists to catch. ## The Example Is the Specification The examples' actual properties become the specification. Ten exemplars sharing a property teach that property; vague examples teach vagueness. Selection therefore requires the same care as writing an explicit requirement: > "Examples transfer taste, constraints mechanize truth, and selection pressure is what keeps the dataset valuable." The golden set shows taste through actual work. The verifier expresses what can be checked mechanically. Annotated counterexamples show the boundary by making the reason for rejection visible. A golden set without counterexamples leaves that boundary undefined. This provides the channel missing from the wheelwright parable in [Taste Compilation](/wiki/taste-compilation): instruction alone could not transmit the craft to the wheelwright's son, but preserved examples can show where the judgment operates. ## Start From the Source, Verbatim A converged artifact includes decisions that a high-level description may omit. Constants, orderings and phrasings can encode dozens of resolved judgments. Asking a generator to derive the artifact again discards that supporting structure: > "For complex outputs with lots of hidden scaffolding, the right pattern is start from the existing source code verbatim, then iterate by editing. Don't ask it to rederive the whole thing from scratch — too much supporting structure lives implicitly in the code." The lesson followed a reconstruction that destroyed a week of tuning: “re-deriving tuned constants isn't caution, it's quality destruction.” Starting with the source retains those decisions, allowing changes to be made against an already plausible result. > "A good starting point is a really, really underrated thing — to iterate you need something plausible that will get you there. Starting from scratch, you have to go back all the way to Noah's Ark." Negative directions do not supply that starting point. A positive example does. The golden set is therefore operational: it provides material a new run can begin from, rather than only a record of admired past work. ## Constraint + Driver A bundle containing only constraints produces work that is correct but lifeless. It also needs something that drives exploration: > "The juice isn't JUST in the DSL — the DSL is CONSTRAINING, but the PROMPT is what drives it to explore and imagine." Grammar, components and verification define what cannot go wrong. The prompt and its ambition determine how much creative exploration occurs within those limits. Constraints alone settle on the safest legal answer; a driver without constraints produces vivid failures. The stored unit must therefore include **(prompt, context, output)**. An output alone loses the conditions that produced it. Retaining the answer without the question prevents the run from being reproduced. ## Versioning and Forkability Each promotion to the golden set and each new rejection changes the definition of good. Committing them as versions makes that change explicit and keeps the pieces coherent. The bundle is also forkable. Taste has historically transferred through years of apprenticeship, with people together pointing at work that cannot be fully described. A versioned bundle moves the grammar and verifier losslessly. The recipient then selects the golden examples again according to their own judgment, inheriting the remaining machinery. The work that must be repeated is concentrated in the part that is personal. ## The Readiness Meter A **readiness meter** checks whether the bundle supports expansion before a large batch is run. It silently generates ten candidates, scores them against the gates and golden set, and reports P(good | ask). The day-one reaction “they all kind of look like shit” corresponded to roughly 0/10 good results, but the probability had not been measured. Fanning out with P approximately 0 produces ten bad variants. Measuring first shows whether the pinned language holds before resources are spent on the batch. With this meter, the lockfile is self-certifying: it can report whether it is sufficient for the domain before a run depends on it. ## Integration with the Mechanistic Framework ### Connection to [Taste Compilation](/wiki/taste-compilation) Taste Compilation turns each verdict into language and machinery, writing back after selection. The lockfile is the resulting output format in which those changes are retained. ### Connection to [Selection over Design](/wiki/selection-over-design) The architecture phase finishes when the bundle exists, rather than merely when one run works. Continued use then changes the bundle: promotions update the golden set and rejected candidates update the ledger. ### Connection to [Accrual Substrate](/wiki/accrual-substrate) and [Memory Is the Substrate](/wiki/memory-is-the-substrate) Every verdict adds something visible to the examples or ledger. The retained, versioned taste constitutes the pipeline across temporary executions, so later runs need not derive it again. ### Connection to [Ratchet](/wiki/ratchet) The lockfile is a judgment lock: it holds compiled verdicts so that subsequent work cannot fall below the standard already established. ### Connection to [Pedagogical Magnification](/wiki/pedagogical-magnification) An explained example shows the work at the resolution where a judgment can be made. A compressed rule omits that view. Annotated positive and negative cases make the distinction available to another reader. ## See Also - [Compounding Artifacts](/wiki/compounding-artifacts) examines what remains useful as models change. - [Structure Over Request](/wiki/structure-over-request) enforces quality through the arrangement of computation. - [Error Signal](/wiki/error-signal) describes the discrepancies whose resolved lessons the golden set, verifier and ledger retain.