Privacy Policy

IMPORTANTWhat this document is

This is the same privacy policy as the one published in Korean at /ko/privacy.html, stated in English. One processing operation, one set of facts, two languages. Where the two texts differ, the Korean text prevails, and a difference is a defect in this document rather than a second policy. Please report one to contact@decisionproof.io.kr.

The Korean instrument marks facts that may be adverse to a user with the label 「중요」. The same passages are marked IMPORTANT here, in the same places.

Controller information

디플런트 (the "company") establishes and publishes this privacy policy under Article 30 of the Personal Information Protection Act, in order to protect the personal data of data subjects and to handle related grievances promptly and smoothly.

Where the content of this policy differs from the content of a contract concluded between the company and a data subject, the one more favourable to the data subject applies (Personal Information Protection Act, Article 30(3)).

Change notice

Under Article 30(2) of the Personal Information Protection Act and Article 27(3) of the Terms of Use, the company publishes the content of this amendment and its effective date as follows.

• Effective date — 20 August 2026. It is the same effective date as the immediately preceding version (en-20260820-8); this amendment raises only the serial number of the identifier within that same effective date.
• Change 1 — the introduction of an advertising tag for measuring advertising performance and conversions. The company has added or amended the purposes of processing (Article 1(1)5), the categories processed (Article 2, item 8), provision to a third party (Article 4(3) item 2), the reasons for not listing a provider as a processor (Article 5(5) and (6)), cross-border transfer (Article 6(1)6 and (2)) and automatic collection devices (Article 10). The tag runs only where a user has chosen Agree on the advertising consent banner, and before that no request to the advertising provider occurs. If you refuse, this website and the company's service continue to work in full.
• Change 2 — a specific correction to what was said about the preceding version (Article 14(3)). The former text described the immediately preceding version as the first published version, which applied from 5 August 2026; the immediately preceding version is in fact en-20260820-1. The company corrects that.
• Change 3 — the introduction of a site-usage analytics tool, a correction to the domains the advertising tag actually calls, and the further disclosure that it also builds audience lists. The company (a) adds site-usage analysis as a purpose of processing (Article 1(1)6); (b) corrects the former text, which said the browser calls a single advertising-provider server, www.googletagmanager.com — it in fact calls several domains (Article 2 item 8, Article 6(1)6, Article 10(1)); and (c) further discloses that the advertising tag is used not only for conversion measurement but also to build audience (remarketing) lists. The company did not disclose (b) or (c) before this amendment. The advertising consent obtained on that earlier disclosure therefore ceases to have effect at this amendment, and the company asks each user to choose again on the new disclosure (Article 10(4) and (5)). Consent is also now split into site-usage analysis and advertising measurement, each separately choosable.
• Change 4 — a means of withdrawing consent, and deletion of the identifiers on withdrawal. Until now, once you chose, the banner did not come back, and the only route this policy offered for choosing again was clearing this site's stored data in your browser — which also clears the session storage in Article 10(2), so it logged you out. Consent took one click and withdrawal did not, and the company assesses that as falling short of the requirement that withdrawal be as easy as giving. This amendment (a) puts a Consent settings control in the footer of every page that carries the banner, so you can choose again at any time, and (b) deletes the identifiers a purpose has already stored when you refuse it (advertising: the cookie _gcl_au and the local-storage value _gcl_ls; analytics: the cookies _ga and _ga_DRZ61CTNL9). Article 6(2) items 6 and 7 and Article 10(1), (4) and (5) are amended accordingly.
• Change 5 — correction and disclosure of advertising-purpose domains being called even where only Site usage analytics had been chosen, and new disclosure that the consent state is transmitted to the recipient. On 22 August 2026, measuring in a real browser with Advertising measurement NOT chosen, the company found that the user's browser was calling advertising-related paths at https://stats.g.doubleclick.net and https://www.google.co.kr. That differed from what Article 1(3) and Article 10(1) of this policy promised — that choosing one does not run the other. The cause was that the company's code withheld the advertising configuration without telling the advertising provider that the purpose had been refused. The company corrected the code the same day so that a refusal is transmitted as denied for advertising storage, use and personalisation, and re-measured the same way afterwards, confirming that neither of those two domains is called and that the analytics recipient domain is https://www.google-analytics.com (Article 6(1) item 7). The company cannot undo the calls made before the correction, and does not state that it can. Because that correction newly causes the consent state you chose to be transmitted to the recipient, it is disclosed at Article 10(5). The company applied the code correction before publishing this amendment. Stopping processing already under way was judged better for users than disclosing first, and for that interval this policy did not disclose the transmission of the consent state. The company records this rather than concealing it. In addition the company (a) added _gcl_aw, _gcl_dc and the _gac_ family to the identifiers deleted on refusal, (b) made those identifiers be deleted when a page is opened with no valid consent, and (c) corrected which of the four cases the sentence "no request arises until you choose again" belongs to — (d), not (c) (Article 10(4) and (5)). Consent taken on the earlier disclosure ceases to have effect at this amendment, and the company asks users to choose again on the new disclosure.
• Change 6 — correction of factual errors found by a quality check after the fact. Immediately after the -5 amendment the company compared this text against the system again, and corrects the following. (a) Article 10(1) stated that the analytics identification cookies are created and read by the advertising provider and live for about 90 days. The party is the analytics provider, the company has not confirmed their lifetime, and about 90 days belongs to the advertising cookie. It was an artefact of the analytics sentence being inserted later. (b) Article 1(3) cited Article 2 item 9 for what the browser passes to the analytics provider. Item 9 is demo executions; the correct citation is item 8. (c) The company now transmits the consent state itself to the recipient, and that had not been added to the item lists for third-party provision and cross-border transfer. It is added to each. (d) Article 10(5) said only that a refusal is transmitted marked as denied, which could be read as saying something is transmitted even when everything is refused. In that case no script runs and nothing is transmitted. (e) The observed-domain lists omitted https://stats.g.doubleclick.net and https://analytics.google.com. Re-measuring live on 22 August 2026 with both purposes chosen, the company observed eight domains, and corrects that list and Article 6(1) item 7. It also newly records that the analytics recipient domain depends on the consent state. (f) The identifiers named in Article 6(2) had not followed the wider set adopted in -5. All six were found by the company's own check, not reported by a user. The company records what it found together with when it began to be wrong. Consent taken on the earlier disclosure ceases to have effect at this amendment, and the company asks users to choose again on the new disclosure.
• Change 7 — disclosure that choosing Advertising measurement alone still produces one analytics transmission. On 22 August 2026 the company measured a browser on which Advertising measurement had been chosen and Site usage analytics had not, and found that a single page-view record was nevertheless being sent to the analytics provider. The cause is that the advertising provider and the analytics provider are the same provider, and that provider has merged the two tags into one, so loading the advertising tag carries the analytics destination with it; withholding the analytics configuration, which the company's code already does, does not prevent it. No analytics cookie is stored in that case. The company accordingly corrects Article 1(1)6 and (3), Article 2 item 8, Article 4(3), Article 6(1)7 and Article 10(1). The earlier text said that choosing one does not enable the other; that was true in one direction only, and the company had not disclosed the other direction before this amendment. Consent taken on the earlier disclosure therefore ceases to have effect at this amendment, and the company asks users to choose again on the new disclosure.
• Change 8 — correction of the same matter where Change 7 did not reach. The preceding amendment (en-20260820-7) disclosed that choosing Advertising measurement alone still produces one analytics transmission, but several passages elsewhere in the same document still read the opposite way. The company corrects Article 1(1)6, the scope label on Article 2 item 8, Article 4(5), the opening of Article 6(1) and item 7's heading, timing and refusal rows, and Article 6(2) item 7. Two of them were the “How to refuse” rows of Article 6, which is where a user reads when deciding whether to refuse; they omitted the case where Advertising measurement alone has been chosen. Nothing new is processed and the change of substance is the preceding one; this amendment makes the rest of the document say it. Consent taken on the earlier disclosure ceases to have effect at this amendment, and the company asks users to choose again.
• Change 9 — listing the domestic payment gateway (Toss Payments Co., Ltd.) as a processor. Article 5(4) previously stated that the company did not list "one domestic payment gateway" as a processor, and gave as the reason that its credentials are separated, so the code path cannot execute. That statement is still true as at this amendment. The company has not opened the domestic payment route and has passed no personal data to that provider. The company is listing it now because the disclosure has to come before the processing: the consignment begins at the moment of the first payment, and amending the policy at that moment would already be late. Accordingly the company (a) adds Toss Payments Co., Ltd. to the table of processors in Article 5(1), together with the fact that the consignment has not yet begun; (b) removes that provider from Article 5(4); and (c) states in Article 5(5)-2 why the domestic payment gateway is listed while the foreign payment provider is not, and what the company has not yet confirmed about that distinction. This amendment does not begin any new processing, and does not describe processing that has not begun as if it had. A processor has nevertheless been added, so consent obtained on the previous notice ceases to have effect at this amendment, and the company obtains a fresh choice on the new notice.
• The full text of the immediately preceding version — https://decisionproof.io.kr/legal/privacy/en-20260820-8.html

