# Case Study 02 - Artifact Audit of the 12 VALUE.md Files in the Field **Date:** 2026-06-04 **Method:** Static analysis of every VALUE.md file across the author's workspace, scored against KAV's six-part gate, Value Statement requirement, hedge-word and em-dash gates, and sibling-file evidence of shipment. Anonymization: company names, personal names, partner organization names stripped. **What this is evidence for:** the standard is being applied in real projects with measurable conformance, and the standard's own version history is visible in the artifacts it produced. --- ## The question being asked Case Study 01 used conversation-transcript analysis to ask whether VALUE.md adoption changes how the author talks. This case study asks a different question: of the VALUE.md files that exist in the author's workspace, what do they look like? Do they pass the standard's own gate? Do they correspond to shipped work? Do they show evidence of the standard being used, or only of the file being created? The standard's central claim is that a VALUE.md is a one-page contract a stranger can verify. If the files in the field do not pass the standard's own gate, the standard is not being used; it is being demonstrated. If they do, the standard is being applied. --- ## What was measured For each of the 12 VALUE.md files in the author's workspace, the following were scored: | Check | Rule | |---|---| | Q1 present | Has a section identifying the recipient | | Q2 present | Has a section describing the change for that recipient | | Q3 present | Has a section describing the verification check | | Value Statement section | Has the v1.2.0+ "Value Statement" lede (one-sentence transaction summary) | | "What we don't promise" section | Names anti-scope | | "What we don't break" section | Names a counter-metric or side-effect bound | | Status lifecycle | Uses Proposed / Promised / Proven / Broken vocabulary | | Zero hedge words | No "maybe", "I think", "kind of", "somewhat", "possibly", "ish" | | Zero em-dashes | No "-" or "-" - the standard's ASCII-hyphen rule | | Specific recipient mentions | Names a concrete role (the operator, the customer, etc.) | | Vague recipient mentions | Counts category-shaped placeholders ("users", "the team") | | Sibling code | The project directory contains files suggesting shipped work | --- ## What the audit found ### Aggregate - **12 files audited.** - **6 of 12** had all three core questions (Q1, Q2, Q3) present in KAV's shape. - **3 of 12** had the Value Statement section (the v1.2.0 addition). - **5 of 12** had "What we don't break." - **12 of 12** used the Status lifecycle vocabulary. - **9 of 12** had zero hedge words. (The gate held in three-quarters of the field.) - **7 of 12** had zero em-dashes. - **5 of 12** had sibling code suggesting the project shipped or is shipping. ### The files split by era The most important finding: the 12 files do not all conform to the *same* version of the standard. The standard's evolution is visible in the artifacts. **Era 1 - the pre-KAV era (4 files):** Files written before KAV existed, against a different workspace standard (the deprecated KYAC format, predating the standard by approximately a week). These files have richer clause structures, not KAV's three-question shape. Auditing them against KAV's gate finds them non-conforming - but they are not non-conforming to KAV; they are conforming to a different standard. Category 1 files: an investment options notebook, a major internal infrastructure project (REDACTED_PROJECT_KAI), an internal quality-assurance project (REDACTED_PROJECT_SQA), an internal brand-management project. All four have zero hedge words. All four have the Status lifecycle. All four describe specific recipients in role-shaped language. They are well-formed contracts; they are just not KAV contracts. **Era 2 - the early-KAV era (3 files):** Files written between v0.1.0 (Genesis, 2026-06-01) and v0.2.0 (the six-part gate, also 2026-06-01). These files have Q1, Q2, Q3 in KAV's shape, but do not have "What we don't break" because that section was added after they were written. Category 2 files: a new-platform-scoping document (REDACTED_PROJECT_BELLWETHER), an external-data-resources catalog (REDACTED_DIR_RESOURCES), a fundraising-event speech preparation (REDACTED_NONPROFIT_EVENT_SPEECH). The speech preparation file is the smallest at 3,355 bytes - a one-page contract for a five-minute speech - and is the cleanest example of KAV applied to a non-software domain. **Era 3 - the late-KAV era (5 files):** Files written under v0.2.x (six-part gate) or v0.3.x (Value Statement + Q0). These files have the full anatomy: Value Statement at the top, Q1/Q2/Q3, Promises with Status, "What we don't promise", "What we don't break." Category 3 files: a custom LLM-CLI client (REDACTED_CLIENT), a written submission to an industry publication (REDACTED_PUBLICATION_SUBMISSION), a directory of RFP portals for sales prospecting (REDACTED_RFP_DIRECTORY), a demo-preparation file for a product team's prospect demo (REDACTED_DEMO_50_QUERIES), a workspace documentation contract (REDACTED_DOCS). The pattern of adoption is clean: every file authored after v0.3.0 has the Value Statement section, including in domains as different as a CLI tool and a documentation directory. ### The hedge-word gate held Nine of twelve files had zero hedge words. Three files had one hedge word each. None had more than one. The standard's central rule - no "maybe", no "kind of", no "ish" - held across 75% of the field unconditionally. This is the cleanest signal in the audit. The discipline produces files that pass the discipline's strictest check. ### The em-dash gate held less cleanly Seven of twelve files had zero em-dashes. Five had between 1 and 47. The largest violators were the pre-KAV files (Era 1) where the standard's ASCII-hyphen rule did not yet exist. Among files written after v0.2.x added the dash gate, conformance is much cleaner. This is field evidence that adding a gate produces conformance to that gate in subsequent files. ### Specific recipients beat vague recipients Across the 12 files, the standard's Q1 was answered with a specific role in 11 of 12 cases. The one exception was an Era 1 file where the recipient is described at a higher level of generality. The "users / the team / everyone" failure mode the standard explicitly warns against did not appear in any of the files written after v0.1.0. This is the cleanest version of the standard's core discipline visible in the field. ### Shipment evidence Five of twelve projects have shipped code (Python, TypeScript, shell, or a populated src/lib/app directory). Six of twelve have a sibling README. The other files describe artifacts that are not shipped code: a speech, a written submission, a directory, a documentation contract. The standard is not exclusively a software tool in this field; it is being applied across writing, speaking, sales operations, and documentation projects. --- ## What this audit DOES establish - **The standard's evolution is visible in the artifacts.** Files written under v0.1.0 do not have the Value Statement. Files written under v0.2.0 do not have "What we don't break." Files written under v0.3.0 have both. The standard is being applied as it evolves, not retrofitted backward. - **The hedge-word gate holds in the field.** Three-quarters of files pass with zero hedge words. The standard's strictest rule survives contact with real authoring. - **The standard travels beyond software.** Files in the audit cover a fundraising-event speech, a written publication submission, a sales-prospecting directory, and a docs-vault contract - in addition to the software projects. - **Specific recipients beat vague ones.** The Q1 discipline produced role-shaped recipient language in 11 of 12 files. The "users / everyone" filler the standard warns against did not appear post-v0.1.0. ## What this audit DOES NOT establish - That every VALUE.md in the field is well-written. Several files have hedge words (rare) or em-dashes (more common in pre-dash-gate files). The audit measures conformance to the gate, not the underlying quality of the contract. - That the projects with VALUE.md files actually delivered the value they named. The audit measures the file, not the outcome. Whether the recipient named in Q1 actually got the change in Q2 is the paired-run question that remains unanswered. - That the standard would survive adoption by anyone other than the author. Every file in this audit was authored by the same person. External-builder evidence still requires the paired-run experiment. - That the four Era-1 files (using the deprecated workspace standard) would conform to KAV if rewritten today. They were authored under different rules; the audit's finding that they "fail" the KAV gate is not evidence against KAV. --- ## How this compares to Case Study 01 Case Study 01 (conversation-transcript analysis) measured whether build-trap signals dropped after VALUE.md adoption. It found a clean positive signal for the standard's own development (Pair 1) and mixed-to-negative results for a deep retrofit (Pair 2). Case Study 02 measures something different: whether the VALUE.md files that exist conform to the standard's own rules. Case 01 asked "did adoption change the conversation?" Case 02 asks "do the files conform?" Both findings are needed for the v1.0 field-evidence package: - Case 01: adoption changes how the author talks, at least for greenfield work. - Case 02: the standard's evolution is visible in 12 produced artifacts, and the gate's strictest rules (no hedges, specific recipients) hold in three-quarters of cases. Neither study substitutes for the Q3 paired-run experiment. Together they constitute the strongest available field evidence, and they are honest about what they do and do not show. --- ## Caveats and limits - **One author.** All 12 VALUE.md files were authored by the same person across a 7-day window. External-builder field evidence is still pending. - **Self-conformance bias.** The author wrote both the standard and the files. The files conforming to the standard is not surprising; the question is whether they would conform if written by a stranger. - **The KYAC files (Era 1) are not failures of KAV.** They conformed to a different workspace standard that predated KAV. Audit scores for those files should not be read as KAV defects. - **Aggregate numbers hide the era split.** "6 of 12 have all three questions" mixes pre-KAV files (which never had Q1/Q2/Q3) with KAV-era files (which all do). The era-breakdown above is the more honest read. --- ## Bundled with Case Study 01: the v1.0 field-evidence package Together, these two studies form the basis for shipping KAV v1.0 with field evidence rather than no evidence: 1. **Adoption-side evidence (Case 01):** the standard's own development shows the predicted build-trap-signal reduction. A retrofit case shows mixed results. The hypothesis sharpens: VALUE.md helps greenfield commitment, not deep retrofits. 2. **Artifact-side evidence (Case 02):** the field contains 12 VALUE.md files. The standard's evolution is visible in them. The gate's strictest rules hold in three-quarters of cases. The standard travels beyond software. This is not a substitute for the Q3 paired-run experiment, which remains the v1.0 → v1.1 gate. It is honest field evidence sufficient to ship v1.0 with the caveat openly named. --- ## Raw data `artifact-audit-raw.json` contains the per-file scoring with company / personal names redacted. Project paths are anonymized to category names.