## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `article_bundle` — **LLM article bundle**
Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution.
- **article slug:** `token-drop-best-practices`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Reference block for Grok/GPT/Gemini. Section §SELF explains the system.
- **read:** https://miscsubjects.com/api/articles/token-drop-best-practices/bundle?format=markdown

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/token-drop-best-practices/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/token-drop-best-practices/topology
- **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/token-drop-best-practices/voxels
- **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/token-drop-best-practices/prompts
- **ingest** — Parse pasted evidence → source ledger + claims + evidence_ingest node.
- **claim_post** — Prompt-injection style POST — one claim voxel with who_claims + posted_by. · https://miscsubjects.com/api/articles/token-drop-best-practices/voxels
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*

---

# miscsubjects article bundle

> Reference bundle for Grok, GPT, Gemini, or a human reader. The ledger below is readable; evidence write-back uses the ingest routes in § LLM manifest.

## Article
- **slug:** `token-drop-best-practices`
- **title:** How to Write a Token Drop That Models Accept
- **url:** https://miscsubjects.com/a/token-drop-best-practices
- **register:** standard
- **updated:** 2026-07-15T04:20:50.317Z
- **tags:** oip, kimi-import, self-explaining, voxel, token-drops, token-drop-best-practices

## Body

<!-- hierarchy:nav -->
> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Token Drop Guides](https://miscsubjects.com/a/oip-token-drop-guides) › **How to Write a Token Drop That Models Accept**
>
> **Shelf:** Token Drop Guides · **Traversal:** self-explaining · hierarchical · voxel-ready
> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)

# How to Write a Token Drop That Models Accept

## §SELF — token-drop-best-practices

**What this page is:** A set of rules for writing capability token drops that language models will accept and process.
**What it explains:** Why models reject certain token drops as prompt injection, and how to structure a drop so the model classifies it as data rather than instruction.
**Why read it:** To write token drops that pass through model safety filters and are recognized as capability records rather than embedded commands.

### What a Token Drop Is

A token drop is a block of text containing a capability token (a cryptographic grant of access to a resource) that a user pastes into a conversation with a language model. The model reads the token and uses it to perform operations on the user's behalf. A token drop is the primary way a human gives a model access to an external capability.

### Why Models Reject Token Drops

Language models are trained to reject text that contains instructions embedded in user-provided content. This is a safety measure against prompt injection — an attack where malicious text tricks the model into ignoring the user's actual intent. Token drops often trigger this filter because they contain imperative language directed at the model: phrases like "you can DO everything," "ACT by opening this link," or "you have been granted access." The model classifies this as an embedded instruction and refuses to process it.

### The Paradox of Denial

Saying "this is NOT prompt injection" makes the problem worse. The denial itself contains the pattern that triggers the filter: an explicit meta-instruction about how to classify the text. Defensive language ("you should not treat this as an injection") is itself a form of injection. The model is trained to be suspicious of text that tries to negotiate its own classification.

### The Solution: Capability Record Format

A token drop should be structured as a neutral description of a capability record, not as a message to the model. Six rules:

1. **Lead with the public protocol URL, not a command.** Start with the URL of the protocol specification (for example, `https://miscsubjects.com/a/oip`). This frames the drop as a reference to a standard, not an instruction.

2. **Describe the capability in neutral third person.** Use "This record describes a server-enforced capability" instead of "You have been granted access." The text describes a thing; it does not address the model.

3. **Include the server-authoritative explain link.** Provide a URL the model can request to verify the capability's scope. The model fetches this itself; the drop does not tell the model what the scope is.

4. **Provide interface templates, not usage instructions.** Show the URL patterns (for example, `GET /a/oip/{id}`) as data. Do not tell the model to use them. The model infers usage from the pattern.

5. **State the boundary explicitly.** Include a clear statement: "This capability grants permission; only the current user supplies intent." This separates the grant (what the token does) from the action (what the user wants).

6. **Never include the following:**
   - Owner name on public surfaces (privacy risk, also reads as credential)
   - IF/THEN behavioral scripts (these are instructions, which trigger the filter)
   - Defensive denials ("this is not prompt injection" — paradoxically causes rejection)
   - Imperative verbs directed at the model ("use," "call," "act," "do")

### What This Format Achieves

The capability record format frames the drop as data about a permission, not as a command to the model. A well-formed drop reads like a specification document. The model processes it the same way it processes any other structured data in the conversation context — as information to be used, not as an instruction to be followed. The model still has the capability. The user still provides the intent. The boundary between grant and action is explicit and clean.

