Privacy and storage notice

1. Who determines the processing

For information that InshiHub processes for site operation, historical release-alert record deletion, product fulfilment, and product support, the organisation determining the purpose and means of processing is Kabushiki Kaisha Fermion, trading as InshiHub, at 8F MIEUX Shibuya Building, 5-3 Maruyamacho, Shibuya-ku, Tokyo 150-0044, Japan.

Privacy requests may be sent to contact@fermion.company. Fermion's India-resident contact position and Dodo's India-facing responsibility allocation are under written review. Checkout will remain disabled until required contacts and procedures are confirmed.

2. Information processed on the public site

• Technical and security information: request time, requested page, internet address and related network information, browser and device information, error data, and security signals needed to deliver and protect the site.
• Measurement information: page views, approximate country, referring host, device and browser category, site performance measurements, product identifiers, and events such as opening a sample.
• Browser storage: the first landing path and first external referring host are stored in local storage. A product-and-sample marker may be stored in session storage so the same sample-open event is not counted repeatedly during one browser session.

We use this information to provide the site, detect abuse, diagnose errors, understand which public resources are useful, and improve performance. We do not use it to make decisions about admission, education, credit, employment, or another similarly significant matter, and we do not sell personal data.

3. Release alerts

Release-alert registration is closed. The public product page does not ask for an email address, and the former submission endpoint returns a rejection. The InshiHub application does not read or store request content sent to that endpoint. InshiHub does not currently send release alerts or promise that a visitor will receive one.

Before collection was closed, the form stored the email address, product identifier, first landing path, referring host, form location, experiment variant, submission timestamps, and keyed one-way fingerprints of the email and network address. Those historical requests remain unverified, are not mailing consent, and will not be used to send messages. They are subject to the automatic deletion schedule below. A requester may ask for earlier erasure by emailing contact@fermion.company.

A future release-alert feature will remain closed until it has an approved email provider, a clear point-of-collection notice, an affirmative confirmation step controlled by the address owner, and a comparably easy withdrawal route. Introducing that feature will require a revised notice; a historical unverified request will not be converted into consent.

4. Direct contact and grievances

If a person contacts us or submits the grievance form, we process the sender's email address, name if supplied, category, subject, message, affected page, product selection, complaint reference, timestamps, status, deadlines, and our response history to answer the request and maintain a reliable complaint record. Product or payment complaints may also require an order or processor reference. Public browser roles have no direct table or grievance-function access. The site server can create a case only through a validated, rate-limited submission function.

Do not send a full card number, security code, password, one-time authentication code, or online-banking credential. Complaint records are retained under the support and grievance schedule described below.

To monitor operational failures, Fermion also derives a separate restricted operational-alert record from grievance-deadline fields and, if sales open, from normalised signed Dodo event records. It is used to identify overdue grievance acknowledgement or resolution, delayed or failed product delivery and licence revocation, open disputes, and a changed payload received under the same webhook identifier. The record contains only fixed alert and source categories, severity, due/open/resolve times, fixed lifecycle and resolution codes, and domain-separated SHA-256 identifiers derived from the source record and, when manual resolution is recorded, a SHA-256 review-reference value. It does not copy a name, email or address, grievance subject, message or response, billing data, raw provider identifier or payload, checkout metadata, or free-text notes.

A separate private operator-notification system checks for a new grievance, a current critical operational alert, or a missing, stale, or future-dated alert-detector heartbeat. Its records are limited to fixed notification, severity, action, result, and lifecycle codes; event, attempt, escalation, lease, delivery, acknowledgement, and recovery times and bounded counters; and domain-separated SHA-256 values for the source, notification, delivery-idempotency key, dispatch-run, claim and lease tokens, reviewed processor and transport host, dedicated worker proof and activation attestation, provider message and bound delivery receipt, responsible owner, acknowledging or recovering operator, and review evidence. It does not copy grievance content or customer identity, a raw provider identifier or payload, checkout metadata, a transport credential, a transport response body, or free-text notes. If the reviewed Resend transport is enabled, the email receives only the fixed taxonomy and action, event time, escalation level, and a non-reversible notification reference. The raw Resend message identifier is used transiently to create notification-bound delivery evidence and is not stored.

5. Proposed Dodo checkout and product-support processing

