Eazy4 should not ask for passport or Aadhaar files without explaining the reason in plain language first.

The first launch slice proves trust in three places: public pages, upload-step notices, and authenticated support guidance.

This packet keeps those layers consistent so the public hub and the case flow tell the same story.

Passport details are needed to identify the traveller and reduce avoidable data-entry mistakes during case preparation.

Aadhaar is needed when the route or local processing workflow requires identity confirmation or matching support.

Supporting documents should only be requested when they are route-relevant, not as a generic catch-all upload list.

Uploaded passport data may be processed with OCR to reduce manual typing and surface mismatches earlier.

OCR is a support tool, not an irreversible decision maker.

Customers should always be able to review and correct extracted values before continuing.

Documents are handled by authorized Eazy4 team members only.

Internal access is role-limited and tied to the customer’s active case work.

The trust message should explain visibility limits without promising impossible absolute secrecy.

We should explain retention in plain language, not hide it behind legal shorthand.

If deletion or export is requested, the guidance should point to support or the approved account flow rather than promising instant self-serve deletion.

The first launch slice should remain honest about what is manual today and what can be improved later.

The customer uploads the route-relevant files, sees OCR-extracted data, and can correct anything that looks off.

The support desk reviews the case with those uploaded files and the route context in mind.

When clarification is needed, the customer should see a human escalation path without hunting for it.