> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bitfield.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Slots

> What a Bitfield slot is and why slots keep features from tangling together.

<div className="bf-article">
  <p className="bf-lead">
    A slot is a named package target your product can ask Bitfield to run.
  </p>

  A screen has a button: "Find the next step." The screen should not import the search code, the ranking code, the package setup, or the storage details. It should send a named request and handle the reply.

  <div className="bf-flow" aria-label="Slot request flow">
    <div className="bf-flow-step">
      <span>App</span>
      <strong>Send request</strong>
      <p>The app names a target and sends payload bytes.</p>
    </div>

    <div className="bf-flow-arrow">→</div>

    <div className="bf-flow-step">
      <span>Slot</span>
      <strong>Own work</strong>
      <p>The slot implementation owns how the work happens.</p>
    </div>

    <div className="bf-flow-arrow">→</div>

    <div className="bf-flow-step">
      <span>Reply</span>
      <strong>Return result</strong>
      <p>The app receives a reply without importing private setup.</p>
    </div>
  </div>

  A feature should be able to call named work without taking a dependency on the private code that performs it.

  The slot might answer a question, transform data, render a view, call another system, or do work in the background. The important part is the public call. The app calls the slot by name. The slot owns how it does the work.

  ## Why slots exist

  Without slots, features start importing each other's implementation files. That feels simple at first. Then the product grows, and one feature directly depends on another feature's storage layout, input names, failure handling, and release timing.

  Slots keep that from turning into every feature depending on every other feature. A feature sends a request to a slot. The slot replies. The feature does not import the slot's private code or copy its private rules.

  ## The model

  <div className="bf-grid">
    <div className="bf-card">
      <strong>A slot has a name.</strong>
      The name is the public target. App code can call that target without knowing the private implementation.
    </div>

    <div className="bf-card">
      <strong>A slot has methods.</strong>
      Methods are the public actions the slot accepts, like a query or a command.
    </div>

    <div className="bf-card">
      <strong>A slot has its own setup.</strong>
      The package decides how the slot runs. The app does not need those details.
    </div>
  </div>

  ## What the app sees

  The app-facing surface stays small:

  ```ts theme={null}
  await sendRequestToBitfieldTarget({
    target: 'product.search',
    payload: { query: 'camera' },
  });
  ```

  The app sends a target and payload. Bitfield gets that request to the right runnable piece and returns reply bytes.

  ## What this prevents

  Slots prevent feature code from importing another feature's private code. That matters because private details change. Public slot names should stay steady.

  ## Common mistakes

  | Mistake                                         | Why it hurts                                                    | Better path                                                 |
  | ----------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------- |
  | Importing the target implementation into the UI | The feature boundary collapses                                  | Use `sendRequestToBitfieldTarget(...)`                      |
  | Giving every feature a custom connection path   | The product becomes hard to change                              | Use named targets and package files                         |
  | Treating slots as storage records               | A slot is a callable package target, not the stored data itself | Read [Database and runtime](/concepts/database-and-runtime) |
  | Hiding failure handling                         | Real target calls can fail                                      | Read [Send a request](/runtime-kit/send-request)            |

  ## Next

  * Send an action request: [Send a request](/runtime-kit/send-request)
  * Declare a callable slot: [Callable package slot](/runtime-kit/cookbook/callable-package-slot)
  * Look up request behavior: [Runtime Kit API](/reference/runtime-kit-api)
</div>