> ## Documentation Index
> Fetch the complete documentation index at: https://docs.maximem.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Your Own Field Types
> Synap ships detection for common identifier formats. When your data has a format we do not know about, an asset tag or a policy number, you describe it yourself with a few examples and pick the category it belongs in. No release and no ticket.
**Read this before you rely on it.** A field type you describe is detected in the **Try it** test box on the Sensitive data page, so you can see exactly what it would match and what your policy would do with it.
It is **not yet applied to live ingestion or to search**. Content flowing through Synap today is matched against the shipped field types only. Describing your own field type records it, shows you what it would catch, and prepares the policy, but it does not yet change what happens to your traffic.
If you need a custom format protected in production now, talk to us at **[support@maximem.ai](mailto:support@maximem.ai)** rather than assuming the definition is live.
## When you need one
Synap ships detection for formats that are common across products: email addresses, phone numbers, card numbers, government identifiers, IP addresses, API keys. It does not ship detection for formats that are specific to your business.
An asset tag, a policy number, an internal order id, a claim reference: these identify a person or a case in your product, they appear all over your content, and nobody outside your company would recognise the shape. That is what this is for.
## Describing one
In the Dashboard, go to **Sensitive data**, then the **Your own field types** tab.
Give it the name your team already uses, in plain words: "Asset tag", "Policy number", "Claim reference". The name is what appears in your findings list, in the test box, and in your audit trail, so it should read like something a person would say out loud.
Names must be unique and cannot reuse the name of a field type Synap already ships.
Every field type sits in one of the [eleven categories](/guides/pii-protection#the-eleven-categories), and the category is what carries the setting. Picking the category is the decision that matters, so see the guidance below.
You can move it to a different category later, and the setting follows it.
Paste two or three real examples, one per line:
```text theme={null}
AST-00123
AST-99881
AST-40027
```
Synap builds a pattern from the *shape* of what you give it: which positions are letters, which are digits, how long each run is, and where the separators sit. Three asset tags produce a pattern that matches asset tags.
Save, then open the **Try it** tab and paste text containing one of your identifiers. A match appears badged as **your field type**, with what your policy would do with it at each destination.
If the tab shows your field type as **inactive** with "not detected yet, needs examples", no usable pattern could be built from what you gave. Add more examples, or examples that are more alike. Synap will not fall back to a pattern that matches everything, because a rule that fires on all text buries you in false alarms while looking like the feature working.
***
## Writing examples that work
The pattern is built from structure, not from meaning. That has three practical consequences.
**Cover every shape your identifier takes.** If asset tags are sometimes `AST-00123` and sometimes `AST-00123-R`, give at least one of each. Each distinct shape you provide becomes one thing the pattern will match; a shape you never showed will never be found.
**Give examples of the same thing, not a grab bag.** Three unrelated strings produce a pattern that matches those three shapes and nothing else, which is honest but not useful. Three genuine examples of one format produce a pattern for that format.
**The more distinctive the shape, the better it works.** `AST-00123` has a literal prefix and a fixed digit count, so it matches almost nothing else. A bare six-digit number matches every six-digit number in your content, including quantities, order totals, and years in a row. If your identifier is a bare number, expect false alarms, and check the test box before you protect it.
A few things to know:
* Up to 20 examples. Examples longer than 128 characters are ignored.
* Examples are used to build the pattern and are never returned by the API. The dashboard shows how many you gave, not what they were.
* Changing the examples means updating the field type; the pattern is rebuilt from what you save.
***
## Picking the category
The category decides the setting, so pick by asking **"what should happen to this value?"** rather than "what is it technically?".
| If it... | Put it in |
| --------------------------------------------------------- | ---------------------- |
| Identifies a specific person by itself | **Formal Identity** |
| Is a way to reach a person | **Contact Info** |
| Is money-related: an account, a card, a payment reference | **Payment Info** |
| Says something about someone's health | **Health** |
| Names a place precisely enough to find someone | **Location (fine)** |
| Names a broad area only | **Location (coarse)** |
| Identifies a device, a session, or an account online | **Device and Online** |
| Would let someone in if they had it | **Secrets** |
| Says something about origin, belief, or affiliation | **Origin and Beliefs** |
| Is a person's name or a direct stand-in for it | **Raw Identity** |
| Is an encoded biometric template | **Biometric** |
Two rules of thumb:
* **When it is close, pick the stricter one.** A category is a default you can override per field type later, and starting stricter costs you nothing visible: a value that is protected and revealed straight back to your app reads identically to one that was never protected.
* **Do not invent a category for a field type that only matters to you.** If an order id genuinely needs different handling from everything else in Formal Identity, put it there and set a per-field-type exception on the advanced view.
**Secrets is not the floor.** Putting a field type in Secrets applies whatever setting you gave that category. The floor is a fixed list of seven shipped field types that are never kept for anyone, and a field type you define cannot join it. If you have a secret format that must never be stored, set the category to **Do not store it**.
***
## What happens next
Once your field type is detected, it behaves like any shipped one. It appears in your findings list with counts, it appears in the test box, it takes the setting from its category unless you set an exception, and if you protect it, it gets an alias like everything else. Aliases for your own field types are prefixed `CUSTOM`.
Removing a field type stops it from being detected going forward. Memories already written are unaffected, and any placeholders already in them keep resolving.
## Next steps
The categories, the settings, and what detection can and cannot do.
The findings list, the test box, and approving a policy.