conformance: worked emitter/consumer cases for trust-annotations

README.md

@@ -25,11 +25,14 @@ potential narrower first cut?" The subsequent design discussion converged on a
 layered answer: a small, stable annotation surface on the wire, with richer
 evidence kept out-of-band and referenced by a bounded pointer.
 
-This repo follows that steer. Each concern becomes a **separate experimental
-extension** with its own [reverse-DNS identifier](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2133-extensions.md#definition),
-its own reference implementation, and its own path to a future Extensions
-Track SEP. Drafts can graduate independently — directly addressing the "narrower
-first cut" ask without throwing away the combinatoric value of the full set.
+This repo follows that steer. The schema-bearing concerns become **separate
+experimental extensions**, each with its own [reverse-DNS identifier](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2133-extensions.md#definition),
+reference implementation, and path to a future Extensions Track SEP, so drafts
+can graduate independently. The concrete data-labelling models that fill an
+extension's evidence slot are kept separate again — as interchangeable **schemes**
+rather than extensions — so no single academic model is baked into the wire. This
+directly addresses the "narrower first cut" ask without throwing away the
+combinatoric value of the full set.
 
 See [docs/decisions.md](docs/decisions.md) for the decision record and
 [docs/trust-model.md](docs/trust-model.md) for the shared enforcement model.
@@ -40,19 +43,42 @@ See [docs/decisions.md](docs/decisions.md) for the decision record and
 | :--- | :--- | :--- | :--- |
 | [`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. | Originally [SEP-2061 (Action Security Metadata)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2061) by [@rreichel3](https://github.com/rreichel3) — closed 2026-06-13 in favour of this extension; worked example `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 a top-level extension
-
-Information-flow control is modelled as a profile rather than the namespace
-root because IFC (an integrity × confidentiality lattice) is one enforcement
-model among several that reviewers raised — capability tokens, caller/tool
-cosigning, and sequence-shape audit records. A top-level `ifc/` root would bake
-one academic model into the namespace and foreclose the others. As one reviewer
-put it, IFC "fits relatively well if you use annotations" — an endorsement of
-IFC *as a profile*, not as the wire root. As a `type` value under
-`trust-annotations`'s open-ended `evidenceRef` slot, the FIDES work stays
-first-class while every other model can occupy the same slot.
+Each extension is proposed in its own pull request so it can be reviewed and
+graduate on its own clock.
+
+## Data-labelling schemes (the `evidenceRef` slot)
+
+The extensions above keep the wire vocabulary deliberately small. Richer
+labelling lives **out-of-band**, referenced by the `trust-annotations`
+[`evidenceRef`](specification/draft/trust-annotations.mdx) pointer, whose `type`
+is an open string. A **scheme** is a concrete data-labelling or tool-annotation
+approach that fills that slot under a `type` value. A scheme is **not** an
+extension and not a sibling of the two above — it is one interchangeable way to
+populate the evidence an extension carries, and a deployment can adopt, swap, or
+ignore it without touching the extension.
+
+The [`schemes/`](schemes/) folder collects these approaches. **FIDES** is the
+first worked example, defining `ifc.fides.v1`; it is one model among several that
+reviewers and the literature have raised, and the slot is designed so any of them
+can occupy it:
+
+| Scheme | `evidenceRef.type` | Source |
+| :--- | :--- | :--- |
+| FIDES information-flow control (integrity × confidentiality lattice) | `ifc.fides.v1` | [arXiv:2505.23643](https://arxiv.org/abs/2505.23643); emitter candidate [`github-mcp-server`](https://github.com/github/github-mcp-server) |
+| Coarse data classification (4-level + regulatory scope) | `data-class.v1` | SEP-1913 taxonomy |
+| Design-pattern controls (Plan-Then-Execute, Dual LLM, Map-Reduce) | _candidate_ | [arXiv:2506.08837](https://arxiv.org/abs/2506.08837) |
+| Capability-token constraints (SINT) | _candidate_ | pshkv, [SEP-1913 thread](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1913) |
+| Caller/tool cosigning | _candidate_ | viftode4, SEP-1913 thread |
+| Sequence-shape audit records | _candidate_ | marras0914, SEP-1913 thread |
+| Tool-call attestation (in-toto / OVERT envelopes) | _candidate_ | [SEP-2787](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2787) |
+
+Modelling IFC as a scheme rather than a namespace root is deliberate: a top-level
+`ifc/` extension would bake one academic model into the wire and foreclose the
+others. As one reviewer put it, IFC "fits relatively well if you use annotations"
+— an endorsement of IFC *behind* the annotation slot, not as the slot itself. See
+[`schemes/README.md`](schemes/README.md) for the full list and the bar for adding
+a scheme.
 
 ## Relationship to SEP-1913
 
@@ -84,7 +110,8 @@ This repo mirrors the structure of official extension repositories such as
 [`ext-auth`](https://github.com/modelcontextprotocol/ext-auth):
 
 ```
-specification/draft/<extension-name>.mdx   # one spec per extension
+specification/draft/<extension-name>.mdx   # one spec per extension (trust-annotations, action-metadata)
+schemes/                                    # data-labelling schemes that fill the evidenceRef slot (FIDES, …)
 docs/                                       # decision log, open questions, related work
 MAINTAINERS.md                              # IG facilitators
 ```

docs/decisions.md

@@ -89,3 +89,31 @@ Resolution. SEP-1862 remains a core/Standards-Track protocol change.
 
 **Rationale.** The 2026-05-28 IG meeting concluded pre-flight is inherently a
 protocol-level change, not an extension.
+
+## 2026-06-16 — FIDES is a scheme, not a sibling extension
+
+**Decision.** Refines the 2026-06-10 "FIDES is a profile" decision. The IFC/FIDES
+work moves out of `specification/draft/` (where it sat next to the two
+extensions) into a `schemes/` folder. There are **two** extensions
+(`trust-annotations`, `action-metadata`); FIDES is **one data-labelling scheme**
+(`ifc.fides.v1`) that fills the `trust-annotations` `evidenceRef` slot.
+
+**Rationale.** FIDES is one model the extension *could* use, not a peer of the
+extensions, and must not be presented as a sibling. The original SEP cites it
+alongside ShardGuard and "Design Patterns for Securing LLM Agents," and the
+SEP-1913 thread adds capability tokens, cosigning, sequence-shape, and
+attestation models — so `schemes/` is a folder for interchangeable approaches,
+with FIDES as the first worked one. This shows the range the open `evidenceRef`
+slot is meant to carry rather than implying IFC is the privileged model.
+
+## 2026-06-16 — Three pull requests, stacked
+
+**Decision.** The work ships as three PRs: `trust-annotations` (the base,
+carrying shared repo scaffolding), `action-metadata` (stacked on the base), and
+the FIDES scheme in `schemes/` (stacked on the base). The two extensions are
+independent; the FIDES scheme depends on `trust-annotations` because it fills
+that extension's `evidenceRef` slot.
+
+**Rationale.** Separate PRs let each piece be reviewed and graduate on its own
+clock. FIDES stacks on `trust-annotations` because a scheme has no meaning
+without the slot it fills.

docs/intent-comment.md

@@ -35,25 +35,37 @@ in sync with [sep-disposition.md](./sep-disposition.md).
 > 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.
+> It's now scaffolded as \*\*two extensions plus a `schemes/` folder\*\* of
+> interchangeable data-labelling approaches, shipped as a stacked set of PRs:
+> >
+> - [#2](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations/pull/2) — repo scaffolding + the `trust-annotations` extension (the base).
+> - [#3](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations/pull/3) — the `action-metadata` extension.
+> - [#4](https://github.com/modelcontextprotocol/experimental-ext-tool-annotations/pull/4) — FIDES as a data-labelling \*\*scheme\*\* under `schemes/`.
 > >
 > | 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. |
+> >
+> \*\*Data-labelling schemes (the `evidenceRef` slot).\*\* Richer evidence models
+> are \*not\* extensions and \*not\* a wire root. They live in `schemes/` as
+> interchangeable fillers of the `trust-annotations` `evidenceRef` slot, each
+> selected by an `evidenceRef.type` value, so a deployment can adopt one, several,
+> or none without changing the extension. FIDES information-flow control
+> ([arXiv:2505.23643](https://arxiv.org/abs/2505.23643)) is the first worked scheme
+> (`ifc.fides.v1`) — the public/private-repo confidentiality case, with
+> github-mcp-server as an emitter example. The folder is built to hold the range of
+> other models raised in review (coarse data classification, design-pattern
+> controls, capability tokens, cosigning, sequence-shape, attestation).
 > >
 > 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
-> extensions. Everything is still in the incubation phase, so naming, design,
-> and the choice of what to put forward as an extension are all open for
-> discussion in the IG.
+> SEP-2127 (#2893). This PR is now the `trust-annotations` base of the stack; the
+> `action-metadata` extension and the `schemes/` folder are stacked on it.
+> Everything is still in the incubation phase, so naming, design, and the choice of
+> what to put forward as an extension are all open for discussion in the IG.
 
 ---
 

docs/open-questions.md

@@ -30,7 +30,7 @@ Tracked here rather than in the spec drafts, so the drafts stay non-temporal.
 - Open strings vs. closed enums for `destination` / `source` / `sensitivity`.
 - Does `requiresReview` need a machine-readable *reason* for good client UX?
 
-## ifc-fides
+## ifc-fides (scheme)
 
 - Inline `_meta.ifc` for low-friction adoption vs. always behind `evidenceRef`.
 - GitHub Enterprise `internal` repo visibility → `public`/`private` mapping

docs/related-work.md

@@ -10,19 +10,19 @@ annotation work. Several were surfaced in IG meetings (notably 2026-05-28).
 - [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.
 - [SEP-2127 — Server Cards](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2893) — precedent for the Standards→Extensions Track refactor.
-- [SEP-2787 — Tool Call Attestation](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2787) — candidate `evidenceRef` profile.
+- [SEP-2787 — Tool Call Attestation](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2787) — candidate `evidenceRef` scheme.
 
 ## Research
 
-- **FIDES** — *Information-flow control for LLM agents.* [arXiv:2505.23643](https://arxiv.org/abs/2505.23643). Basis for the `ifc.fides.v1` profile.
+- **FIDES** — *Information-flow control for LLM agents.* [arXiv:2505.23643](https://arxiv.org/abs/2505.23643). Basis for the `ifc.fides.v1` scheme in [`schemes/`](../schemes/).
 - **Design Patterns for Securing LLM Agents** — IBM/Google/Microsoft. [arXiv:2506.08837](https://arxiv.org/abs/2506.08837). Plan-Then-Execute, Dual LLM, Map-Reduce, etc.
 - **Trail of Bits** — prompt-injection via hidden content in GitHub issues. [blog](https://blog.trailofbits.com/2025/08/06/prompt-injection-engineering-for-attackers-exploiting-github-copilot/).
 - **OpenAI Auto Review** — https://alignment.openai.com/auto-review/ (shared in IG chat).
 
 ## Implementations & tooling
 
 - [`kapil8811/mcp-trust-annotations`](https://github.com/kapil8811/mcp-trust-annotations) — reference Python SDK PoC for `trust-annotations`.
-- [`github-mcp-server`](https://github.com/github/github-mcp-server) — public MCP server; emitter candidate for `ifc-fides` (knows repo visibility + collaborators).
+- [`github-mcp-server`](https://github.com/github/github-mcp-server) — public MCP server; emitter candidate for the `ifc-fides` scheme (knows repo visibility + collaborators).
 - **Ethyca** data-labeling docs — https://www.ethyca.com/docs (shared in IG chat).
 - **GitHub Next** agentic-workflows research on data labeling — to be documented as issues in this repo (IG action item, @gokhanarkan / @joannakl).
 
@@ -35,4 +35,4 @@ annotation work. Several were surfaced in IG meetings (notably 2026-05-28).
 - **Sequence-shape** policies — marras0914.
 
 These are exactly the models that `evidenceRef`'s open `type` is designed to
-accommodate as profiles.
+accommodate as schemes — see [`schemes/`](../schemes/).

docs/sep-disposition.md

@@ -62,7 +62,10 @@ preference:
 - **(C)** Close 1913 outright and open three fresh Extensions Track SEPs. Loses
   the discussion history's continuity; not preferred.
 
-**Moved into extensions:** `trust-annotations`, `action-metadata`, `ifc-fides`.
+**Moved into extensions:** `trust-annotations`, `action-metadata`.
+**Moved into `schemes/`:** the IFC/FIDES work, as one data-labelling **scheme**
+(`ifc.fides.v1`) that fills the `trust-annotations` `evidenceRef` slot — not an
+extension and not a sibling of the two above.
 **Parked on the umbrella:** `maliciousActivityHint`,
 session-level propagation rules. See [open-questions.md](./open-questions.md).
 
@@ -90,14 +93,14 @@ with it if it lands, but do not block on it.
   for Tools)** — tracked by the IG as discussion items; not part of these
   extensions. Cross-link only.
 - **SEP-2787 (Tool Call Attestation)** and the various attestation/evidence
-  threads — these are natural `evidenceRef` *profile* candidates rather than
+  threads — these are natural `evidenceRef` **scheme** candidates rather than
   competitors. Coordinate so the `evidenceRef.type` registry can list them.
 
 ## Mapping table
 
 | SEP | Title | Proposed disposition | Extension home |
 | :-- | :-- | :-- | :-- |
-| 1913 | Trust & Sensitivity Annotations | Umbrella thread; schema moves to extensions | `trust-annotations` (+ `ifc-fides`) |
+| 1913 | Trust & Sensitivity Annotations | Umbrella thread; schema moves to extensions | `trust-annotations` (+ `schemes/ifc-fides`) |
 | 2061 | Action Security Metadata | **Closed 2026-06-13**; lives as extension | `action-metadata` |
 | 1862 | Tool Resolution (pre-flight) | Stays core / Standards Track | — (composes, no dependency) |
 | 1984 | Comprehensive Tool Annotations | IG discussion item | — |

docs/trust-model.md

@@ -1,7 +1,7 @@
 # Trust model
 
-A single statement of the enforcement model shared by all extensions in this
-repository, so individual specs don't re-litigate it.
+A single statement of the enforcement model shared across this repository's
+extensions and data-labelling schemes, so individual specs don't re-litigate it.
 
 ## Annotations are claims, not guarantees
 
@@ -41,7 +41,7 @@ SEP-1913 thread): rather than blanket-blocking flows a policy engine is unsure
 about, **flag the specific call for user confirmation**. This preserves utility
 while keeping a human on the genuinely risky edges, and is the recommended
 default for `requiresReview` ([`action-metadata`](../specification/draft/action-metadata.mdx))
-and for IFC policy violations ([`ifc-fides`](../specification/draft/ifc-fides.mdx)).
+and for IFC policy violations (the [`ifc-fides`](../schemes/ifc-fides.md) scheme).
 
 ## Cross-domain is the hard case