experimental-ext-tool-annotations

These are the worked emitter/consumer cases from the #2 thread, now as runnable fixtures so the shape can be checked rather than asserted. Everything reproduces from alone. The first family is the public-repo-with-private-subresource case. A world-public repository still serves things that are not world-readable, like a draft security advisory or the collaborator roster, so the emitter classifies the resource it returns rather than the container. The coarse boolean rides the wire and the four-level class sits out of band on a . A world-readable resource makes no claim, unknown or mixed provenance classifies rather than defaulting to public from a repo-level shortcut, and a content-block annotation may refine a result-level claim but never weaken it. The second exercises re-derivation for the and types: the small annotation stays on the wire while the rich record lives out of band, and a client holding the record recomputes the digest independently. Each is shown under both and , and the same record under the two envelopes produces two distinct, each-recomputable digests, so neither canonicalization reads as the default. recomputes every digest from the committed records, checks the per-resource classification rule, and checks the content-block union semantics. There are no third-party dependencies: the JCS and canonical CBOR encoders are pure-Python and self-test against the RFCs' own published vectors before any digest is trusted. The value profile is restricted to strings, arrays, string-keyed maps, booleans, null and non-negative integers, so the float and number-format edge cases stay out of scope until the spec pins them. I targeted this at the scaffold branch so the fixtures land next to the spec they validate. If you would rather merge #2 first, say the word and I will retarget to main.

Adds the ** experimental extension. / + outcome classifiers (including ) on : a declarative contract describing where a tool's inputs go, where its outputs originate, and what real-world effects it can cause. Origin Carries forward the field semantics from SEP-2061 (Action Security Metadata) by @rreichel3, which @localden closed on 2026-06-13 in favour of this extension. SEP-2061 is preserved as the origin and credit. @connor4312's review of SEP-1913 — "InputMetadata/ReturnMetadata seem okay. I _would_ be able to trust these as a client" — is the clearest external endorsement of this shape. Stacking Part of the three-PR split of SEP-1913 (see the base PR for the full plan): base — shared scaffolding + extension this PR — extension (independent of the FIDES scheme) FIDES scheme — , stacked on the base Targets the base branch; retarget to once the base merges.

FIDES as a data-labelling scheme (not an extension) This is the third PR in the SEP-1913 split. It adds FIDES as one data-labelling scheme under a new folder, rather than as an extension or a sibling of the two extensions. — the FIDES information-flow-control label ( × ), selected by on a annotation. A client that does not implement IFC ignores it safely. — the index for the folder: what a scheme is, FIDES as the worked example, and the range of candidate schemes raised in SEP-1913 review (data classification, design-pattern controls, ShardGuard, capability tokens, cosigning, sequence-shape, attestation), plus the bar a scheme doc must meet. Why a scheme, not an extension Information-flow control is one enforcement model among several. Making it an extension () would put the FIDES lattice at the namespace root and foreclose the other models. As a value behind the open slot, FIDES is first-class while the slot stays free for the rest. The folder exists to hold those interchangeable approaches. Stack Stacked on (the base / PR that adds the scaffolding + ). FIDES fills that extension's slot, so it depends on the base. Merge order: base → this. Retarget to once the base merges. Review continuity The normative body here is the same text reviewed by @JoannaaKL and @Rul1an on the original combined PR (their threads are now marked outdated there because the file moved out of ). Their changes are preserved verbatim: /-only confidentiality, the wire-hint vs host-resolved split, the integrity-total / confidentiality-partial asymmetry, fail-closed on unresolvable reader sets, and the no-durable-grant rule. Note: commits in this stack are currently unsigned** due to a local signing agent issue; they can be re-signed on request before merge.