Before this amendment is published, the company does not place the analytics provider's script on the website and does not display the new consent banner. The legal basis in Article 6(1)6 and (1)7 arises only from the time those matters are disclosed in this policy and consent has been obtained from the user.

IMPORTANTImportant notice (please read this first)

The following four facts may be adverse to a user. The company does not conceal them and states them as they are. The scope within which the company performs deletion on the expiry of a retention period is confined to the items listed in Article 7(3) and 7(6), and no part of this policy is to be read as meaning that the company deletes, or destroys after a period, any other personal data.

1. The function that transmits execution requests to an AI model provider in the United States was suspended on 4 August 2026 and resumes on 20 August 2026, the effective date of this policy. This statement is how the company records the resumption and its date in this policy; the resumption follows it. However, content already transmitted before the suspension is not recovered, and from the resumption date subsequent execution requests are transmitted again. See Article 6(1)1 for detail.
2. Unlike item 1, the act of visiting this website and the enquiry e-mail you send the company are still being transferred abroad now. When you visit the website your IP address and browser information reach the overseas servers of the content-delivery provider, and because that happens before any of the company's pages run, the company has no means of blocking it after the fact. The content of an enquiry e-mail is stored on the servers of a mailbox provider located abroad. In addition, from the effective date of this policy, the order acknowledgement the company sends you when a payment is confirmed is also sent through that same provider, so the recipient address and the content of the notice are transferred abroad. There is no way to refuse this transfer other than not purchasing a paid plan. See Article 6(1)4 and (1)5 for detail.
3. The scope within which the company performs deletion on the expiry of a retention period is confined to execution result artifacts and execution inputs. There is not yet a procedure for deleting the other records stored in the database (account and tenant records, payment records, authentication and access records, e-mail notice and send-result records, execution metadata). Execution inputs are stored unencrypted, in plaintext, until they are deleted, and are deleted 30 days after the execution completes. That is a logical deletion and not cryptographic erasure. The refusal of result lookups after 30 days is in itself an access block and not a deletion, but the company also states that deletion of the result artifact and of the execution inputs begins at that same point. See Article 3, Article 7 and Article 8 for detail.
4. The hash values of IP address and user agent stored in the authentication request records are pseudonymised personal data and are not anonymised information. The company manages them as personal data. See Article 9 for detail.

A caution about what you submit. The company's systems do not reject additional input fields that are not defined; they store them with the execution record. As item 3 says, inputs are held in plaintext until they are deleted, the inputs of an execution that never completed are not deleted, and from 20 August 2026 the function in item 1 resumes so questions and context are again transmitted abroad. Please do not enter information that is not necessary for using the service, including the personal data of third parties.

Article 1 (Purposes of processing personal data)

(1) The company processes personal data for the following purposes. It does not use personal data it processes for any purpose other than these, and where a purpose of use changes it takes the measures the law requires, including obtaining separate consent.

1. Registration and account management — confirming an intention to register, identifying and authenticating a user, maintaining and managing membership, preventing improper use of the service, giving notices, and handling grievances
2. Provision of the service — receiving and processing execution requests and providing result artifacts, settling usage charges and enabling usage review, and reviewing refund requests
3. Responding to enquiries, resolving disputes and handling complaints — establishing the facts, notifying the outcome, and preserving records
4. System security and improvement of the service — retaining authentication request records, error records and audit evidence
5. Measurement of advertising performance and conversions — measuring the performance and conversions of the online advertising the company runs, adjusting how that advertising is served, and building the audience (remarketing) lists the advertising provider operates. Processing for this purpose takes place only where a user has chosen Agree on the advertising consent banner on the website; where you choose Refuse, or have made no choice, no processing for this purpose occurs (see Article 4(3) item 2, Article 6(1)6 and Article 10).
6. Site-usage analysis — counting how this website is used (which pages are visited, how long is spent on them, where visitors arrive from) in order to improve the layout and the wording of the guidance. Processing for this purpose takes place where a user has chosen Site usage analytics on the consent banner, and to the extent of one page-view record where Advertising measurement alone is chosen (Article 1(3)); where you have not chosen it, no processing for this purpose occurs. This consent is separate from the advertising consent in item 5, and you may choose only one of the two (see Article 4(3) item 3, Article 6(1)7 and Article 10).

