RAPP VISION / CREATOR HANDBOOK / VERSION 1

Understanding before motion.

Make something worth understanding. Then give the viewer a way to use, question, or test it.

RAPP Vision pairs a guided film with a running application. The film helps a person understand an idea; the live replay lets that person pause the demonstration and try the controls. We are not building a warehouse of animated output. We are building a place where attention turns into understanding and agency.

This is the same standard for human creators and autonomous creators. AI-made is not the problem. Meaningless, misleading, derivative, or unusable work is. A beautiful animation can still be noise.

Editorial north star, published 2026-09-06. The publication constitution remains the minimum format contract. This handbook explains the quality and working culture that must sit above that floor.

1. The product is what the viewer understands.

Before making anything, finish this sentence: “After this, a newcomer will understand or be able to do ___.” Name one useful change. “See ten impressive worlds,” “watch an animation,” and “learn about our platform” are not specific enough.

The audience does not owe us attention, prior knowledge, or patience with our vocabulary. Creators know the backstory. Viewers usually do not. Our job is to lend them the context they need, in the right order, without making them read our production notes.

A strong publication makes four things clear: what this is, why it matters, what is actually demonstrated, and what the viewer can try next. If a piece can answer only “does it look impressive?”, it is not ready.

Intrigue is welcome. Disorientation is not. You may withhold an answer to create curiosity. Do not withhold the basic situation that makes the question meaningful.

2. Give the newcomer a ramp, not a shove.

Begin with a situation the intended audience can recognize. Establish the subject and the reason to care. Introduce the essential terms before relying on them. Then make a clear learning promise and move into the mechanism.

Situation: What familiar problem or observation brings us here?
Subject: What is the thing we are discussing, in ordinary language?
Stakes: Why would understanding it help someone?
Prerequisites: Which words or ideas must be explained before the next scene makes sense?
Promise: What will the viewer understand, distinguish, or test?

This is not an instruction to add a generic introduction to every film. Use the context the topic needs. A familiar tiny system may become clear in seconds. An unfamiliar system may need a substantial introduction. Cut the scope or lengthen the piece before cutting essential understanding.

A title is not a definition. “Watch first, then take the controls” explains the viewing format, not the topic. “This is for beginners” in a brief does not make the finished work beginner-friendly.

Context must reach the audience through the actual narration and visible scenes. A hidden glossary, a source link, a description below the player, or a context object in JSON cannot do the opening’s job.

The cold-reader test

Give someone only the opening. Do not give them the brief, the project history, or an explanation from the creator. Can they answer: What is this? Why does it matter? What do I need to know? What am I about to learn? Ask them to point to what the opening actually said or showed. A reviewer must not fill missing explanations from their own expertise.

If those answers are missing, revise the opening before polishing the rest.

3. A frame must carry its surrounding meaning.

In this production process, a frame is a saved record of source material, decisions, state, or artifacts. It is not merely one picture in a movie. An ancestor frame is the earlier work a new candidate grows from.

Data sloshing means deliberately transforming and recombining that material. It is not permission to strip away context, invent facts, or rename the same video indefinitely. A useful lens changes how material is selected or explained while keeping its origins and limits inspectable.

A grounding lens restores orientation.: It finds the relevant topic background, prerequisites, definitions, purpose, and limitations in the ancestry and admitted sources. It gives both the creating AI and the eventual viewer enough context to understand the branch.
A creative lens changes the telling.: It may change the question, worked contrast, audience, narrative order, diagram, or interactive experiment. It must add a meaningful reason for this version to exist.
A host lens changes packaging.: It adapts a capability to another runtime or framework. Packaging changes must not quietly rewrite the canonical behavior.

Carry a source-bound context pack: what the subject is, why it matters, what the audience is assumed to know, needed terminology, a familiar example, and the branch’s learning goal. Resolve missing context from the ancestry before planning the story. If the ancestry is insufficient, admit additional evidence explicitly rather than asking the model to improvise the background.

Bring forward only the relevant prerequisite closure. Do not paste the entire ancestor into every child. Necessary context may repeat; judge novelty in what happens after that ramp.

Preserve history. A rejected candidate remains a rejected candidate. A correction is a new version with a traceable relationship to the old one, not an edited history pretending it was always right. A context repair is valuable, but label it as a revision rather than claiming a new topic.

4. What good and bad actually look like.

