Simplify policy wording while preserving explicit safeguards

docs/adoption.md

@@ -21,13 +21,11 @@ templates themselves, use the [contributor guide](development.md).
 
 Select an upstream commit and read the policies relevant to the requested work.
 Use a revision containing the [project grant](../COPYRIGHT) and the reference
-assets you intend to use. Record its full commit identifier; a moving branch
-name is not an adoption baseline. No package manager or automatic update service
-is required.
+assets you intend to use. Record its full commit identifier as the adoption
+baseline. Git records are sufficient to maintain adoption provenance.
 
-Preserve existing downstream decisions and unrelated changes. Adoption is a
-local customization task, not authorization to add every capability, document,
-restriction, or release gate mentioned in the templates.
+Preserve existing downstream decisions and unrelated changes. Customize selected
+policies to existing project responsibilities and the author's requested scope.
 
 ## Copy And Customize
 
@@ -35,10 +33,9 @@ restriction, or release gate mentioned in the templates.
    downstream locations.
    Follow each template's adoption instructions and remove its `Base Policy
    Template` section afterward. Create supporting documents when they have useful
-   content for an existing responsibility, rather than filling an empty outline.
+   content for an existing responsibility.
 2. Tailor architecture to the actual project. Preserve the author's selected
-   license and existing application contracts. Do not infer new product behavior
-   from policy examples.
+   license and existing application contracts.
 3. Retain each document's `Base Policy Version` and set `Last Updated` to the
    local adoption date. Add `Upstream Source` metadata linking to that specific
    document at the selected commit. Retain this provenance in future edits.
@@ -90,8 +87,8 @@ there; the documentation policy remains the owner of the documentation topic map
 ## Attribute Copied Policies
 
 Use the [canonical attribution entry](../examples/licensing/policy-attribution.md)
-in the downstream `docs/oss/attribution.md`. It is an entry fragment to insert
-beneath that document's existing title, not an additional document title.
+by inserting it beneath the existing title in the downstream
+`docs/oss/attribution.md`.
 
 - Replace `UPSTREAM_COMMIT` with the selected full commit in all three URLs.
 - Adjust the `Material:` sentence to identify the files actually copied. Keep
@@ -134,7 +131,7 @@ Original example formatting is available under CC0 as specified in
 attribution entry for this project.
 
 Keep links to these examples in the adopted policy pointed at upstream commits.
-Do not populate the downstream `examples/` directory with this collection.
+Keep the example collection upstream and use it to create actual project notices.
 Copy the applicable standard license texts into the actual local license files;
 retain their wording and their own terms. Those copies remain necessary under
 the House Format even though example documents stay upstream.
@@ -147,30 +144,27 @@ When asked to check the policy set and recommend updates:
    `Base Policy Version`, and local customizations. Different documents may have
    different adoption baselines.
 2. Inspect upstream `main` and record its full commit identifier. Use that fixed
-   revision for the review so later upstream changes do not shift the comparison.
+   revision throughout the comparison.
 3. Compare each recorded upstream file with its counterpart at the review
    revision, then assess the upstream changes against the locally customized
    policy. Version labels help orientation; inspect the actual differences.
    Note new, renamed, or removed upstream policies where relevant to the project.
 4. Recommend applicable changes with their reasons, identify conflicts with
    deliberate local choices, and name policies that need no update. Include the
-   baseline and review revisions so the comparison can be reproduced. Do not
-   recommend wholesale replacement merely because upstream differs.
-5. If a baseline is missing or unavailable, report the uncertainty. You may
-   compare available content, but do not assume the local policy is an unchanged
-   upstream copy or invent an adoption revision. If upstream cannot be reached,
-   report that limitation rather than claiming the policies are current.
+   baseline and review revisions so the comparison can be reproduced. Ground
+   recommendations in the local project's needs.
+5. Base provenance claims on available evidence. Report missing or unavailable
+   baselines explicitly and qualify comparisons accordingly. Report upstream
+   access failures and the resulting limits on the review.
 
-For a recommendation-only request, leave files and adoption metadata unchanged.
-A completed review does not mean a newer policy has been adopted. Apply the
-following procedure when implementation is requested.
+For a recommendation-only request, preserve the current files and adoption
+metadata. Apply the following procedure when implementation is requested.
 
 ## Update Deliberately
 
 Compare the previously recorded upstream files with a selected newer revision.
-Apply relevant changes while preserving local decisions; do not overwrite
-customized documents wholesale or treat every upstream recommendation as a new
-local requirement.
+Apply relevant changes while preserving local decisions and selecting updates
+that serve the project.
 
 Update `Base Policy Version` when adopting a newer template version and update
 `Upstream Source` to the revision actually incorporated. Change `Last Updated`
@@ -178,7 +172,7 @@ when revising the local document. Keep the material description, modification
 status, and attribution links accurate. If documents use different upstream
 revisions, retain each file's exact source metadata and include the necessary
 commit-specific source and notice links in the single project attribution entry.
-Do not change a source reference to a version that was merely reviewed.
+Update source references when the corresponding upstream changes are incorporated.
 
 Ordinary review should check the resulting rules, attribution facts, and affected
 links. A commit-based adoption record is sufficient; no recurring synchronization