> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/guides/verticals/beauty-and-nails/intake.md).

# Intake without sensitive data

Why a salon labels every intake field standard, what the fail-closed default does, and the one case where a salon still needs the sensitive label.

## Standard means conversational

`sensitivity` is the contract's channel-policy hook. A field labeled `standard` may be collected by the AI concierge directly in the WhatsApp conversation; a field labeled `sensitive` is never exposed on untrusted channels. For a salon, everything in the previous page's schema is preference data: nail shape, color, whether removal is needed. Labeling those `standard` is what lets the concierge ask them in chat, which is the whole point of a light salon intake.

## The default works against silence

The contract is fail-closed: **an omitted `sensitivity` is treated as `sensitive`**. If you publish a field without the label, it gets maximum protection and the concierge will not collect it conversationally. So a salon schema must say `"sensitivity": "standard"` on every field, out loud. This is deliberate contract design: the safe failure mode for a forgotten label is over-protection, never leakage.

## When a salon still needs the sensitive label

Sensitivity follows the data, not the vertical. If your platform asks a clinical question, the clinical label applies even in a salon:

```json
{ "key": "product_allergies", "label": "Any allergies to nail products?", "kind": "longText", "required": false, "options": null, "sensitivity": "sensitive" }
```

Allergy information is clinically sensitive wherever it is collected. Declaring keys like `allergies`, `medical_history`, `medications`, or `diagnosis` as `standard` fails the `intake.sensitivity_labels` conformance check. If you want the details of how sensitive answers are handled, the [medicine guide](/guides/verticals/medicine/sensitive-intake.md) is the deep end.

## What conformance proves here

* `intake.declaration`: `IntakeForms` is declared and at least one service publishes a well-formed schema.
* `intake.sensitivity_labels`: no clinically sensitive key is labeled `standard`.
* `intake.appointment_round_trip` and `intake.undeclared_key_refusal` run against your booking flow; the [next page](/guides/verticals/beauty-and-nails/booking.md) shows both.

Next: [Book and confirm](/guides/verticals/beauty-and-nails/booking.md).


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nerovasystems.com/guides/verticals/beauty-and-nails/intake.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.