(2) The company processes the name, e-mail address and contact details of a corporate customer's staff to the extent necessary for concluding and performing the service contract, providing the service, responding to enquiries and dealing with disputes. Processing within that scope rests on Article 15(1)4 of the Personal Information Protection Act and no separate consent is obtained. Where the company wishes to use such data for a purpose beyond performance of the contract — marketing, promotion, notification of new services, or analysis for service improvement — it will, under Article 15(1)1 and Article 15(2) of the same Act, give notice of the purpose of collection and use, the items processed, the retention period, the fact that consent may be refused and the consequences of refusal, and obtain consent.

(3) The company does not use the personal data it collects on registration and in the course of providing the service (name, e-mail address, contact details and the like) for marketing or promotional purposes, and is not obtaining consent for those purposes. The company does not send advertising or promotional e-mail or text messages. The measurement of advertising performance and conversions under paragraph (1)5, and the site-usage analysis under paragraph (1)6, are however processing for a marketing purpose or for analysis aimed at improving the service, and this paragraph does not apply to that extent. What that processing acts on is not the items this paragraph lists but the information a user's browser passes directly to the advertising provider (Article 2, item 8) or to the analytics provider (Article 2, item 8), and each takes place where a user has chosen the corresponding item — Advertising measurement, or Site usage analytics — on the consent banner. Where a user chooses Advertising measurement alone and does NOT choose Site usage analytics, however, the browser still sends one analytics record — a single page view — to the analytics provider. The advertising provider and the analytics provider are the same provider (Google LLC), and that provider has merged the two tags into one: loading the advertising tag carries the analytics destination with it, and the company's code cannot prevent it by withholding the analytics configuration, which is what the code already does. No analytics cookie (_ga, _ga_DRZ61CTNL9) is stored in that case. The converse does not hold: where a user chooses Site usage analytics alone, no request is made to the advertising provider. The company measured this on 22 August 2026 and recorded it in this policy the same day. The company states both facts together.

Article 2 (Categories of personal data processed)

The items the company actually processes are as follows. The company does not list in this Article any item it does not in fact collect.

1. Registration and account management

• (Required) The information Google returns to the company's authentication service when you sign in with a Google account — e-mail address, name (display name), account unique identifier, profile image
• (Required) The tenant (using organisation) display name — this value stores your e-mail address verbatim
• (Required) User identifier, the tenant you belong to, role, status
• (Optional) None. The company does not collect optional items such as industry, job title or areas of interest.
• Sign-in is supported with a Google account only.

2. Provision of the service — execution requests

• (Required) The question and context you enter, and the execution mode
• (Required) Any additional input field you add of your own accord — the system does not reject additional input fields that are not defined; it stores them with the execution record
• (Required) Execution metadata — execution identifier, tenant identifier, idempotency key, input hash, trace identifier, result storage location and hash, cost items, error detail (error detail may contain strings derived from the request)
• (Required) The execution result artifact — the result text, the original question echoed back in the result envelope, the model name, token counts, and the amount charged

3. Payment

• (Required — items the company transmits to the payment provider) Payment amount, currency, plan identifier, the company's internal order identifier, return and cancellation addresses. The company does not transmit name, e-mail address or postal address to the payment provider.
• (Required — items the company collects from the payment provider) The whole body of the payment-completion notification (webhook) is stored verbatim, and it contains whatever the payment provider fills in, including a payer identifier, e-mail address and name (given name, surname).
• (Required) Checkout session, order and entitlement records, and payment audit records

4. Authentication and access records

• (Required) Authentication request records — the hash of the access IP address, the hash of the user agent, the request path, method and response code, token identifier, tenant identifier, trace identifier. The hash values are pseudonymised personal data (see Article 9, item 4).
• (Required) API authentication token records — the hash of the token, its name, prefix, last four characters, scope, and issuer identifier
• (Required) Token event records — event type, actor identifier, token identifier, tenant identifier
• Note: the API authentication token table has columns for an IP address and a user agent, but no value is written to them. The company does not list them as items collected.

5. Sending e-mail notices, and handling the outcome

• (Required) Sender address, list of recipient addresses, primary recipient address, and the addresses and original text of bounce and unsubscribe notifications. These items are stored in plaintext.
• (Required) The recipient e-mail address of the order acknowledgement the company sends when a payment is confirmed, and the full subject and body of that notice together with the hash of the body. The body contains the order identifier, the payment provider's order reference, the price and currency, the type and period of access, the date and time payment was confirmed, and the versions of the terms of use and this privacy policy that apply. These items are created before sending and stored in plaintext, and remain regardless of whether sending succeeds.
• (Required) The buyer's e-mail address stored at the point the purchase process begins. This is a separate copy from the recipient address above, and is stored in plaintext.
• (Required) Send status, attempt count, send time, the message identifier assigned by the transport provider, and an error classification code. The error records do not contain the recipient address or the body of the notice.

6. Enquiries

• (Required) The content of an enquiry you send and the sending e-mail address, together with any contact details you choose to include
• Note: the enquiry form on the website does not transmit to the company's servers; it opens your own e-mail program. The content of an enquiry is received and held in the company's e-mail mailbox.

7. Operational logs

• (Required) Application logs record the user's e-mail address, user identifier, tenant identifier, execution identifier and storage location, among others. Automatic redaction in the logs is confined to authentication headers; e-mail addresses are not redacted.

8. Website visits

• Access IP address, user agent and request path — records held by the content-delivery (CDN) provider and by the authentication service provider. The browser on the dashboard screen calls the authentication service domain directly, so a visitor's IP address reaches that provider without passing through the company's API.
• (Only where advertising consent has been given) Access IP address, user agent, the address of the page visited and the address of the previous page (referrer), the time of the visit, and the value stored in the user's browser for advertising identification (_gcl_au) — records held by the advertising provider. The conversion action the company has configured with the advertising provider is a single one, "Page view", which means the act of opening a page of this website itself. These items arise only where a user has chosen Agree on the advertising consent banner; before that the user's browser sends no request whatever to the advertising provider. After consent the user's browser calls several domains the advertising provider operates directly, so a visitor's IP address reaches that provider without passing through the company's servers. The domains the company actually observed on 22 August 2026 are https://www.googletagmanager.com, https://googleads.g.doubleclick.net, https://www.google.com, https://www.google.co.kr, https://ad.doubleclick.net, https://www.googleadservices.com, https://stats.g.doubleclick.net, https://analytics.google.com. That list is the extent of what the company observed, and the company does not assert it is complete. Which domains are called differs from page to page, and also with the country a visitor connects from (country-specific domains such as https://www.google.co.kr are among them), and the company is not in a position to enumerate them all. The script also stores a value, _gcl_ls, in the browser's local storage. The company has not confirmed the full list of the other items the advertising provider's script collects. The detail is as stated in Article 6(1)6 and Article 10.
• (Only where site-usage analytics or advertising consent has been given) Access IP address, user agent, the address of the page visited and the address of the previous page (referrer), the time of the visit, the time spent on the page, the values the analytics provider stores in the user's browser (_ga, _ga_DRZ61CTNL9), and the per-purpose granted/denied state the user chose on the consent banner — records held by the analytics provider. These items arise where a user has chosen Site usage analytics OR Advertising measurement on the consent banner; before either, the user's browser sends no request whatever to the analytics provider. Where Advertising measurement alone is chosen, what reaches the analytics provider is a single page-view record carrying the access IP address, the user agent, the address of the page visited, the time of the visit and the per-purpose granted/denied state; the identifiers _ga and _ga_DRZ61CTNL9 are not stored. The reason is in Article 1(3). After consent the browser calls https://www.googletagmanager.com and https://www.google-analytics.com directly, so a visitor's IP address reaches that provider without passing through the company's servers. The company has not confirmed the full list of the other items the analytics provider's script collects. The detail is as stated in Article 6(1)7 and Article 10.

