Jewelry AI · Acceptance record

Tapping accept is the consent, and the first record of it stays as written

There is no checkbox on the registration or acceptance screens - the wording sits beside the button, and the tap is the act. What the tap produces is a pair of records written together, checked against the document you were actually shown, and left untouched if the same acceptance arrives again.

There is no box to tick

On the registration screen and on the acceptance screen, the acceptance and age wording sits beside the button. A search of those screens for a tick or a switch finds none: the tap is the consent (apps/jewelry-mobile/src/features/legal/legal-contract.ts).

That also means the flow does not require the documents to be opened first. You can proceed straight from the wording to the button, and the screen treats that as the completed act.

This page describes the two screens the evidence covers. It makes no claim about tick boxes or switches on other surfaces of the app.

What is submitted at that moment

Three values travel with the tap, and one of them is checked against another before anything is written.

A fingerprint of the document you were shown.: It is submitted with the acceptance, and it is what the server tests before the submission stands as an acceptance of that text.
The language that text was displayed in.: It is declared as part of the submission rather than inferred afterwards.
An age eligibility declaration, sent as a fixed value.: It is a declaration made by tapping. It is not an age verification and nothing on the server treats it as one.
The fingerprint and the language must agree.: The server compares the submitted fingerprint with the one expected for the declared language, so a client cannot report a text as accepted that it did not display (apps/api/src/auth/auth.controller.ts). The same comparison is applied to the notice recorded at the generation endpoints (apps/api/src/generation/generation.controller.ts:51).

The pair of records, and how the count works

An acceptance is not one row. It is two, written together, and counted together.

Record	What it carries	How it is counted
Terms acceptance	The moment it was made and the language the text was displayed in	Counted only against the current version
Age eligibility	The declaration submitted as a fixed value with the acceptance	Counted only against the current version
The two together	Written in a single transaction, so a half-written state is not expected in the normal path	Both present at the current version means accepted; either one missing means not accepted

A second acceptance does not replace the first

If an acceptance for the same version reaches the server again, the row that already exists is left as it is. The time first recorded and the language read at that moment stay in place (apps/api/src/legal/legal-evidence.service.ts).

The same holds for the notice receipts written from generation requests: a repeat leaves the existing receipt untouched.

One consequence follows directly. Changing the interface language later does not rewrite what an earlier record holds - the record describes what was displayed at the time, not what the app is set to now.

This is a property of how the write is defined on the server. It is not a setting, not a control on any screen, and not something a flow in the app asks you to operate.

What a generation request adds, and how often

Each generation request carries a notice about transfer to the third-party AI provider as a required field, on all four create requests (apps/api/src/generation/generation.controller.ts:83).

The server does not turn that into a record per image. It keeps a single receipt per version and surface, so repeating the same work does not accumulate entries (apps/api/src/legal/legal-evidence.service.ts).

The receipt is written when the request is accepted, before any generation has succeeded. Its counterpart on your side is the short note at the summary step of the create wizard (create-wizard.tsx:699), which is what you see rather than a fresh consent prompt.

Matters this page keeps out

The evidence here is the write path of an acceptance. Several adjacent questions are answered by other mechanisms entirely.

What the documents say, cover, grant or waive. This page describes only what is written down, never what it means.
Which requests are refused while an acceptance is outstanding, and the screen that holds you until it is given - a separate page owns that mechanism.
Where the documents open and which language they appear in, which is decided before an acceptance is submitted and is covered elsewhere.
What actually leaves your device when a generation runs; the notice record shows that a notice was made, not what was transmitted.
How acceptance records are displayed in any internal tool, and how they behave if an account is deleted or exported.
Which text version is deployed at any given time; the code shows a write path, not the running state.

Sources for the statements above

No checkbox and the fixed age declaration: apps/jewelry-mobile/src/features/legal/legal-contract.ts, where the age confirmation is a constant sent with the acceptance.

The pair-of-records count: apps/api/src/legal/legal-evidence.service.ts, which treats an acceptance as current only when both records exist at the current version.

The write that leaves an existing record alone: the same service, where the update path is defined as empty.

Fingerprint against declared language: apps/api/src/auth/auth.controller.ts, and again on the generation side at apps/api/src/generation/generation.controller.ts:51.

The mandatory notice field on the create requests: apps/api/src/generation/generation.controller.ts:83; the note shown to you at the summary step: create-wizard.tsx:699.

Questions

Was anything recorded if I never opened the documents?

Yes. The tap on the button is the act, and neither the registration screen nor the acceptance screen has a separate tick that has to be set first. Opening the documents is not part of what is submitted.

If I accept again, does the record update to today?

No. For the same version, a second submission leaves the existing row as it is: the moment first recorded and the language read then remain. That is how the write is defined on the server, not a choice presented anywhere in the app.

I switched the app to another language. Which language is on file?

The one the text was displayed in when the record was written. A later change to the interface does not rewrite an existing record.

Does every generated image record a fresh consent?

No. The notice field is required on each of the four create requests, but the server keeps one receipt per version and surface, so records do not accumulate per image and no prompt is repeated. What you see is the short note at the summary step of the create wizard.