Start Here — RevFramework¶
What RevFramework is
RevFramework is not a single script or drop-in component.
It is a set of modular systems designed to be:
- composed
- extended
- adopted incrementally
This page shows you how to approach the framework, so you can start small, use what you need, and avoid extending the wrong layer.
The Big Picture¶
Every system follows the same documentation pattern:
Overview
→ Mental Model
→ Integration Surfaces
→ Public API
→ System Guarantees
→ FAQ
→ Teachable Panels
→ Samples
You do not need to read everything.
Start with the system you are using.
Go deeper only when you need to.
If You’re New¶
Start here:
- Overview
- Mental Model
- Teachable Panels
- Samples
👉 Stop here unless you need to extend something.
If You’re Integrating¶
Start here:
- Mental Model
- Public API
- Teachable Panels
- Samples
- Runtime Code
If You’re Extending¶
Start here:
- Mental Model (mandatory)
- Public API
- FAQ
- Integration Surfaces
- Teachable Panels
- Samples
Teachable Panels¶
Teachable Panels are more than demos.
They are:
- live, in-editor learning tools
- built against the public API
- designed to show real runtime behaviour
- useful for checking how a system is expected to behave
Source of truth
If documentation and Teachable Panels disagree, trust the panel behaviour first.
If Something Isn’t Working¶
Check in this order:
- FAQ
- Teachable Panel behaviour
- Sample scene
- Mental Model
- Public API
Runtime vs Docs vs Teaching¶
| Layer | Purpose |
|---|---|
| Runtime | Actual system code |
| Documentation | Explanation, contracts, and guarantees |
| Teaching | Live validation and learning |
Mental Model vs Public API¶
| Mental Model | Public API |
|---|---|
| Where logic belongs | What you can call |
| Architecture rules | Stable interfaces |
| How the system thinks | How you integrate safely |
You usually need both.
Why It Works This Way¶
Most of the reasoning lives beside the code it governs — in the documentation on a method, and in the README in each folder.
A handful of decisions are the exception. They are visible in your project long before you reach any explanation of them, and without one they read as mistakes: where the framework installs, why the scene services are large single files, where authority deliberately stops.
Those have their own section on the site. Read it when a choice looks wrong and you want to know whether it was considered:
Samples¶
Samples are:
- runnable
- editable
- intentionally focused
They are meant to be inspected, copied, and modified.
Cookbook¶
Samples and Teachables show you one system working. The Cookbook shows you several working together — compositions built only from public seams.
Use it when:
- you are comfortable with a system and wondering what else it can reach
- you want to see a composition before committing to designing one
- you want the traps someone else already hit
It is on the website, not in this package — deliberately. Recipes are reference implementations to copy, adapt and own, not part of the supported runtime surface.
What You Can Skip¶
You can skip:
- systems you are not using
- internal folders
- advanced samples
- integration pages for systems you do not own
One Rule¶
If you are unsure where something belongs:
👉 go back to the Mental Model
TL;DR¶
TL;DR
- Start with Overview → Mental Model
- Use Teachable Panels to see behaviour live
- Use Samples to learn by doing
- Use the Cookbook to see systems composed
- Use Public API to integrate safely
- Use FAQ to avoid wrong extension points
RevFramework is designed to prove behaviour, not just describe it.