9. Demo executions

• The hash of the input, the input length, the hash of the actor key, and the hash of the result. The original question is not stored, and no AI model provider is called on this path.

Article 3 (Processing and retention periods)

(1) The law requires personal data to be processed and held within the retention and use period provided by law or consented to by the data subject at collection, but the periods the company actually holds data for are as set out in the table in paragraph (2), and for a considerable number of items they do not meet that requirement. This paragraph is not a promise about retention periods; it states the difference between what the law requires and the actual position. The items for which the company performs deletion on the passage of a period are confined to the items so described in the table in paragraph (2), and no part of this Article is to be read as meaning that the company deletes any other item on the passage of a period.

(2) The company states its actual operating position as it is. The "actual retention period" column below is not the period the company would like; it is what the system in fact does today.

(3) For those reasons the company does not state a maximum retention period common to all items. The company does not tell users that all personal data is deleted after a particular period, because that would not be true.

(4) Records relating to transactions and payments for which the law requires retention for a period are retained for at least that period.

Article 4 (Provision of personal data to third parties)

(1) The company processes personal data only within the scope of the purposes stated in Article 1, and provides it to a third party only where there is a basis in law, such as the data subject's consent or a specific statutory provision.

(2) Every case in which the company passes personal data to an external provider is recorded in this Article, in Article 5 (consignment) and in Article 6 (cross-border transfer). The company does not provide personal data to any third party for any other purpose.

(3) There are three cases in which the company provides personal data to a third party. Item 1 arises only when you purchase a paid plan, item 2 only where you have chosen Advertising measurement on the consent banner, and item 3 where you have chosen Site usage analytics, and once per page where Advertising measurement alone is chosen (Article 1(3)).

(4) The provision in paragraph (3) item 1 is also a cross-border transfer, so at the payment step the company discloses the matters in Article 6(1)3 as well and obtains, in one separate consent, consent to both the provision to a third party (Article 17) and the cross-border transfer (Article 28-8(1)1). Because the two consents rest on different legal bases, the company states that fact on the consent screen. The provision in paragraph (3) item 2 is also a cross-border transfer, so on the advertising consent banner the company discloses the matters in Article 6(1)6 as well and obtains one consent in the same way. The provision in paragraph (3) item 3 is also a cross-border transfer, so on the consent banner the company discloses the matters in Article 6(1)7 as well and obtains one consent in the same way. The records of the item 2 and item 3 consents are, however, kept only in the user's browser and not on the company's servers (Article 10(5)).

(5) Where a change is needed to the recipient, the purpose of use, the items provided or the retention and use period, the company gives notice in advance and obtains the necessary consent.

Article 5 (Consignment of personal-data processing)

(1) For the smooth provision of the service the company consigns the processing of personal data as follows.

(2) The law requires a consignment contract to provide for a prohibition on processing personal data beyond the purpose of the consigned work, technical and administrative protective measures, restrictions on sub-consignment, supervision of the processor and liability including damages, and requires the processor to be supervised. The company has not yet confirmed that all of those requirements are satisfied in respect of each processor listed in paragraph (1). The company does not state that it is performing something it has not confirmed, and this paragraph is not to be read as meaning that the company already performs those matters. As soon as confirmation is complete the company will reflect the result in this policy.

(3) Where a processor or the content of consigned work changes, the company discloses the change through this policy without delay.

(4) The company does not list the following providers as processors, because they receive no personal data from the company: an error-collection service (only connection settings exist, and no component uses them) and a distributed-tracing collector (it operates in memory only and transmits nothing externally). One domestic payment gateway was also listed in this paragraph until this amendment; the company has moved it into the table in paragraph (1). It remains true that the provider receives no personal data yet, and that fact is stated in the table itself.

(5) The company does not list the payment provider (PayPal Pte. Ltd.), the sign-in provider (Google LLC), the advertising provider (Google LLC) or the analytics provider (Google LLC) as processors under this Article. None of the four processes on the company's instructions for the company's purposes; the substance and the reasons for that assessment are stated in Article 4(3) item 1, in Article 6(1)2, in Article 4(3) item 2 together with Article 6(1)6, and in Article 4(3) item 3 together with Article 6(1)7 respectively. The advertising provider and the analytics provider are not persons processing only within the scope of the company's instructions; each processes its data under its own terms and for its own purposes and sets its own retention period, and the company is not in a position to instruct or supervise that processing. The company does not enter in this table a legal characterisation different from the actual relationship.

(5)-2 Why the domestic payment gateway appears in the table in paragraph (1) while the foreign payment provider does not. The foreign payment provider takes on the payment in its own name and under its own terms and sets its own basis for handling disputes and refunds, so it is not a person processing only within the scope of the company's instructions (paragraph (5), Article 4(3) item 1). The domestic payment gateway requests payment using order information the company supplies and returns the result to the company, so the company treats it as a processor acting on the company's instructions and lists it as one. The company has not, however, confirmed that this distinction holds in every respect. When the first payment is made and the actual scope of processing is settled, the company will re-examine the distinction, and will amend this policy if it differs from the actual relationship. The company does not state as confirmed what it has not confirmed.

(6) The content-delivery provider and the mailbox provider in paragraph (1) process personal data even when a user is not signed in to the company's service. The processing occurs merely by visiting the website or sending an enquiry e-mail, and both of those cases are cross-border transfers within Article 6. Separately from those two, there are two further cross-border transfers that can occur while a user is not signed in. They are the transfer to the advertising provider in paragraph (5) (the third) and the transfer to the analytics provider (the fourth), and each occurs where a user has chosen Advertising measurement, or Site usage analytics, on the consent banner; the transfer to the analytics provider also occurs once per page where Advertising measurement alone is chosen (Article 1(3)). Those providers are not processors under this Article, so they do not appear in the table in paragraph (1); the detail is as stated in Article 6(1)6 and (1)7.

