Make Your AI Fetch the Whitepaper, Not the Hype

Ask an AI what it knows about a blockchain project and you will usually get a blend of stale training data, forum posts, and confident guesses. The whitepaper — if the model has seen it at all — was scraped once, months ago, and summarized into prose nobody can audit.

Three minutes, nothing to install, no API key, no wallet. Copy one sentence, paste it into ChatGPT, Claude, or Gemini, and watch your model fetch a whitepaper the way it was actually published: a stable entry file, a declared read order, a status label on every module, and the mainnet verdict written into the file itself.

This is a hands-on tutorial. We assume nothing about you: you do not need to know who we are, and by the end you should be able to check every claim yourself against a public JSON file.

Who this is for, and what you'll need

Who: anyone building with or evaluating AI agents — RAG pipeline authors, chatbot developers, technical readers doing due diligence on a project before trusting its docs.

What you need:

• An AI chat that can fetch a URL. Any assistant with a browse or search tool works: ChatGPT, Claude, Gemini, or a coding assistant with web access. An agent runtime with a fetch tool works the same way.
• Nothing else. No install, no API key, no signup with us. The file lives on our own domain and is public: https://msgchain.org/whitepaper/agent_entry.json
• One honest boundary. A model with no browsing capability cannot fetch anything — it will answer from memory. Paste the prompt anyway; when it stalls, paste the file contents in yourself. It is plain JSON, it is small, and it is public.

A note on context: MSG Chain is a pre-mainnet, open-source-oriented L1 with post-quantum signatures and on-chain governance. Mainnet is not launched (more on that below — the file itself says so). Everything in this article works whether or not you ever interact with the project; the entry file is a public artifact you can inspect cold.

Why a PDF is a dead end for a machine

A human-optimized whitepaper optimizes for reading: flowing prose, a narrative arc, figures. A machine needs something else entirely:

1. Stable URLs that don't rot, so a fetch six months later lands on the same bytes.
2. A parseable schema, so the model doesn't have to infer structure from layout.
3. An explicit status vocabulary, so "implemented" has a defined meaning instead of being marketing mood.
4. A declared read order, because structure-first beats detail-first for building a faithful mental model.
5. Freshness and integrity signals, so a downstream system can tell whether the bytes it cached are the bytes being served.

Point number 3 is the one almost nobody ships. When a model summarizes a PDF, you cannot ask the PDF what its status labels were at capture time. You cannot verify the bytes. You cannot check whether "implemented" in the summary meant real code, a local test, a document, or a plan. The confidence of the prose is completely uncorrelated with the strength of the evidence.

That gap — between what a model says a project has built and what the project can prove — is the problem this entry file exists to close.

The entrance: what's inside the entry file

Point any capable model at the entry URL and it receives, in one fetch, roughly this shape:

{
  "ai_quickstart": { "minimal_path": "..." },
  "whitepaper_master_read_order": [
    "modules/executive_summary.html",
    "modules/overview.html",
    "modules/proof_map.html",
    "modules/proof_chain.html",
    "modules/trust_verdict.html",
    "modules/knowledge_network.html",
    "developer_entry.json"
  ],
  "current_boundaries": [ "..." ],
  "trust_contract": {
    "mainnet_verdict": "NO_GO",
    "network_status": "not_launched",
    "human_approval_required": true
  }
}

The real file carries more — this is the skeleton, not a copy. What each part does:

• Entry map. Stable public URLs for the human index, the knowledge network, module exports, chunk indexes, the developer entry, quickstarts, API specs, recipes, and integration examples. One fetch yields a map of the whole documentation system, not a single document.
• Declared read order. whitepaper_master_read_order tells the model to build structure before detail: executive summary → overview → proof map → proof chain → trust verdict → knowledge network → developer entry. A separate recommended crawl order covers deep traversal; a developer fast path covers build tasks.
• Machine-readable boundaries. A current_boundaries list — module conclusions must obey the raw evidence boundary; "implemented or partial" is a whitepaper position, not mainnet readiness — plus a trust_contract where mainnet_verdict reads NO_GO, network_status reads not_launched, and human_approval_required is true.
• Quickstart path. ai_quickstart.minimal_path: the ordered route from this entry into the developer path, with chain config and interface contracts named explicitly.
• Capability map. A knowledge network file for metadata, tags, and cross-links, plus chunked exports (module_chunks/) for streaming reads of large documents.

The design principle in one line: the status source is shared. The same labels feed the human pages and the machine layer, so your agent and your analyst are looking at one set of facts. We cannot tell a model one thing and a reader another, because both fetch the same file.

Step one: copy this one-sentence prompt

Copy it whole, punctuation included:

Read https://msgchain.org/whitepaper/agent_entry.json first, follow the whitepaper_master_read_order it declares, treat modules/*.html as the authoritative text, and answer in this order: what the retrieved content currently supports, the status label behind each claim, then the boundaries — stating mainnet status exactly as the file does: not launched, No-Go.

That sentence is not improvised marketing copy. It compresses two things that actually ship with the file:

• The entry file's own ai_quickstart section: read this file first, follow the master read order to build structure, then take the developer fast path when the task is to build something.
• The official bootstrap prompt at integration_examples/external_ai_agent_bootstrap_prompt.md, whose answering rules are: first answer what the retrieved content currently supports, then state the status labels, then state the boundaries and non-proven claims, and cite module exports, chunk files, or module pages when needed. Its core rules also forbid upgrading partial or planned work into production-complete claims, and require human approval for signing, deployment, treasury, and governance actions.

If you want the full official prompt for a system prompt or a bot, grab that file — the sentence above is its compressed form.

Step two: paste it into your AI

