Safety
The boundary is the architecture, not a disclaimer.
A prime dataset invites one obvious misuse. MMRF's answer is not a terms-of-use paragraph; it is a guard that runs before the data layer and refuses seventeen field names outright.
What MMRF is
- A public dataset of mathematical properties of primes in a fixed range.
- An aggregate query surface: densities, quantiles, histograms, counts.
- A governance and provenance record for how that dataset came to exist.
What it will not do
- Accept an externally supplied integer of any kind, including an RSA modulus.
- Return a factor, a factor candidate, or a set of candidates.
- Narrow a search range, or answer a question whose value lies in narrowing one.
- Return a nearest prime, an exact prime list, or raw prime records.
- Store or publish a relation between a composite and its factors.
- Expose controlled datasets. They do not reach this site by any path.
Endpoints that will never exist
- POST /factor
- POST /rsa
- POST /nearest-prime
- POST /candidate-range
- POST /target-query
- POST /raw-primes
- POST /source-factor
How the refusal actually works
The guard evaluates a request before the data layer is touched. A forbidden field name causes a denial with the field named in the reason, a cost of cost_units: 0, and a normalized_request of null — the request is never normalised, so there is nothing downstream to execute.
{
"version": "MMRF-SQL-0.8",
"operation": "interval_density",
"shard_start": 0,
"shard_count": 1,
"rsa_modulus": "1000036000099"
}{
"status": "DENIED",
"decision": {
"allowed": false,
"decision": "DENY",
"reasons": [
"target_conditioned_or_factor_related_field_forbidden",
"forbidden_field:rsa_modulus"
],
"cost_units": 0,
"normalized_request": null
},
"audit": {
"event_id": "lake-query:ed5a56ba-…",
"event_hash_sha256": "1d60abd3c37dbb0d…"
}
}The denial still produces an audit event with its own hash. Refusals are recorded, not silently dropped, which is what makes a pattern of attempted misuse visible rather than invisible.
The composition rule
Individual aggregate answers are safe; a long series of carefully chosen ones is the thing to watch. So the surface is bounded in three ways at once: a fixed operation allowlist, a per-session query budget, and a cap on how many shards one query may touch. Researchers are additionally asked not to reconstruct a forbidden output by composing permitted ones.
That last one is a request, not an enforcement, and it is stated as a request deliberately. A policy that claims to enforce what it cannot is worse than one that is honest about where the mechanism ends.
Reporting
If you find a way to obtain a forbidden output from permitted operations, that is a defect in this design and worth reporting through the runtime repository. Please describe the composition rather than publishing a working sequence.