Purchases are unavailable. Dodo Payments merchant and product review, the exact transaction-seller entity, India-facing responsibility allocation, and the live payment-delivery-refund journey are not yet approved.If checkout later opens, the product page and Dodo checkout will identify the data actually required before it is collected. The proposed hosted checkout may collect a purchaser's name, email address, payment information, and complete billing address, including country, state or region, city, street, and ZIP or postal code. Fermion's session request keeps phone-number collection disabled, but permits Dodo to present an optional business Tax ID field, including an Indian GSTIN where applicable. Dodo may also collect a business name, validate a submitted Tax ID in real time, determine the purchaser's billing location and tax status, apply any exemption or reverse-charge rule that Dodo determines is applicable, and use those details to calculate and display tax and issue an invoice or receipt. Dodo processes those checkout, billing, Tax ID, and transaction details under its own notices; Fermion does not place them in its restricted local commerce ledger merely because Dodo collected them. Before creating a session, Fermion's server is designed to record only the following security, consent, and product-binding evidence:

• a random checkout-attempt identifier, product, offer, content-version and private-asset identifiers, price, currency, purchase-button location, and timestamp;
• the consent text version, affirmative responses, hashes identifying the exact consent fields and legal-document versions, and the applicable Terms, Privacy, Refund, and Delivery URLs;
• keyed one-way fingerprints of the request network address and browser user-agent for rate limiting and abuse investigation; and
• the Dodo checkout-session identifier, its expiry time, and a one-way hash of the hosted checkout URL.

After Dodo sends a signed transaction event, Fermion's server is designed to retain a restricted, normalised evidence record rather than the raw event body. Depending on the event, that record may include:

• Dodo business, product, brand, checkout, payment, refund, dispute, entitlement, grant, and file identifiers;
• event type and time, amount, currency, tax amount, transaction status, payment-method category, delivery status, and refund or dispute status;
• product version, delivered PDF filename, content type and size, consent responses, legal-document versions, and one-way event-body hashes; and
• delivery counts and the receipt times needed to identify duplicate or replayed signed events.

That normalised-only rule applies to the Production Mode checkout and webhook ledgers. A separate, normally disabled Dodo Test Mode endpoint may be enabled for one documented pre-release journey. It accepts only correctly signed Test Mode events bound to the configured test business, product, entitlement, file, amount, currency, and capture session. While that controlled capture is active, its isolated private store may hold up to seven original signed event bodies and signatures, their Test Mode provider identifiers and event times, and the associated body hashes. The seven roles are a successful primary test payment and delivery, successful refund, automatic refund revocation, then a separate test payment, delivery, and manual revocation. This store is not a Production Mode commerce ledger and cannot receive a Live Mode event. Testers are instructed to use synthetic details, but an original test body may contain identity or transaction details entered into the hosted Test Mode checkout.

An authorised operator may export exactly one complete, unexpired seven-receipt set to a newly created private directory solely to run the signed release-evidence check. That local export contains the original bodies and signatures and must be deleted immediately after the check. It is not a customer, support, analytics, or accounting dataset.

The Production Mode restricted checkout and webhook ledgers are not designed to store a purchaser's name, email address, billing or postal address, full card or bank details, authentication code, raw network address, raw user-agent, raw Dodo event body, hosted checkout URL, invoice document, or Dodo download URL. Such information may still be processed separately by Dodo under its notices. If a purchaser asks Fermion for support, the person may choose to provide an email address, Dodo reference, and limited technical evidence reasonably needed to investigate product delivery or a defect.

Fermion will use the restricted evidence it receives to validate the approved product and price, create checkout, prevent abuse, support delivery, administer the product licence, provide corrections, reconcile resale records, investigate fulfilment, refunds, disputes, and security events, and comply with applicable duties. Dodo independently determines the data needed to form and perform its resale contract, collect payment, issue invoices or receipts, prevent fraud, handle disputes and refunds, and meet its tax and legal duties. Payment credentials are submitted to Dodo or its payment providers, not Fermion.

Dodo may make additional purchaser information available through its dashboard or support channels. Fermion will not copy that information into its own product ledger unless it is necessary for a documented support, legal, security, or reconciliation purpose and this notice is updated where required.

6. Dodo Payments and other service providers

