# Phase 14 Demo Form Contract

## Approved business fields

The implementation preserves the Phase 9 contract exactly: `fullName`, `workEmail`, `company`, `fleetSize`, optional `market`, optional `preferredLanguage`, optional `message`, `idempotencyKey`, and `source`. No phone, job title, location count, revenue, marketing profile, or lead-scoring field was added.

Fleet-size values are `1-9`, `10-24`, `25-49`, `50-99`, `100-249`, and `250+`.

## Transport envelope

The JSON submission body contains an approved lead object and a separate non-business guard object. The guard contains an empty honeypot and the form-open timestamp. Both objects reject unknown fields. The timestamp is not treated as authoritative identity or anti-fraud evidence.

## Validation

Client validation improves correction. The same strict Zod schema is executed on the server. Text is trimmed, repeated whitespace is collapsed, email casing is normalized, lengths are bounded, enum values are allowlisted, and unknown fields are rejected. Email validation is deliberately practical rather than a theatrical reenactment of the entire email RFC.

## State machine

`idle → validating → submitting → success | recoverable_error | terminal_error`

A pending submission disables repeat activation. The same idempotency key is retained for a retry after a recoverable transport failure. Success is rendered only after adapter acceptance.

## Privacy and consent boundary

The local adapter discards the payload and does not create a lead. The operational notice states this explicitly. Final privacy notice, legal basis, acknowledgment, marketing opt-in, retention, and deletion behavior remain blocked by P9-003. Production submission cannot be enabled by the shipped configuration.