docs: drop jargon, make repo docs descriptive

Replace 'carve'/'headline' throughout; reframe the front-facing docs
(README, spec drafts, related-work) to describe what the repo contains
and link to it rather than narrate the process. Process framing stays in
the decision log and the intent-comment/sep-disposition planning docs.
Live SEP-1913/SEP-2061 comments updated to match.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

README.md

@@ -38,41 +38,41 @@ See [docs/decisions.md](docs/decisions.md) for the decision record and
 
 | Identifier | Status | What it specifies | Reference implementation(s) |
 | :--- | :--- | :--- | :--- |
-| [`io.modelcontextprotocol/trust-annotations`](specification/draft/trust-annotations.mdx) | Draft skeleton | **Headline.** A small, scheme-agnostic client-facing data-classification vocabulary (`sensitive`, `untrusted`) on result `_meta`, plus an optional `evidenceRef` pointer slot that carries richer payloads out-of-band. | Python SDK: [`kapil8811/mcp-trust-annotations`](https://github.com/kapil8811/mcp-trust-annotations) (138-test suite, healthcare demo, LLM usability study). |
+| [`io.modelcontextprotocol/trust-annotations`](specification/draft/trust-annotations.mdx) | Draft skeleton | **Primary extension.** A small, scheme-agnostic client-facing data-classification vocabulary (`sensitive`, `untrusted`) on result `_meta`, plus an optional `evidenceRef` pointer slot that carries richer payloads out-of-band. | Python SDK: [`kapil8811/mcp-trust-annotations`](https://github.com/kapil8811/mcp-trust-annotations) (138-test suite, healthcare demo, LLM usability study). |
 | [`io.modelcontextprotocol/action-metadata`](specification/draft/action-metadata.mdx) | Draft skeleton | `inputMetadata` / `returnMetadata` / outcome classifiers (incl. `requires_review`) on `ToolAnnotations`, describing where inputs go, where outputs originate, and what real-world effects a tool can cause. | Carries forward [SEP-2061 (Action Security Metadata)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2061) by [@rreichel3](https://github.com/rreichel3); reference impl per that proposal (`read_drafts` / `list_inbox` / `send_email`). |
 | [`io.modelcontextprotocol/ifc-fides`](specification/draft/ifc-fides.mdx) | Draft skeleton | A **profile** of the `trust-annotations` `evidenceRef` slot: `type: "ifc.fides.v1"` carrying an integrity + confidentiality label for deterministic information-flow control, following the FIDES paper ([arXiv:2505.23643](https://arxiv.org/abs/2505.23643)). | Emitter candidate: [`github-mcp-server`](https://github.com/github/github-mcp-server) (does not emit IFC labels today — closing that gap is the proof point). |
 
-### Why FIDES is a profile, not the headline
+### Why FIDES is a profile, not a top-level extension
 
-An earlier sketch made information-flow control the top-level extension. That
+Information-flow control is modelled as a profile rather than the namespace
-was the wrong cut: it bakes one academic model (an integrity × confidentiality
+root because IFC (an integrity × confidentiality lattice) is one enforcement
-lattice) into the namespace root and silently forecloses the other enforcement
+model among several that reviewers raised — capability tokens, caller/tool
-models reviewers raised — capability tokens, caller/tool cosigning, and
+cosigning, and sequence-shape audit records. A top-level `ifc/` root would bake
-sequence-shape audit records. As one reviewer put it, IFC "fits relatively well
+one academic model into the namespace and foreclose the others. As one reviewer
-if you use annotations" — an endorsement of IFC *as a profile*, not as the wire
+put it, IFC "fits relatively well if you use annotations" — an endorsement of
-root. Demoting it to a `type` value under `trust-annotations`'s open-ended
+IFC *as a profile*, not as the wire root. As a `type` value under
-`evidenceRef` slot keeps the FIDES work first-class while leaving room for every
+`trust-annotations`'s open-ended `evidenceRef` slot, the FIDES work stays
-other model to occupy the same slot.
+first-class while every other model can occupy the same slot.
 
 ## Relationship to SEP-1913
 
 SEP-1913 remains the canonical place to discuss the overall problem framing.
-This repo carves the schema-bearing parts of that proposal into independently
+This repository develops the schema-bearing parts of that proposal as
-shippable pieces. When an extension here is ready to graduate, an Extensions
+independently shippable extensions. When an extension here is ready to graduate,
-Track SEP can reference this repo as the prior art and the working
+an Extensions Track SEP can reference this repo as the prior art and the working
 implementation that SEP-2133 [requires](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2133-extensions.md#creation).
 
 For the full per-SEP plan — what happens to SEP-1913, SEP-2061, SEP-1862 and
 others, and the SEP-2127 refactor precedent — see
 [docs/sep-disposition.md](docs/sep-disposition.md).
 
-**Deliberately not carved here** (see [docs/open-questions.md](docs/open-questions.md)):
+**Out of scope for these extensions** (see [docs/open-questions.md](docs/open-questions.md)):
 
 - **`maliciousActivityHint`** — reviewer concerns are structural (it fires at
   `tools/resolve` before execution can produce evidence; a boolean is the wrong
   granularity for client UX; clients won't trust server self-attestation). If it
-  returns, it is per-`ContentBlock` with spans, on a different clock. Parked on
+  returns, it is per-`ContentBlock` with spans, on a different clock. It stays
-  the SEP-1913 umbrella as a known cut item.
+  on the SEP-1913 umbrella rather than in an extension here.
 - **Propagation rules** — sensitivity escalation across session boundaries, and
   the sequence-shape gap (an annotation surface for "this was call N in a
   flagged sequence") remain open. Likely a future extension once the taxonomy

docs/decisions.md

@@ -3,7 +3,7 @@
 Append-only record of design decisions for the Tool Annotations IG's trust /
 privacy extension work. Newest at the bottom.
 
-## 2026-06-10 — Carve SEP-1913 into independent extensions
+## 2026-06-10 — Split SEP-1913 into independent extensions
 
 **Decision.** Split the schema-bearing parts of SEP-1913 into separate
 experimental extensions, each with its own `io.modelcontextprotocol/…`
@@ -17,13 +17,13 @@ clock and avoid hard-to-remove schema.
 
 ## 2026-06-10 — Three initial extensions
 
-**Decision.** `trust-annotations` (headline), `action-metadata`, `ifc-fides`.
+**Decision.** `trust-annotations` (primary), `action-metadata`, `ifc-fides`.
 
 **Rationale.** These are the three pieces with either a reference implementation
 or an existing SEP behind them: Kapil's SDK, SEP-2061 (Reichel), and the FIDES
 model respectively.
 
-## 2026-06-10 — FIDES is a profile, not the headline
+## 2026-06-10 — FIDES is a profile, not a top-level extension
 
 **Decision.** Information-flow control is `type: "ifc.fides.v1"`, a profile of
 the `trust-annotations` `evidenceRef` slot — not a top-level `io.modelcontextprotocol/ifc`
@@ -65,7 +65,7 @@ change.
 
 ## 2026-06-10 — Parked: maliciousActivityHint, propagation rules
 
-**Decision.** Neither is carved into an extension now; both stay on the SEP-1913
+**Decision.** Neither becomes an extension now; both stay on the SEP-1913
 umbrella.
 
 **Rationale.** `maliciousActivityHint` has unresolved structural objections

docs/intent-comment.md

@@ -12,14 +12,14 @@ Kept here so it can be reviewed and stays in sync with
 ## For SEP-1913
 
 > **Intent: split this SEP and migrate to the Extensions Track**
->
+> >
 > A note on direction for everyone following this thread. When SEP-1913 was
 > first framed, the **Extensions Track** (SEP-2133) and the `experimental-ext-*`
 > incubation process didn't exist in their current form. They now do, and
 > they're a better fit for this work than a single Standards Track SEP.
->
+> >
 > Two things pushed us here:
->
+> >
 > - @localden's review ask for a **narrower first cut** — the concern that a
 >   broad taxonomy with array-or-scalar polymorphism is hard to remove or change
 >   once it lands.
@@ -27,26 +27,26 @@ Kept here so it can be reviewed and stays in sync with
 >   [May 28 decision](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2820)
 >   to pursue trust/privacy as an **experimental extension first**, gather
 >   adoption evidence, then ask core maintainers to absorb anything.
->
+> >
-> So the plan is to **carve this proposal into a few small,
+> So the plan is to \*\*split this proposal into a few small,
-> independently-shippable extensions**, each with its own
+> independently-shippable extensions\*\*, each with its own
 > `io.modelcontextprotocol/…` identifier, reference implementation, and path to
 > an Extensions Track SEP. Incubation is in
 > [`experimental-ext-tool-annotations`](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations).
->
+> >
 > Kicking off with a few draft extensions in the tool annotations repo — not
 > sure yet whether they'd each need separate repos eventually, or whether
 > grouping them in one is fine. That's part of what incubation is for.
->
+> >
 > | Extension | Scope |
 > |---|---|
 > | `trust-annotations` | The narrow data-classification taxonomy (`sensitive`, `untrusted`) + an open-ended `evidenceRef` pointer for richer, out-of-band evidence. |
 > | `action-metadata` | Tool I/O + outcome contract (folds in @rreichel3's SEP-2061). |
 > | `ifc-fides` | Information-flow control ([arXiv:2505.23643](https://arxiv.org/abs/2505.23643)) as **one profile** of `evidenceRef`, not a wire root — the public/private-repo confidentiality case, with github-mcp-server as an emitter example. |
->
+> >
 > Deliberately removed: `maliciousActivityHint` (the structural concerns raised
 > here are unresolved) and session-level propagation rules.
->
+> >
 > This follows the same Standards-Track → Extensions-Track refactor pattern as
 > SEP-2127 (#2893). This PR will eventually pivot to the `trust-annotations`
 > piece itself, with the other schema-bearing pieces moving out into their own
@@ -58,4 +58,4 @@ Kept here so it can be reviewed and stays in sync with
 
 ## For SEP-2061 (coordination note)
 
-> @rreichel3 — carving this out into an independent extension as discussed: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4675047154
+> @rreichel3 — splitting this out into an independent extension as discussed: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913#issuecomment-4675047154

docs/open-questions.md

@@ -36,7 +36,7 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal.
 - GitHub Enterprise `internal` repo visibility → public/private/reader-set
   mapping (audience is the whole org, broader than collaborators).
 
-## Parked (SEP-1913 umbrella, not carved)
+## Parked (SEP-1913 umbrella)
 
 - **`maliciousActivityHint`** — if it returns, it is per-`ContentBlock` with
   spans, driven by the host's own detection, not a server-attested boolean.

docs/related-work.md

@@ -5,7 +5,7 @@ annotation work. Several were surfaced in IG meetings (notably 2026-05-28).
 
 ## SEPs
 
-- [SEP-1913 — Trust and Sensitivity Annotations](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913) — the umbrella this work carves from.
+- [SEP-1913 — Trust and Sensitivity Annotations](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913) — the umbrella proposal these extensions derive from.
 - [SEP-2061 — Action Security Metadata](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2061) — carried forward as `action-metadata`.
 - [SEP-1862 — Tool Resolution / pre-flight checks](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1862) — core-protocol, composes with these extensions.
 - [SEP-2133 — Extensions](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2133-extensions.md) — the framework this repo incubates under.

docs/sep-disposition.md

@@ -25,7 +25,7 @@ form. Two inputs since then point at a different shape:
    adoption/evidence base, and only then ask core maintainers to absorb
    anything into the protocol.
 
-The result: carve the schema-bearing parts into small, independent extensions,
+The result: split the schema-bearing parts into small, independent extensions,
 each able to graduate on its own clock.
 
 ## The precedent: SEP-2127 (Server Cards)
@@ -50,7 +50,7 @@ We apply the same playbook below.
 ### SEP-1913 — Trust and Sensitivity Annotations
 
 **Proposed:** becomes the **umbrella / problem-framing** thread. The schema-
-bearing content is carved out into the extensions below. Options, in order of
+bearing content moves into the extensions below. Options, in order of
 preference:
 
 - **(A, preferred)** Keep the PR open as the framing umbrella; add an intent
@@ -62,8 +62,8 @@ preference:
 - **(C)** Close 1913 outright and open three fresh Extensions Track SEPs. Loses
   the discussion history's continuity; not preferred.
 
-**Carved out:** `trust-annotations`, `action-metadata`, `ifc-fides`.
+**Moved into extensions:** `trust-annotations`, `action-metadata`, `ifc-fides`.
-**Parked on the umbrella (not carved):** `maliciousActivityHint`,
+**Parked on the umbrella:** `maliciousActivityHint`,
 session-level propagation rules. See [open-questions.md](./open-questions.md).
 
 ### SEP-2061 — Action Security Metadata
@@ -73,7 +73,7 @@ extension. SEP-2061 is by [@rreichel3](https://github.com/rreichel3), who is
 also an IG co-facilitator and SEP-1913 co-author, so this is a fold-in, not a
 collision. Disposition mirrors 1913 option (A): keep the thread as the field-
 semantics discussion, add a pointer comment linking it to the
-`action-metadata` carve, refactor to Extensions Track when ready.
+`action-metadata` extension, refactor to Extensions Track when ready.
 
 ### SEP-1862 — Tool Resolution (pre-flight checks)
 
@@ -86,8 +86,8 @@ with it if it lands, but do not block on it.
 ### Other related SEPs (not owned here)
 
 - **SEP-1984 (Comprehensive Tool Annotations)**, **SEP-2417 (Model Preferences
-  for Tools)** — tracked by the IG as discussion items; not part of this carve.
+  for Tools)** — tracked by the IG as discussion items; not part of these
-  Cross-link only.
+  extensions. Cross-link only.
 - **SEP-2787 (Tool Call Attestation)** and the various attestation/evidence
   threads — these are natural `evidenceRef` *profile* candidates rather than
   competitors. Coordinate so the `evidenceRef.type` registry can list them.
@@ -96,7 +96,7 @@ with it if it lands, but do not block on it.
 
 | SEP | Title | Proposed disposition | Extension home |
 | :-- | :-- | :-- | :-- |
-| 1913 | Trust & Sensitivity Annotations | Umbrella thread; carve schema out | `trust-annotations` (+ `ifc-fides`) |
+| 1913 | Trust & Sensitivity Annotations | Umbrella thread; schema moves to extensions | `trust-annotations` (+ `ifc-fides`) |
 | 2061 | Action Security Metadata | Fold into extension | `action-metadata` |
 | 1862 | Tool Resolution (pre-flight) | Stays core / Standards Track | — (composes, no dependency) |
 | 1984 | Comprehensive Tool Annotations | IG discussion item | — |

specification/draft/ifc-fides.mdx

@@ -26,17 +26,16 @@ protocol or into the `trust-annotations` wire surface.
 
 ## Why a profile
 
-An earlier sketch proposed information-flow control as a top-level extension
+Information-flow control is one enforcement model among several that reviewers
-(`io.modelcontextprotocol/ifc`). That was the wrong cut. IFC is **one**
+of SEP-1913 raised — capability tokens, caller/tool cosigning, and
-enforcement model among several that reviewers of SEP-1913 raised — capability
+sequence-shape audit records were all put forward. A top-level extension
-tokens, caller/tool cosigning, and sequence-shape audit records were all put
+(`io.modelcontextprotocol/ifc`) would make the FIDES integrity × confidentiality
-forward. Making the FIDES integrity × confidentiality lattice the namespace
+lattice the namespace root and silently foreclose those other models.
-root would silently foreclose those.
 
-Carrying it as a `type` value under the open-ended `evidenceRef` slot keeps the
+As a `type` value under the open-ended `evidenceRef` slot, the FIDES label is
-FIDES work first-class while leaving the slot free for every other model. One
+first-class while the slot stays free for every other model. One reviewer's
-reviewer's framing captured it: IFC "fits relatively well *if you use
+framing captured it: IFC "fits relatively well *if you use annotations*" — an
-annotations*" — an endorsement of IFC as a profile, not as the wire root.
+endorsement of IFC as a profile, not as the wire root.
 
 ## Motivation
 

specification/draft/trust-annotations.mdx

@@ -20,9 +20,10 @@ related:
 This extension defines a small, stable, scheme-agnostic vocabulary for
 classifying **data in transit** through MCP tool results, plus an optional
 `evidenceRef` pointer that lets a deployment attach richer, out-of-band
-evidence without growing the on-wire schema. It is the headline extension of
+evidence without growing the on-wire schema. It is the primary
-the Tool Annotations IG's trust work; other extensions (information-flow
+data-classification extension in the Tool Annotations IG's trust work; other
-control, action metadata) compose with it rather than duplicating it.
+extensions (information-flow control, action metadata) compose with it rather
+than duplicating it.
 
 The design follows the [@localden](https://github.com/localden) review steer on
 SEP-1913 — take a *narrow first cut* of the taxonomy and avoid hard-to-remove