4a. Trust signals — verified-by records and trust tiers#

Verified-by records. Every human promotion — a status change that raises a concept's trust (draft/deprecated → reviewed, anything → authoritative) — stamps a verification record on the concept: who promoted it and when. Repeat promotions stamp again (each is a distinct human vouching event); demotions and deprecations never stamp — they are lifecycle moves, not verifications. The records are shown in the Provenance block on the concept page, next to the source lineage, and travel with the concept in OKF export (§7).

Trust tiers. Each concept's tier is derived from its verification records — never stored, always computed at read time:

Filtering retrieval by trust (min_trust). Every retrieval surface accepts an optional min_trust floor — /v1/query, /v1/answer, /v1/skills/search, and the MCP search_knowledge / search_skills tools. Omitted means no filtering (current behavior); an invalid value is rejected loudly (HTTP 400 / tool error) rather than silently ignored, so a typo can never over-return.

curl -s https://knowledge.servicev8.com/v1/query \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"question": "how do we rotate signing keys?", "min_trust": "human-reviewed"}'

Over MCP, pass it as a tool argument:

{ "name": "search_knowledge",
  "arguments": { "query": "key rotation policy", "min_trust": "human-reviewed" } }

Honest scope note: raw documents and skills don't receive verification stamps today — only concept promotion writes them — so any floor above unverified currently filters results down to curated, human-vouched concepts and excludes raw documents (and skills) entirely. Use the floor when that's exactly what you want: "answer only from knowledge a person has signed off on."