Forms Intake, Consent, Rate Limit, and Inbox Handoff

1. Do not confuse HTTP success with accepted intake

A form can return 200 or 202 while fields are invalid, the processing basis is unbound, abuse controls are incomplete, or downstream delivery later fails. Submission transport is one event; the final intake decision is assembled from separate typed states.

2. CON-008 ownership boundary

CON-008 owns the form-intake contract, purpose/basis/consent evidence, rate-limit decision, idempotent submission identity, and inbox handoff. CON-006 owns routes, CON-007 workspace versions, CON-009 SEO records, and CON-010 rollback/monitoring.

3. Version the form contract

form_id may remain stable, but material changes to schema, purpose, or consent copy need an explicit form_version. Historical submissions must bind to the version actually shown at collection time, not whichever version is newest today.

4. Validation is an independent state

Server-side validation should produce a typed result such as PASS, FAIL, or UNKNOWN when evidence is missing. A successful transport response must not coerce FAIL or UNKNOWN into valid input.

5. Record processing purpose and the declared basis separately

For every purpose, preserve an explicit record of why the data is collected and which basis is being relied upon. This lesson does not decide the legally correct basis; it prevents a missing or unbound basis from disappearing inside a generic success state.

6. If consent is used, preserve reconstructable evidence

European Commission guidance says consent used under the GDPR must be freely given, specific, informed, and unambiguous, with withdrawal possible. The ledger therefore binds the displayed consent-text version, affirmative action, and withdrawal path. This is general EU guidance, not legal advice for every form or jurisdiction.

7. Never rewrite historical consent copy

If an opt-in changes from v2 to v3, an older submission must not be silently relabeled as v3. Stored evidence must retain the version displayed at collection; a mismatch is a repair condition, not a convenience update.

8. Treat minimization and retention as intake evidence

Abuse controls and analytics do not justify indefinite raw-data retention. Keep only what the purpose requires, redact PII from logs where possible, and assign a bounded retention_class so the handoff remains auditable.

9. Rate limiting is not one magic signal

OWASP recommends layered anti-automation controls: rate limits/quotas on appropriate keys plus logging and other signals. Do not turn one IP, CAPTCHA, or score into universal authority; record the rate_limit_key, window, and explicit decision.

10. Do not convert a bounded limit into a global ban

One source hitting a threshold does not prove every request is abusive. Preserve the scope of the key and decision: a throttled source may be BLOCK, while a separate legitimate session or identity below its threshold can remain ALLOW.

11. Idempotency protects one logical intake

Users retry after timeouts. submission_id and idempotency_key should let the same request resume one logical intake. Creating two independent records for one legitimate retry is a duplicate-risk failure.

12. Inbox handoff needs a versioned envelope

Before downstream delivery, create a handoff_envelope_id bound to the submission, destination, payload/version, and provenance. Provider acceptance is a delivery attempt, not final receipt evidence.

13. Provider ACCEPTED is not DELIVERED

An email or workflow API can accept a message and later report bounce or delivery failure. The handoff must then remain RETRY_PENDING or another bounded state instead of pretending the item was delivered.

14. Negative example and transfer

Add a file attachment and a new optional marketing purpose, then simulate a legitimate retry and later provider failure. Bind the new form/purpose/consent versions, keep the retry as one logical intake, preserve the abuse decision, and keep the handoff RETRY_PENDING until delivery evidence closes.

15. Auditable output

Form Intake Decision Ledger & Handoff Envelope v1 records Form/Version, Submission/Idempotency, Validation, Purpose/Basis, Consent Evidence, Withdrawal Path, Retention, Rate-Limit Key/Window/Decision, Abuse State, Handoff Envelope, Destination, Delivery Attempt/Status, Retry, PII Redaction, Decision, Reason, and Provenance. HANDOFF_COMPLETE is bounded to that exact closed evidence set.