> For the complete documentation index, see [llms.txt](https://docs.arcv.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arcv.network/1.-overview-and-protocol-fundamentals/1.1-introduction.md). # 1.1 Introduction **SOURCE. VALIDATE. ARCHIVE.** *The Living Provenance of Artificial Intelligence.* ## Part I: The Post-Training Data Crisis ### Capability is not the same as reliable behavior Pre-training exposes a model to broad statistical regularities in text, code, images, and other representations. It can build useful abstractions and a large repertoire of capabilities, but its objective does not directly specify how those capabilities should be used in a particular enterprise workflow. Predicting likely continuations does not, by itself, establish whether an answer follows instructions, distinguishes evidence from speculation, handles an exceptional input, or satisfies a customer's evaluation criteria. Post-training supplies additional objectives and evidence. Supervised fine-tuning teaches demonstrations of desired behavior. Preference-based methods distinguish better from worse responses to the same context. Reinforcement learning optimizes a policy against feedback, which may come from people, learned reward models, deterministic verifiers, or combinations of these sources. The usefulness of the feedback depends on what the evaluator can actually observe and verify. OpenAI's instruction-following research documents a pipeline combining human demonstrations, preference comparisons, and reinforcement learning. It demonstrates why optimizing for human preferences is a different objective from predicting internet text. [Training language models to follow instructions with human feedback](https://arxiv.org/abs/2203.02155). Anthropic's Constitutional AI work uses explicit principles, model-generated critiques and revisions, and AI preference feedback. It illustrates RLAIF: reinforcement learning from AI feedback. The supervisory assumptions move into the constitution, evaluator, and training process; using machine feedback does not eliminate the need to inspect those assumptions. [Constitutional AI](https://www.anthropic.com/research/constitutional-ai-harmlessness-from-ai-feedback). DeepSeek's reasoning research demonstrates reinforcement learning on tasks with verifiable outcomes, while Meta's Llama 3 report describes an extensive post-training process alongside pre-training. These are concrete examples of investment in post-training methods and infrastructure. They do not establish an independently quantified capital reallocation across the four organizations, nor imply that pre-training has ceased to matter. [DeepSeek-R1](https://arxiv.org/abs/2501.12948), [The Llama 3 Herd of Models](https://arxiv.org/abs/2407.21783). Direct Preference Optimization offers another route: learning from preference pairs without explicitly running the conventional reward-model-and-RL pipeline. It changes the optimization procedure, not the requirement for meaningful comparisons. A preference dataset that systematically rewards superficial confidence can still teach an undesirable preference. [Direct Preference Optimization](https://arxiv.org/abs/2305.18290). The resulting infrastructure problem is broader than procuring more labels. A laboratory needs to specify which behavior matters, identify contributors capable of judging it, measure agreement without hiding ambiguity, preserve the source material, and determine whether a later training artifact still corresponds to the accepted work. When those stages are disconnected, defects can be discovered only after they have propagated into evaluation or training. ### Synthetic feedback and Model Autophagy Disorder Synthetic data can expand coverage, generate challenging examples, and support controlled experiments. The failure mode arises when generation substitutes for verification: outputs are accepted because they resemble training material, then become the evidence used to train subsequent generators. Apparent scale can increase while the diversity and independence of the underlying information decrease. The research introducing Model Autophagy Disorder, or MAD, studies self-consuming generative training loops and deterioration in quality or diversity under its experimental conditions. It emphasizes the role of fresh real data and sampling choices. It is not a universal theorem that every synthetic dataset causes every frontier model to collapse. [Self-Consuming Generative Models Go MAD](https://proceedings.iclr.cc/paper_files/paper/2024/hash/ebc042e767de551803ccfcc45e2454f5-Abstract-Conference.html). A useful threat model is the loss of an independent corrective signal. A model generates an answer with an unsupported premise; an evaluator sharing its assumptions approves the answer; a synthetic-data collector retains the approved text; and a later model encounters that text as apparent evidence. Rare cases can disappear when each generation preferentially samples familiar, high-probability examples. Repeated errors can become easier to reproduce precisely because the generated corpus makes them look conventional. ``` Source observations and original tasks | v Model generation | v Unverified synthetic publication | v Web collection without lineage | v Next training corpus | +----> Next model ----> More synthetic publication Independent observations, tests, and expert correction must enter the loop; copying an earlier model's approval is not independent validation. ``` The feedback loop is contingent on the training regime. Research on accumulating real and synthetic data finds that collapse is not inevitable under the studied accumulation settings. For ARCV, the operational implication is to retain provenance, preserve reference material, and measure the effect of filtering rather than treating the word “synthetic” as either a quality certificate or an automatic disqualification. [Data accumulation and recursive training](https://arxiv.org/abs/2404.01413). ### Poisoning, coordinated labeling, and missing evidence Poisoning can enter through prompts, candidate answers, evaluator instructions, or the aggregation process. A malicious response can embed instructions intended for an automated judge. A preference campaign can coordinate apparently independent accounts to reward the same defect. A code task can provide a solution that passes visible examples while failing an untested boundary. A retrieved reference can be altered after evaluation if only a mutable URL is retained. Sybil crowdsourcing farms exploit the difference between accounts and independent judgment. Ten wallets controlled by one operator do not provide ten independent reviews. Agreement can be high because reviewers copied one another or used the same machine-generated rationale. Dwell time and interaction events can reveal suspicious patterns, but neither establishes a unique person or proves that the person understood the task. | Attack vector | Evidence needed to investigate | Design response | | ----------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------- | | Coordinated preference manipulation | Assignment history, decision distributions, independent benchmarks | Review separation, calibration, disagreement escalation | | Judge prompt injection | Exact submitted content and judge-policy version | Treat submissions as data; constrain evaluator tools and output schema | | Benchmark leakage | Benchmark revision and anomalous performance changes | Rotate restricted reference sets and limit exposure | | Content substitution | Accepted bytes and their recorded digest | Hash exact artifacts and verify retrieval before use | | Fabricated correctness claims | Test execution records and relevant references | Require observable evidence beyond a fluent rationale | | Duplicate submissions | Canonical task and artifact identifiers | Exact replay rejection plus off-chain semantic deduplication | Cryptographic provenance is not universally absent from existing vendors, and this documentation makes no such claim. The practical concern is whether a particular delivery includes evidence the buyer can verify independently. A vendor may provide audit logs, dataset versioning, signatures, or source attestations. The buyer must still determine what those records bind, which parties control them, and whether the delivered bytes can be substituted without detection. A source URL, a quality score, and a spreadsheet row identifier serve different purposes. None alone binds the task, rubric, accepted output, storage artifact, and settlement event into one verifiable chain. ARCV's thesis is to make that binding an explicit part of the dataset production workflow. ## Part II: The ARCV Protocol Thesis ### SOURCE: make demand and acceptance criteria explicit SOURCE begins with an enterprise task definition: input prompts, candidate responses or other evaluation material, an acceptance rubric, an intended distribution, and a funded number of payable units. The specification must distinguish a unique task from a paid review. Three independent reviews of one prompt represent three potential compensation obligations, not three distinct source prompts. The enterprise determines what evidence is valuable. A programming campaign may prioritize correctness and runtime behavior; a retrieval campaign may prioritize citation support; an adversarial campaign may seek examples that expose a known failure class. A schema can ensure the required evidence fields exist, but the organization must still define how their contents will be judged. ### VALIDATE: combine human correction with machine assistance Human contributors inspect the task and candidate outputs, make a preference decision, and provide the rationale or correction required by the campaign. Optional contributor-side AI copilots can suggest tests, compare algorithms, or draft an explanation. The human remains responsible for checking the submitted result. Rewording an unverified machine answer is not a new source of ground truth. Automated validators are intended to enforce structural requirements, assess interaction evidence, compare the submission with the rubric, and combine judgments across reviews. Diversity of model providers can reduce some shared failure modes, but a collection of models is not automatically an independent consensus mechanism. Acceptance policy must specify which failures are hard rejections, which require human adjudication, and what evidence permits a payout. For reasoning tasks, the useful evidence is an auditable explanation: assumptions, intermediate results where relevant, references, tests, and a conclusion supported by those checks. Lengthy prose is not a proxy for reasoning quality. The protocol should not require disclosure of a model's private internal chain of thought to establish the correctness of an observable answer. ### ARCHIVE: preserve the accepted artifact and its context ARCHIVE binds acceptance to a particular artifact version. The intended storage design uses Arweave-backed archival through a verified Irys integration and a separate hot cache for frequent reads. The archival identifier locates an object; the digest identifies its exact bytes; the manifest explains how those bytes relate to tasks, schemas, and transformations. A corrected dataset is a new version rather than a silent replacement. Downstream consumers should be able to determine whether two training runs used identical source shards, the same split definition, and the same preprocessing configuration. This evidence enables reproducibility and investigation without implying that the dataset is free of mistakes. The current repository provides a workbench, enterprise configuration interface, a Solidity registry, and a wallet swap implementation. A continuously operated autonomous validation service and an end-to-end archival pipeline are not established by those components. The architectural responsibilities in this chapter are specifications unless identified as implemented source behavior. ## Part III: The Tripartite Ecosystem ### Enterprise laboratories: capital and demand Enterprises translate evaluation requirements into funded campaigns. Their responsibilities include defining lawful input access, objective acceptance criteria, sufficient task context, and the relationship between quantity, consensus, and compensation. Proprietary data requires an entitlement and encryption design before it is distributed or archived. A public hash commitment cannot substitute for that access-control design. Capital provides a budget for accepted work, not proof that the campaign is well specified. A vague rubric can reward inconsistent decisions even when all contributors act honestly. Enterprises therefore need calibration tasks, error analysis, and versioned changes to acceptance rules. A material rubric change should not retroactively redefine the obligations associated with previously accepted work. ### Human curators: veracity and edge-case correction Contributors provide situated judgment: recognizing a hidden assumption, reproducing a code failure, identifying missing evidence, or writing a corrected reference answer. Their comparative advantage is not that humans never err. It is that accountable review can incorporate independent observations and expertise that a purely self-referential generation loop lacks. The Golden Patch workflow is intended to turn a defective completion into a checked reference artifact. It must preserve the original task and make the correction inspectable. A patch that changes the problem into an easier one should not be accepted as a solution to the original prompt. Compensation should follow the campaign's verified reward terms rather than the apparent sophistication of the submitted text. ### Autonomous validators: consensus and settlement authority Validators connect off-chain acceptance decisions to authorized on-chain execution. They must maintain a durable decision record, avoid paying the same unit twice, and separate uncertain evaluation results from definitive failures. The bundler registers provenance metadata; an authorized validator pays or rejects the pending record. ``` Enterprise specification and escrow | v Human decision or correction | v Validator evidence and acceptance policy | +-------+-------+ | | Accept Reject / review | v Archival commitment and authorized payout ``` The registry checks the validator's role, not the correctness of its reasoning. An authorized signer can approve a poor submission if its upstream policy is compromised. Governance, signer custody, model evaluation, and operational monitoring remain part of the trust model. ## Part IV: Architectural Guarantees ### Immutability is a binding property, not a truth oracle A cryptographic digest makes content substitution detectable when consumers independently recompute it. A finalized chain record binds the stored digest and metadata to a transaction history. Neither mechanism proves that the contributor owned the source material or that the answer is factually correct. Those claims require additional evidence and review. The registry stores a nonzero digest supplied by an authorized bundler; it does not download Arweave content or calculate the payload's SHA-256 internally. Its implemented mapping is `usedHashes(bytes32)`. A false commitment can therefore be registered by an authorized but faulty operator, even though duplicate commitments are rejected. Independent retrieval verification is part of the guarantee's preconditions. ### Private-key isolation and credential boundaries The wallet swap implementation requests signatures through the user's browser wallet and does not request a seed phrase or raw wallet private key. That is a concrete application boundary. An absolute promise of zero private-key leakage across compromised devices, malicious extensions, wallet software, and every future service would be unsupported. Copilot API credentials are a different secret class. The current implementation supports browser local-storage persistence and direct provider requests. Local storage is not encrypted credential custody, and provider requests are subject to the provider's handling policy. Operational validator keys require their own protected signer and access controls; they do not belong in a browser bundle or a public environment variable. ### Deterministic lineage requires a complete transformation record Deterministic lineage means that a verifier can identify the inputs and transformations that produced an artifact. It does not mean that every LLM evaluation can be reproduced bit for bit. The record should bind the task revision, schema and rubric versions, accepted response, transformation code, tokenizer configuration when applicable, serialized artifact, and storage identifier. ``` Task version + input digest + rubric version | v Decision + evidence + correction version | v Transformation configuration + output bytes | v SHA-256 + archival identifier | v Registry dataset ID + settlement receipt ``` A provenance graph loses its meaning if a referenced schema changes without versioning or if a cache returns a different shard under the same label. Every irreversible archival step must follow final redaction and serialization. Every downstream consumer must verify the bytes it receives. These conditions define an inspectable data supply chain while preserving the distinction between cryptographic evidence, operational controls, and semantic judgment. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.arcv.network/1.-overview-and-protocol-fundamentals/1.1-introduction.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.