# The MTS drop standard

> Something a researcher would comfortably send to an intelligent friend.

Accessible enough to follow without background; precise enough that experts recognize the distinctions.

## 1. One cohesive explanation

State the question and the scope before building the experience. Every chapter should create the need for the next. Introduce vocabulary when it resolves a question the reader already has. The narrative must work as prose without its animations.

## 2. A durable reference

Aim to become the resource someone returns to and shares for a specific topic. Durable does not mean exhaustive. Define terms, make distinctions explicit, provide stable section anchors, attach primary sources to claims, and date product-specific facts. Separate enduring mechanisms from changing prices, model IDs, and software instructions.

## 3. An interaction that teaches

The reader should make a consequential choice, predict an outcome, or test a mechanism. The interaction must reveal something that a static illustration alone would not. State what it computes and what it cannot establish. Do not use fabricated leaderboards or simulated results presented as measurements.

## 4. Visuals advance the argument

Use a persistent visual that evolves with the explanation, as in the benchmarks and Millennium work. Keep visual meaning stable: location, color, motion, and scale should encode the same things across scenes. Reveal one new relationship at a time. Carry the shared Compute/Benchmarks visual language forward: white background, black serif headings, MTS branding, quiet rules, and restrained functional color. Give every scene a caption and an accessible description. Avoid motion that merely decorates the page.

## 5. Precision without prerequisite knowledge

Use familiar examples, then explain where their analogy stops. A toy model is a toy model. An observed result is scoped to its experiment. A diagram of infrastructure is conceptual unless a primary source establishes its exact topology. Clearly separate hypothesis, illustration, reported result, and original measurement.

## 6. Evidence carries the relationship with partners

A company should want to share the drop because it explains the subject well. Represent products accurately and substantively; preserve editorial judgment. Do not imply endorsement or invent results. Request factual review of a complete draft rather than seeking approval for an empty outline. Sending it requires explicit user instruction.

## 7. A useful ending

Finish with a reusable artifact appropriate to the subject: a reference map, dataset, experiment, checklist, or practical guide. Explain prerequisites, assumptions, and the evidence needed to make a claim. Instructions should connect to current primary documentation.

## 8. Reader control

Use native scrolling, responsive layouts, keyboard controls, readable type, reduced-motion support, and a plain reading mode. Keep the core explanation accessible even without interaction. Test real decisions and mobile layouts, not only the opening screenshot.

## Release questions

- Can a reader state the central mechanism after reading?
- Does each chapter logically lead to the next?
- Does the interaction expose the mechanism rather than merely entertain?
- Are adjacent topics separated without denying their overlap?
- Can a researcher trace the factual claims and identify the limitations?
- Does the page remain useful after a product release changes?
- Are downloadable instructions honest about what was and was not run?

Applied scope for this edition: post-training through demonstrations, preferences, and rewards. Fine-tuning is a method within the story. Alignment is a connected question about intended objectives and reliable behavior, not a synonym for post-training. Tinker demonstrates infrastructure; Inkling and Nemotron supply model and recipe context. No real language-model experiment has been run.