MMRF v1.0
中文

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.

sent
{
  "version": "MMRF-SQL-0.8",
  "operation": "interval_density",
  "shard_start": 0,
  "shard_count": 1,
  "rsa_modulus": "1000036000099"
}
returned
{
  "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…"
  }
}
cost: 0shards read: 0

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.