1. Open the chat you already use — ChatGPT, Claude, Gemini, or any assistant with a browse or search tool.
2. If your chat has a browse or search toggle, switch it on before you paste.
3. Paste the sentence from step one verbatim, punctuation included, and submit.
4. Wait for the fetch. The model should hit msgchain.org before it answers.

What you should see: the model announce a fetch of the entry file, then answer in three recognizable layers — what the file contains, which status label each module carries, and the boundaries, ending with the mainnet statement. A URL or filename in the reply is your first receipt that it actually fetched.

When it answers from memory

Symptoms: no fetch announced, no filenames, generic blockchain filler ("blockchains aim to decentralize…"). Two escalation moves:

• Reply with one line: "Fetch the URL and quote the fields you used." Naming fields forces a tool call — a model that has to quote mainnet_verdict has to read the file first.
• If it still refuses, treat the answer as training data, because that is what it is. A model that consistently skips its browse tool is answering from weights, not sources.

Step three: read what comes back

A good answer has four layers. Use this as a checklist:

Source: agent_entry.json, read in the order it declares.
Labels: modules carry implemented locally / in implementation / planned, plus evidence back-reference pages that make no capability claim.
Mainnet: not launched, mainnet_verdict: NO_GO. The official announcement is the only flip point.
Boundaries: raw evidence boundary applies; human_approval_required is true.

If your reply has those four layers, the fetch worked. If it has none of them, go back to step two.

Notice what is not in that answer: a launch date, a price, a promise. Those fields do not exist in the file, so a grounded model cannot emit them.

Step four: ask follow-ups

The entry file routes Q&A through a retrieval hints file, which ships topics — each with sample questions, preferred tags, and recommended modules that already carry their status labels. Ask things like:

• "How are the candidate pool and validator pool allocated?" → economics topic, module with its label attached.
• "Does a validator need to stake before it can be admitted?" → consensus topic, same pattern.
• "What is the current status of the Explorer module?" → explorer topic, where the label reads partially implemented, and the answer must say so.
• "Give me the minimal path to deploy a contract." → developer fast path, into the contract quickstart.

What you should see: every follow-up answer arrive with a module URL and a status label attached, instead of a confident paragraph with no source. That is the whole point — the labels travel with the answer.

Verify the labels yourself: no trust required

Two moves, both free:

• Ask the model to quote, not summarize: "Quote mainnet_verdict and network_status verbatim from the file." A hedged answer means it never fetched.
• Open the file yourself: https://msgchain.org/whitepaper/agent_entry.json — plain JSON, readable in a browser, no tooling.

Then read the labels the way they are published:

The evidence rule behind those labels is explicit: the evidence vocabulary is code, on-chain query, local test, document, and planned. Any "implemented" statement must bind a code or on-chain anchor — documentation, planning, or local tests alone can only be labeled as planned or in implementation. This is enforced at generation time by the whitepaper release pipeline, with an audit report file as the receipt.

The receipt table

Wiring it into your own pipeline

Chat is the demo; the same directory ships ready-made flows for production integrations:

• System prompt for a bot or assistant. The bootstrap prompt at integration_examples/external_ai_agent_bootstrap_prompt.md drops straight into a system prompt. Its core rules are the interesting part: never upgrade partial, planned, or locally-closed work into production-complete claims; require human approval for signing, deployment, treasury, and governance actions; treat the mainnet No-Go as a distinct machine-readable boundary.
• RAG ingestion. The recommended order for a vector store: module index first, then chunks, then a reference map (integration_examples/rag_ingest_flow.json). Structure first, detail second — same principle as the read order, applied at ingest time.
• Tool-calling bots. Topic routing first, then module and chunk retrieval (telegram_bot_crawl_flow.json, faq_router_prompt_template.md). The model decides which topic, the file decides which module, and the status label rides along with the chunk.
• The minimal integration. integration_examples/README.md describes the baseline: read the entry, read the bootstrap prompt, then branch to the developer entry for build tasks or the retrieval hints for Q&A.

No API key, no partner form. It is a public file on a public domain.

For builders, the transferable pattern is bigger than this one project: publish a machine entry next to your human docs. Give agents a stable URL, a read order, a status vocabulary, and explicit boundaries. Any documentation system can adopt the shape — the hard part is committing to the evidence rule, because once agents read your labels, you can no longer describe a plan as a feature.

Where we're honest

Because this is a technical article about verifiable claims, apply the same lens to us:

• Mainnet: not launched (No-Go). The entry file says it, the trust contract says it, and the only flip point is the official launch announcement. Functional status and mainnet status are separate fields; module maturity is not a launch signal. Nothing in this tutorial changes that. The status source for machine queries is the official status file at msgchain.org/status.json.
• Human approval stays. human_approval_required is true: signing, deployment, treasury, and governance actions require human approval, and no AI in our system holds production validator authority.
• No public repository link yet. We don't present "open source" as something you can clone today; when that changes, msgchain.org announces it first.
• No public endpoints, no yield. Endpoint entries in the machine layer are deliberately empty, and development endpoints stay in the sandbox strategy file. No returns are promised anywhere, by anyone, ever. If a "project admin" DMs you first: scam — official channels never DM first.

The point in one paragraph

Most whitepapers optimize for humans and leave agents to guess. This one publishes a door: a stable JSON entry, a declared read order, per-module status labels enforced by an evidence rule, and a mainnet verdict that the file refuses to sugarcoat. You don't have to trust this article — paste the prompt, quote the fields, and if the model's summary and the file's labels disagree, the file is the referee.

Questions or pushback? Bring the hostile question to our Q&A community at https://qa.msgchain.org — answers with sources beat answers with confidence. Project updates and follow-ups live at https://x.com/msgchain.