• Dodo Payments:the exact Dodo group entity that would act as transaction seller and independent controller has not been confirmed. Dodo's current public privacy notice says that several controller entities exist, but its Section U does not identify them. Subject to that confirmation, the identified entity is expected to process checkout, payment, invoicing or receipts, fraud prevention, disputes, refunds, indirect tax, customer-portal access, and transaction-level support. Checkout will remain disabled until the responsible entity and applicable notices are displayed consistently. Dodo's current privacy notice and Buyer Terms are linked here only as current generic public documents and do not establish the India transaction entity.
• Supabase: any historical release-alert records pending automatic deletion, grievance, content-version, private backup, restricted checkout-attempt, checkout-session, consent, and normalised signed-event records, restricted operational-alert lifecycle records, isolated short-lived Test Mode signed receipts, private operator-notification lifecycle and evidence records, and aggregate alert-refresh and alert-retention-audit records, together with notification scan, dispatch, health, and retention-audit records, in a project configured for the Mumbai region. Service-only alert read and health views and notification health views expose fixed fields, hashed source keys, timestamps, status, and aggregate counts needed to hold commerce when monitoring is unsafe. Direct public access to the restricted commerce, grievance, test evidence, alert, and notification ledgers is disabled.
• Vercel: site hosting, delivery, security, web analytics, performance measurement, and a private scheduled invocation of the operator-notification worker. The worker rejects an invocation without its dedicated project cron credential.
• Email and support providers: direct customer communications and operational support where a relevant provider is approved. No provider is configured to send release alerts.
• Operator-notification transport:Plus Five Five, Inc., operating as Resend, is approved through 26 October 2026 for the narrow fixed-template transport described above. If separately enabled after the remaining production-readiness checks, only Resend's fixed email API endpoint may receive the message, and it may deliver only to one reviewed corporate mailbox. Resend may process the sender and recipient addresses, limited subject and plain-text body, and normal connection, authentication, security, and service-usage information. Its Data Processing Addendum describes primary processing in the United States, authorised subprocessors, security duties, and deletion of customer data within 90 days after account termination, subject to the exceptions in that addendum. It does not promise a short fixed message-retention period while the account remains active, and Fermion does not assume that Resend's optional message-storage-off feature is enabled. The implementation requires an unexpired checked-in review, exact domain-separated matches for the configured sender and recipient, a dedicated domain-restricted sending key, disabled open and click tracking, and a successful controlled synthetic exercise before dispatch is enabled. Approval of the processor does not itself configure or activate the transport. The checked-in activation attestation is currently held: those operational prerequisites and synthetic lifecycle exercises are not recorded as completed, and dispatch remains disabled.
• Professional and public authorities: advisers, auditors, courts, regulators, law-enforcement bodies, and other recipients where disclosure is reasonably necessary or legally required.

Fermion-selected providers may process information in India, Japan, the United States, and other locations used by their approved infrastructure and subprocessors. Dodo's current privacy notice describes recipients, transfers, and safeguards in general, but does not currently name the controller entities promised in its Section U. The exact controller, final checkout data map, and transfer arrangements must be confirmed before sales open.

7. Retention

• Historical unverified release-alert requests are automatically deleted 30 days after their most recent submission or update. Associated keyed email and network fingerprints used in the submission rate-limit ledger are automatically deleted after 24 hours. These records are not used for email delivery, and a requester may ask for earlier erasure.
• Local storage remains until the visitor clears it. Session storage ordinarily ends when the browser session closes.
• Support and grievance records are retained while the matter is active and afterwards only for a reasonable period needed for follow-up, legal claims, audit, and compliance.
• If sales open, Dodo retains transaction data under its own privacy notice and legal duties. Fermion's keyed checkout network and user-agent fingerprints are erased 24 hours after collection, including where other evidence is temporarily preserved.
• An abandoned attempt for which no hosted checkout session was attached is deleted 30 days after its last database processing time. Session records and failed, cancelled, or still-processing payment evidence are deleted 180 days after the last processing time across their related attempt or payment group. A group containing a successful payment, delivery, refund, or dispute event is deleted one year after the last processing time across the related group.
• An original Dodo Test Mode signed receipt becomes unavailable for export 24 hours after it was first received. A guarded purge is scheduled every 15 minutes to remove expired receipt rows and two-hour capture rate windows. New receipt recording fails closed if the successful-purge heartbeat is missing, stale, or future-dated. Counts-only purge audits contain no webhook, customer, provider-resource, payload, or capture-session identifier. A local seven-receipt export is outside that database purge and must be deleted immediately after the signed evidence check.
• Operational-alert chains are separate from their source records. Deletion or expiry of a source record alone does not close an alert. An open chain is retained while the detected condition remains unresolved. A guarded daily process deletes a complete resolved chain only after every event in it is more than one year old. The separate refresh and purge audit records contain only execution times, fixed status, and aggregate counts and are not linked to an alert or source identifier.
• A private operator-notification chain is retained while it is pending, leased, waiting for retry or acknowledgement, exhausted, or under documented recovery. An exhausted episode is never silently treated as acknowledged. A guarded daily process may delete the complete linked chain only after its terminal notification has been acknowledged and every notification, attempt, acknowledgement, recovery, and related chain event is more than one year old. Counts-only purge audits are not linked to a notification or source identifier.
• A narrowly scoped legal, regulatory, fraud, or security hold may delay deletion only for an affected Production Mode checkout-attempt or signed-webhook chain. A hold record contains no buyer identity; it requires an allow-listed reason and legal basis, a non-personal review reference, and an expiry no more than 366 days after review. It may be released early and otherwise expires automatically. Any renewed hold requires a new review. This hold mechanism does not apply to operational-alert or private operator-notification chains; those remain governed by their preceding resolution, acknowledgement, recovery, and one-year rules.
• Separate from that operational ledger, Fermion may later preserve aggregate Dodo supplier invoices, payout statements, tax statements, and accounting exports in a restricted Japanese accounting archive. Its index contains no buyer identity and no checkout, session, payment, or webhook link. Its deletion-not-before date is ten years after the relevant accounting period closes. The operational purge never touches this index. The index alone does not mean that an archive exists: private object upload, content-hash verification, and buyer-unlinked review must be implemented and tested before it is used.