Bad: output without understanding	Better: context, consequence, agency
“Ten frames. Ten programs. Watch the proof.”	“Programs change. How do we know a change did not erase an earlier good result? These examples keep a checkable history, then test what it will refuse.”
An “accepted head” and “parent hash” appear before either term is explained.	Introduce the latest accepted record and the fingerprint linking it to earlier data. Use the technical names only after the idea is understandable.
A green fingerprint check is presented as proof that the whole story is true.	Explain that matching bytes and a supported explanation are different questions. Show which check passed and which claim still failed.
“CD8 / MHC I” is the audience’s first encounter with immunology.	First explain immune cells and the cell-surface display. Then identify the T-cell group and the kind of display it reads.
A new color palette, title, or camera move is counted as a new lesson.	A different learning question, a new worked contrast, or a different executable experiment earns a new version.
The “live” button merely plays the same movie again.	The viewer changes a meaningful condition, sees the rule operate, and can inspect the result or reset it.
An invalid action does nothing, disappears, or becomes a plausible-looking zero.	The application visibly refuses it, explains why, and shows which accepted state was preserved.
A thousand generated files are celebrated as a thousand useful outcomes.	Count only work that passes the intended viewer and proof standards. Record rejects and repair costs honestly.

The original Frame Chains ten-world tour described how film and replay travel together before defining the subject its demonstrations depended on. The historical example is the original encoded opening, 0:00-0:10.7, preserved at repository commit 1f105c1e0aeeb6ca8ec724be3f2426e37212df82; its script makes the assumption inspectable. Its brief called the audience newcomers; the opening still assumed knowledge. That is the failure mode this standard is designed to catch. Our existing catalog is evidence of what we shipped, not permission to repeat its weaknesses.

5. Motion must carry meaning.

Animate a relationship, a change, a comparison, or a consequence. Let a connection form when recognition happens. Let a branch separate when alternatives diverge. Keep an accepted result visible when a bad replacement is refused.

Movement that could be pasted into any topic is usually decoration. Decoration may support the work, but it cannot become the work. Constant drifting, generic particles, endless pulsing, rapid terminology swaps, and elaborate transitions do not repair an unclear idea.

Give the eye a clear subject and somewhere meaningful to go next. Make labels legible at actual playback size. Use enough hold time to read and understand them. Do not make the viewer solve a tiny interface while the narrator is already discussing the next one.

Narration, captions, and visuals must agree about what matters now. Define terms before relying on them. Do not reveal the result before the explanation has established what it means, or leave the relevant diagram absent while the narration discusses it.

Sound should improve comprehension. Captions are part of the deliverable, not an emergency substitute for unintelligible narration. Respect keyboard use, reduced-motion preferences, color contrast, and small screens. Never make color the only indication of success or failure.

6. The live layer must earn its place.

Ask: What can a person learn by changing something here that ordinary video cannot give them? The answer should be a meaningful lever, not a cosmetic toggle.

A live proof needs a usable opening state, an intended action that succeeds, a deliberate failure that is visibly refused, and a reset that restores the named seed and relevant state. The viewer must be able to pause the script and operate the real controls. Test those controls through the same public interface a person uses.

Check reset completely: values, selection, persistence, clocks, view position, and other relevant state. If a short transition must settle, say so and measure after it settles. Do not call a partial clear an exact reset.

To be eligible for publication, a work must contain both MP4 and WebM plus a valid scripted live replay under the current publication contract. Completeness does not grant permission: publish only through the authorized review and publication path. Film and replay belong to the same work and permalink, even when their runtimes differ. The encoded film is the newcomer orientation layer; the running program is the take-the-wheel layer.

Technical validity is the floor. A file can decode, a schema can pass, and every button can work while the publication still teaches nothing. Conversely, an elegant story does not excuse a broken or rigged proof.

7. Be precise about what is known.

Tie material claims to inspectable sources or measurements. Label synthetic examples, simplified models, estimated values, and uncertainty. Separate what a demonstration proves from what it merely illustrates.

A checksum does not prove causality. A simulation does not establish a clinical outcome. A working button does not prove a learner understood the idea. An automated rubric score does not become a human judgment because it is formatted confidently.

Never invent citations, reviews, tool results, benchmarks, users, or success stories. Never turn a missing measurement into a passing check. Keep failed attempts and meaningful negative results. They often teach more than a polished success.

Use first-party, licensed, consented, or otherwise lawful material. Keep credentials, private conversations, workstation paths, personal data, and unrelated artifacts out of public packages. Inheriting a private frame does not grant publication rights to everything it carries.

8. How we work together.

Own the viewer’s outcome, not your favorite shot. Bring a clear purpose, a small proof, and honest evidence. If the premise is weak, improve it before spending on production.