Article 6 (Cross-border transfer of personal data)

The company discloses the matters relating to cross-border transfer as follows, under Article 31 of the Enforcement Decree of the Personal Information Protection Act.

(1) Cross-border transfers

There are seven cross-border transfers in which the company is involved. Item 1 was suspended on 4 August 2026 and resumes on 20 August 2026; item 3 occurs only where separate consent has been obtained at the payment step; item 6 occurs only where a user has chosen Advertising measurement and item 7 where a user has chosen Site usage analytics on the consent banner, and once per page where Advertising measurement alone is chosen (Article 1(3)); items 4 and 5 are continuing now. Item 2 is a case the company has assessed as not amounting to a transfer by the company. The company records resuming transfers, transfers that occur only where consent has been obtained, and continuing transfers separately.

Item 1. AI model provider (resumes 20 August 2026)

What the company has confirmed is only that the recipient has itself published that it does not do so. The company has no means of confirming that the publication is in fact honoured, holds no contractual document compelling it, and does not warrant that the data is not used. The recipient may change that publication unilaterally. The company makes no representation as to whether the recipient holds any certification relating to cross-border transfer.

This transfer was suspended on 4 August 2026 and resumes on 20 August 2026, the effective date of this policy. For the duration of the suspension the company had kept the setting of the component that performs executions so that it does not use the model-invocation function, with the result that while the suspension lasts, submitting an execution request transmits nothing to the recipient. The company has confirmed that state in the production environment. From the resumption date, transmission occurs on each execution request, as set out in the table above.
The previous text undertook that if the company resumed the function it would record the resumption and its date in this policy before resuming. This text is that record, and the resumption follows its effective date.
Two further things are stated plainly. First, content already transmitted before the suspension is not recovered, and the recipient's retention period is as in the table above. Second, after the resumption this transfer remains a setting the company can reverse, and if the company suspends it again it will record that in this policy the same way.

Item 2. Sign-in (authentication) provider

Item 3. Payment provider

On completion of payment the payment provider returns payer identifying information (identifier, e-mail address, name) to the company, and that content is stored as described in Article 2, item 3 and Article 3.

Item 4. Content delivery (CDN) and domain name resolution provider (continuing)

Item 5. E-mail mailbox and sending provider (continuing)

Item 6. Advertising provider (only where advertising consent has been given)

Item 7. Analytics provider (only where site-usage analytics or advertising consent has been given)

(2) If you do not want a cross-border transfer

The extent to which a transfer can be refused, and how, differs from transfer to transfer. The company does not present them as one and states each as it is.

• Item 1 (AI model provider) — it resumes on 20 August 2026. The legal basis for this transfer is Article 28-8(1)3(a) of the Personal Information Protection Act, as stated in the table above, and it is not a transfer made on separate consent, so it cannot be stopped by withdrawing consent. A demand to suspend processing is governed by Article 8. The transmission occurs each time a user requests an execution, so if you do not request an execution the transfer does not occur. Registration and use of the other functions are unaffected in that case.
• Item 2 (sign-in provider) — a case the company assessed as not amounting to a transfer by the company. If you do not use Google account sign-in the transmission does not occur; but the company currently offers no sign-in method other than a Google account, so in that case you cannot use the service.
• Item 3 (payment provider) — the company obtains separate consent at the payment step, and you may decline. If you decline, payment does not proceed and you cannot purchase a paid plan; registration and use within the free scope are unaffected.
• Item 4 (content-delivery provider) — there is no means of refusal. This transfer occurs the moment you connect to this website, before the company's pages run. There is no refusal method the company can offer other than not visiting, and the company does not describe a procedure that does not exist.
• Item 5 (e-mail mailbox and sending provider), enquiry e-mail — if you make an enquiry by telephone (+82 10-7634-6265) instead of by e-mail, this transfer does not occur.
• Item 5, order acknowledgement — there is no means of refusal. The company sends this notice as the law requires once a payment is confirmed, and telephone enquiry is not a substitute for it. There is no refusal method the company can offer other than not purchasing a paid plan, and the company does not describe a procedure that does not exist. If you do not purchase, registration and use within the free scope are unaffected.
• Item 6 (advertising provider) — you may refuse, and there is no disadvantage in refusing. If you do not choose Advertising measurement on the consent banner this transfer does not occur. Where the company changes what it discloses in this item, the earlier consent ceases to have effect and the banner is shown again automatically. If you have already chosen it, the Consent settings control in the footer lets you choose again immediately — no clearing, and you stay signed in — and switching to refuse makes the company delete _gcl_au, _gcl_aw, _gcl_dc, cookies whose names begin with _gac_, and _gcl_ls (Article 10(5)). Clearing this site's stored data in your browser also still works and removes the consent record in Article 10(5) and the banner is shown again on your next visit, so you can choose afresh. If you refuse, registration, sign-in, execution requests and payment all remain available — this website and the company's service work in full. A transfer already made cannot be reversed, however.
• Item 7 (analytics provider) — you may refuse, and there is no disadvantage in refusing. If you do not choose Site usage analytics on the consent banner this transfer does not occur, unless you have chosen Advertising measurement, in which case one page-view record per page still occurs (Article 1(3)). That choice is separate from item 6 (advertising), so you may consent to one only. How to withdraw a choice already made (the Consent settings control in the footer), the fact that switching to refuse makes the company delete _ga and _ga_DRZ61CTNL9, and the fact that the earlier consent ceases to have effect where the company changes what it discloses, are as stated for item 6. If you refuse, registration, sign-in, execution requests and payment all remain available — this website and the company's service work in full. A transfer already made cannot, however, be undone.

If you wish to stop using the service you may make a request at the contact in Article 11. Ending use does not mean that records already stored are deleted, as stated in Article 3 and Article 8. The company does not tell users that records are deleted when they stop using the service.

(3) A consignment whose status as a cross-border transfer is not settled

The company's authentication service and database run on a managed service provided by Supabase, and the data storage region of that project is the Republic of Korea (Seoul). Supabase is, however, a company headquartered in the United States.

The company has not yet confirmed the facts needed to decide whether this amounts to a cross-border transfer — whether personnel or systems located abroad can access data stored domestically, and whether backups, replicas or logs leave the domestic region. The company therefore does not assert either that it "is" or that it "is not" a cross-border transfer, and states those facts as they are. It will reflect the position in this policy as soon as confirmation is complete.

(4) Infrastructure processed domestically

Result artifact storage, backups, the work queue, the cache server, retention of audit evidence and the handling of e-mail bounce and unsubscribe notifications are processed in the Republic of Korea (Seoul) region. The sending of e-mail by the company is not included. Notice e-mail is sent through the recipient in paragraph (1) item 5, and the country in which it is processed is not the Republic of Korea.