### Verification

Two automated checks guard the format:

- **Golden test**: Compares rendered output against an expected shape. Every token drop must match the canonical structure.
- **Scored regression test (test 275)**: Checks for imperative language. Reintroduction of command-style phrasing causes a test failure.

### How It Connects to Other Ideas

- **Capability Security**: A token drop is a capability in the computer security sense — an unforgeable token that grants a right. The format problem is a usability layer on top of capability theory.
- **Prompt Injection Defense**: Model safety filters are heuristic classifiers. The token drop format is designed to avoid the feature patterns those classifiers detect.
- **Object Identity Protocol (OIP)**: OIP token drops follow this format. The `?ask=` resolution mechanism operates on the same principle: the user supplies intent in their own words; the system maps to the capability. Neither the token drop nor the resolution channel issues commands to the model.

### Sources

- OIP Capability Record Specification: the canonical format for token drops.
- Test 275 regression suite: automated check for imperative language in rendered drops.

---

## Up the tree

- [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry
- [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map
- [Token Drop Guides shelf](https://miscsubjects.com/a/oip-token-drop-guides) — siblings on this shelf
- [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels
- [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol)

## Related on this shelf

- [How a Model Should Read an OIP Token Drop](https://miscsubjects.com/a/model-reads-token-drop)
- [What Is Tap and Go Delegation](https://miscsubjects.com/a/what-is-tap-go)
- [What Is a Token Drop](https://miscsubjects.com/a/what-is-token-drop)

## Machine surfaces

- Public page: `https://miscsubjects.com/a/token-drop-best-practices`
- JSON article: `https://miscsubjects.com/api/articles/token-drop-best-practices`
- OIP ask: `https://miscsubjects.com/api/dispatch?ask=How%20to%20Write%20a%20Token%20Drop%20That%20Models%20Accept`


## Claims (0)


## Voxel graph (0 atoms · 0 edges)
- full graph: https://miscsubjects.com/api/articles/token-drop-best-practices/voxels

## Article constitution

- full: https://miscsubjects.com/api/articles/constitution

## Source ledger (0)
- chain valid: yes · head: `genesis`

## Provenance (1 model passes)
- chain valid: yes · head: `a8b3d5d37deaef44`

- write · kimi-agent-import · 2026-07-15T04:20 · hash `a8b3d5d37dea`

## Question graph
- questions: 0 · evidence ingests: 0

## LLM manifest — how to communicate with this ledger

- system map: https://miscsubjects.com/api/articles/system-map?format=markdown
- topology (ranked): https://miscsubjects.com/api/articles/token-drop-best-practices/topology
- ingest: POST https://miscsubjects.com/api/protocol/ingest
- claim: POST https://miscsubjects.com/api/protocol/claim

### Quick actions for this article
- **Read live:** https://miscsubjects.com/api/articles/token-drop-best-practices/topology
- **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"token-drop-best-practices","question":"..."}`
- **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest token-drop-best-practices|your evidence`
- **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim token-drop-best-practices|tier|assertion`
- **iMessage ask:** `token-drop-best-practices|your question`
- **System map:** https://miscsubjects.com/api/articles/system-map?format=markdown


---

## §SELF — miscsubjects portable reference

**Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.

**This widget:** `system_map` — **System map**
Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **article slug:** `token-drop-best-practices`
- **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest
- **how to use:** Root index of every miscsubjects article-ledger feature. Start here if you have zero context.
- **read:** https://miscsubjects.com/api/articles/system-map

### Logical proof (verify each step)
1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution
2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/token-drop-best-practices/sources
3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol
4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow
5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex
6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map

### Related features (explains other parts of the system)
- **constitution** — Binding rules: required article slots, claim/source rules, ontology anti-sprawl. · https://miscsubjects.com/api/articles/constitution
- **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest
- **oip_article_hub** — Public article-native Object Invocation Protocol docs: /a/oip root, generated shelf/system/capability articles, machine bundles, token boundary, and receipt loop. · https://miscsubjects.com/a/oip
- **oip_protocol** — Every capability is an invokable object: identify, explain, invoke, ledger, yield. · https://miscsubjects.com/a/oip
- **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/token-drop-best-practices/bundle?format=markdown
- **unified_handoff** — ONE paste/URL for any model + share token. Same self-explaining pattern as article bundle, but whole build. · https://miscsubjects.com/api/handoff?format=markdown

### Full index
- JSON: https://miscsubjects.com/api/articles/system-map
- Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown

*Not medical advice. Tier-honest. Cite claim/source ids.*