Acceptable Use Policy

This Acceptable Use Policy (the "AUP") applies to every person and organisation using the Onkydra service (the "Service"), whether via the web workspace, the API, an MCP server integration, or any other interface we offer. By using the Service you agree to this AUP and to the terms of service, the privacy policy, and the research-use-only scope.

The Service is for pre-clinical, in-silico research use: hypothesis generation, target prioritisation, and simulated co-mutation cohort analysis. All outputs are probabilistic and citation-backed; a qualified human must interpret them before any downstream scientific, clinical, or regulatory decision.

Acceptable uses include:

• Exploring competitive landscape for a candidate target class in a rare cancer indication.
• Prioritising which experiments to run before committing wet-lab budget.
• Drafting hypotheses for grant applications, fellowship submissions, and internal research planning.
• Teaching and academic training in cancer bioinformatics, translational research methodology, and multi-agent AI systems.
• Building on top of Onkydra outputs in your own research, subject to citation of the underlying public data sources and to the licence terms of the Service and its sub-processors.

You will not use the Service, and will not permit anyone acting on your behalf to use it, for any of the following:

1. Direct clinical decision-making. Outputs must not be used as the sole basis to diagnose, treat, cure, prevent, or monitor any disease in any identified patient. The Service is not a medical device within the meaning of Regulation (EU) 2017/745 (MDR) or Regulation (EU) 2017/746 (IVDR), and it is not authorised for such use in any jurisdiction.
2. Uploading patient-identifiable data. You will not upload, paste, or otherwise transmit to the Service any personal data identifying a natural patient, including names, addresses, hospital record numbers, insurance IDs, identifiable genome sequences, or any other data from which a natural person can reasonably be identified. The Service is not architected to process Article 9 special-category health data.
3. Bypassing sub-processor obligations.You will not attempt to reroute Onkydra's underlying model calls to third-party model endpoints that are not authorised sub-processors under our published register.
4. Training or fine-tuning third-party AI systems on our outputs. You will not use the Service or its outputs to train, fine-tune, distil, or benchmark a competing AI system, foundation model, or downstream service without prior written permission.
5. Reverse engineering, scraping, and abuse-of-service patterns.You will not attempt to extract the Service's internal system prompts, reverse engineer its agent architecture, scrape its output at rate exceeding your tier's rate limits, or use headless automation to circumvent per-user rate limits.
6. Misrepresentation. You will not present Onkydra outputs to third parties as if they were peer-reviewed clinical evidence, regulatory-grade submissions, or the opinion of a specific licensed medical practitioner. Every export the Service produces already carries the research-use-only banner and citations; you will not remove them.
7. Unlawful or harmful research. You will not use the Service to plan, execute, or accelerate research whose purpose is the development of weapons, deliberately harmful pathogens, surveillance of specific individuals, or any activity prohibited under the applicable law of your jurisdiction or of the Republic of Ireland.
8. Sharing account credentials.Each seat is for one named user. You will not share your workspace credentials, MCP tokens, or API keys with any other individual, including inside the same organisation. Foundation-sponsored seats are set up for named grantees under the sponsoring foundation's agreement, one workspace per named grantee.

Most of what you bring is text: the indication you select, the target you choose from the grounded list, the cohort-size setting, and the free-text query box that pre-fills those fields. That text, and the runs, cohorts and artefacts it produces, are stored in your workspace and retained as set out in the privacy policy.

Two endpoints take a file, and neither of them keeps it. The histology panel takes one image tile (its picker accepts PNG, JPEG and TIFF, up to 12 MB), forwards it to our own MedGemma service, and returns a description; the service reads the image in memory and writes it nowhere, and a whole-slide image is refused with the reason, because a diagnostic slide has to be tiled server-side before any of it reaches a model. The dataset check takes one file (.csv, .tsv, .txt, .md, .json or .mtx, up to 12 MB) as an assay matrix, a protocol, model metadata or an outcome, reports on its structure and quality, and discards the bytes. There is no customer file store to upload to. The only thing either endpoint can retain is one audit entry from the dataset check, recording counts, a content hash and the outcome, on a closed key list that no cell value can travel in.

Because nothing you send is stored, the prohibition in section 3 bites at submission rather than afterwards. You must not paste, type or submit patient-identifiable data of any kind, including names, hospital record numbers, insurance IDs, or identifiable sequence. A file sent to the dataset check is screened per cell and per header for structured identifiers, and a hit refuses the whole submission and tells you the row, the column and the header without repeating the value. That screen is not a guarantee, and three prohibited things have no detector at all: a person's name, a treating institution together with a date of care, and initials used with a date. Keeping those out is your obligation and not something we can catch for you. Published, de-identified summary statistics from public repositories are fine to reference in your prompt text. If a future release stores what you send, this section will be updated before that capability ships, and it will still exclude patient-identifiable data. If you are unsure whether something is safe to include, email hello@onkydra.com before you send it.

Each subscription tier has a documented per-user daily run limit: five runs a day on the academic lab and the commercial seat, and fifteen on the commercial team. It is a ceiling on spend rather than a price basis: nothing is sold by the run. The Service also enforces a hard cap of 500,000 tokens per run, and a run that crosses it is stopped and recorded as failed rather than allowed to continue. Attempting to circumvent these limits by rotating accounts, using headless browsers to parallelise interactive workflows, or otherwise abusing the platform is grounds for immediate suspension.

Genuine bursts (a paper deadline, a grant application, a board meeting) are fine. Email us before the burst if you need a temporary increase and we will handle it manually.

If you become aware of a violation of this AUP, including your own accidental violation, please report it to hello@onkydra.com. We treat reports confidentially and do not retaliate against good-faith reporters.

We investigate every credible report of a violation. Depending on the severity and repetition of the conduct, enforcement can include:

• Written notice and a request to remediate.
• Temporary suspension of the offending workspace while the investigation is open.
• Termination of the subscription without pro-rata refund for wilful, repeated, or unlawful violations.
• In cases involving potential harm to natural persons, referral to the appropriate supervisory authority (in Ireland, the Data Protection Commission).

We share aggregate enforcement statistics with Team subscribers and engagement clients on request, subject to protecting the anonymity of individual reporters.

We may update this AUP from time to time to reflect new capabilities, new data sources, or new abuse patterns. Material changes are notified to the email address on your account at least fourteen (14) days before they take effect and are recorded in the version stamp at the top of this page. Continued use after the effective date constitutes acceptance.