KHOJ — Consent Flow Specification

PUBLIC DOCUMENT · Engineering & Compliance Reference

Axiomaera Private Limited | CIN: U62011MH2026PTC467707 | DPIIT: DIPP248013 Registered Office: Shop 8, Upper Ground Floor, Amenity Bldg, Ashok Astoria, Gangapur, Nashik, Maharashtra 422222, India

Version: 1.0 Effective Date: [To be set by Managing Director] Document Owner: Founder & Chief Architect, Axiomaera Private Limited Audience: KHOJ engineering team, compliance reviewers, external auditors

---

LANGUAGE

This document is published in English. Translations will be made available in Hindi and additional Indian languages on a rolling basis. This document is currently available in English only. The English version shall prevail for all legal purposes.

Any discrepancy in a future translated version is unintentional. Axiomaera respects each language and is committed to improving translation accuracy on an ongoing basis. If you notice a translation error, please report it to legal@axiomaera.com.

The English version of all legal documents (Terms of Service, Privacy Policy, Data Retention Policy, Grievance Mechanism, and Methodology Disclosure) is freely accessible at khoj.axiomaera.com/legal at all times, in all circumstances, at no charge.

For the KHOJ diagnostic report itself (the paid product), the report language is determined at the time of scan and additional language versions are subject to standard service fees.

---

1. PURPOSE

This document specifies the technical and legal requirements for KHOJ's consent capture flow. It is the canonical reference for engineers implementing the User journey and for compliance reviewers verifying DPDPA Section 6 conformance.

2. DESIGN TENETS

1. Fail-closed defaults: Every consent flag defaults to false. A missing field in a request payload is treated as the absence of consent.
2. Explicit affirmative action: Each consent is captured by an unambiguous user action (an unticked checkbox that the User must actively tick).
3. Layered notice: A summary is shown at the point of consent; full Privacy Policy and Terms of Service are accessible by hyperlink at the same screen.
4. Auditable record: Every consent event is logged with a content-addressable version of the consent text shown.
5. Withdrawability: Consent withdrawal is at least as easy as consent grant — a single email to privacy@axiomaera.com triggers the erasure flow.
6. Verification before processing: OTP verification precedes the explicit consent screen, so the consenting User is verifiably the owner of the email/phone.

3. STEP-BY-STEP FLOW

Step 1 — Data Entry

1.1 User navigates to khoj.axiomaera.com and selects the Free Tier or Paid Tier. 1.2 User enters email address (and, for Paid Tier, telephone number). 1.3 Below the input fields, the following pre-consent notice is displayed:

KHOJ will scan publicly available breach databases to check if your [email/phone] appears in known data breaches. Before any scan is initiated, you will verify your identity via OTP and explicitly consent.

1.4 Hyperlinks to the full Terms of Service and Privacy Policy are visible and accessible from this screen at all times.

Step 2 — OTP Verification

2.1 Upon submission of the email/phone, KHOJ dispatches an OTP:

• Email OTP via Resend (DKIM/SPF/DMARC authenticated);
• SMS OTP via Bharti Airtel (DLT-approved transactional template, sender ID AXMERA).

2.2 User enters the OTP into the verification screen. 2.3 System records:

2.4 OTP value itself is never persisted. It exists only in Redis with a 600-second TTL.

Step 3 — Explicit Consent Screen

This screen is shown after successful OTP verification and before any third-party API call. The screen is non-skippable; the "Start Scan" button is disabled until both mandatory consents are granted.

3.1 Heading: Confirm and Consent

3.2 Consent text (displayed verbatim):

I, the owner of [email/phone], consent to KHOJ scanning breach intelligence databases to identify data exposures associated with my [email/phone].

I understand that:

• KHOJ will query Have I Been Pwned and DeHashed APIs using my [email/phone];
• My [email/phone] will be transmitted to these third-party services via encrypted connection for the purpose of this scan;
• Results will be displayed to me and, for paid reports, generated as a downloadable PDF;
• Exposed Credentials sourced from third-party breach data may be shown to help me identify exposure;
• Raw API data is not stored — only the processed report is retained for 30 days;
• I can request deletion of all my data at any time by emailing privacy@axiomaera.com.

I confirm I am the owner of this [email/phone] and I am 18 years or older.

3.3 Mandatory consent checkboxes (each defaults to unticked, must be actively checked):

• ☐ I have read and agree to the Terms of Service and Privacy Policy (combined consent)
• ☐ I consent to anonymous processing of my scan results for product analytics — no personal data is stored, only HMAC-anonymised metrics
• ☐ I understand that KHOJ's analytical and verification features implement patent-pending technology under active refinement. Scores, classifications, and re-scan results may evolve as the methodology improves. This does not affect my data protection rights under DPDPA 2023.

3.4 Optional consent checkbox (defaults to unticked):

• ☐ Optional — store my name, email, and phone for user records and product communication

3.5 Submit button: Start Scan (disabled until all three mandatory checkboxes are ticked).

3.6 Backend validation: The Pydantic schema rejects any request payload where tnc_consent !== true, analytics_consent !== true, or technology_preview_consent !== true, with a 422 error and a clear message indicating which consent is missing. This is a defense-in-depth check independent of the frontend.

Step 4 — Consent Record Capture

Upon the User clicking Start Scan, the following record is persisted:

This record is immutable. Subsequent withdrawals or modifications are recorded as new events linked by consent_id.

Step 5 — Scan Execution (Free Tier)

