> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/zingg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/zingg/tuning/blocking-strategy.md).
# Blocking Strategies: DEFAULT vs WIDER
Choose between DEFAULT and WIDER blocking strategies to control how Zingg orders candidate fields when building the blocking tree.
{% hint style="info" icon="right-long" %}
**Enterprise only.** Controlled by the `blockingModel` config key (`DEFAULT` or `WIDER`, case-insensitive). If omitted, Zingg uses `DEFAULT`. Community/OSS has no such key - it always behaves like `DEFAULT`.
{% endhint %}
## What each strategy does
Zingg builds a blocking tree greedily. At every node it asks: *of the eligible field/hash-function combinations, which one splits the group into smaller pieces?* That combination becomes the split at this node, and the process recurses into each resulting group.
The **strategy** controls only the *order* candidate fields are offered at each node - never the comparison logic itself:
* **`DEFAULT`** - every node is offered your `fieldDefinition` list in the exact order you configured it. The field listed first is always tried first, everywhere in the tree.
* **`WIDER`** - each node looks at which field its *parent* node just used, and pushes that field to the back of the candidate list for this node, so the very next field in line gets first consideration instead. This repeats going down the tree, so the field that "won" one level isn't automatically favored again immediately below it.
DEFAULT vs WIDER field ordering down the blocking tree
## When to use which
Use DEFAULT when your fields have very different discriminating power
If one field (for example, a national ID or a well-populated postcode) is consistently the best splitter for your data, `DEFAULT` lets that field win at every node where it's eligible. This produces a narrower, more predictable tree built around your strongest signal.
Use WIDER when several fields have similar discriminating power
If your first field only slightly outperforms the second and third (for example, `fname`, `lname`, and `city` all split the data reasonably well), `DEFAULT` can end up leaning on the same field repeatedly down consecutive levels, producing a tree that is deep in one dimension and under-uses the others. `WIDER` forces the next-best field into consideration at the child node, spreading splits across more fields and typically producing a wider, shallower tree.
Use WIDER if verifyBlocking shows large, low-specificity blocks
Large blocks with `DEFAULT` are a symptom of the tree over-relying on one or two fields. Try `WIDER` and re-run `verifyBlocking` to compare block-size distribution and coverage before committing to the change.
## Configure
Set `blockingModel` right after `labelDataSampleSize` when building your Enterprise arguments object.
{% tabs %}
{% tab title="Python" %}
```python
args.setBlockingModel("WIDER")
```
{% endtab %}
{% tab title="JSON" %}
```json
{
"fieldDefinition": [ ... ],
"blockingModel": "WIDER"
}
```
{% endtab %}
{% endtabs %}
{% hint style="success" icon="right-long" %}
**Read more**:
* Set up field definitions and the arguments object this key belongs to → [Configure Zingg](/zingg/running-zingg/configure-zingg.md)
* Check block-size distribution and coverage after changing strategy → [Verify Blocking](/zingg/running-zingg/create-training-data/verify-blocking.md)
* Blocking model concept and how it fits in the pipeline → [Blocking Model](/zingg/zingg-concepts/how-zingg-learns/zingg-models/blocking-model.md)
* Define your own blocking functions for specialized data patterns → [Custom Blocking and Similarity](broken://pages/DWdyf7az3MmhJaVca3k7)
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.zingg.ai/zingg/tuning/blocking-strategy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
