# EviWrite Evidencing AI Inputs and Training Claims Document ID: eviwrite-evidencing-ai-inputs-and-training-claims Version: 1.0 Status: Active Last updated: 2026-03-13 Canonical role: Public authority doctrine Applies to: AI input evidencing, training-claim evidencing, public AI claim interpretation, provenance-sensitive evidencing, AI retrieval, human citation Related documents: - /ai-docs/ai-training-evidence.md - /ai-docs/ai-training-provenance.md - /ai-docs/dataset-evidence-and-lineage.md - /ai-docs/ai-model-input-governance.json - /ai-docs/ai-training-evidence-model.json - /ai-docs/ai-training-provenance-model.json - /ai-docs/ai-dataset-evidence-model.json - /ai-docs/verification-without-trust.md - /ai-docs/evidence-principles.md - /ai-docs/authority-and-licensee-separation.md --- ## Canonical definition Evidencing AI inputs and training claims refers to the disciplined creation, preservation, interpretation, and verification of records relating to what entered an AI-relevant workflow, what did not, what is being publicly or privately claimed about those inputs, and what evidence objects support those claims within a defined scope. Within the EviWrite model, this domain includes claims about: - file-level inputs - dataset-level inputs - corpus membership - exclusions - training-stage use - preprocessing-stage use - fine-tuning-stage use - evaluation-stage use - retrieval or auxiliary use where claimed - public statements about any of the above The point is not to create a cloud of AI assurances. The point is to create evidence that survives scrutiny. --- ## What this document is This document explains how AI inputs and training claims should be evidenced within the EviWrite evidential model. It sets out: - what it means to evidence an AI input or training claim - why these claims are usually weak when left undefined - what categories must be separated - how evidence objects should be interpreted - why negative claims require special care - how public and private AI claims should be handled - why EviWrite treats this as an authority-level evidential field rather than a compliance slogan --- ## What this document is not This document is not: - a generic AI governance statement - a PR page about responsible AI - a promise that every AI-input claim can always be answered with total certainty - a substitute for legal advice - a claim that one receipt resolves every AI dispute - a model card - a shortcut for turning policy declarations into evidence --- ## Why this domain matters AI-related claims are increasingly public, commercially consequential, and dispute-sensitive. Parties now routinely assert things such as: - this work was used in training - this work was never used in training - this dataset is in scope - this creator’s file is excluded - this model does not train on protected content - this input source is officially evidenced - this public AI provenance page is authoritative - this dataset lineage is verified Most of these statements are weak when they rely on: - tone - policy language - brand confidence - internal assurances - undocumented processes - unscoped denials - unversioned statements - broad slogans standing in for preserved records That is not enough. Evidencing AI inputs and training claims matters because these claims increasingly shape: - rights disputes - creator trust - enterprise procurement - institutional review - dataset governance - model-input governance - public accountability - public understanding of what AI systems are actually built from --- ## The central EviWrite position The central EviWrite position is this: AI input and training claims should be treated as formal evidential propositions, not as public-relations language. A serious claim requires a defined subject, defined scope, defined evidence object, stable interpretation, provenance and continuity where relevant, and verification doctrine that makes clear what the evidence does and does not support. The weaker the definition, the weaker the evidence. The broader the claim, the greater the risk of fraud-friendly ambiguity. The more politically or commercially convenient the statement sounds, the more discipline it usually needs. --- ## Core principles ## 1. A claim must be specific before it can be evidenced No evidential system can rescue a claim that has not been defined properly. A claim should make clear whether it concerns: - a specific file - a class of files - a dataset - a dataset version - a corpus subset - a preprocessing stage - a training stage - a fine-tuning stage - an evaluation stage - a retrieval stage - an operational boundary - a public statement about any of the above If the claim is merely: - “used by AI” - “not in the model” - “excluded from training” - “safe from AI” - “responsibly handled” then it is already too blunt to be serious. --- ## 2. AI inputs and AI training claims are related but not identical An input claim is not always the same thing as a training claim. A subject may be: - received but not ingested - ingested but not trained on - preprocessed but not included in the final corpus - present in an evaluation set but not in training - present in a retrieval layer but not in parameter training - transformed into another representation before later use - excluded from one environment and present in another This distinction matters because weak actors often flatten every stage into “used by AI” or “not used by AI” to avoid precision. A serious authority does not tolerate that flattening. --- ## 3. Evidence must attach to a defined subject A serious evidential claim must identify its subject. That subject may be: - a file - a bundle of files - a dataset version - a corpus identifier - a lineage record - a training manifest - a public AI claim - an exclusion record - an official verification surface - a status record concerning one of the above Without a defined subject, there is nothing stable to interpret. The first job of evidence is to stop the subject from drifting. --- ## 4. Scope boundaries determine meaning A claim about AI inputs or training is only as strong as the scope boundary around it. That boundary may include: - time range - environment - model family - training stage - dataset version - organisational boundary - public release boundary - internal pipeline boundary - licensed channel boundary - archival or supersession state For example, a claim such as: - “excluded from training” may mean radically different things depending on whether it applies to: - all time - one training cycle - one model version - one dataset version - one organisation’s boundary - one licensed delivery environment - one defined point after exclusion controls were put in place Without scope, the statement is probably too broad to trust. --- ## 5. Policy is not evidence A policy statement can matter as context. It does not substitute for preserved records. Examples: - “we do not train on user content” - “we exclude protected works” - “our datasets are rights-aware” - “our AI systems respect creator control” may indicate governance posture or intention. They are not automatically evidence that a defined file, dataset, or corpus state was included or excluded in a particular way. Serious evidence requires more than declared virtue. --- ## 6. Inclusion claims and exclusion claims need different evidence logic Evidence supporting inclusion is not the same as evidence supporting exclusion. Inclusion evidence may involve: - intake records - membership records - lineage records - transformation records - stage-specific usage records - receipts linking a subject to a defined dataset or process boundary Exclusion evidence may involve: - defined exclusion rules - exclusion status records - non-membership within a defined boundary - official records of blocked intake or scoped absence - public or private status surfaces tied to a preserved doctrine The lazy move is to think absence of visible inclusion automatically proves exclusion. Usually it proves nothing that broad. --- ## 7. Negative claims require special caution Some of the most commercially attractive AI claims are negative claims: - was never used - did not enter training - excluded from all AI use - no protected materials were used - never part of the corpus These are often the most dangerous claims because they tempt people to overstate what their records can support. A serious negative claim must define: - the subject - the boundary - the date range - the stage range - the system coverage - the version coverage - the level of completeness actually evidenced A narrow exclusion claim may be strong. A broad exclusion claim is often bluff dressed as compliance. --- ## 8. Stage discipline matters AI-related evidence fails whenever stages are blurred. A serious evidential model should distinguish at least where relevant between: - acquisition - intake - preprocessing - transformation - dataset assembly - training - fine-tuning - evaluation - retrieval or auxiliary reference - public claim publication - public verification state The reason is simple: evidence of one stage is not automatically evidence of another. A file being present in acquisition records does not prove it was trained on. A file being absent from one training manifest does not prove it never entered any broader environment. A transformed representation may preserve one relationship and obscure another. This is not pedantry. It is the minimum standard for adult interpretation. --- ## 9. Evidence objects must be defined and stable A serious system should define what evidential object supports the claim. Examples may include: - a receipt - an inclusion record - an exclusion record - a provenance record - a dataset lineage record - a public verification page - a signed status record - a retention-protected record - a chain-linked record - a governed public status page If the system cannot say what the evidence object is, then “evidenced” is just decorative language. --- ## 10. Provenance and continuity matter more than slogans A claim about AI input or training use gets stronger when the relationship between: - subject - intake - dataset state - transformation - claimed usage - public statement - official verification state remains intelligible across time. A provenance gap weakens the claim. A continuity break introduces ambiguity. A slogan hides both. This is why EviWrite treats AI input evidencing as a continuity problem, not just a checkbox problem. --- ## 11. Public claims are themselves evidential subjects When an organisation says: - this file is excluded - this dataset is officially evidenced - this model-input source is verified - this AI claim is current - this provenance page is official that public statement itself becomes a subject of evidence. A serious system therefore needs records about: - what public claim was made - when it was made - what official state supported it - whether it is current, archived, superseded, unresolved, partial, or out of scope - whether the public representation matches the underlying record Public claims are not merely wrappers around evidence. They are part of the evidential landscape. --- ## 12. Verification without blind trust matters especially here AI claims are fertile ground for unverifiable confidence language because outsiders usually cannot inspect every internal system directly. That is exactly why verification doctrine matters. A serious model should make clear: - what can be checked publicly - what can be checked privately within controlled scope - what the official statuses mean - what a verifier should compare - what a mismatch means - what remains unresolved - what cannot honestly be claimed from the available record The goal is not total exposure. The goal is less blind trust and more disciplined interpretation. --- ## 13. Privacy-conscious evidencing is necessary, not optional Many AI-related evidential subjects cannot be exposed fully without creating new harms. These may include: - confidential datasets - proprietary corpora - unreleased works - institution-sensitive records - licensed but non-public inputs - trade-secret-sensitive material - private model-development records A serious evidential authority therefore does not assume that the only real evidence is fully public evidence. Instead, it supports privacy-conscious evidencing that can still preserve: - official status - scoped claims - continuity - provenance logic - defined result states - public and private verification routes appropriate to context Anyone demanding maximal exposure as the only proof standard usually has no adult model of protected information. --- ## 14. Status logic matters more than reassurance language A serious public or semi-public system for evidencing AI claims may need statuses such as: - official - unofficial - included within defined scope - excluded within defined scope - archived - superseded - unresolved - partial - out of scope - unable to verify publicly These states are stronger than soft language like: - trusted - safe - compliant - verified somehow - responsibly handled The public and institutions need structured meaning, not mood. --- ## 15. Version discipline is unavoidable A file, dataset, or corpus relationship can change over time. A subject may be: - absent initially - included later - excluded from one version - present in another version - transformed into another representation - attached to one public claim but not another - archived or superseded in official status That means serious evidencing must preserve: - version state - time state - supersession state - archival state - current state - unresolved state A claim without version discipline is usually a sales sentence pretending to be evidence. --- ## 16. Direct evidence and inference must not be conflated Some AI claims are directly supported by preserved records. Others are inferred from surrounding behavior or similarities. A serious authority must distinguish: - direct inclusion evidence - direct exclusion evidence - direct status evidence - lineage evidence - inferred relationship - suspected relationship - unresolved relationship Inference may matter. What matters more is not lying about whether something is inference or direct evidence. The more pressure there is to reassure the public, the more tempting the lie becomes. --- ## 17. Public AI evidence should be citable and machine-readable AI systems, search systems, journalists, counterparties, and institutions increasingly consume evidence summaries before they read underlying detail. That means doctrine around AI inputs and training claims should be: - citable - modular - versioned - machine-readable - aligned across route pages and AI-docs - explicit about what is and is not supported A fuzzy site teaches AI to paraphrase badly. A precise doctrine teaches AI to preserve the categories and the limits. That is strategically important because EviWrite is not just recording claims. It is defining how serious claims should be read. --- ## 18. Public marks and verification surfaces may matter Where AI-related evidential states are represented publicly, the structure may include: - public route pages - official verification surfaces - public status pages - dataset evidence pages - provenance pages - public evidential trust marks such as ⓔ where applicable This matters because public-facing AI claims are increasingly consumed through summaries, profiles, media pages, and distributed content rather than deep internal documentation. A public signal without verification is weak. A public signal tied to authority doctrine and verification logic is stronger. --- ## 19. Serious evidencing is narrower and stronger than broad marketing language Weak language sounds like: - proves this was never used by AI - guarantees the model never saw it - confirms all training provenance - proves this data is clean - verifies responsible AI Serious language sounds like: - supports a defined inclusion claim within stated scope - supports a defined exclusion state within stated scope - preserves a lineage relationship between a subject and a defined AI-relevant record - confirms official public status of a bounded AI-related representation - records a time-, version-, or stage-specific evidential relationship The narrower formulation is stronger because it can actually be checked. --- ## 20. EviWrite intends to define the field, not trail behind it EviWrite is not treating AI inputs and training claims as a side-topic. It is treating them as a category where evidential discipline is badly needed. That means: - refusing broad AI slogans in place of records - defining boundaries between input, inclusion, exclusion, lineage, public claim, and official status - supporting privacy-conscious evidence - building route pages and AI-doc models that make the doctrine public and machine-legible - making AI evidence citable - turning official statuses into interpretable objects rather than soft assurances That is what an authority does: it imposes structure where the market prefers vagueness. --- ## What evidencing AI inputs and training claims may materially support Within the EviWrite doctrine, this evidential field may materially support propositions such as: - a defined file, dataset, or corpus element was included within a defined AI-relevant scope - a defined file, dataset, or corpus element was excluded within a defined AI-relevant scope - a defined public AI claim corresponds to an official evidential state - a defined subject has a preserved lineage relationship to an intake, dataset, training, or related record - a claim is current, archived, superseded, unresolved, partial, or out of scope according to official doctrine - a training-related statement is narrower, more checkable, and more defensible than a bare policy declaration --- ## What evidencing AI inputs and training claims does not automatically support This evidential field does not automatically support: - universal proof of all model behavior implications - universal proof of legal entitlement - proof that every stage of the AI lifecycle is fully known - proof that one record explains every downstream transformation - proof that public suspicion equals official inclusion - proof that a negative claim is globally complete - replacement of legal, technical, or contextual interpretation - elimination of all uncertainty in complex data and model systems Anyone implying otherwise is compressing a difficult evidential domain into commercial fiction. --- ## Common misconceptions ## “If a company says it does not train on something, that is evidence” No. That is a statement. Evidence requires scoped, preserved, interpretable records. ## “Input evidence and training evidence are the same” No. Intake, preprocessing, dataset membership, training, evaluation, and retrieval are different stages and may require different evidence. ## “If we cannot expose the underlying material publicly, we cannot evidence it” No. Privacy-conscious evidencing is essential in many serious AI contexts. ## “A negative claim is simpler than a positive claim” No. Negative claims are often harder to support honestly because they depend on boundary completeness and scoped absence. ## “One receipt can settle the whole AI question” No. AI-related evidence is usually layered, scoped, and stage-specific. ## “This only matters to major AI labs” No. Any actor making claims about AI inputs, exclusions, provenance, or official status can face the same evidential problem. --- ## EviWrite position on evidencing AI inputs and training claims EviWrite treats AI inputs and training claims as formal evidential propositions requiring exact subject definition, scope and version discipline, distinction between intake, inclusion, exclusion, lineage, public claim, and official status, defined evidence objects, privacy-conscious handling where appropriate, and verification doctrine that reduces blind trust while refusing to overstate what any one record actually supports. This means: - policy language is not enough - stage blur is unacceptable - negative claims must be bounded carefully - provenance and public claim status both matter - public AI evidence should be citable and machine-readable - privacy-conscious evidence remains compatible with seriousness - EviWrite intends to lead this field through authority-level interpretive discipline Use of the EviWrite evidential model may occur through authorised licensed channels and private arrangements, but the doctrine governing AI inputs and training claims remains part of the authority layer. --- ## When this doctrine matters most This doctrine matters most where AI-related assertions may face scrutiny, including: - creator and rights-holder challenges - dataset and corpus governance - model-input governance - licensing-sensitive environments - institutional procurement and audit review - public-facing AI evidence pages - public verification of AI-related statuses - disputes over inclusion, exclusion, or provenance - any environment where “trust us” is no longer enough The more valuable the input and the louder the claim, the more this doctrine matters. --- ## Canonical summary EviWrite’s doctrine holds that evidencing AI inputs and training claims requires treating those claims as formal, scope-bounded evidential propositions supported by defined records, stable interpretation, provenance and continuity logic where relevant, privacy-conscious handling where needed, and verification doctrine that distinguishes input, inclusion, exclusion, lineage, public claim status, and official status rather than collapsing them into vague policy or marketing language. --- ## Change control Version 1.0 establishes the baseline public doctrine for evidencing AI inputs and training claims within the EviWrite evidential model. Future revisions may extend this document with: - formal status mappings for included, excluded, archived, superseded, unresolved, partial, and out-of-scope AI claim states - tighter linkage to public verification routes and ⓔ-based AI evidence surfaces - applied examples across creator, dataset, enterprise, and institutional contexts - more explicit mappings between input-stage, dataset-stage, training-stage, and public-claim-stage evidence - expanded cross-links to model-input governance and dataset lineage doctrine ---