State what the fleet model achieves, before the per-type rules

README.md

@@ -31,6 +31,7 @@ See [Release History][history] for the full history.
 ## Table of Contents <!-- omit from toc -->
 
 - [What This Repo Is](#what-this-repo-is)
+- [What It Achieves](#what-it-achieves)
 - [How This Repo Operates](#how-this-repo-operates)
 - [Rules](#rules)
   - [Always](#always)
@@ -65,6 +66,27 @@ This repo is the single home for those rules, a machine-readable spec they are c
 - **[catalog/][catalog]** - reusable reference snippets (workflow tasks, config exemplars, devcontainers) the audit compares implementations against.
 - **[reports/][reports]** - per-repo audit output.
 
+## What It Achieves
+
+Keeping a fleet of repositories consistent has always been a tax paid in review attention, and it stops scaling at the point where one person can no longer hold every repo in their head. An agent changes that arithmetic in both directions at once. It can apply a convention across every repository in an afternoon, and it can spread a mistake exactly as fast. What makes the speed worth having is a ground truth an agent can read, a gate that proves the result rather than reporting it, and a boundary naming the decisions that are never the agent's to make. Each objective below is a standing capability, with the machinery that delivers it named so the claim is checkable.
+
+- **Workflow consistency, by contract rather than by copy.** Every repo satisfies one behavioral CI/CD contract ([WORKFLOW.md][workflow], guarantees D1 to D9) instead of inheriting one YAML file it then edits. The fixed part is the orchestration seam, meaning job names, the ruleset-bound required check, and the artifact handoff. What a repo builds inside that seam is its own, so a Hugo site and a NuGet package satisfy the same contract without pretending to be the same pipeline.
+- **Technical consistency that does not depend on anyone remembering it.** One line-ending policy, one comment shape, one character set, one US-English convention, and one config per linter shared by the editor, the CLI, and CI. A rule that holds in review therefore holds on a laptop and in the pipeline, because all three read the same file rather than three copies that drift apart.
+- **Best practices promoted once, not re-litigated per repo.** A practice that proves itself becomes fleet law in [GOVERNANCE.md][governance] or [CODESTYLE.md][codestyle] and is carried, rather than being rediscovered and re-argued in the next repository. Every rule here traces to a specific failure that actually happened, which is why the collection is opinionated and small rather than exhaustive.
+- **Feedback loops that close on the procedure, not the instance.** [AUDIT.md][audit] reads a live repo and reports drift, the per-repo reports in [reports/][reports] record it, and a repo that cannot be stood up from the docs alone is a documentation defect tracked in the [conformance matrix][matrix]. When a downstream agent hits something the procedure did not cover, the fix lands in the procedure so the next repo never meets it.
+- **Onboarding a new language or deployment target is a spec change.** Thirteen project types are declared today in [spec/project-types.json][project-types]. Adding one means declaring its detection, its checks, and the files it carries, then proving a context-free agent can stand it up cold. No fleet-wide rewrite, and no per-repo improvisation.
+- **Re-deployment that is measured and traceable.** Versions come from git history through NBGV rather than a hand-edited number, a release is always a deliberate act and never a side effect of a merge, and staleness is detected by **content hash against the hub's own past revisions**, so the audit can say whether a repo is behind the canonical or has forked it. A version stamp is a claim a repo can keep while editing the content underneath, so it is never trusted for that answer.
+- **Every carried unit declares how much freedom it grants.** This is the distinction that makes the whole thing tolerable to work in, and it is a field on each [spec/files.json][files] entry rather than something a reader infers from the file's shape. An entry that names no level takes `presence`, the most permissive one, so silence grants freedom rather than withholding it:
+
+  | Level | The obligation | Who owns the content |
+  | --- | --- | --- |
+  | `verbatim` | Byte-identical to canonical, after governed normalization | The hub. A paraphrase is a defect, not an adaptation. |
+  | `interface` | Honor a named contract, checked by name and wiring | The repo owns the body entirely. |
+  | `intent` | Reach the same outcome, judged by meaning | The repo owns the wording and shape. |
+  | `presence` | The unit exists | The repo owns all of it. |
+
+- **The human contributes where domain expertise is decisive, and only there.** The maintainer keeps what an agent cannot know or must not decide: creating a repository, granting a write outside the owner boundary, changing a ruleset, approving every merge, and every judgment about the domain a repo actually serves. The agent takes the mechanical scale-out, which is the part that does not benefit from human attention and degrades under it. A repo's own knowledge also has a declared destination rather than an improvised one, chosen by what the content is: `CODESTYLE.md` for conventions beyond the carried rules, `ARCHITECTURE.md` for how a code repo is built, `OPERATIONS.md` for how a live-service repo is run, and `TODO.md` for its backlog. Which of those a repo carries follows from what it is, so this hub holds the two that apply to it. Domain expertise therefore lands somewhere declared instead of being diluted into a carried file that the next re-vendor overwrites.
+
 ## How This Repo Operates
 
 ProjectTemplate follows the same model it documents, and audits its own rules against itself (it classifies as the source-only project type in [WORKFLOW.md][workflow]).
@@ -148,17 +170,20 @@ See [LICENSE][license].
 <!-- Repo -->
 
 [agents]: ./AGENTS.md
-[governance]: ./GOVERNANCE.md
-[governance-branching-model]: ./GOVERNANCE.md#branching-model
-[governance-pr-review-etiquette]: ./GOVERNANCE.md#pr-review-etiquette
-[governance-running-the-linters-locally-known-working-invocations]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [audit]: ./AUDIT.md
 [catalog]: ./catalog/
 [codestyle]: ./CODESTYLE.md
 [devcontainer]: ./docs/devcontainer.md
+[files]: ./spec/files.json
+[governance]: ./GOVERNANCE.md
+[governance-branching-model]: ./GOVERNANCE.md#branching-model
+[governance-pr-review-etiquette]: ./GOVERNANCE.md#pr-review-etiquette
+[governance-running-the-linters-locally-known-working-invocations]: ./GOVERNANCE.md#running-the-linters-locally-known-working-invocations
 [history]: ./HISTORY.md
 [host-setup]: ./docs/host-setup.md
 [license]: ./LICENSE
+[matrix]: ./reports/conformance-matrix.md
+[project-types]: ./spec/project-types.json
 [readme-structure]: ./spec/readme-structure.md
 [repo-config]: ./repo-config/
 [reports]: ./reports/