(5) Bases the company does not rely on, and why

Article 28-8(1) of the Personal Information Protection Act provides five bases. In each item above the company invoked only subparagraph 1 (separate consent) or subparagraph 3(a) (consignment or storage, together with disclosure in the privacy policy). The reasons for not invoking the remaining bases are as follows, and they are reasons of having checked and found them inapplicable rather than of not having checked.

• Subparagraph 2 (a special provision of statute, or a treaty) — the company has not identified a special provision or treaty applicable to its transfers.
• Subparagraph 4 (certification) — the certification this subparagraph requires is limited to what the Personal Information Protection Commission has designated by public notice. The only certification listed in Annex 2 of the Notice on the Operation of Cross-Border Transfers of Personal Data (Personal Information Protection Commission Notice No. 2023-11) is ISMS-P under Article 32-2 of the Personal Information Protection Act, and none of the recipients above holds it. The international certifications the recipients hold (ISO 27001, ISO 27701, SOC 2, Global CBPR and the like) are not included in that annex.
• Subparagraph 5 (adequacy recognition) — the countries and international organisations the Republic of Korea has recognised as having an equivalent level of personal-data protection are limited to the European Union and the European Economic Area (as at September 2025), and the United States and Singapore are not among them. Every recipient above is a United States or Singapore entity, so this subparagraph cannot apply.

The company does not write as though it invoked a basis it cannot invoke, and the facts above are the result of checking the public notice and the list of adequacy recognitions published by the Personal Information Protection Commission.

Article 7 (Procedure and method of destruction)

(1) The law requires personal data to be destroyed without delay once it becomes unnecessary, whether because the retention period has passed or the purpose of processing has been achieved. Of the personal data stored in the database, the company performs that requirement in respect of execution inputs (question and context) as described in paragraph (6), but does not currently perform it in respect of the other items. This paragraph states the difference between what the law requires and what the company actually does; it is not a promise that the company will destroy. Beyond the scope described in paragraphs (3) and (6), no part of this Article is to be read as meaning that the company destroys personal data without delay, or promises to destroy it.

(2) Specifically, the company's systems do not currently implement a procedure for deleting an individual item of personal data stored in the database. The company does not conceal that fact. "Individually" here means a procedure for deleting a particular record at a data subject's individual request; deletion performed in bulk on the passing of a retention period is carried out for some items, as described in paragraphs (3) and (6). What is actually performed is set out in paragraph (3), and what is not performed in paragraph (4).

(3) The deletions actually performed at present are confined to the following.

(4) Destruction is not currently performed for the following items.

1. The records stored in the database other than execution inputs (question, context) — account, tenant and role records, payment records, authentication and access records, e-mail notice and send-result records, and execution metadata. Deletion of execution inputs is as described in paragraph (6), and the inputs of executions excluded from that paragraph fall within this item
2. Records in the audit evidence store — object lock is applied, so they are not deleted or overwritten on the ordinary operational path, and the store is operated so that alteration is evident (tamper-evident). No store-level default retention rule is set, however, and a retention period is specified per record
3. Some operational log groups that have no expiry setting

"The result store of the closed pilot period", previously included in this paragraph, was disposed of in its entirety on 5 August 2026 and is no longer within it (see the table in paragraph (3) of Article 3).

(5) Method of destruction — information stored in electronic file form is dealt with by a deletion request to the store and by expiry under a lifecycle rule.

(6) Progress on remedying the destruction procedure. Having identified the defect in paragraph (2) itself, the company modified the program so that execution inputs (question and context) are deleted from the database once the retention period has passed. The time of deletion is the same as the time at which the execution result artifact is deleted; the execution record itself is kept for audit, usage review and dispute handling, and only the inputs, which are personal data, are deleted.

The company states the limits of that remedy as well.

1. It is a logical deletion and not cryptographic erasure (destruction of an encryption key). The database may hold the previous value until its internal cleanup runs, and a backup holds the previous value until its own retention period (paragraph (3)) expires.
2. The remedy is confined to execution inputs. It does not apply to the remaining items in paragraph (4) (account and tenant records, payment records, authentication and access records, e-mail notice and send-result records, execution metadata), and a deletion procedure for those items has not yet been established.
3. The automatic deletion applies only to executions that completed normally. An execution that did not reach completion (for example a failed execution), an execution for which no result artifact was created, and an execution already marked as cleared before this remedy applied are not covered by the automatic deletion. On 5 August 2026 the company deleted, as a one-off measure, all execution inputs within that scope that existed at that point. That was a one-off measure, however, and execution inputs arising within that scope afterwards are not deleted automatically. The company is considering how to bring that scope within the automatic deletion and will reflect the outcome in this policy.
4. The company will establish deletion procedures for the remaining items in turn and will reflect its progress in this policy.

Article 8 (Rights of data subjects and legal representatives, and how to exercise them)

(1) A data subject may at any time require the company to allow access to, correction of, deletion of, or suspension of the processing of, personal data, or withdraw consent. That is a statement of the rights the law confers on a data subject and does not mean that the company can perform every such requirement; the measures the company can actually perform are confined to those in paragraph (4). This paragraph does not exclude or reduce the obligations the company bears under applicable law.

(2) A right under paragraph (1) may be exercised in writing, by e-mail or otherwise at the contact in Article 11. The company notifies the fact of receipt and the outcome without delay, but performs the measure requested within the scope of paragraph (4)(a), and judges a deletion request individually, record by record, on the criteria in paragraph (4)(b). "Without delay" in this paragraph relates to the notification and is not a promise as to performance of the measure.

(3) A data subject may exercise a right through a legal representative or another duly authorised agent. The company may in that case require a document evidencing the authority.

(4) The company handles a request to exercise a right on the following criteria. Sub-paragraph (a) is the scope of measures the company can currently perform and is exhaustive; (b) is the criteria applied to a deletion request; (c) is the common procedure; and (d) is guidance on the access block. Each is one disclosure, and none may be taken in isolation as a promise of performance or as a ground for refusing deletion.

(a) Measures that can currently be performed (this list is exhaustive)

1. Access — informing you of the items held and the state of processing
2. Correction — amending an item that can be corrected
3. Suspension of processing — stopping use of the service, revoking authentication tokens, setting the account status to inactive
4. Carrying out a deletion request in respect of an execution result artifact (object)
5. Blocking API lookups of an execution result

(b) Criteria applied to a deletion request

The company does not refuse deletion requests as a class. Each time it receives one it judges individually, record by record, on the criteria below, and informs the person who made the request of the outcome and the reasons.

