docs/adr/20261023T214738672Z-adopt-a-checked-format-for-adrs-and-implementation-plans.md

@@ -40,7 +40,7 @@ We need one format that people and tools can write without surprises, that separ
 
 ## Decision Outcome
 
-Chosen option: "Define one format and implement one shared Go CLI that creates and checks records", because it is the only option that gives a single enforced vocabulary and identity scheme while keeping the checks dependency-free.
+Chosen option: "Define one format and implement one shared Go CLI that creates and checks records", because it is the only option that gives a single enforced vocabulary and identity scheme while keeping the checks free of service dependencies.
 
 The format is specified in [docs-format](/docs/docs-format.md). It uses the MADR 4 layout, with `### Consequences` under Decision Outcome made mandatory, and adds the parts MADR leaves open: timestamp-based permanent IDs in filenames, a fixed frontmatter schema, a separate `implementation` field, reciprocal supersession, durable repo-root references, and a plan record with its own lifecycle. The CLI, `docs`, offers `docs new adr|plan` and `docs check`.
 
@@ -73,7 +73,7 @@ The format is specified in [docs-format](/docs/docs-format.md). It uses the MADR
 ### Define one format and implement one shared Go CLI that creates and checks records
 
 * Good, because one specification and one implementation can be tested thoroughly and installed with `go install`.
-* Good, because the same binary creates records, so new files start valid.
+* Good, because the same binary creates records, so new files start with the required structure.
 * Bad, because we commit to maintaining a small public tool and a specification.
 
 ## More Information