Runtime Kit keeps product code from tangling by turning package material into two app-facing moves: read named data and call named targets.
Picture a founder shipping a launch screen. The screen needs headline copy, a checklist, a help panel, and a button that asks for the next step. Without Runtime Kit, the screen starts importing data files, helper functions, search code, and setup code. With Runtime Kit, those jobs stay separated.The whole map
01
The package declares records, package-owned bytes, and callable targets.
02
Runtime Kit checks the package and turns source material into active local truth.
03
The app sees data names and action names, not package setup.
04
React reads data, sends requests, renders states, and stays out of setup machinery.
| Concept | Plain meaning | Public names |
|---|---|---|
| Package file | The package says what it brings. | things-to-store-and-run.json with record, stored_bytes, or slot things. |
| Named data read | The screen asks for data that Runtime Kit already prepared. | useBitfieldData(inputName) returns { data, loading, error }. |
| Callable target | The user asks a named target to do work. | sendRequestToBitfieldTarget({ target, payload }, signal?) returns reply bytes. |
| Local state | The device has active Bitfield material. | Customer-visible areas under ~/.bitfield, not hand-edited app data. |
| Placeable surface | A shell places UI by descriptor, not by product branches. | Surface descriptor names region, component key, data names, and targets. |
Package file
You want your welcome copy to ship with a package, not as a hardcoded React string.A package file is the file that says what the package owns. It can declare package-owned records, package-owned bytes, and callable targets.Anti-pattern
Next links
| Need | Page |
|---|---|
| Tutorial | Package to screen |
| Recipe | Package set with one record |
| Reference | Package file |
Named data reads
The launch screen wantswelcome-copy, but it should not care which package record, file, or derived value produced it.A named data read is a named app-facing value. The component asks for the name and renders the public states.Anti-pattern
Next links
| Need | Page |
|---|---|
| Tutorial | Package to screen |
| Recipe | React surface for package data |
| Reference | Runtime Kit API |
Callable targets
The user clicks “Suggest next step.” The app should calllaunch.next-step, not import the target implementation.A callable target is a stable public name for work. Runtime Kit sends bytes to that target and gives the app reply bytes.Anti-pattern
Next links
| Need | Page |
|---|---|
| Tutorial | Package to screen |
| Recipe | Callable package slot |
| Reference | Runtime Kit API |
Local state ownership
One customer says the feature works on a laptop but not a phone. You need to know whether the device has the package, activation, and local Runtime Kit material, without telling the customer to edit files.Local state is customer-visible evidence, not a place for manual repair.Anti-pattern
Next links
| Need | Page |
|---|---|
| Guide | Local state |
| Troubleshooting | Troubleshooting |
| Reference | Package file |
Placeable surfaces
The product grows from one launch screen to launch, help, support, and settings. The shell should not grow a branch for every business area.A placeable surface descriptor says where a surface can appear and which data names or targets it may use.Anti-pattern
Next links
| Need | Page |
|---|---|
| Concept | Placeable surfaces |
| Recipe | Placeable surface product loop |
| Reference | Runtime Kit API |