1. Where it deletes — where none of the grounds in sub-paragraph 2 applies to the record, the company deletes it. Execution inputs (question, context) are deleted once the retention period has passed, under the remedy in Article 7(6), subject to the limits listed in that paragraph.
2. Where deletion may be restricted — deletion may be restricted only in respect of a record to which one of the following applies. The company informs you individually of the ground and of the extent of the restriction, and deletes the record once the ground ceases to exist.
   • i. Where another law requires retention of that personal data (records relating to transactions and payments and the like)
   • ii. Where retention of the record is necessary for performance of the contract, settlement of usage charges, handling a dispute or preventing improper use, and only while that necessity continues
   • iii. Where the record is retained as audit evidence under the criteria in sub-paragraph 3
3. Statement of fact about audit evidence — audit evidence is held in a store to which object lock is applied, and it is not deleted or overwritten on the ordinary operational path; the store is operated so that alteration is evident (tamper-evident). The company states two further things. First, no store-level default retention rule is set, and a retention period is specified per record at the time the record is written. Second, the function that writes changes of the service's emergency stop control to this store is not configured in the production environment, so those records are not currently being created; the store holds one record, dated 21 February 2026. Where the company receives a deletion request in respect of that record it judges it individually on the criteria in sub-paragraph 2 and informs you of the outcome.
4. Statement about a technical constraint — it is not a ground of refusal. As Article 7(2) states, there is a scope within which the company's systems do not yet implement a procedure for deleting individual database records. That is a defect the company must remedy and is not a ground on which a deletion request may be refused. On receiving a deletion request the company performs deletion to the extent it can, and for the remaining scope informs you of the state of handling, the measures planned and the expected timing.

(c) Common procedure when handling a request

Where there is a scope the company cannot delete, it informs the person who made the request specifically of that scope and the reasons, and does not describe a measure it has not performed as though it had.

(d) Guidance on the access block after 30 days

The refusal of API lookups of an execution result after 30 days is in itself an access block and not a deletion. The company also states, however, that deletion of the execution result artifact and of the execution inputs (question, context) begins at that same point (Article 7(3) and (6)). Even after that deletion, the execution record itself, the input hash and the idempotency key remain. The company does not describe an access block as a deletion, nor describe that deletion as no more than an access block.

(5) A deletion request may be restricted where another law expressly specifies the personal data as data to be collected, and the specific criteria are as in paragraph (4)(b) sub-paragraph 2.

(6) A request for access or for suspension of processing may be restricted where a ground provided by law exists.

(7) The company verifies that the person requesting the exercise of a right is the data subject or a duly authorised agent.

Article 9 (Measures to secure the safety of personal data)

The measures the company currently has in force are as follows. The company has not listed in this Article a measure whose implementation is not confirmed, and this Article promises no level of protection beyond the measures listed below.

1. Encryption in transit — HTTPS/TLS is applied to communications with users and with external providers, and encryption is also applied on the transport path to the cache server.
2. Encryption at rest — encryption at rest provided by the cloud provider is applied to the result store, the backup store, the work queue and the cache server. These are shared managed keys applied at the level of the store; there is no per-user or per-tenant encryption key. Execution inputs in the database are stored in plaintext until they are deleted under Article 7(6).
3. Hashed storage of credentials — API authentication tokens are not stored in their original form; only a hash is stored.
4. Pseudonymisation of access records — the IP address and user agent in the authentication request records are stored as hash values. That is pseudonymisation and not anonymisation. The company manages those hash values as personal data.
5. Access authentication — authentication is applied to the cache server and the work queue.
6. Alteration-resistant retention of audit evidence — audit evidence is held in a store to which object lock is applied, and is not deleted or overwritten on the ordinary operational path; the store is operated so that alteration is evident (tamper-evident). No store-level default retention rule is set, and a retention period is specified per record. See Article 8(4) for detail.
7. Physical safeguards — physical access control follows the data-centre controls of the cloud infrastructure provider.

Matters the company does not state that it performs — operation of per-user or per-tenant encryption keys, cryptographic erasure by destruction of an encryption key, periodic vulnerability assessment, periodic staff training, and the operation of a dedicated privacy team. Implementation of those measures is not confirmed, so they are not listed.

Article 10 (Installation and operation of automatic collection devices, and refusal of them)

