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

# Features & Modules

> Defining your product's vocabulary so everything else reads in your own words.

The feature catalog is where you tell Superhawk what your product is made of. It is the smallest piece of configuration with the widest effect: every usage read, adoption gap, health factor, and signal is expressed in the vocabulary you define here.

Without it, Superhawk can only talk about raw event names. With it, it can tell you a customer never adopted the clause library.

## Features and modules

* A **feature** is a single capability: contract creation, clause library, approval workflows, e-signature.
* A **module** is a group of features you sell or position together.

Modules matter because entitlement usually works at the module level. Knowing a customer pays for a module and uses none of it is a different conversation from knowing they never clicked one button.

## Setting it up

The catalog is under **Manage** in the classic sidebar, and under **Settings** in the rail.

<Steps>
  <Step title="Open the feature catalog">
    Go to **Manage**, then **Feature catalog**.
  </Step>

  <Step title="Add your features">
    Give each one the name your team and your customers actually use. This name appears everywhere in the product.
  </Step>

  <Step title="Group them into modules">
    Group features the way you sell them, so entitlement and adoption line up.
  </Step>

  <Step title="Map them to product events">
    Connect each feature to the events or metrics that indicate it is being used.
  </Step>

  <Step title="Mark the key features">
    Flag the features that represent real adoption. These are what "Not Explored" is measured against on the account.
  </Step>
</Steps>

## Modules configuration

**Settings → Modules** holds the workspace-level configuration for how CS reads your product: which modules exist, how they map to what is measured, and the definitions the health judgement and signals reason against.

<Note>
  Changes here take effect on the next computation cycle rather than instantly. If you add a feature, give the next scheduled run time to pick it up before concluding the mapping is wrong.
</Note>

## Getting it right

**Use customer-facing names.** If your customers call it "Redlining", the catalog should say Redlining, not `diff_engine_v2`.

**Be honest about what counts as adoption.** If a feature registers usage on page load, every account will look adopted and the signal is worthless. Map it to the event that means the customer got value.

**Keep key features to a genuine few.** If everything is key, nothing is. Five to ten is usually right.

## Related

* [Feature Usage](/accounts/feature-usage) -- where the catalog surfaces
* [Metrics](/customer-success/metrics) -- the numbers behind each feature