# SourceMesh Verification Harness V01 Issue: #54 Status: operator verification artifact. This harness is markdown-first field guidance, not policy, not package authority, not source registry mutation, and not runtime retrieval. ## Purpose Provide a repeatable Source Claim Verification Harness for normalized transcripts, practitioner videos, podcasts, articles, repos, vendor-promoted material, and other external material before reuse in doctrine, framework input, pattern input, Shared Core input, AI Capability Discipline input, WESS input, EA Assistant input, or SourceMesh input. The harness verifies source identity, lineage, credibility, claim strength, commercial incentive posture, and safe reuse boundaries. It does not certify truth by packaging a source, citing a source, hashing a source, or recording a receipt. ## When To Use Use this harness before external material supports: - doctrine input after verification - pattern input with caveats - perspective signal only - terminology signal only - backlog candidate only - no reuse Use it when a source is a normalized transcript, practitioner video, podcast, article, repo, vendor documentation, vendor-promoted material, sponsor content, conference talk, course material, consulting-funnel material, benchmark claim, product claim, tool claim, model claim, security claim, pricing claim, or implementation claim. Do not use this harness to fetch sources, crawl websites, perform arbitrary web search, execute browser-side source fetching, execute provider calls, mutate package authority, mutate a source registry, grant production approval, grant vendor approval, grant model approval, grant tool approval, or grant GxP approval. ## Required Inputs Every review packet must identify: - source ID - source title - source type - source location or controlled citation pointer - source owner, publisher, channel, presenter, guest, repo owner, or author - publication date or unavailable marker - review date - reviewer - transcript, article, repo, documentation, or recording path - normalized transcript path when applicable - known sponsor, affiliate, employer, vendor, product-placement, consulting-funnel, course-funnel, paid-partnership, or referral-incentive context - intended reuse target - claim inventory - evidence packet or evidence gap Do not invent unavailable values. Record `not available`, `not applicable`, or `owner validation required` when deterministic inspection cannot supply a field. ## Source Identity And Lineage Record how the reviewed item came into the package: | Field | Requirement | |---|---| | source ID | Stable local identifier for the reviewed item. | | source title | Human-readable title. | | source class | transcript, practitioner video, podcast, article, repo, vendor documentation, vendor-promoted material, standards material, research, official documentation, field observation, or other. | | source owner or publisher | Person, channel, organization, vendor, repo owner, standards body, or publisher when available. | | source lineage | Original source, mirror, clipped transcript, summary, derived notes, repo fork, archived copy, or normalized transcript. | | capture method | Manual copy, owner-supplied file, normalized transcript, repo inspection, official page, or controlled citation pointer. | | transformation history | Transcription, summarization, translation, excerpting, normalization, or none. | | integrity evidence | Hash, stable URL, commit SHA, issue/PR reference, receipt, or not available. | Lineage must distinguish the original source from derived notes. A normalized transcript is not source truth by itself. ## Publication Metadata Capture: - publication date - update date - access or review date - source version - repo commit SHA or release tag when applicable - platform or channel - jurisdiction or domain scope when applicable - content format - license or reuse constraint - public, controlled-sharing, internal, paywalled, confidential, or rights-controlled status Version-sensitive material requires a refresh trigger before reuse. ## Author Channel Presenter Guest Or Repo Owner Identity Record the identities that matter to the claim: - author - channel owner - presenter - guest - interviewer - repo owner - maintainer - vendor or employer affiliation - sponsor or commercial relationship - named product or service promoted Identity claims are claim inventory items. Do not infer identity, employer, role, credential, or independence from branding alone. ## Speaker Or Author Credibility By Domain Evaluate credibility by domain, not universal authority. | Domain | Review question | |---|---| | technical implementation | Does the speaker or author have relevant implementation evidence for this technical claim? | | security | Is the source qualified for the security claim and supported by independent evidence? | | compliance or GxP | Is the source authoritative for the jurisdiction, standard, and regulated-use context? | | pricing or limits | Is the source the official source of record or independently checked against one? | | product behavior | Is the source official product documentation or otherwise limited to practitioner observation? | | model capability | Is the claim sourced to official model documentation, benchmark context, or independent evaluation? | | operating doctrine | Is the source strong enough for doctrine, or only a weak signal? | Credibility in one domain must not transfer to another domain without evidence. ## Transcript Or Source Quality Check: - transcript completeness - audio or video clarity where applicable - speaker attribution reliability - timestamp coverage - missing sections - transcription confidence - translation or summarization distortion - excerpt completeness - quote fidelity - repo state at reviewed commit - article update history Low transcript quality can support only perspective signal, terminology signal, or backlog candidate use unless independently verified. ## Metadata Consistency Check whether title, author, channel, URL, publication date, version, repo commit, sponsor disclosure, transcript metadata, and cited source details agree across available records. Metadata inconsistency must be recorded as a caveat or stop condition. ## Claim Extraction Extract claims into claim IDs. Each claim row should include: - claim ID - source ID - quoted or paraphrased claim text - claim location, timestamp, section, line, or commit - claim classification - verification priority - verification status - supporting evidence - contrary evidence - caveat - safe reuse category - unsafe reuse category - owner validation required Keep claim text narrow. Split compound claims into separate rows when evidence requirements differ. ## Claim Classification Use these controlled claim types: - identity - credential - reputation - technical - tool capability - model capability - security - pricing - metric - product - sponsor - opinion - inference One claim may carry multiple types when necessary, but each high-risk type must receive evidence suited to that type. ## Claim Verification Priority Use these priority levels: | Priority | Meaning | |---|---| | high | The claim could affect doctrine, security, compliance, product approval, model/tool approval, pricing, metrics, or production interpretation. | | medium | The claim could affect pattern extraction, terminology, backlog routing, or operator caveats. | | low | The claim supports context, perspective, or narrative only. | High-priority claims must be independently verified before doctrine, framework, security, compliance, production, pricing, metric, tool, model, or vendor approval meaning is allowed. ## Evidence Requirements Match evidence to claim type: | Claim type | Minimum evidence posture | |---|---| | identity | Official profile, repo ownership, publication metadata, or owner-validated identity. | | credential | Official biography, credential issuer, employer profile, standards body, publication record, or owner validation. | | reputation | Multiple independent sources or label as reputation commentary. | | technical | Primary documentation, source code, reproducible test, official docs, or bounded implementation evidence. | | tool capability | Official vendor documentation or reproducible bounded test. | | model capability | Official model documentation, system card, benchmark record with caveats, or independent evaluation. | | security | Authoritative security source, advisory, standard, vulnerability record, or independent security review. | | pricing | Official pricing page or current vendor documentation with review date. | | metric | Original measurement source, method, denominator, date, and caveat. | | product | Official product documentation, release notes, or scoped product source. | | sponsor | Disclosure, affiliate note, vendor relationship, employer relationship, or incentive evidence. | | opinion | Label as opinion and do not promote to fact. | | inference | Label as inference and require reviewer rationale. | Verification status must be one of: - verified - mostly verified - plausible but unverified - partially supported - contradicted - outdated - not independently verifiable - opinion ## Sponsor And Commercial Incentive Split Sponsor, affiliate, vendor, employer, product-placement, self-promotional, consulting-funnel, course-funnel, paid-partnership, and referral-incentive content must be separated from editorial or technical claims. Commercial claims must not support doctrine unless independently verified from a suitable source class. Vendor and sponsor material may support product-specific facts only when scoped and independently checked against authoritative documentation. Sponsor disclosure absence is not proof of neutrality. ## Vendor And Self-Promotion Handling Vendor documentation is implementation-specific unless corroborated or explicitly scoped. Vendor documentation is not neutral industry truth. Vendor-promoted material, sponsor segments, affiliate recommendations, partner claims, employer claims, consulting-funnel material, course-funnel material, and self-promotional claims may support only: - product-specific facts after independent check - perspective signal only - terminology signal only - backlog candidate only They must not create vendor approval, tool approval, model approval, production approval, security assurance, compliance assurance, pricing or limits authority, benchmark or performance proof, or source-of-record replacement. ## Source Inclusion Decision Use one inclusion decision: - include - include with caveats - perspective-only - hold pending verification - exclude Record the decision rationale, highest-risk claim types, evidence gaps, owner validation requirement, and refresh trigger. ## Safe Reuse Categories Every processed source must choose one safe reuse category: - doctrine input after verification - pattern input with caveats - perspective signal only - terminology signal only - backlog candidate only - no reuse Safe reuse is bounded by the recorded evidence status and caveats. ## Unsafe Reuse Categories Every processed source must mark unsafe reuse categories that are prohibited: - unsupported doctrine - vendor approval - tool approval - model approval - production approval - security assurance - compliance assurance - pricing or limits authority - benchmark or performance proof - source-of-record replacement If any unsafe category is plausible, the output packet must state the prohibition directly. ## Pattern Extraction And Mapping Extract patterns only after claim posture is visible. Pattern extraction must record: - pattern ID - supporting claim IDs - source verification status - target lane - reuse category - caveat - owner review requirement Allowed handling lanes are Shared Core, AI Capability Discipline, WESS, EA Assistant, and SourceMesh. Pattern registration does not promote the pattern into doctrine. ## Claim Reuse Labels Use compact evidence posture labels, not truth certification labels: - verified-source-supported - source-supported-with-caveat - perspective-only - weak-signal - vendor-claim - sponsor-claim - self-promotional-claim - practitioner-commentary - needs-independent-verification - do-not-promote - stale-or-version-sensitive - unsafe-for-doctrine - safe-for-pattern-intake - owner-validation-required Labels guide handling. They do not certify truth, approve tools, approve models, approve vendors, approve production use, approve security posture, approve compliance posture, or replace owner validation. ## Stop Conditions Stop and do not promote the source when: - source identity cannot be established - source lineage is unclear - transcript quality is too weak for the intended claim - metadata consistency fails for material fields - high-priority claims lack independent verification - sponsor, affiliate, employer, vendor, product-placement, consulting-funnel, course-funnel, paid-partnership, referral-incentive, or self-promotional material is not separated from editorial or technical claims - the source is stale or version-sensitive and no refresh trigger exists - the source asks the operator to infer package authority, production approval, vendor approval, model approval, tool approval, security assurance, compliance assurance, pricing authority, benchmark proof, or GxP approval - the source requires arbitrary web search, browser-side source fetching, provider calls, source registry mutation, package authority mutation, database, vector store, graph store, durable memory, crawler, worker, webhook, queue, polling, or Cloudflare configuration change ## Output Packet Each completed review should produce a markdown packet with: - source identity - source lineage - publication metadata - author, channel, presenter, guest, or repo owner identity - speaker or author credibility by domain - transcript or source quality - metadata consistency - claim inventory summary - highest-risk claim types - verification status summary - sponsor and commercial incentive split - vendor or self-promotion caveats - inclusion decision - safe reuse category - unsafe reuse category - pattern extraction and mapping - owner validation required - refresh trigger - final reviewer note ## Non-Goals This harness does not create: - arbitrary web search - browser-side source fetching - provider calls - package authority mutation - source registry mutation - runtime retrieval - browser-side provider calls - uncontrolled live retrieval - Cloudflare configuration - provider/model configuration - database - vector store - graph store - Supabase - durable memory - crawler - worker - webhook - queue - polling - production approval - vendor approval - model approval - tool approval - GxP approval - source-of-record replacement ## Non-Inference Rules - A source entry is traceability, not truth certification. - A verification receipt proves bounded validation, not semantic truth. - A reference entry does not create package authority. - A sponsor disclosure absence is not neutrality evidence. - Vendor documentation is not neutral industry truth. - Practitioner commentary is weak signal unless independently verified. - A transcript is not proof that the speaker's claim is true. - A repo exists does not prove its pattern is safe or reusable. - A demo is not production approval. - A benchmark claim is not performance proof without method, context, and independent review. - Owner validation remains required for doctrine, governance, policy-sensitive claims, regulated-use claims, and package promotion.