5.1 KHOJ queries HIBP for the email address. 5.2 Results are processed (severity scoring, Indian-origin tagging, ATI computation). 5.3 Free Tier Report is rendered. 5.4 Raw HIBP response is discarded.

Step 6 — Paywall and Payment Consent (Paid Tier)

6.1 Before payment, the following text is displayed:

You are paying ₹99 for KHOJ Advanced Diagnostics. This includes proprietary threat scoring, credential exposure analysis, and a downloadable PDF report. Breach metadata from Have I Been Pwned is provided free under CC BY 4.0. The fee covers analytics and report generation, not the underlying breach or credential data.

6.2 Payment is processed via Razorpay. 6.3 Upon successful payment, the following are recorded:

6.4 Razorpay webhook signature is verified using RAZORPAY_WEBHOOK_SECRET. Webhook events are deduplicated using a Redis idempotency key (rzp:webhook:seen:{event_id}, 24h TTL).

Step 7 — Triple-Source Scan (Paid Tier)

7.1 KHOJ executes three concurrent queries:

• HIBP for the email address (breach metadata);
• DeHashed for the email vector (exposed credentials);
• DeHashed for the phone vector (exposed credentials).

7.2 Each query is tagged with its source for the merge service. 7.3 Results are merged via fuzzy breach-name matching; duplicates are removed. 7.4 ATI Score is computed across the merged dataset. 7.5 Paid Tier Report is rendered as PDF. 7.6 Raw API responses are discarded.

Step 8 — Analytics Recording (Conditional on Consent)

8.1 If analytics_consent === true, an event is recorded in scan_events:

• subject_hmac — HMAC-SHA256(email_or_phone_lowercased, ANALYTICS_HMAC_KEY)
• ip_class_hmac — HMAC-SHA256(truncate_ip_to_/24_or_/48, ANALYTICS_HMAC_KEY)
• coarse geo (country / region / city via ip-api.com, cached 24h per /24 in Redis)
• device / OS / browser bucket (no full UA stored)
• outcome metrics (ATI score, level, breach counts, password counts)

8.2 Per-breach observations are recorded in breach_observations:

• public breach name and year (already public information)
• boolean signals only for credential presence (had_password_plaintext, had_phone, etc.) — never the actual values

8.3 If analytics_consent === false, zero rows are written. The analytics service is fail-closed: the consent flag must be explicitly true for any record to be persisted.

4. CONSENT WITHDRAWAL FLOW

4.1 User emails privacy@axiomaera.com with subject DPDPA Rights Request — Erasure. 4.2 System auto-acknowledges within 24 hours, assigning a request reference number. 4.3 Verification (e.g., reply-to-confirm from the email being erased) within 48 hours. 4.4 Erasure executed within the period prescribed under the DPDP Rules, 2025 (up to 90 days). We will endeavour to complete simple erasure requests within 72 hours where operationally feasible. The technical actions taken are, per Data Retention Policy:

• All scan_users rows for the matching email_hash and phone_hash are hard-deleted;
• All scan_results_cache, scan_payments, and scan_events rows linked to those user IDs are hard-deleted;
• consent_id records are pseudonymised (the linking hash is salted-rehashed and the original hash deleted) to retain DPDPA compliance evidence without retaining identifiability;
• Confirmation email sent to the User.

4.5 The deletion record itself (request reference, dates, categories) is retained for 3 years per Data Retention Policy Section 9.

5. CONSENT TEXT VERSIONING

Each version of the consent text is content-addressable: the SHA-256 of the text shown is stored on the consent record. When the consent text is modified:

1. The new text is published with a new content hash;
2. Existing Users are not retroactively bound to the new text — their consent stands against the version they accepted;
3. On the next interaction, returning Users are shown the new text and asked to re-consent before any new processing.

The historical consent texts are archived in legal/consent_text_archive/ indefinitely, indexed by version hash.

6. OBSERVABILITY

The following metrics are exported to internal monitoring:

• consent_grant_rate — proportion of OTP-verified Users who proceed to grant both mandatory consents;
• consent_withdrawal_count — daily count of erasure requests;
• consent_withdrawal_sla — time-to-erasure histogram (target: 95th percentile < 72 hours);
• analytics_opt_in_rate — for cohort understanding;
• retention_opt_in_rate — for understanding willingness to share identity for record-keeping.

7. REPORT DESIGN NOTES — WELLNESS

The KHOJ diagnostic Report (PDF) must include the following wellness note on the final page (Findings & Actions page), positioned after the action items and before the footer:

If this report causes you concern, remember: data exposure is common and fixable. Follow the action items above. For support:

• Vandrevala Foundation: 1860-2662-345 (24/7, free)
• KIRAN helpline: 1800-599-0019 (24/7, free, Government of India)

This note must appear in every Report — Free Tier and Paid Tier — in the language selected by the User at the time of scan. The helpline numbers are India-wide and do not change by language.

The note must be visually distinct (cream-tinted callout box) but not alarming in colour. It must not appear above the action items, as the desired flow is: see findings → see remediation → if distressed, see helplines.

9. CONTACT

Grievance Officer: Mukund Hemant Mohadikar, Managing Director

---

End of Consent Flow Specification.

This document is referenced by the KHOJ Privacy Policy (Section 2.5) and Terms of Service (Section 1.3). The consent flow implements the requirements of Section 6(1) of the Digital Personal Data Protection Act, 2023.