Information is deleted, aggregated, or de-identified when it is no longer needed, unless continued retention is required by law or needed to establish, exercise, or defend a legal claim.

These schedules apply to the live Dodo operational database only after the retention migration and daily job have been applied and verified. Before checkout opens, Fermion must document and test deletion behaviour for Supabase backups, point-in-time recovery, read replicas, and exports; identify an owner for cron-failure alerts; and evidence a successful scheduled run. A restored backup must run the retention process again before serving commerce traffic.

8. Choices and individual requests

Subject to applicable law, a person may ask for a summary of personal data processed about them, correction or updating of inaccurate data, erasure of data no longer required, erasure of a historical release-alert request, or review of a privacy grievance. A person may also nominate another person to exercise applicable data rights in circumstances recognised by law.

Purchases are currently unavailable, so no current buyer right is asserted for a Fermion Dodo order that does not yet exist. Current requests concern this public site, historical release-alert records, direct contact, or grievances. If sales later open, Fermion will handle requests for its restricted product and operational records, while Dodo will handle requests for personal data it independently controls as merchant of record.

Send the request from the relevant email address to contact@fermion.companyand describe a Fermion website, product, licence, correction, or support request. For Dodo checkout, payment, invoice, refund, fraud, or transaction data, use the privacy or buyer-support route in Dodo's checkout, receipt, customer portal, or privacy notice. Each party may ask for limited information needed to verify identity and prevent disclosure to the wrong person. Consent may be withdrawn as easily as it was given where processing depends on consent, without affecting processing already lawfully completed.

9. Children

The commercial service is intended for adults aged 18 or older. We do not knowingly direct behavioural advertising to children or ask a child to purchase. A parent or legal guardian should contact us before providing information for a person under 18. If we learn that a child's information was collected without any consent required by law, we will take appropriate steps to stop the processing and delete it.

10. Staged Indian data-protection framework

India's Digital Personal Data Protection Act and its 2025 Rules commence in stages. The official 13 November 2025 notifications bring the provisions identified for a one-year stage into force on 13 November 2026 and the identified core processing, notice, security, breach, rights, children, and related provisions into force on 13 May 2027.

Until a provision has commenced, a request facility or safeguard described in this notice is a Fermion policy or a commitment under another applicable law; it is not represented as a statutory DPDP right already in force. Current applicable privacy, consumer, cybersecurity, and contractual duties continue independently. Fermion is preparing the itemised notice, equally easy withdrawal, processor, security, breach, rights, nomination, and child-data controls required for the relevant future dates.

11. Security and incident response

We use access controls, restricted service credentials, encrypted network transport, private product storage, validation, logging, and provider security measures proportionate to the information and risk. No internet service can promise absolute security.

A suspected incident is investigated and contained, and affected people and competent authorities will be notified where and when applicable law requires. Security concerns may be reported to contact@fermion.company.

The CERT-In Directions and official FAQ can apply to a foreign body corporate or service provider serving users in India even without a physical Indian presence. Covered entities must designate a point of contact, report specified incidents within six hours of notice, maintain synchronised clocks, enable and retain relevant ICT logs for a rolling 180 days, and be able to produce them to CERT-In. The official FAQ permits logs to be stored outside India if they can be produced to CERT-In within a reasonable time; it separately requires covered financial-transaction logs and records to satisfy the stated Indian-jurisdiction requirement. The point of contact is not described here as an India-resident role.

Fermion has not yet represented that its Annexure II point-of-contact submission, six-hour operating procedure, or compliant log-coverage, retention, jurisdiction, and production architecture is in place. This review applies to the public India-targeted service and not only to a future checkout. It remains an unresolved current-site and commercial-release prerequisite.

12. Storage and analytics controls

A visitor can clear or block local and session storage in browser settings. Blocking storage may reduce attribution measurement but should not prevent access to public study content. This site does not currently use third-party advertising pixels or cross-site advertising profiles.

If a future feature requires non-essential cookies or another consent-based tracking technology, it will not be enabled until the required clear choice and withdrawal control are available.

13. Complaints and changes

Privacy complaints use the grievance redressal process. We will publish material changes with a revised effective date. A change that requires renewed consent will not be treated as accepted merely because a person continues browsing.