(1) The company does not use cookies until a user has chosen Site usage analytics or Advertising measurement on the consent banner. The company's public website files contain no script of the analytics or advertising providers', and the company's own code that loads those scripts runs only once the corresponding item has been chosen. Accordingly, before that choice the user's browser sends no request whatever to those providers, no cookie is stored, and nothing is transmitted. The two items are chosen independently. The script file that is loaded, however, is a single file in which the provider has merged both, and it carries the advertising destination and the analytics destination together. Choosing Advertising measurement alone therefore also produces one analytics transmission (Article 1(3)). Choosing Site usage analytics alone produces no advertising transmission. From the point at which a user chooses Advertising measurement, the company's pages load the advertising provider's script (https://www.googletagmanager.com), and that script stores a cookie for advertising identification (_gcl_au) and a local-storage value (_gcl_ls) in the user's browser. From the point at which a user chooses Site usage analytics, the analytics provider's script is loaded the same way and stores cookies for analytics identification (_ga, _ga_DRZ61CTNL9). The advertising-identification cookie is stored on this website's domain, but the party that creates and reads its value is the advertising provider, and its lifetime is, on the default the advertising provider publishes, about 90 days. The cookies for analytics identification (_ga, _ga_DRZ61CTNL9) are created and read by the ANALYTICS provider, not the advertising provider, and the company has not confirmed their lifetime (Article 6(1) item 7). The earlier text attached this sentence to the analytics cookies immediately before it, describing their author as the advertising provider and their lifetime as about 90 days. That was an artefact of the analytics sentence being inserted later, and the company corrects it. That 90-day figure is a value the advertising provider can change unilaterally; it is not a value the company sets or warrants. The provision to a third party and the cross-border transfer that take place through these cookies are as stated in Article 4(3) items 2 and 3, and Article 6(1)6 and (1)7. The company operates no automatic collection device other than those two. The preceding version said in this place that the company operated no other automatic collection device, such as a behavioural-analytics script; this amendment introduces a site-usage analytics script, and the company corrects that statement accordingly.

(2) In order to maintain the signed-in state, however, the following values are stored in the browser's session storage (sessionStorage), and are removed when the browser tab is closed: the authentication token, the refresh token, the user identifier, the e-mail address, the checkout session identifier, and the pending-consent record that carries the consent items ticked on the sign-in screen across to the callback screen. The last of these is written on the sign-in screen and removed by the callback screen once the record has been filed.

(3) During Google account sign-in the authentication library stores temporary values in the browser's local storage (localStorage), and the company's callback screen removes them once sign-in is complete.

(4) You may refuse the storage above through your browser settings. In that case you will not be able to use functions that require sign-in, and the consent record in paragraph (5) is erased with it, so the consent banner is shown again on your next visit. There are four cases in which the banner is shown again: (a) you clear the stored data, (b) you use a different browser or device, (c) you open it yourself from the Consent settings control in the footer, and (d) the company changes what it disclosed when it took the consent, so that the earlier consent ceases to have effect. In case (d) the company asks you to choose again on the new disclosure, and no request arises until you do. The earlier text attached this sentence to (c), but (c) is the case where you open the banner yourself, and at that moment requests under your earlier choice are already being made. The sentence is true of (d), where the earlier consent has ceased to have effect, and the company corrects it. In addition, where a page is opened with no valid consent under this policy — cases (a) and (d) — the company deletes the identifiers stored under the earlier choice at that point.

(5) Whether the consents under paragraph (1) have been given is stored in the dpp_ads_consent item of the browser's local storage, and the values stored in that item are the following: whether consent to site-usage analysis was given (granted or denied), whether consent to advertising measurement was given (granted or denied), the time of the choice, and the identifier of the version of this policy that applied at the time of the choice. The two are recorded separately, so a state in which only one was consented to is preserved as such. That item survives the closing of a browser tab, and is removed when a user clears this site's stored data in the browser. The company does not keep a record of this consent on its servers. Because the record of whether consent was given exists only in the user's browser, the company holds no record by which it could prove that a particular user consented, and does not state that it holds evidence it does not hold. Where a user clears stored data or uses a different browser or device the company cannot know the earlier choice, so the banner is shown again, and until a choice is made afresh no request to those providers arises. You may choose again at any time, without clearing anything, using the Consent settings control in the footer of any page that carries the banner. It opens showing the choices you made last time — that is not a pre-tick, it is the current state of a setting you came to change. When you refuse a purpose, the company deletes the identifiers that purpose has already stored in your browser (advertising: the cookies _gcl_au, _gcl_aw and _gcl_dc, cookies whose names begin with _gac_, and the local-storage value _gcl_ls; analytics: the cookies _ga and _ga_DRZ61CTNL9). This list is what the company has confirmed, and it is not asserted to be complete. _gcl_aw, _gcl_dc and the _gac_ family are values that may be stored when you arrive by clicking an advertisement, and the previous amendment did not include them in what is deleted. The company also deletes those identifiers when a page is opened with no valid consent (Article 10(4)). Separately, the consent state you chose is itself transmitted to the recipient at the moment the script runs. Where you have chosen Site usage analytics and have NOT chosen Advertising measurement, the company transmits advertising storage, use and personalisation marked as denied, so that the recipient actually honours that refusal. Where you refuse both, or have not yet chosen at all, no script runs and nothing whatever is transmitted — not even the refusal. The earlier text drew no such distinction and could be read as saying a refusal is transmitted even when everything is refused. The company corrects it. That transmission communicates the state only; it does not mean the company keeps a record of the consent. What has already reached the recipient the company cannot delete, and it does not claim to do what it cannot. Where the company changes what it disclosed when it took the consent, it can tell from the stored version identifier that the record no longer matches the current policy, treats the earlier consent as having ceased to have effect, and shows the banner again. This exists to stop what a user consented to from drifting apart from what is actually done, and the company did exactly that at this amendment (see the Change notice at the top of this document).

Article 11 (Privacy officer)

(1) The company designates the privacy officer below to take overall responsibility for work relating to the processing of personal data and to handle data subjects' complaints and provide redress in relation to the processing of personal data.

▸ Privacy officer

• Name: 배성무 (Bae Sungmoo)
• Position: Representative
• Contact: contact@decisionproof.io.kr (e-mail)

(2) A data subject may direct to the privacy officer any enquiry, complaint or request for redress relating to personal-data protection arising from use of the service. The company answers the fact of receipt and the outcome without delay, but the scope within which a requested measure is performed is as set out in Article 8(4).

Article 12 (Remedies for infringement of rights)

To obtain redress for an infringement of personal data, a data subject may apply to the bodies below for dispute resolution or advice.

The contact details above are reproduced from the Korean privacy policy. The websites of those bodies are published in Korean.

Article 13 (Other matters notified)

(1) Personal data of children under 14

The company does not collect age information and operates no procedure for verifying a user's age. It therefore cannot know whether a user is under 14. Where the company learns that the personal data of a child under 14 has been collected, it deletes that data on a request made at the contact in Article 11 and informs you of the outcome.

(2) Automated decisions

The company does not make a fully automated decision producing a legal effect, or a similarly significant effect, on a data subject. A result text the service produces is generated at a user's request and provided to that user; it is not an evaluation of a data subject or a decision made by the company about a data subject. There is automated processing for the operation of the service, such as blocking requests once a usage limit is exceeded, but that concerns the contractual scope of use and is not an evaluation or judgment about a data subject.

(3) Where a request for access is received

The company has no separate department for receiving access requests; a request for access to personal data is received at the privacy officer's contact address (e-mail) in Article 11.

(4) Processing of pseudonymised data

The company does not process pseudonymised data for the purposes of compiling statistics, scientific research or preservation of records in the public interest. As stated in Article 9, item 4, however, it stores the IP address and user agent in the authentication request records as hash values, and those are pseudonymised personal data rather than anonymised information; the company manages them as personal data.

(5) Infrastructure and hosting of the service

The database, authentication, storage and transport infrastructure of the service is provided by the providers listed in Article 5. Hosting and content delivery for the public website are provided by Cloudflare, Inc., and the enquiry e-mail mailbox and the sending of notice e-mail by the company are provided by Google Asia Pacific Pte. Ltd. (Google Workspace); the cross-border transfer matters for those two providers are as in Article 6(1)4 and (1)5. The countries in which those two providers process are not fixed, and all that has been confirmed is that they are not the Republic of Korea.

Article 14 (Changes to this privacy policy)

(1) This privacy policy applies from 2026-08-20.

(2) Policy version: checking…

(3) Where the company changes this policy it publishes the content of the change and the effective date through the website. The content of this amendment and its effective date are as stated in the Change notice at the front of this document. The immediately preceding version of this policy is the version whose identifier is en-20260820-8, and its full text can be read at https://decisionproof.io.kr/legal/privacy/en-20260820-8.html. From the versions whose identifier begins en-20260905- or en-20260820- onwards, including this policy, the company posts the full text of each version at its own stable address so that it remains readable. For the first published version, which applied from 5 August 2026, the company holds no preserved published copy. The published text changed more than once while that identifier was in use and the company cannot establish which of those texts the identifier names, so the company does not state that it provides a route to read that version. Where you need a previous version, on request at the contact in Article 11 the company will provide what its records hold, and will tell you the limits of those records. The company does not describe in this policy a route to read a version that does not yet exist.

(4) This policy is a document separate from the company's Terms of Use, and does not replace them or change their content.