Public requests and protected delivery
LadVen OS can provide an external person with a request form and a separate protected page for a prepared response. This is a configurable workflow, not a legal service or proof of the applicant's identity.
The shell locale is not proof that the public form and response page are fully
localized: the current frontend inherits Russian complianceIntakeUi labels,
errors, and actions for kk and ky. Keep the four request/response and
recovery screenshot targets planned and source-gated until native dictionaries
and same-locale review pass. For training, use only a human-readable synthetic
request and response recorded in the setup; do not present either name as an
already seeded record. No PII, codes, tokens, or raw IDs.
Two separate routes
- Request form: /public-data-requests/:profilePublicId. The profile publishes its name, description, language, fields, and privacy notice.
- Response page: /public-data-responses/:servingSessionId. The recipient enters a separate delivery code and downloads the prepared file while access is valid.
Do not combine these links or place a delivery secret in a URL, QR code, screenshot, or public task.
Using the request form
- Open the link provided by the organisation.
- Check the profile name, explanation, language, and notice before entering data.
- Complete required fields. A profile can request text, email, or phone and limit response length.
- Submit and fix highlighted fields if validation fails.
- Save the accepted request number. It can be copied, but it does not verify identity or open a response by itself.
The profile accepts only its declared fields: blank optional values are omitted, unknown keys are rejected, and an entirely blank form is not accepted. Each field has its own length limit; the character counter is that limit, not a statutory deadline or processing quota.
An accepted request receives a timestamp and identifier. Repeating the same submission may show a replay state; a payload conflict requires a new submission. The idempotency key remains only in the current page and must not be copied into a URL or note.
If the profile requires verification, the accepted page offers a hand-off to the external verifier. Until that step is completed, a protected response has not been delivered.
Opening a response
Open the separate response link and enter the code sent through a safe channel. The code stays in the open page's memory and must be entered again after a reload.
After successful verification, the page shows the response name, optional expiry, file size, download action, and (when available) a checksum. Check that the file belongs to your request. Do not send the code with the link or post it in a shared chat. An expired, revoked, or unknown session cannot be recovered by repeated attempts.
Errors and recovery
- For an unavailable or disabled profile, retry or contact the organisation through a known channel.
- Correct empty or overlong fields; do not paste secrets into them.
- For an invalid response code, check the keyboard layout and request a new code. Do not share it in a group chat.
- Only the process owner can create a new delivery after expiry or revocation.
- If download fails after opening, retry in the same tab; if it fails again, contact the process owner and do not copy or share the file in an unprotected location.
Language, time, and privacy
The request form follows the language configured on its profile so its fields and chrome do not become mixed. This only holds for a portal-supported language: a profile may store another valid language code, in which case its text and fields can arrive in that language while the page chrome falls back to the portal language. Do not treat that combination as localization proof or use it for screenshot/evidence. The response page follows the browser language or locale hint until content is opened. Displayed dates use the page locale and are not proof of a statutory deadline.
Ask only for necessary personal data; never enter passwords, tokens, or payment details. The organisation must define the fields, reviewer, identity-check method, storage, and deletion policy. A public form does not itself create a legal basis, a complete DSAR register, or a guaranteed regulatory deadline.
Process-owner checklist
Before publishing a profile, check its purpose and contact, minimum fields and length limits, language and notice, staff permissions, identity-check process, delivery expiry/channel, and revocation/deletion steps.
Use synthetic data for training. Never screenshot real request IDs, delivery codes, applicant names, or response contents. Documentation must not promise automatic GDPR, local-law, or contractual compliance.
Related sections