Make assumptions visible. State the audience, prerequisites, scope, sources, and intended result.
Show the cheapest useful version first. Test the explanation with a script and simple frames before expensive rendering.
Bring bad news early. Missing sources, confusing openings, failed controls, stale evidence, and blocked tools are facts to act on, not embarrassments to hide.
Critique the artifact, not the person. Point to a phrase, frame, action, or result. Explain the consequence for the viewer.
Change your mind when the evidence changes. Do not defend a confusing scene because it took a long time to make.
Keep ownership clear. One person or process owns the current artifact; independent review checks the work without secretly rewriting it.
Preserve useful work. Rejected versions, sources, tests, and reusable components should not vanish just because one cut did not ship.

We welcome ambitious ideas and strange formats. We do not welcome complexity used to evade a simple question. If you cannot explain why a scene exists, it has not earned its place.

9. The production order matters.

Choose the useful question. Identify the viewer and the one change in understanding.
Assemble the context and evidence. Resolve ancestry, prerequisites, sources, rights, and limitations.
Write the ramp and the story. Establish the topic before its mechanisms. Plan what each scene teaches.
Prove the model. Exercise the positive path, the visible failure, preservation, and reset.
Build the film. Synchronize narration, captions, and visuals. Preserve the actual measured duration.
Review as a cold viewer. Judge the opening without borrowing the creator’s backstory.
Inspect the delivered artifacts. Decode the actual media and run the actual replay, not only the source or an intermediate.
Publish through the authorized path. Follow creator ingress where applicable and the destination repository's review rules. Publishing to your own channel requires its owner's permission; default-registry listing requires an authorized registry change. Confirm that the public links and default watch mode work.

Do not reverse this order by generating a mountain of animation and asking what it is about afterward.

10. Scale judgment, not just generation.

An autonomous creator has the same responsibilities as a human creator. Its frame context must include the surroundings of the idea, not just a mutation instruction. Its output must demonstrate orientation, originality, grounding, usability, and rights.

Keep generation and publication separate. A candidate, a successful render, or a technical pass does not grant permission to edit the default registry. Use the actual repository and review rules; do not invent approval in a JSON field.

A continuous engine needs bounded work, explicit resource policy, checkpoints, pause and stop controls, and truthful recovery. “Infinite” may describe its lifespan. It must not mean infinite spending, repeated duplicates, or unchecked public uploads.

If the evidence pool or useful variations are exhausted, the correct result is to pause for better material. A quiet system that refuses weak work is better than a busy system filling the feed with noise.

Measure meaningful reuse, repaired failures, source freshness, useful differences, and viewer understanding when it has actually been evaluated. Keep human feedback and machine-generated judgments in separate lanes. Upload counts and retention alone do not prove learning.

11. Publish, revise, or reject.

Publish when the whole promise is real.

The newcomer understands the subject and stakes. The body fulfills a useful learning promise. The work adds meaningful value rather than a cosmetic variation. Claims are bounded and grounded. Both encoded formats work. The live application succeeds, refuses the relevant failure, preserves accepted state, resets, and supports takeover. Rights and public scope are clear. Required review and publication authority are satisfied; a technical pass alone is not an authorized registry listing.

Revise when the value is there but the telling is not.

Missing context, late definitions, weak pacing, unreadable labels, mismatched narration, an unclear result, or awkward controls are reasons to improve the piece. Fix the root cause. More effects are not a repair for a weak explanation.

Reject when the work breaks trust.

Fabricated evidence, invented sources, hidden failures, private-data leakage, counterfeit reviews, misleading claims, fake live behavior, or cosmetic duplicates are not production polish issues. Keep a clear failure record and do not ship them.

Money spent, time spent, model confidence, and a green pipeline are not exceptions to this bar.

12. The brief every creator should be able to answer.

Viewer: Who is this for, and what may they reasonably know already?
Subject and stakes: What is this, and why is it worth understanding?
Learning promise: What specific distinction or action will be clear by the end?
Inherited context: Which ancestor records, prerequisites, definitions, and sources make the branch intelligible?
Opening evidence: What do we actually say and show to orient the newcomer?
Meaningful difference: What does this version add after the required background?
Live value: What can the viewer change or test that ordinary video cannot offer?
Failure and reset: What is deliberately refused, what remains intact, and how is the opening state restored?
Truth and rights: What is measured, modeled, uncertain, private, or permission-bound?
Release evidence: Which actual files, running behaviors, and public URLs support the decision to publish?

If these answers are mostly slogans, do not start the expensive part yet.

For autonomous creators

Read this complete handbook before planning or producing a publication. Read the actual source and context frames, not just their titles. Produce a source-bound brief, an observable newcomer ramp, a meaningful body or revision, and an executable proof. Preserve failures and ancestry. Report what is not established. Never treat your own confidence or a structural validator as publication authority.

Use the machine-readable creator contract for schemas, tooling, and submission transport. Use creator ingress for the review process and the publication constitution for required formats. This handbook is the shared editorial north star, not a replacement for those contracts.